Amazon SOA-C02: Implantação, Provisionamento e Automação — Guia de estudos

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Faz parte do AWS SysOps Administrator Associate SOA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Este domínio abrange os métodos e as ferramentas usadas para provisionar, atualizar e operar a infraestrutura e as implantações de aplicações da AWS de forma confiável e repetível. Ele enfatiza o provisionamento declarativo e idempotente, pipelines automatizados para releases e automação operacional que reduz o trabalho manual, preservando a auditabilidade e a segurança. Os operadores devem equilibrar a segurança (rollbacks, políticas de alteração) com a velocidade (imagens imutáveis, patches automatizados) e escolher padrões que suportem a conformidade e a recuperabilidade.

CloudFormation e padrões de Infraestrutura como Código

Use o CloudFormation (ou CDK/Terraform) para declarar a infraestrutura como código para que as pilhas (stacks) sejam idempotentes: um template descreve o estado desejado e o motor converge os recursos para esse estado. Prefira recursos e parâmetros declarativos em vez de scripts imperativos. Padrões de CLI típicos:

Criar e inspecionar um change set: aws cloudformation create-change-set –stack-name my-stack –template-body file://template.yaml –parameters ParameterKey=Env,ParameterValue=prod –change-set-name cs1
Revisar e executar: aws cloudformation describe-change-set –change-set-name cs1 && aws cloudformation execute-change-set –change-set-name cs1
Conveniência de implantação: aws cloudformation deploy –template-file template.yaml –stack-name my-stack –parameter-overrides Key=Value –capabilities CAPABILITY_NAMED_IAM

Decisões de design:

Use pilhas aninhadas (nested stacks) ou módulos para reutilização e para contornar limites; mova segredos mutáveis e binários grandes para fora dos templates (SSM Parameter Store / Secrets Manager).
Use políticas de pilha (stack policies), proteção contra exclusão (termination protection) e gatilhos de rollback para segurança; habilite a detecção de desvio (drift detection) com aws cloudformation detect-stack-drift e aws cloudformation describe-stack-drift-detection-status.
Conceda à service role do CloudFormation uma política do IAM com escopo definido para criar recursos; evite conceder permissões amplas de administrador ao CloudFormation.

Ao comparar abordagens de IaC:

CloudFormation/CDK: nativo, integrado com change sets e drift detection da AWS, requer CAPABILITY_NAMED_IAM para recursos do IAM.
Terraform: agnóstico em relação ao provedor, requer gerenciamento de arquivo de estado (state file), bom para ambientes multinuvem.
Scripts imperativos (CLI/SDK): adequados para operações pontuais, mas não são idempotentes e são mais difíceis de auditar.

CI/CD e práticas de automação de implantação

Implemente estágios de pipeline repetíveis: fonte (source) -> compilação (build) -> teste (test) -> implantação (deploy). Use o AWS CodePipeline integrando o CodeBuild, o CodeDeploy ou ferramentas de terceiros (Jenkins, GitHub Actions). Configurações principais:

CodeBuild: defina o buildspec.yml para as fases e artefatos; conceda o menor privilégio possível à role do projeto (s3:GetObject para entradas, s3:PutObject para artefatos).
CodeDeploy: use grupos de implantação (deployment groups) e o AppSpec.yml; escolha o tipo de implantação — in-place ou blue/green. Para EC2/ASG, prefira blue/green para reduzir o risco.
ECR + ECS/EKS: faça o push das imagens a partir do CI, use tags imutáveis (semânticas ou ID do build) e referencie a tag ou o digest da imagem nas definições de tarefa (task definitions).

Critérios de decisão para estratégias de implantação:

Use blue/green ou canary com desvio de tráfego (traffic shifting) quando precisar de tempo de inatividade próximo de zero e rollback seguro; o desvio de tráfego por peso no Application Load Balancer (ALB) suporta isso.
Use atualizações contínuas (rolling) ou in-place para frotas menores e sem estado (stateless) onde a capacidade pode ser reduzida durante a atualização.
Garanta que as roles do pipeline tenham escopo definido: a role de execução do pipeline, a service role do CodeBuild e a role de implantação (instance profile) devem ter, cada uma, permissões mínimas.

