Amazon SOA-C02: Implementación, Aprovisionamiento y Automatización — Guía de estudio

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

Forma parte de la AWS SysOps Administrator Associate SOA-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Este dominio abarca los métodos y herramientas utilizados para aprovisionar, actualizar y operar la infraestructura y los despliegues de aplicaciones de AWS de forma fiable y repetible. Pone énfasis en el aprovisionamiento declarativo e idempotente, los pipelines automatizados para los lanzamientos y la automatización operativa que reduce el trabajo manual repetitivo, preservando al mismo tiempo la auditabilidad y la seguridad. Los operadores deben equilibrar la seguridad (reversiones, políticas de cambio) con la velocidad (imágenes inmutables, aplicación de parches automatizada) y elegir patrones que soporten el cumplimiento y la recuperabilidad.

CloudFormation y patrones de Infraestructura como Código

Utilice CloudFormation (o CDK/Terraform) para declarar la infraestructura como código, de modo que los stacks sean idempotentes: una plantilla describe el estado deseado y el motor converge los recursos. Prefiera los recursos y parámetros declarativos sobre los scripts imperativos. Patrones típicos de la CLI:

Crear e inspeccionar un conjunto de cambios: aws cloudformation create-change-set –stack-name my-stack –template-body file://template.yaml –parameters ParameterKey=Env,ParameterValue=prod –change-set-name cs1
Revisar y ejecutar: aws cloudformation describe-change-set –change-set-name cs1 && aws cloudformation execute-change-set –change-set-name cs1
Despliegue simplificado: aws cloudformation deploy –template-file template.yaml –stack-name my-stack –parameter-overrides Key=Value –capabilities CAPABILITY_NAMED_IAM

Decisiones de diseño:

Use stacks anidados o módulos para la reutilización y los límites; mueva los secretos mutables y los binarios grandes fuera de las plantillas (SSM Parameter Store / Secrets Manager).
Use políticas de stack, protección contra la terminación y disparadores de rollback para mayor seguridad; habilite la detección de desviaciones (drift) con aws cloudformation detect-stack-drift y aws cloudformation describe-stack-drift-detection-status.
Otorgue al rol de servicio de CloudFormation una política de IAM con alcance limitado para crear recursos; evite dar a CloudFormation permisos amplios de administrador.

Al comparar los enfoques de IaC:

CloudFormation/CDK: nativo, integrado con los conjuntos de cambios de AWS y la detección de desviaciones (drift), requiere CAPABILITY_NAMED_IAM para los recursos de IAM.
Terraform: independiente del proveedor, requiere la gestión de un archivo de estado, bueno para entornos de nube mixta.
Scripts imperativos (CLI/SDK): adecuados para operaciones puntuales, pero no son idempotentes y son más difíciles de auditar.

Prácticas de CI/CD y automatización de despliegues

Implemente etapas de pipeline repetibles: código fuente -> compilación -> prueba -> despliegue. Use AWS CodePipeline integrando CodeBuild, CodeDeploy o herramientas de terceros (Jenkins, GitHub Actions). Configuraciones clave:

CodeBuild: defina buildspec.yml para las fases y los artefactos; otorgue al rol del proyecto el mínimo privilegio (s3:GetObject para las entradas, s3:PutObject para los artefactos).
CodeDeploy: use grupos de despliegue y AppSpec.yml; elija el tipo de despliegue: in situ o azul/verde. Para EC2/ASG, prefiera el despliegue azul/verde para reducir el riesgo.
ECR + ECS/EKS: suba las imágenes desde el CI, etiquételas de forma inmutable (semántica o ID de compilación) y referencie la etiqueta o el digest de la imagen en las definiciones de tareas.

Criterios de decisión para las estrategias de despliegue:

Use despliegues azul/verde o canary con desvío de tráfico cuando necesite un tiempo de inactividad casi nulo y una reversión segura; los cambios de peso en el Application Load Balancer (ALB) soportan esto.
Use actualizaciones continuas (rolling) o in situ para flotas más pequeñas y sin estado donde la capacidad puede reducirse durante la actualización.
Asegúrese de que los roles del pipeline tengan un alcance limitado: el rol de ejecución del pipeline, el rol de servicio de CodeBuild y el rol de despliegue (perfil de instancia), cada uno con permisos mínimos.

