O dominio de resposta a incidentes e eventos representa 14% do exame DOP-C02. As perguntas vao alem do conhecimento basico de ferramentas e exigem que voce projete cadeias completas de automacao baseadas em eventos e identifique a fonte de evento correta para cada cenario.
Fontes de eventos e padroes de processamento
Compreender as fontes de eventos com precisao e critico para um engenheiro DevOps. A AWS oferece varios servicos que geram eventos, cada um com um proposito especifico.
Padrao AWS Health + EventBridge
O AWS Health publica eventos em tempo real sobre interrupcoes de servico, manutencao programada e retirada de instancias que afetam sua conta. Usando nas regras do EventBridge, voce pode capturar imediatamente os eventos do Health.
Considere este cenario real: uma empresa que opera milhares de instancias EC2 recebe avisos de retirada da AWS. O monitoramento manual do console produz respostas tardias e degradacao do servico. A solucao e uma regra do EventBridge que detecta e aciona um runbook do SSM Automation para parar e reiniciar automaticamente as instancias afetadas.
| Fonte de evento | Valor source | Tipos de eventos representativos | |----------------|-------------|----------------------------------| | AWS Health | aws.health | Retirada de EC2, interrupcao de servico, manutencao | | CloudTrail | (integrado nativamente) | Todas as chamadas de API da AWS | | EC2 Auto Scaling | aws.autoscaling | Eventos de ciclo de vida de lancamento/terminacao | | CodePipeline | aws.codepipeline | Mudancas de estado do pipeline |
Nao confunda Health com CloudTrail. Mudancas de estado da infraestrutura da AWS vem do Health; chamadas de API feitas por usuarios vem do CloudTrail.
CloudTrail + EventBridge — Vigilancia de eventos de API em tempo real
Quando voce precisa detectar em tempo quase real chamadas de API sensiveis como criacao de usuario IAM ou modificacoes de grupos de seguranca, aproveite a integracao nativa entre CloudTrail e EventBridge.
Cenario de instituicao financeira: a politica IAM proibe a criacao direta de usuarios IAM, mas alguns desenvolvedores burlam isso. A arquitetura de resposta funciona da seguinte forma.
Configurar o padrao da regra do EventBridge: Registrar Lambda como destino Lambda chama + para desabilitar imediatamente o usuario SNS envia notificacao para a equipe de seguranca
Esta arquitetura completa detectar→desabilitar→notificar em segundos apos a chamada de API. Consultas periodicas de logs do CloudTrail com Athena introduzem dezenas de minutos de atraso e sao inadequadas para resposta em tempo real.
Para a porta SSH 22 aberta para 0.0.0.0/0 em um grupo de seguranca, o mesmo padrao se aplica: detectar eventos com condicoes do EventBridge filtrando , entao acionar Lambda para chamar .
SQS Dead Letter Queue — Isolando mensagens envenenadas
Em sistemas de processamento de eventos em larga escala, certas mensagens que falham repetidamente e bloqueiam o fluxo normal de mensagens sao chamadas de mensagens "poison pill".
SQS Dead Letter Queue (DLQ) move automaticamente mensagens que excedem da fila de origem para uma DLQ separada. O beneficio principal e isolar mensagens toxicas para proteger o fluxo normal, enquanto mensagens isoladas na DLQ sao preservadas em sua forma original para analise posterior de causa raiz e reprocessamento.
Quando Lambda processa mensagens via mapeamento de fonte de eventos SQS, todas as mensagens em um lote devem ter sucesso antes que um ACK seja enviado. Em caso de falha, o lote inteiro e repetido. Ao atingir , a mensagem vai para a DLQ. O recurso DLQ Redrive do console SQS permite enviar mensagens de volta para a fila de origem apos analise.
Kinesis Data Streams Enhanced Fan-Out — Escalando consumidores
Quando multiplos consumidores Lambda tentam ler simultaneamente do mesmo shard do DynamoDB Streams, ocorrem erros . DynamoDB Streams permite no maximo 2 consumidores concorrentes por shard.
Mudar para Kinesis Data Streams com Enhanced Fan-Out da a cada consumidor um throughput dedicado de 2 MB/s por shard. Os consumidores operam de forma independente sem contencao. O DynamoDB tambem suporta integracao direta com o Kinesis, permitindo transicao suave sem mudancas de codigo. Compare isso com o padrao fan-out SNS + SQS, que adiciona uma camada de broker de mensagens, enquanto o Kinesis Enhanced Fan-Out escala diretamente os consumidores do stream.
Mudancas de configuracao baseadas em eventos e auto-recuperacao
CloudWatch Alarm + SSM Run Command — Auto-recuperacao de processos
Imagine uma aplicacao de servidor de jogos onde a propria instancia esta saudavel mas o processo do servidor de jogos falha intermitentemente. As verificacoes de integridade do Auto Scaling detectam apenas falhas no nivel da instancia e nao conseguem detectar falhas de processos de aplicacao.
A solucao e usar o plugin do CloudWatch Agent para coletar o estado de execucao de um processo especifico como metrica personalizada. Quando a contagem de processos cai para zero, um alarme do CloudWatch dispara, e a acao de alarme aciona SSM Run Command para reiniciar apenas o processo na instancia afetada.
A vantagem desta abordagem: nenhuma substituicao de instancia significa nenhuma desconexao de sessao de jogadores. A DesiredCapacity do Auto Scaling permanece inalterada. Os comandos sao executados remotamente atraves do SSM Agent sem SSH.
ASG Lifecycle Hook — Coleta de logs antes da terminacao
Quando uma instancia do Auto Scaling e terminada, os logs nessa instancia desaparecem com ela. Os ASG Lifecycle Hooks sao a ferramenta principal quando voce precisa preservar logs para analise de causa raiz de falhas.
Um Lifecycle Hook insere um estagio quando uma instancia faz a transicao de para . Durante este periodo de espera (padrao 3600 segundos, maximo 48 horas), a instancia nao e realmente terminada e permanece acessivel.
Dois padroes de uso criticos aparecem no exame.
Padrao 1, coleta de logs: EventBridge detecta o evento , aciona Lambda para enviar logs ao S3, depois chama para permitir a terminacao final. A terminacao so prossegue apos a transferencia de logs ser concluida.
Padrao 2, sincronizacao de descoberta de servicos: Hooks em lancamento () e terminacao () acionam Lambda para sincronizar automaticamente registros externos.
Armadilha comum: EventBridge + Run Command parece conceitualmente similar, mas comandos SSM nao podem alcancar uma instancia que ja esta sendo terminada. Voce deve pausar a terminacao com um Lifecycle Hook para tornar possivel a execucao de comandos.
Solucao de problemas de pipelines CI/CD
Quando o gatilho automatico CodeCommit para CodePipeline nao dispara
Um desenvolvedor faz push de codigo para a branch main mas o pipeline nao inicia automaticamente. A execucao manual funciona bem. O que voce deve verificar primeiro?
A resposta e verificar o status da regra do EventBridge. Quando CodePipeline configura uma fonte CodeCommit, ele cria automaticamente uma regra do EventBridge que detecta eventos . Se esta regra estiver DESATIVADA ou apontar para o ARN do pipeline errado, o gatilho automatico falha. O fato de a execucao manual funcionar prova que nao ha problema de permissao IAM, apontando para o proprio mecanismo de disparo.
Quando todos os eventos de implantacao do CodeDeploy mostram status Skipped
A implantacao nao falha; nunca comeca e mostra o status Skipped. O CodeDeploy Agent opera no modo pull. O agente sonda periodicamente o endpoint do servico CodeDeploy para verificar comandos de implantacao.
Em uma sub-rede privada sem NAT Gateway nem endpoints de VPC, o agente nao consegue alcancar e a sondagem falha. Todos os eventos mostrando Skipped significa que o agente nunca recebeu o comando. Distinga entre Skipped e Failed: Failed significa que o agente recebeu e executou o comando mas falhou. Skipped significa que o agente nunca recebeu o comando.
Solucao: criar um endpoint de interface VPC , ou fornecer acesso a internet atraves do NAT Gateway.
X-Ray e Step Functions para rastrear fluxos de trabalho complexos
Implementar um fluxo de trabalho de automatizacao de incidentes de seguranca de multiplas etapas (desativar chave de acesso exposta → resumir atividade do CloudTrail → notificar a equipe) com encadeamento de Lambda torna muito dificil rastrear falhas em etapas individuais. O AWS Step Functions Standard Workflow preserva a entrada/saida de cada estado e o historico de transicoes por 90 dias. Retry/Catch permite definir de forma declarativa a logica de reintento por etapa. O padrao de EventBridge detectando um evento do AWS Health e acionando um fluxo de trabalho do Step Functions e a arquitetura padrao da AWS para automatizacao de incidentes de seguranca.
Pontos chave do exame
"Auto-detectar retirada de EC2 + reinicio automatico" -- EventBridge(source: aws.health, AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED) + SSM Automation
"Detectar criacao de usuario IAM instantaneamente + auto-desabilitar" -- CloudTrail + EventBridge(source: aws.iam, CreateUser) + Lambda
"Isolar mensagens que falham repetidamente + proteger fluxo normal" -- SQS Dead Letter Queue(maxReceiveCount)
"Escalar consumidores do DynamoDB Streams + sem throttling" -- Kinesis Data Streams Enhanced Fan-Out
"Detectar crash de processo + recuperar sem substituicao de instancia" -- CloudWatch Agent procstat + CloudWatch Alarm + SSM Run Command
"Preservar logs antes da terminacao da instancia" -- ASG Lifecycle Hook(Terminating:Wait) + Lambda + complete-lifecycle-action
"Push do CodeCommit nao dispara pipeline" -- Verificar status ENABLED/DISABLED da regra EventBridge
"Todos os eventos do CodeDeploy Skipped" -- Sub-rede privada sem endpoint VPC nem NAT (Agent nao consegue sondar)