Última revisión: mayo de 2026
Crea los servicios de AWS del examen SOA-C03 con Terraform puro: bloque a bloque, cada uno vinculado a un dominio del examen. El mismo código funciona en OpenTofu.
Al final de este laboratorio habrás aprovisionado, con Terraform simple, un bucle completo de monitoreo y auto-remediación: un grupo de logs de CloudWatch con un filtro de métricas, un tema de SNS que notifica a un humano, un runbook de Systems Manager que realiza la corrección automatizada y una regla de EventBridge que conecta los eventos de alta severidad al runbook para que los incidentes comunes se resuelvan por sí solos antes de que alguien se despierte.
Todos los recursos son Terraform simple; el mismo código funciona sin modificaciones en OpenTofu. Sin variables, sin módulos. Simplemente inserta los fragmentos en un único main.tf, ejecuta terraform init y luego terraform apply paso a paso.
>= 1.5 o OpenTofu >= 1.6.us-east-1.Todo en este laboratorio no cuesta nada mientras está inactivo:
Si la remediación automática se activa (el Paso 5 activa un documento de SSM), eso no tiene ningún costo adicional: Systems Manager Automation es gratuito para las acciones utilizadas aquí.
Apertura estándar. default_tags se aplican a toda la pila para que el equipo de operaciones pueda filtrar posteriormente Cost Explorer, AWS Config y Tag Editor por Project = certlabpro-soa-c03 para ver todo lo que este laboratorio ha creado. El dominio de Fiabilidad y Continuidad del Negocio de SOA-C03 prueba explícitamente esto: el etiquetado es la base de cada consulta operativa 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"
}
}
}Cada historia operativa en AWS comienza en CloudWatch Logs. Creamos un grupo de logs con una retención explícita de 30 días (el valor predeterminado de nunca expira es el anti-patrón de costo de SOA-C03 que surge en cada pregunta de optimización de costos) y un filtro de métricas que monitorea el flujo de logs en busca de la palabra ERROR y publica un conteo en CloudWatch Metrics.
Los filtros de métricas convierten los datos de logs no estructurados en métricas accionables. Ese es el modelo mental de SOA-C03 para la monitorización: logs → filtro → métrica → alarma → SNS → humano (o automatización). Estamos construyendo la cadena pieza por pieza a partir de este paso.
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"
}
}Ahora conectamos la métrica del Paso 2 a un humano. Creamos un tema de SNS, suscribimos una dirección de correo electrónico a él y configuramos una alarma de CloudWatch que se dispara cuando el recuento de errores supera nuestro umbral. SOA-C03 prueba esta cadena exacta — métrica → alarma → SNS → correo electrónico — bajo el dominio de Monitorización, Registro y Remediación (~20% del examen).
Después de terraform apply, AWS envía un correo electrónico de confirmación a la dirección en endpoint — haz clic en Confirmar suscripción una vez, y la alarma te llegará cuando se active.
treat_missing_data = "notBreaching" es un detalle pequeño pero relevante para el examen: por defecto, un punto de datos faltante se considera una infracción, lo que significa que una alarma nueva sin datos se dispara inmediatamente. Configurar esto en notBreaching coincide con la convención de SOA-C03 para métricas de bajo volumen.
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"
}Pagar a un humano está bien para incidentes nuevos, pero es costoso para los recurrentes conocidos. SOA-C03 se apoya fuertemente en AWS Systems Manager Automation como la respuesta a "¿cómo soluciono automáticamente las cosas que ya sé cómo solucionar?" — reiniciar un servicio no saludable, rotar una credencial, liberar espacio en disco.
Creamos un documento SSM mínimo que ejecuta un paso aws:sleep (uno de los tipos de paso administrados por AWS); en producción, esto sería aws:executeAutomation contra un runbook de recuperación conocido, o aws:runCommand contra un grupo de instancias. La forma es la misma: declarar una secuencia de pasos, otorgar al documento un rol de ejecución, registrarlo como una automatización reutilizable.
El rol de IAM que adjuntamos le otorga a SSM Automation permiso para asumirse a sí mismo y llamar a las acciones dentro del documento. El dominio de Fiabilidad y Continuidad del Negocio de SOA-C03 prueba este patrón exacto: un runbook nombrado y con control de versiones es auditable; un mensaje de Slack que dice "oye, ¿puedes reiniciar eso?" no lo es.
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
}La pieza final del bucle. Las alarmas de CloudWatch emiten eventos al bus predeterminado de EventBridge cuando cambian de estado; filtramos la alarma que creamos en el Paso 3 que pasa a ALARM, y apuntamos al documento de SSM del Paso 4 como respuesta.
La regla de EventBridge necesita su propio rol de IAM para llamar a SSM Automation en nuestro nombre; ese es un detalle sutil pero recurrente en SOA-C03. El examen prueba si recuerdas que EventBridge invocando un objetivo en tu nombre es una acción de servicio a servicio que necesita un rol de ejecución dedicado, distinto del rol de asunción del propio documento de SSM.
La cadena completa es ahora: línea de log que contiene ERROR → el filtro de métricas publica en CloudWatch Metrics → la alarma se activa cuando el recuento es > 10 en 5 minutos → la alarma publica un evento de cambio de estado en EventBridge Y envía un correo electrónico al equipo de operaciones a través de SNS → la regla de EventBridge coincide con el cambio de estado → SSM Automation ejecuta el runbook de remediación. El localizador se activa y la solución comienza en paralelo. Ese es el ideal operativo de 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 elimina todo en este laboratorio. Una advertencia: la suscripción por correo electrónico de SNS permanece en el historial de tu cuenta después de la eliminación (AWS conserva el registro de cancelación de suscripción por motivos de cumplimiento). Sin cargos, solo un rastro en papel. Todo lo demás se elimina limpiamente en un minuto.
SOA-C03 cubre aspectos operativos que este laboratorio no puede abarcar: reglas de AWS Config y paquetes de conformidad para la deriva de cumplimiento, CloudTrail para auditoría de API, verificaciones de Trusted Advisor, detección de deriva de CloudFormation y StackSets para operaciones multi-cuenta, AWS Backup, eventos de AWS Health, Resource Explorer, License Manager y Service Quotas.
Nos centramos en el bucle de alarma a auto-remediación porque es el patrón operativo más probado en el examen y el que conecta los cuatro servicios de mayor frecuencia (CloudWatch, SNS, SSM, EventBridge). Las otras herramientas operativas son de cobertura conceptual; consulta las secciones Buscar y Editorial de esta página de certificación.