Gestione los secretos y parámetros de forma segura: almacene los parámetros en SSM Parameter Store (como SecureString) o en AWS Secrets Manager; otorgue a los roles del pipeline los permisos kms:Decrypt y ssm:GetParameter o secretsmanager:GetSecretValue según sea necesario.

Creación de AMIs, imágenes inmutables y gestión de AMIs

La infraestructura inmutable significa crear una nueva AMI con todos los parches del sistema operativo y de la aplicación ya incorporados («horneados»), y luego reemplazar las instancias en lugar de modificarlas. Use EC2 Image Builder o Packer en el CI para producir AMIs automáticamente:

Los pipelines de EC2 Image Builder pueden ejecutarse según una programación, instalar paquetes, ejecutar pruebas y producir AMIs con convenciones de nomenclatura y etiquetas versionadas.
Packer se integra en el CI (CodeBuild/Jenkins) para ejecutar scripts de compilación y generar los ID de las AMIs; almacene la AMI más reciente en SSM Parameter Store (p. ej., /ami/app-prod) como referencia.

Gestione el ciclo de vida de las AMIs:

Etiquete las imágenes con metadatos de compilación y una fecha de expiración; automatice la anulación del registro y la eliminación de snapshots después del período de retención.
Use Launch Templates/ASG con una actualización de versión para desplegar las nuevas AMIs; para despliegues inmutables, cree un nuevo ASG que haga referencia a la nueva versión del Launch Template y cambie los grupos de destino.

Comparación entre mutable e inmutable:

Inmutable (nueva AMI/nuevo ASG): más seguro, reversión más fácil al cambiar al ASG o AMI anterior, ciclo de vida consistente.
Mutable (aplicación de parches in situ): más rápido para aplicar pequeñas correcciones, pero con mayor desviación (drift) y más difícil de reproducir; úsese solo cuando las restricciones lo exijan.

Automatización, Run Command y aplicación de parches con AWS Systems Manager

Systems Manager (SSM) centraliza las tareas operativas: Run Command para comandos ad-hoc, State Manager para el estado deseado, Patch Manager para la aplicación programada de parches de SO y Automation para flujos de trabajo complejos. Patrones comunes de CLI:

Enviar comando ad-hoc: aws ssm send-command –instance-ids i-0123456789abcdef0 –document-name “AWS-RunShellScript” –parameters commands=’[“yum update -y”]'
Iniciar automatización predefinida: aws ssm start-automation-execution –document-name “AWS-ApplyPatchBaseline” –parameters “InstanceIds=[‘i-…’]”
Usar asociaciones de State Manager para forzar la configuración (p. ej., configuración del agente de SSM, trabajos de cron) y líneas base (baselines) de Patch Manager para reglas de aprobación y escaneos de cumplimiento.

Detalles de configuración y puntos de decisión:

Usa Patch Manager con Líneas Base (Baselines) y Ventanas de Mantenimiento (Maintenance Windows) para una aplicación de parches predecible y conforme a las normativas; elige los días de autoaprobación y rechaza las imágenes de AMI no aprobadas si usas una estrategia inmutable.
Para instancias sin el agente de SSM o con red limitada, considera Session Manager con VPC endpoints para evitar abrir puertos SSH.
Requiere siempre un perfil de instancia con la política AmazonSSMManagedInstanceCore para el acceso de SSM; limita los permisos adicionales según sea necesario.

Gestión de cambios, detección de deriva y rollback

Implementa un control de cambios que integre ejecuciones de pipeline, etiquetas (tags) y aprobaciones. Usa conjuntos de cambios (change sets) de CloudFormation para previsualizar las diferencias y políticas de pila (stack policies) para rechazar actualizaciones destructivas. Patrones de CLI:

Detectar deriva (drift): aws cloudformation detect-stack-drift –stack-name my-stack y aws cloudformation describe-stack-resource-drifts –stack-name my-stack
Usa una política de pila para proteger los recursos críticos durante las actualizaciones y establece RollbackConfiguration con disparadores de rollback (rollback triggers) para notificar sobre actualizaciones fallidas.

Estrategias de rollback:

Para CloudFormation: el rollback automático en caso de fallo es el comportamiento por defecto; usa disparadores de rollback y retén los recursos cuando sea necesario.
Para aplicaciones: prefiere despliegues blue/green o canary con desvío de tráfico para permitir un rollback instantáneo reajustando los pesos en ALB/Route53 o restableciendo los conjuntos de tareas (task sets) anteriores.
Mantén artefactos inmutables (IDs de AMI, imágenes de contenedor) y preserva las versiones anteriores en los registros/SSM para que los rollbacks sean deterministas.

Criterios de decisión:

Si hay migraciones de datos con estado (stateful) involucradas, incluye scripts de migración reversibles o usa feature flags para separar la publicación del código de la migración del esquema.
Usa comprobaciones de estado del despliegue y pruebas de humo (smoke tests) automatizadas como puerta de control en el pipeline para activar los rollbacks de forma temprana.

Errores Comunes y Criterios de Decisión

Realizar cambios manuales fuera de banda en la consola que causan deriva (drift) en el estado de la IaC: fuerza la detección de deriva (aws cloudformation detect-stack-drift) y exige que las correcciones se apliquen a través de plantillas de IaC; usa controles de IAM para restringir las ediciones en la consola.
Falta de un plan de rollback seguro para los lanzamientos: adopta despliegues blue/green o canary y mantén disponibles los artefactos/AMIs anteriores para revertir instantáneamente.
IAM con permisos excesivos para pipelines y roles: aplica el principio de privilegio mínimo; divide los roles (rol de servicio del pipeline, rol de compilación, perfil de instancia) y concede solo los permisos necesarios de ssm:GetParameter, secretsmanager:GetSecretValue, kms:Decrypt y acceso a S3.
Almacenar secretos directamente en plantillas o en texto plano: mueve los secretos a Secrets Manager o a SSM Parameter Store como SecureString y referéncialos en el momento del despliegue con los permisos de descifrado adecuados.
Aplicar parches en producción directamente (in-place) sin pruebas: crea (bake) AMIs en CI con los paquetes actualizados y pruebas de humo, luego despliega las imágenes inmutables a través de ASG o pipelines blue/green.
Ignorar la deriva y la protección de recursos con estado: usa políticas de pila y detecta la deriva regularmente; para los recursos con estado, exige aprobación manual y snapshots antes de realizar cambios destructivos.

Problema Práctico: Escenario de Caso de Uso

Acme Payments debe desplegar un servicio de API que cumpla con PCI, aplicar parches de SO mensuales y poder hacer rollback rápidamente si un despliegue causa errores durante el horario comercial.

Implementar un pipeline inmutable: usar CodePipeline/CodeBuild para crear (bake) AMIs con EC2 Image Builder (o Packer), etiquetar las AMIs y publicar el ID de la AMI en SSM Parameter Store.
Desplegar a través de plantillas de CloudFormation que referencien el parámetro de SSM para la AMI y creen una nueva versión de ASG + Launch Template para cada lanzamiento; usar conjuntos de cambios (change sets) para una revisión previa.
Usar CodeDeploy o el desvío de tráfico blue/green de los grupos de destino (target groups) de ALB con comprobaciones de estado y pruebas de humo automatizadas; configurar el rollback automático en caso de fallo de la comprobación de estado.
Programar Patch Manager a través de las Ventanas de Mantenimiento (Maintenance Windows) de Systems Manager para la aplicación de parches en horas de baja actividad; realizar un proceso de “crear y desplegar” (bake-and-deploy) para las imágenes con parches para evitar la aplicación de parches directamente en producción.
Forzar el privilegio mínimo en los roles de IAM del pipeline, almacenar los secretos en Secrets Manager y habilitar la detección de deriva de CloudFormation y las políticas de pila para los recursos críticos.

Justificación: Crear imágenes y desplegar de forma inmutable separa las responsabilidades de construcción (build) y ejecución (run), proporcionando artefactos reproducibles y rutas de rollback seguras; la aplicación automatizada de parches a través de SSM junto con despliegues inmutables minimiza el riesgo y apoya el cumplimiento normativo mientras se mantiene la capacidad de recuperación.

← Alta Disponibilidad · Todos los dominios · Seguridad →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →