MLA-C01 Domínio: Preparação de Dados para ML (28% do exame)

Resumo de estudo de preparação de dados para a MLA-C01: ingestão e armazenamento com S3, Glue e Feature Store, engenharia de features e rotulagem com Ground Truth.

Por Leonardo Chiarelli · Atualizado em 21/06/2026 · 1 min de leitura

Preparação de Dados para ML: o maior domínio da MLA-C01

O domínio Preparação de Dados para ML vale 28% da prova MLA-C01, a maior fatia individual do exame. Isso significa que aproximadamente 18 das 65 questões virão desse domínio. Candidatos que subestimam a profundidade técnica aqui pagam caro no score final: a prova cobra cenários reais de pipeline de dados, não apenas vocabulário.

A MLA-C01 (AWS Certified Machine Learning Engineer Associate) tem 65 questões, 130 minutos de prova e nota de corte 720 de 1000. O estilo é predominantemente cenário-based: o enunciado descreve um problema de engenharia de ML e você precisa escolher a solução mais adequada entre quatro alternativas plausíveis.

Este guia cobre os quatro subtopics do domínio em profundidade, com foco nos serviços AWS envolvidos, nos trade-offs que a prova cobra e nas pegadinhas mais comuns.

Subtopic 1: Ingestão e armazenamento (S3, Glue, Feature Store)

Amazon S3 como camada base

O S3 é o ponto de entrada de praticamente todo pipeline de dados para ML na AWS. A prova pressupõe que você conhece as camadas de uma arquitetura de lake:

Raw layer (bronze): dados brutos exatamente como chegaram da fonte. Sem transformação.
Processed layer (silver): dados limpos e normalizados, prontos para feature engineering.
Curated layer (gold): features prontas para treinamento ou servir ao modelo.

A organização por partição (ano/mês/dia, ou por certSlug/domainId) afeta diretamente a performance de queries no Athena e no Glue. A prova cobra quando usar particionamento e qual estratégia reduz scan de dados.

Formatos de arquivo importam na MLA-C01. O Parquet é o formato padrão para dados tabulares em ML: colunar, comprimido, compatível com Glue e Athena, lido diretamente pelo SageMaker. O CSV só aparece em etapas de ingestão inicial ou para dados pequenos.

AWS Glue para ETL e catalogação

O AWS Glue cumpre dois papéis distintos que a prova explora separadamente:

Glue Data Catalog: repositório central de metadados. Define bancos de dados e tabelas sobre dados no S3, tornando-os consultáveis via Athena ou SageMaker. Um Glue Crawler varre o S3 e infere schema automaticamente. A prova cobra o fluxo: Crawler descobre schema → Catalog armazena → Athena consulta.

Glue ETL jobs: scripts Apache Spark gerenciados que transformam dados em escala. Você escreve em PySpark ou Scala, ou usa os visual transforms do Glue Studio. São serverless: você não provisiona cluster. Para volumes menores, o Glue tem o modo DPU adaptativo que ajusta capacidade automaticamente.

Quando a prova diz "precisa transformar terabytes de dados CSV em Parquet e particionar por data, sem gerenciar servidores," a resposta é Glue ETL job. Quando diz "precisa catalogar os dados do S3 para consulta via Athena," a resposta é Glue Data Catalog com Crawler.

Glue DataBrew é o item que mais confunde candidatos. É uma ferramenta visual de preparação de dados, sem código, voltada para analistas que não escrevem PySpark. Em cenário onde "o time de dados não tem engenheiros de dados e precisa normalizar colunas sem código," DataBrew é a resposta, não o Glue ETL tradicional.

SageMaker Feature Store

O Feature Store resolve um problema específico: reutilização e consistência de features entre treinamento e inferência. Sem ele, é comum o chamado training-serving skew: a feature calculada no treino difere da calculada em produção porque o código divergiu.

Arquitetura do Feature Store:

Online store: armazenamento gerenciado de baixa latência (milissegundos) para servir features em inferência real-time. Oferece o tier Standard (padrão) e um tier InMemory para latências ainda menores.
Offline store: armazenamento em S3 no formato Parquet para treinamento. Consultável via Athena.

O Feature Store suporta time travel: você pode consultar features com o valor que tinham em um timestamp específico, o que permite reconstruir datasets de treino historicamente corretos (fundamental para evitar data leakage temporal).

A prova gosta de testar o conceito de feature group: coleção de features com schema definido e versionado. Um feature group pode alimentar tanto o online quanto o offline store simultaneamente.

Pegadinha clássica: o candidato confunde o Feature Store com um substituto do S3. Não é. O Feature Store usa S3 como offline store internamente, mas adiciona controle de schema, versionamento, time travel e a separação online/offline. Use Feature Store quando há necessidade de reutilização de features entre projetos, consistência treino-serviço ou acesso real-time a features. Use S3 diretamente quando está apenas armazenando datasets brutos ou intermediários.

Subtopic 2: Transformação e engenharia de features

O que a prova cobra em feature engineering

A MLA-C01 não é uma prova de ciência de dados clássica. Ela não cobra qual transformação matemática é teoricamente ótima. Ela cobra qual serviço AWS implementa a transformação de forma escalável e gerenciada.

As transformações mais cobradas são:

Normalização e padronização: feature scaling. Standard Scaler (z-score) ou Min-Max. Implementado via SageMaker Processing Jobs com sklearn, ou via Glue ETL.

Encoding de variáveis categóricas: One-Hot Encoding para categorias nominais, Label Encoding para ordinais. Implementado em SageMaker Processing ou diretamente no training script.

Tratamento de missing values: imputação por média/mediana/moda (para dados numéricos/categóricos) ou remoção de rows. Glue DataBrew tem transforms visuais para isso; SageMaker Data Wrangler também.

Feature creation: combinação de features existentes, extração de componentes de data/hora, bucketing numérico. Feito em Glue ETL ou SageMaker Processing.

SageMaker Processing Jobs

Os Processing Jobs são a forma padrão de executar transformações em escala no SageMaker. Você define um container (sklearn, Spark, ou custom), especifica o input no S3 e o output volta para o S3. O SageMaker provisiona e destrói o cluster automaticamente.

O SageMaker Data Wrangler (parte do SageMaker Studio) oferece uma interface visual para explorar e transformar dados. Você conecta ao S3, Redshift, Athena ou outros sources, aplica transforms com preview imediato e exporta o fluxo como Processing Job ou script Python. A prova cobra Data Wrangler quando o cenário envolve "análise exploratória visual" ou "engenheiro que quer iterar rapidamente em transformações sem escrever tudo do zero."

Quando usar cada serviço

| Necessidade | Serviço | |---|---| | ETL em escala, Spark, serverless | AWS Glue ETL | | Transformação sem código, visual | Glue DataBrew ou SageMaker Data Wrangler | | Transformação como parte do pipeline de ML | SageMaker Processing Job | | Consistência treino-serviço de features | SageMaker Feature Store |

Subtopic 3: Integridade, balanceamento e splitting

Qualidade de dados: o que a prova testa

A prova assume que datasets do mundo real têm problemas. Ela cobra como detectar e tratar cada tipo:

Dados faltantes (missing values): o SageMaker Data Wrangler detecta automaticamente a percentagem de valores nulos por coluna e sugere estratégias. Para datasets grandes, o Glue DataBrew tem receitas de imputação. A decisão de remover a coluna inteira (quando missing rate > 50-70%) versus imputar é um trade-off de engenharia que a prova pode cobrar em cenário.

Outliers: valores fora do intervalo esperado. Técnicas comuns incluem clamping (substituir por percentil 1/99), z-score threshold, ou IQR. Implementados em Processing Jobs.

Data leakage: o modelo usa no treino informação que não estará disponível em produção. É o erro mais grave e mais cobrado da prova. Cenário típico: "a feature aprovado foi calculada depois do evento que você quer predizer." A resposta sempre é: remover a feature ou recalcular com time travel no Feature Store.

Class imbalance

Desbalanceamento de classes é um dos tópicos mais testados do domínio. Se 98% dos exemplos são negativos e 2% positivos, um modelo que sempre prevê negativo tem 98% de acurácia mas é inútil.

A prova cobra três abordagens:

Oversampling da classe minoritária: SMOTE (Synthetic Minority Oversampling Technique) gera exemplos sintéticos da classe minoritária. Implementado via imbalanced-learn em um Processing Job.

Undersampling da classe majoritária: remove exemplos aleatórios da classe majoritária. Cuidado: perde informação.

Class weights: ajustar class_weight no algoritmo de treino para penalizar mais os erros na classe minoritária. Implementado diretamente no SageMaker Estimator, sem mudar o dataset.

Pegadinha clássica: a prova pode apresentar oversampling e undersampling como se fossem intercambiáveis. Prefira oversampling (especialmente SMOTE) quando o dataset não é absurdamente grande e preservar informação importa. Class weights costumam ser a solução mais simples e menos propensa a overfitting.

O SageMaker Clarify tem funcionalidade de bias detection que mede desbalanceamento antes do treino. A prova pode cobrar Clarify nesse contexto: "detectar viés nos dados de treino antes de iniciar o training job."

Train/validation/test splitting

A divisão correta do dataset é mais sutil do que parece. A prova cobra os cenários onde a divisão aleatória simples falha:

Dados temporais: séries temporais nunca devem ser divididas aleatoriamente. A divisão correta é cronológica: treino nos eventos mais antigos, validação nos intermediários, teste nos mais recentes. Divisão aleatória vaza informação futura para o treino (data leakage temporal).

Dados com grupos: se há múltiplos registros do mesmo usuário, uma divisão aleatória pode colocar o mesmo usuário em treino e teste, inflando as métricas. A divisão correta é por grupo (Group K-Fold), garantindo que todos os registros de um usuário ficam no mesmo split.

Proporções típicas: 70/15/15 ou 80/10/10 para treino/validação/teste. Em datasets pequenos, K-Fold Cross Validation substitui o validation set fixo.

O SageMaker tem integração com essas estratégias via Canal de dados: você pode definir TrainingInput com S3 prefixes separados para treino e validação, e o SageMaker passa como channels distintos para o container de treino.

Subtopic 4: Rotulagem com SageMaker Ground Truth

O que é e quando usar

O SageMaker Ground Truth é o serviço da AWS para criar datasets rotulados por humanos (ou automaticamente) em escala. A prova cobra Ground Truth especificamente em cenários onde você tem dados não rotulados e precisa criar ground truth labels.

Casos de uso típicos: classificação de imagens, detecção de objetos, transcrição de áudio, classificação de texto, análise de sentimento. Qualquer tarefa que exija julgamento humano para criar o rótulo.

Workforce options

O Ground Truth oferece três opções de força de trabalho, e a escolha entre elas é cobrada em questão de cenário:

Amazon Mechanical Turk: pool de anotadores públicos (crowdsourcing). Barato, escala rapidamente, mas não adequado para dados sensíveis ou que exigem expertise de domínio.

Vendor-managed (AWS Marketplace): empresas parceiras certificadas pela AWS que fornecem equipes de anotação profissional. Para dados que exigem qualidade superior ao Mechanical Turk.

Private workforce: sua própria equipe de funcionários ou especialistas, acessando via portal do Ground Truth. Obrigatório para dados confidenciais (HIPAA, dados financeiros, dados de clientes internos).

Pegadinha clássica: candidatos confundem "privacidade" com "qualidade". A force de trabalho privada não é necessariamente mais precisa que os vendors, mas é a única opção quando confidencialidade dos dados é requisito.

Automated data labeling

O Ground Truth tem uma funcionalidade de automated labeling que reduz custo: para tasks de imagem ou texto, um modelo é treinado progressivamente com os rótulos humanos e começa a rotular automaticamente exemplos com alta confiança. Apenas os exemplos de baixa confiança vão para revisão humana.

A prova pode apresentar isso como "Active Learning" ou "ML-assisted labeling." O ponto importante é que você reduz o volume de anotação humana (e o custo) sem abrir mão da qualidade nos exemplos difíceis.

Ground Truth Plus e Label Geração com IA

O SageMaker Ground Truth Plus é uma oferta gerenciada onde a AWS cuida do recrutamento e gerenciamento da força de trabalho. Você fornece os dados e os critérios de qualidade; a AWS entrega os rótulos. Útil quando você não quer operar o fluxo de anotação.

O Amazon Bedrock pode ser usado para gerar rótulos de texto automaticamente (via LLM) em cenários onde o julgamento humano não é obrigatório e a task é bem definida. A prova pode cobrar isso como alternativa ao Ground Truth para tasks de NLP simples.

Pegadinhas gerais do domínio

S3 vs Feature Store: S3 é armazenamento genérico; Feature Store adiciona consistência treino-serviço, time travel e baixa latência para inferência. Se o cenário menciona "mesmas features em treino e em produção sem discrepância," a resposta é Feature Store.

Glue vs SageMaker Processing: Glue ETL é para pipelines de dados gerais, incluindo ingestão, transformação e carga em data lakes. SageMaker Processing é para transformações específicas de ML integradas ao pipeline de treinamento. Na prática se sobrepõem, mas a prova tende a usar Glue para cenários de "preparação de dados em escala antes de qualquer ML" e SageMaker Processing para "transformação como etapa de um pipeline SageMaker Pipelines."

Splitting temporal: qualquer cenário com dados de série temporal deve disparar o alerta de "não divida aleatoriamente." Divisão cronológica é sempre a resposta correta para séries temporais.

Data leakage: se o enunciado descreve métricas de treino excelentes mas performance ruim em produção, suspeite de leakage. A feature que "sabe o futuro" ou a divisão aleatória em séries temporais são as causas mais cobradas.

Automated labeling não é sinônimo de Ground Truth Plus: automated labeling é a funcionalidade de ML-assisted annotation dentro do Ground Truth padrão. Ground Truth Plus é a oferta de workforce gerenciado.

Como esse domínio cai na prova

O padrão típico de questão do Domínio 1 é: "uma empresa tem X problema de dados e precisa resolvê-lo com o mínimo de overhead operacional." As palavras-chave que direcionam a resposta:

"sem gerenciar servidores" + ETL em Spark: Glue ETL serverless
"visual, sem código": DataBrew ou Data Wrangler
"consistência entre treino e produção": Feature Store
"confidencialidade obrigatória" + rotulagem: Ground Truth com private workforce
"série temporal" + divisão de dataset: divisão cronológica, nunca aleatória
"classe desbalanceada" + "não alterar o dataset": class weights no estimator
"detectar viés nos dados de treino": SageMaker Clarify

Com 28% do peso, dedicar uma parcela proporcional do tempo de estudo a esse domínio é obrigatório. Foque nos serviços (S3, Glue, Feature Store, Ground Truth, SageMaker Processing, Data Wrangler, Clarify) e nos trade-offs de cenário, não apenas nos nomes.

Pronto para praticar?

Questões de cenário MLA-C01 em PT-BR, com flashcards dos serviços que mais caem nesse domínio. 7 dias grátis.

Conhecer o CertAI

Preparar para a certificação (trial grátis)