MLA-C01 Domínio: Monitoramento, Manutenção e Segurança (24% do exame)

Resumo de estudo de monitoramento para a MLA-C01: Model Monitor, drift, custo, segurança com IAM e VPC, e auditoria com CloudWatch.

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

O que é o domínio Monitoramento, Manutenção e Segurança na MLA-C01?

O domínio Monitoramento, Manutenção e Segurança representa 24% da MLA-C01 (AWS Certified Machine Learning Engineer Associate), ou seja, aproximadamente 15 a 16 das 65 questões da prova. É o domínio que cobre o que acontece com o modelo depois do deploy: como detectar que ele está degradando, como reduzir custos de infraestrutura de ML, como proteger dados e workloads, e como manter visibilidade operacional com logs e métricas.

A MLA-C01 tem 65 questões, duração de 130 minutos e nota de corte 720 (em uma escala de 100 a 1000). O custo oficial é USD 150. A prova é nível Associate, ou seja, espera cenários realistas, não apenas definições. Neste domínio especificamente, as questões costumam apresentar uma situação operacional (modelo em drift, custo alto, acesso não autorizado a dados de treino) e pedir a ação ou serviço correto.

Este guia cobre os quatro subtopics do domínio: Model Monitor e drift, Custo e otimização de recursos, Segurança, IAM e VPC para ML e Logging e auditoria com CloudWatch.

Model Monitor e drift

Por que modelos degradam em produção

Um modelo treinado em dados históricos reflete os padrões do passado. Quando o mundo muda (comportamento do usuário, sazonalidade, mudanças de negócio), os dados de entrada em produção divergem dos dados de treino. Essa divergência é chamada de drift e é a causa número um de degradação silenciosa de modelos.

A prova cobra dois tipos de drift:

Data drift (covariante drift): as features de entrada mudam de distribuição. O modelo recebe dados que nunca viu durante o treino. Exemplo: um modelo de fraude treinado em 2023 começa a ver padrões de pagamento de 2025.
Concept drift: a relação entre as features e o target muda. O mesmo perfil de usuário que antes indicava risco agora não indica mais. O modelo pode receber dados com distribuição parecida, mas estar errado nas previsões.

Drift de label (quando você consegue comparar previsão com resultado real com delay) também existe, mas é menos frequente nas questões da MLA-C01.

Amazon SageMaker Model Monitor

O SageMaker Model Monitor é o serviço central deste subtopic. Ele monitora endpoints de inferência em tempo real e detecta desvios automaticamente, comparando os dados de produção com uma baseline gerada a partir dos dados de treino.

Fluxo operacional que a prova cobra:

Você gera a baseline a partir do dataset de treino (usando o job CreateDataQualityJobDefinition ou via console/SDK). A baseline calcula estatísticas e restrições de cada feature.
O Model Monitor executa jobs de monitoramento em schedule (por exemplo, a cada hora), capturando amostras de inferência armazenadas no S3 via Data Capture.
O job compara a distribuição atual com a baseline e gera um relatório de violações.
As violações disparam alarmes no CloudWatch, que podem acionar SNS, Lambda ou SageMaker Pipelines para retraining automático.

Quatro tipos de monitoramento suportados:

Data Quality Monitor: monitora distribuição de features (drift covariante).
Model Quality Monitor: monitora métricas de acurácia comparando previsão com ground truth (quando o label real chega com delay).
Bias Monitor: detecta viés emergente em produção (usa SageMaker Clarify internamente).
Explainability Monitor: monitora importância de features ao longo do tempo (também via SageMaker Clarify).

Pegadinhas comuns na prova:

O Model Monitor requer que o endpoint tenha Data Capture habilitado (não é o default). Questões que descrevem que o monitoramento não está capturando dados geralmente têm a resposta "habilitar Data Capture no endpoint".
A baseline precisa ser gerada antes de configurar o monitor. Sem baseline, o job não sabe contra o que comparar.
O Model Monitor não detecta drift em batch transforms automaticamente, apenas em endpoints real-time (embora Batch Transform Monitoring exista via configuração manual).

Estratégias de resposta ao drift

A prova também cobra o que fazer quando drift é detectado:

Retraining com dados mais recentes via SageMaker Pipelines automatizado.
Rollback para versão anterior do modelo via SageMaker Model Registry (o registro mantém versões com status Approved/Rejected).
Shadow deployment: enviar tráfego para o modelo antigo e novo em paralelo, comparar outputs antes de promover o novo.
Canary deployment: liberar o novo modelo para uma fração pequena do tráfego (5-10%) e aumentar gradualmente se as métricas estiverem dentro do esperado.

Custo e otimização de recursos

Onde o dinheiro vai em workloads de ML

Workloads de ML na AWS têm três grandes centros de custo: treinamento, inferência e armazenamento/dados. A prova cobra otimização nos três, mas com foco especial em inferência (onde o custo é recorrente e difícil de prever).

Otimização de instâncias de treinamento

Spot Instances para treinamento: SageMaker suporta Managed Spot Training nativamente. O treinamento pode ser interrompido e retomado de um checkpoint. Economiza até 70-90% comparado com instâncias On-Demand. A prova frequentemente apresenta cenários onde o treinamento não é urgente e pergunta qual opção reduz custo: resposta é Spot com checkpoint habilitado.
Escolha de instância certa: instâncias de GPU (p3, p4d, g4dn, g5) são caras e fazem sentido para deep learning. XGBoost e modelos tabulares simples rodam bem em instâncias CPU (m5, c5). Questões sobre "right-sizing" geralmente cobram essa distinção.
SageMaker Experiments: registra runs de treinamento, hiperparâmetros e métricas. Ajuda a evitar re-executar experimentos já feitos, o que reduz custo indiretamente.

Otimização de inferência

Multi-Model Endpoints: permitem hospedar centenas de modelos em um único endpoint, carregando modelos sob demanda na memória e descarregando quando não usados. Ideal para SaaS onde cada cliente tem um modelo personalizado, mas nenhum deles tem tráfego constante.
Serverless Inference: endpoint serverless escala para zero quando não há tráfego. Paga apenas pelo tempo de processamento, sem custo fixo de instância idle. Adequado para modelos que recebem tráfego esporádico. A desvantagem é latência de cold start (questões sobre latência consistente = não usar serverless).
Inferência Assíncrona: para payloads grandes ou processamento que tolera delay. O cliente envia a requisição, a resposta fica no S3 quando pronta. Barato porque a instância escala para zero entre jobs.
SageMaker Savings Plans: comprometimento de uso de compute (similar a EC2 Savings Plans), com desconto de até 64% sobre On-Demand. Faz sentido para endpoints com tráfego previsível e constante.
Compilação de modelos com SageMaker Neo: compila o modelo para o hardware alvo (CPU, GPU, edge), reduzindo latência de inferência e consumo de compute. Um modelo compilado pelo Neo pode rodar em uma instância menor sem perda de performance.

Otimização de armazenamento e dados

S3 Lifecycle Policies: mover datasets de treino para S3 Infrequent Access ou Glacier quando o projeto de ML encerra. Dados raramente reutilizados em storage Standard são custo desnecessário.
SageMaker Feature Store: armazenar features computadas uma vez e reutilizar em múltiplos modelos evita recomputação. Feature Store tem store online (baixa latência, para inferência) e offline (S3, para treinamento). Entender quando usar cada um é recorrente na prova.
Compressão de dados: usar Parquet ou ORC em vez de CSV para datasets de treino reduz I/O e tempo de job de processamento no Glue ou no SageMaker Processing.

Segurança, IAM e VPC para ML

Modelo de responsabilidade compartilhada em ML

Em workloads de ML, a responsabilidade compartilhada se aplica da mesma forma que no resto da AWS: a AWS protege a infraestrutura subjacente do SageMaker; você protege os dados, as permissões, o acesso aos endpoints e a segurança das instâncias de treinamento.

A prova MLA-C01 cobra quatro camadas de segurança em ML: controle de acesso (IAM), isolamento de rede (VPC), criptografia de dados e auditoria de ações.

IAM para ML

Execution Roles: cada job de SageMaker (treinamento, processamento, endpoint) assume uma IAM Role, não usa credenciais diretas. A role tem as permissões mínimas necessárias (acesso ao S3 de dados, ao ECR para imagem do container, ao CloudWatch Logs para output).
Princípio do menor privilégio: questões sobre "uma role de treinamento não deveria ter acesso a dados de produção" testam se você entende que cada stage de ML (prep de dados, treino, inferência) deve ter roles separadas com scopes distintos.
Políticas baseadas em recursos: buckets S3 com dados sensíveis de treino devem ter bucket policies que restringem acesso apenas às roles de treino, negando acesso a tudo mais (incluindo o root account se necessário).
SageMaker Studio e IAM Identity Center: Studio usa profiles isolados por usuário. Em ambientes corporativos, integrações com IAM Identity Center (sucessor do SSO) permitem federação de usuários de ML.

VPC e isolamento de rede

Por padrão, jobs de treinamento e endpoints do SageMaker rodam em uma VPC gerenciada pela AWS, separada da sua VPC. Isso significa que:

Tráfego entre o container de treinamento e o S3 passa pela internet pública da AWS (mas dentro da rede AWS).
Você não tem controle sobre esse isolamento.

Para workloads que exigem isolamento completo:

VPC Mode: configure o job de treinamento ou o endpoint para rodar dentro da sua VPC, em subnets privadas específicas. Isso exige que a VPC tenha os SGs e NACLs corretos para que o container consiga acessar o S3 e outros serviços.
VPC Endpoints (PrivateLink): para que o tráfego entre a VPC do SageMaker e os serviços AWS (S3, ECR, CloudWatch, SageMaker API) nunca saia para a internet, crie Interface Endpoints ou Gateway Endpoints. Questões sobre compliance que exigem "sem tráfego pela internet" geralmente têm PrivateLink como resposta.
Network Isolation: parâmetro que desabilita completamente o acesso à internet do container de treinamento. O modelo não pode fazer nenhum download externo. Adequado para ambientes financeiros ou de saúde com requisitos rigorosos.

Pegadinhas comuns:

VPC Mode sem VPC Endpoint para S3 faz o tráfego S3 sair pela internet. A resposta correta nesses cenários é adicionar um Gateway Endpoint para S3 na route table da subnet privada.
Network Isolation e inter-container traffic encryption são configurações separadas. Desabilitar um não implica o outro.

Criptografia de dados

Criptografia em repouso: dados de treino no S3 com SSE-S3, SSE-KMS ou CSE. Volumes EBS das instâncias de treinamento cifrados com KMS. SageMaker suporta especificar uma KMS Key em todos os jobs.
Criptografia em trânsito: TLS para tráfego entre containers em treinamento distribuído (inter-container traffic encryption). Deve ser habilitada explicitamente em configurações de treinamento distribuído.
Amazon Macie: detecta dados sensíveis (PII, dados financeiros) nos buckets S3 usados para ML. Questões sobre descoberta de dados sensíveis em buckets de dataset geralmente têm Macie como resposta.
AWS Secrets Manager: armazenar credenciais de acesso a fontes de dados externas (banco de dados, APIs) que alimentam pipelines de ML. Nunca hardcodar credenciais no código de treinamento.

Logging e auditoria com CloudWatch

Por que logs são críticos em ML

Em ML, logs servem para três finalidades distintas: debugging de jobs (por que o treinamento falhou?), monitoramento operacional (o endpoint está saudável?) e auditoria de compliance (quem acessou os dados de treino?). A prova cobra os três.

CloudWatch Logs para jobs SageMaker

Jobs de treinamento, processamento e inferência publicam stdout e stderr automaticamente no CloudWatch Logs, no grupo /aws/sagemaker/TrainingJobs.
Log Insights: para analisar logs estruturados e buscar padrões de erro entre múltiplos runs de treinamento. Questões sobre "identificar por que 30% dos jobs de treinamento falharam" geralmente cobram Log Insights como ferramenta de análise.
Endpoints publicam métricas de latência e throughput automaticamente no CloudWatch Metrics (namespace AWS/SageMaker).

CloudWatch Metrics e Alarmes

Métricas importantes que a prova cobra:

Invocations, InvocationErrors, ModelLatency, OverheadLatency: métricas nativas de endpoint. Altas taxas de InvocationErrors indicam problema no modelo ou no payload.
CPUUtilization, MemoryUtilization, GPUUtilization: para detectar se a instância do endpoint está subdimensionada (uso constante acima de 80%) ou superdimensionada (uso abaixo de 20%, candidato a downsize).
Alarmes com Auto Scaling: use métricas como SageMakerVariantInvocationsPerInstance para acionar Application Auto Scaling em endpoints. Quando as invocações por instância ultrapassam um threshold, novas instâncias sobem automaticamente.

CloudTrail para auditoria de ML

CloudTrail registra todas as chamadas de API do SageMaker: quem criou o job de treinamento, quem deletou um modelo do Model Registry, quem mudou as permissões de um endpoint.
Em compliance (LGPD, HIPAA, PCI DSS), CloudTrail é o recurso que prova que o acesso a dados de ML foi controlado e auditável.
CloudTrail Insights: detecta atividade anômala de API. Exemplo: um pico de chamadas DescribeTrainingJob pode indicar varredura não autorizada.
Questões sobre "como demonstrar para auditores que apenas roles autorizadas acessaram o dataset de treino": CloudTrail + S3 Access Logs.

Amazon EventBridge para automação operacional

EventBridge escuta eventos do SageMaker (job concluído, job falhou, drift detectado pelo Model Monitor) e roteia para targets (Lambda, SNS, SageMaker Pipelines para retraining).
É a cola operacional entre monitoramento e resposta automatizada. Fluxo típico: Model Monitor detecta drift → publica violação no CloudWatch → alarme aciona EventBridge rule → Lambda inicia pipeline de retraining.

Pegadinhas gerais do domínio

Model Monitor vs CloudWatch: CloudWatch monitora infraestrutura (latência, CPU, erros de endpoint). Model Monitor monitora a qualidade do modelo (drift de dados, drift de métricas). A prova diferencia os dois cenários. Se o enunciado fala em "distribuição de features mudando", é Model Monitor. Se fala em "endpoint com alta latência", é CloudWatch.
Serverless Inference vs Inferência Assíncrona: serverless escala para zero e é para payloads pequenos com latência aceitável. Assíncrona é para payloads grandes (até 1 GB) e onde o cliente não precisa da resposta imediata. São escolhas diferentes para casos diferentes.
VPC Mode não implica PrivateLink: os dois precisam ser configurados separadamente. VPC Mode coloca o container na sua VPC; PrivateLink define como o tráfego para serviços AWS (S3, ECR) é roteado dentro dessa VPC.
Data Capture é requisito do Model Monitor: candidatos que estudaram SageMaker mas nunca configuraram monitoramento erram esse ponto com frequência.
Spot Training requer checkpoint: se o treinamento for interrompido sem checkpoint, começa do zero na retomada. A pergunta sobre "Spot Training com Managed Spot Training habilitado mas jobs sempre recomeçam do zero" tem como resposta "configurar checkpointing no código de treino e no parâmetro CheckpointConfig".

O que estudar neste domínio

Como configurar um job de monitoramento do SageMaker Model Monitor do início ao fim (baseline, Data Capture, schedule, alarm).
Os quatro tipos de monitoring (Data Quality, Model Quality, Bias, Explainability) e quando usar cada um.
Diferença entre drift covariante e concept drift, e como cada um é detectado.
Estratégias de redução de custo: Spot Training, Serverless Inference, Multi-Model Endpoints, SageMaker Neo, Savings Plans.
IAM Roles para cada estágio de ML e princípio de menor privilégio.
VPC Mode + PrivateLink como camadas complementares de isolamento de rede.
CloudWatch para monitoramento operacional vs CloudTrail para auditoria de acesso.
EventBridge como conector entre alertas e automação de retraining.

Pronto para testar o que aprendeu?

Loop fechado em PT-BR: simulado com questões do domínio Monitoramento, flashcards dos pontos que você errou, revisão espaçada. 7 dias grátis.

Iniciar simulado MLA-C01

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