Última revisão: maio de 2026
Construa os serviços da AWS do exame SOA-C03 com Terraform puro — um bloco de cada vez, cada um vinculado a um domínio do exame. O mesmo código funciona no OpenTofu.
Ao final deste laboratório, você terá provisionado, com Terraform puro, um loop completo de monitoramento e autorremediação — um grupo de logs do CloudWatch com um filtro de métricas, um tópico SNS que notifica um humano, um runbook do Systems Manager que realiza a correção automatizada, e uma regra do EventBridge que conecta eventos de alta gravidade ao runbook para que incidentes comuns se resolvam antes que alguém precise intervir.
Cada recurso é Terraform puro — o mesmo código funciona sem modificações no OpenTofu. Sem variáveis, sem módulos. Cole os trechos em um único main.tf, execute terraform init, depois terraform apply passo a passo.
>= 1.5 ou OpenTofu >= 1.6.us-east-1.Tudo neste laboratório não custa nada enquanto ocioso:
Se a autorremediação for de fato acionada (o Passo 5 dispara um documento SSM), isso não custa nada extra — o Systems Manager Automation é gratuito para as ações usadas aqui.
Abertura padrão. default_tags se aplicam a toda a stack para que a equipe de operações possa, mais tarde, filtrar o Cost Explorer, AWS Config e Tag Editor por Project = certlabpro-soa-c03 para ver tudo o que este laboratório criou. O domínio Confiabilidade e Continuidade de Negócios da SOA-C03 testa explicitamente isso — a marcação (tagging) é a base de toda consulta operacional transversal.
terraform {
required_version = ">= 1.5"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.60"
}
}
}
provider "aws" {
region = "us-east-1"
default_tags {
tags = {
Project = "certlabpro-soa-c03"
ManagedBy = "terraform"
}
}
}Toda história operacional na AWS começa no CloudWatch Logs. Criamos um grupo de logs com retenção explícita de 30 dias (o padrão de nunca expirar é o antipadrão de custo da SOA-C03 que surge em todas as questões de otimização de custos) e um filtro de métricas que monitora o fluxo de logs pela palavra ERROR e publica uma contagem nas métricas do CloudWatch.
Filtros de métricas transformam dados de log não estruturados em métricas acionáveis. Esse é o modelo mental da SOA-C03 para monitoramento: logs → filtro → métrica → alarme → SNS → humano (ou automação). Estamos construindo a cadeia peça por peça a partir deste passo.
resource "aws_cloudwatch_log_group" "app" {
name = "/certlabpro/soa-c03/app"
retention_in_days = 30
}
resource "aws_cloudwatch_log_metric_filter" "app_errors" {
name = "certlabpro-soa-c03-app-errors"
log_group_name = aws_cloudwatch_log_group.app.name
pattern = "ERROR"
metric_transformation {
name = "AppErrorCount"
namespace = "CertLabPro/SOA-C03"
value = "1"
default_value = "0"
}
}Agora conectamos a métrica do Passo 2 a um humano. Criamos um tópico SNS, inscrevemos um endereço de e-mail nele e configuramos um alarme do CloudWatch que dispara quando a contagem de erros excede nosso limite. A SOA-C03 testa essa cadeia exata — métrica → alarme → SNS → e-mail — sob o domínio Monitoramento, Registro e Remediação (~20% do exame).
Após terraform apply, a AWS envia um e-mail de confirmação para o endereço em endpoint — clique em Confirmar inscrição uma vez, e o alarme realmente chegará até você quando for acionado.
treat_missing_data = "notBreaching" é um detalhe pequeno, mas relevante para o exame: por padrão, um ponto de dados ausente conta como violação, o que significa que um alarme recém-criado sem dados dispara imediatamente. Definir como notBreaching corresponde à convenção da SOA-C03 para métricas de baixo volume.
resource "aws_sns_topic" "ops_alerts" {
name = "certlabpro-soa-c03-ops-alerts"
}
resource "aws_sns_topic_subscription" "ops_email" {
topic_arn = aws_sns_topic.ops_alerts.arn
protocol = "email"
endpoint = "ops@example.com" # replace with your real email
}
resource "aws_cloudwatch_metric_alarm" "app_errors_spike" {
alarm_name = "certlabpro-soa-c03-app-errors-spike"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = 1
metric_name = "AppErrorCount"
namespace = "CertLabPro/SOA-C03"
period = 300
statistic = "Sum"
threshold = 10
alarm_description = "More than 10 ERROR log lines in 5 minutes."
alarm_actions = [aws_sns_topic.ops_alerts.arn]
treat_missing_data = "notBreaching"
}Notificar um humano é bom para incidentes novos, mas caro para aqueles que são conhecidos e recorrentes. A SOA-C03 aposta fortemente no AWS Systems Manager Automation como a resposta para "como eu corrijo automaticamente as coisas que já sei como corrigir?" — reiniciar um serviço não saudável, rotacionar uma credencial, limpar espaço em disco.
Criamos um documento SSM mínimo que executa uma etapa aws:sleep (um dos tipos de etapas gerenciados pela AWS) — em produção, isso seria aws:executeAutomation contra um runbook de recuperação conhecido, ou aws:runCommand contra uma frota de instâncias. A forma é a mesma: declare uma sequência de etapas, dê ao documento uma função de execução, registre-o como uma automação reutilizável.
A função IAM que anexamos concede permissão ao SSM Automation para assumir a si mesmo e chamar as ações dentro do documento. O domínio Confiabilidade e Continuidade de Negócios da SOA-C03 testa exatamente esse padrão: um runbook nomeado e com controle de versão é auditável; uma mensagem do Slack dizendo "ei, você pode reiniciar aquilo" não é.
resource "aws_iam_role" "ssm_automation" {
name = "certlabpro-soa-c03-ssm-automation"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Service = "ssm.amazonaws.com" }
Action = "sts:AssumeRole"
}]
})
}
resource "aws_iam_role_policy_attachment" "ssm_automation" {
role = aws_iam_role.ssm_automation.name
policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonSSMAutomationRole"
}
resource "aws_ssm_document" "remediate_app_errors" {
name = "certlabpro-soa-c03-remediate-app-errors"
document_type = "Automation"
document_format = "YAML"
content = <<-EOT
schemaVersion: "0.3"
description: "Lab-only runbook — auto-acknowledges app-error spikes."
assumeRole: "${aws_iam_role.ssm_automation.arn}"
mainSteps:
- name: pause
action: aws:sleep
inputs:
Duration: PT5S
EOT
}A peça final do loop. Os alarmes do CloudWatch emitem eventos para o barramento padrão do EventBridge quando mudam de estado — filtramos pelo alarme que criamos no Passo 3 fazendo a transição para ALARM, e direcionamos o documento SSM do Passo 4 como resposta.
A regra do EventBridge precisa de sua própria função IAM para chamar o SSM Automation em nosso nome — esse é um detalhe sutil, mas recorrente, da SOA-C03. O exame testa se você se lembra que o EventBridge invocando um alvo em seu nome é uma ação de serviço para serviço que precisa de uma função de execução dedicada, distinta da função de assunção do próprio documento SSM.
A cadeia completa é agora: linha de log contendo ERROR → filtro de métricas publica nas Métricas do CloudWatch → alarme dispara quando a contagem > 10 em 5 minutos → alarme publica evento de mudança de estado no EventBridge E envia e-mail para a equipe de operações via SNS → regra do EventBridge corresponde à mudança de estado → SSM Automation executa o runbook de remediação. O pager dispara e a correção é iniciada em paralelo. Esse é o ideal operacional da SOA-C03.
resource "aws_iam_role" "eventbridge_invoke_ssm" {
name = "certlabpro-soa-c03-eventbridge-invoke-ssm"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Service = "events.amazonaws.com" }
Action = "sts:AssumeRole"
}]
})
}
resource "aws_iam_role_policy" "eventbridge_invoke_ssm" {
name = "start-automation"
role = aws_iam_role.eventbridge_invoke_ssm.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = "ssm:StartAutomationExecution"
Resource = "*"
}]
})
}
resource "aws_cloudwatch_event_rule" "app_errors_alarm" {
name = "certlabpro-soa-c03-app-errors-alarm-fired"
description = "Fires the auto-remediation runbook when the app-errors alarm trips."
event_pattern = jsonencode({
source = ["aws.cloudwatch"]
"detail-type" = ["CloudWatch Alarm State Change"]
detail = {
alarmName = [aws_cloudwatch_metric_alarm.app_errors_spike.alarm_name]
state = { value = ["ALARM"] }
}
})
}
resource "aws_cloudwatch_event_target" "run_ssm_doc" {
rule = aws_cloudwatch_event_rule.app_errors_alarm.name
arn = "arn:aws:ssm:us-east-1::automation-definition/${aws_ssm_document.remediate_app_errors.name}"
role_arn = aws_iam_role.eventbridge_invoke_ssm.arn
}terraform destroy desmonta tudo neste laboratório. Uma ressalva: a assinatura de e-mail do SNS permanece no histórico da sua conta após a destruição (a AWS mantém o registro de cancelamento de inscrição para conformidade). Sem cobranças, apenas um registro. Tudo o mais é encerrado de forma limpa em um minuto.
A SOA-C03 abrange áreas operacionais que este laboratório não pode incluir — regras e pacotes de conformidade do AWS Config para desvio de conformidade, CloudTrail para auditoria de API, verificações do Trusted Advisor, detecção de desvio do CloudFormation e StackSets para operações de múltiplas contas, AWS Backup, eventos do AWS Health, Resource Explorer, License Manager e Service Quotas.
Nos apegamos ao ciclo de alarme para autorremediação porque é o padrão operacional mais testado no exame e o que conecta os quatro serviços de maior frequência (CloudWatch, SNS, SSM, EventBridge). As outras ferramentas operacionais são cobertura conceitual — consulte as seções Navegar e Editorial desta página de certificação.