Gerencie segredos e parâmetros de forma segura: armazene parâmetros no SSM Parameter Store (como SecureString) ou no AWS Secrets Manager; conceda às roles do pipeline as permissões kms:Decrypt e ssm:GetParameter ou secretsmanager:GetSecretValue, conforme necessário.

Criação de AMIs (baking), imagens imutáveis e gerenciamento de AMIs

Infraestrutura imutável significa criar uma nova AMI com todos os patches de SO e de aplicação já incorporados (baked in) e, em seguida, substituir as instâncias em vez de modificá-las. Use o EC2 Image Builder ou o Packer no CI para produzir AMIs automaticamente:

Os pipelines do EC2 Image Builder podem ser executados de forma agendada, instalar pacotes, executar testes e produzir AMIs com convenções de nomenclatura versionadas e tags.
O Packer se integra ao CI (CodeBuild/Jenkins) para executar scripts de compilação e gerar os IDs das AMIs; armazene a AMI mais recente no SSM Parameter Store (ex: /ami/app-prod) para referência.

Gerencie o ciclo de vida da AMI:

Adicione tags às imagens com metadados de build e data de expiração; automatize o cancelamento do registro (deregistration) e a exclusão do snapshot após o período de retenção.
Use Launch Templates/ASG com uma atualização de versão para implementar novas AMIs; para implantações imutáveis, crie um novo ASG referenciando a nova versão do Launch Template e troque os target groups.

Comparando mutável vs. imutável:

Imutável (nova AMI/novo ASG): mais seguro, rollback mais fácil ao trocar para o ASG ou AMI anterior, ciclo de vida consistente.
Mutável (patch in-place): mais rápido para aplicar pequenas correções, mas gera mais desvio (drift) e é mais difícil de reproduzir; use apenas quando as restrições exigirem.

Automação, Run Command e aplicação de patches do AWS Systems Manager

O Systems Manager (SSM) centraliza tarefas operacionais: Run Command para comandos ad-hoc, State Manager para o estado desejado, Patch Manager para aplicação agendada de patches de SO e Automation para fluxos de trabalho complexos. Padrões comuns de CLI:

Enviar comando ad-hoc:

undefined

Iniciar automação predefinida:

undefined

Usar associações do State Manager para impor configurações (por exemplo, configuração do Agente SSM, cron jobs) e baselines do Patch Manager para regras de aprovação e varreduras de conformidade.

Detalhes de configuração e pontos de decisão:

Use o Patch Manager com Baselines e Janelas de Manutenção (Maintenance Windows) para uma aplicação de patches previsível e em conformidade; escolha dias para aprovação automática e rejeite imagens de AMI não aprovadas se estiver usando uma estratégia imutável.
Para instâncias sem o agente SSM ou com rede limitada, considere o Session Manager com VPC endpoints para evitar a abertura de portas SSH.
Sempre exija um perfil de instância (instance profile) com a política AmazonSSMManagedInstanceCore para acesso ao SSM; restrinja permissões adicionais conforme necessário.

Gerenciamento de mudanças, detecção de desvio (drift) e rollback

Implemente um controle de mudanças que integre execuções de pipeline, tags e aprovações. Use change sets do CloudFormation para visualizar as diferenças (diffs) e políticas de pilha (stack policies) para rejeitar atualizações destrutivas. Padrões de CLI:

Detectar desvio (drift):

undefined

Use uma política de pilha (stack policy) para proteger recursos críticos durante atualizações e defina uma RollbackConfiguration com gatilhos de rollback (rollback triggers) para notificar sobre atualizações com falha.

Estratégias de rollback:

Para o CloudFormation: o rollback automático em caso de falha é o padrão; use gatilhos de rollback e retenha recursos quando necessário.
Para aplicações: prefira blue/green ou canary com desvio de tráfego para permitir rollback instantâneo, reajustando os pesos no ALB/Route53 ou restaurando os conjuntos de tarefas (task sets) anteriores.
Mantenha artefatos imutáveis (IDs de AMI, imagens de contêiner) e preserve as versões anteriores nos registros/SSM para que os rollbacks sejam determinísticos.

Critérios de decisão:

Se migrações de dados com estado (stateful) estiverem envolvidas, inclua scripts de migração reversíveis ou use feature flags para separar o lançamento do código da migração de esquema.
Use verificações de saúde (health checks) da implantação e testes de fumaça (smoke tests) automatizados como um gate de pipeline para acionar rollbacks antecipadamente.

Armadilhas Comuns e Critérios de Decisão

Fazer alterações manuais fora de banda no console que causam desvio (drift) no estado da IaC: imponha a detecção de desvio (

undefined

) e exija que as correções sejam aplicadas por meio de templates de IaC; use controles do IAM para restringir edições no console.

Falta de um plano de rollback seguro para os lançamentos: adote implantações blue/green ou canary e mantenha os artefatos/AMIs anteriores disponíveis para reverter instantaneamente.
IAM excessivamente permissivo para pipelines e roles: aplique o princípio do menor privilégio; divida as roles (role de serviço do pipeline, role de build, perfil de instância) e conceda apenas as permissões necessárias de ssm:GetParameter, secretsmanager:GetSecretValue, kms:Decrypt e acesso ao S3.
Armazenar segredos diretamente em templates ou em texto plano: mova os segredos para o Secrets Manager ou para o SSM Parameter Store como SecureString e referencie-os no momento da implantação com as permissões de decriptografia adequadas.
Aplicar patches em produção in-place sem testar: crie (bake) AMIs na CI com pacotes atualizados e testes de fumaça, depois distribua imagens imutáveis por meio de ASGs ou pipelines blue/green.
Ignorar o desvio (drift) e a proteção de recursos com estado (stateful): use políticas de pilha (stack policies) e detecte desvios regularmente; para recursos com estado, exija aprovação manual e snapshots antes de alterações destrutivas.

Problema Prático: Cenário de Caso de Uso

A Acme Payments precisa implantar um serviço de API em conformidade com o PCI, aplicar patches de SO mensais e ser capaz de reverter rapidamente se uma implantação causar erros durante o horário comercial.

Implemente um pipeline imutável: use o CodePipeline/CodeBuild para criar (bake) AMIs com o EC2 Image Builder (ou Packer), adicione tags às AMIs e publique o ID da AMI no SSM Parameter Store.
Implante via templates do CloudFormation que referenciam o parâmetro SSM para a AMI e crie uma nova versão do ASG + Launch Template para cada lançamento; use change sets para revisão prévia (pre-flight).
Use o CodeDeploy ou o desvio de tráfego blue/green de target groups do ALB com verificações de saúde (health checks) e testes de fumaça automatizados; configure o rollback automático em caso de falha na verificação de saúde.
Agende o Patch Manager por meio das Janelas de Manutenção (Maintenance Windows) do Systems Manager para aplicação de patches fora do horário de pico; execute o processo de bake-and-deploy para imagens com patches para evitar a aplicação de patches in-place em produção.
Imponha o princípio do menor privilégio (least-privilege) do IAM para as roles do pipeline, armazene segredos no Secrets Manager e habilite a detecção de desvio (drift detection) do CloudFormation e as políticas de pilha (stack policies) para recursos críticos.

Justificativa: Criar (baking) imagens e implantar de forma imutável separa as responsabilidades de build e de execução, fornecendo artefatos reproduzíveis e caminhos de rollback seguros; a aplicação automatizada de patches via SSM, somada a implantações imutáveis, minimiza o risco e apoia a conformidade, mantendo a capacidade de recuperação.

← Alta Disponibilidade · Todos os domínios · Segurança →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →