Amazon SAP-C02: Despliegue, Automatización y DevOps — Guía de estudio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Forma parte de la AWS Solutions Architect Professional SAP-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Infraestructura como Código y Gestión de Entornos

Considere la infraestructura como código (IaC) como la única fuente de verdad para los entornos, integrando redes, IAM y la topología de la aplicación en artefactos reutilizables y versionados. Elija CloudFormation para un control estricto y declarativo y una integración profunda con AWS, y utilice el AWS Cloud Development Kit (CDK) cuando las construcciones de nivel superior y las abstracciones nativas del lenguaje mejoren la productividad de los desarrolladores; fuerce siempre a la CI a sintetizar el CDK en plantillas y a almacenar los artefactos en un bucket de S3 cifrado y versionado. Utilice CloudFormation StackSets para una instanciación de stacks consistente entre cuentas y regiones y habilite la detección de desviaciones (drift) combinada con la remediación automatizada a través de Systems Manager cuando la desviación indique entropía en la configuración. Cree imágenes doradas (golden images) con EC2 Image Builder o Packer y publique las AMIs en cuentas y regiones a través de pipelines automatizados; esto soporta despliegues inmutables y reduce la desviación de configuración posterior al lanzamiento. Sea deliberado con los conjuntos de cambios (change sets) de CloudFormation, la protección contra terminación y las políticas de actualización para evitar el reemplazo involuntario de recursos que puede causar pérdida de datos. Las trampas comunes incluyen incrustar secretos en las plantillas, depender de cambios manuales negligentes que rompen la detección de desviaciones u otorgar roles de ejecución de CloudFormation demasiado amplios; restrinja los roles de ejecución al mínimo privilegio y conserve el historial de CloudTrail y Config para la auditabilidad. Las compensaciones son claras: CDK acelera el desarrollo, pero requiere una CI/CD disciplinada para evitar stacks en tiempo de ejecución no sincronizados; CloudFormation puro es más rígido, pero inmediatamente auditable.

Pipelines de CI/CD y Estrategias de Despliegue

Diseñe pipelines que separen las etapas de construcción (build), prueba (test) y despliegue (deploy) y que tomen decisiones de reversión (rollback) de forma automática. AWS CodePipeline, CodeBuild y CodeDeploy proporcionan una ruta completamente gestionada para los flujos desde el código fuente hasta la producción, mientras que los sistemas de terceros (GitHub Actions, Jenkins, GitLab) se integran con los servicios de AWS para el almacenamiento de artefactos (S3), los registros de contenedores (ECR) y los hooks de despliegue. Para las estrategias en tiempo de ejecución, prefiera despliegues inmutables o azul/verde (blue/green) para servicios con estado (stateful) o con sesión (sessionful) para eliminar la desviación de configuración en el sitio (in-place); utilice despliegues canary con desvío de tráfico (traffic shifting) para una reducción incremental del riesgo. Para Lambda, utilice alias y desvío de tráfico ponderado con alarmas de CloudWatch o CodeDeploy para una reversión (rollback) automatizada. Para ECS/EKS, combine controladores de despliegue (CodeDeploy, AWS App Mesh o estrategias nativas de Kubernetes) con el drenaje de grupos de destino (target group draining) del ALB y hooks de ciclo de vida para garantizar un apagado ordenado (graceful shutdown). Tenga cuidado con los cambios en el esquema de la base de datos: diseñe migraciones compatibles con versiones anteriores y utilice indicadores de funcionalidad (feature flags) (AWS AppConfig) o lanzamientos oscuros (dark launches) para desacoplar el despliegue del código de la evolución del esquema. Las consideraciones de costo frente a velocidad son importantes: los despliegues canary ralentizan los lanzamientos, pero minimizan el radio de impacto (blast radius), mientras que los despliegues azul/verde en paralelo duplican el costo de la infraestructura durante la ventana de transición. Integre siempre las políticas de despliegue, las comprobaciones de estado (health checks) y las reversiones (rollbacks) automáticas en los pipelines para evitar la intervención manual durante los incidentes.

Automatización, Conformidad de la Configuración y Observabilidad

La excelencia operativa depende de la remediación automatizada, la configuración consistente y la observabilidad holística. AWS Systems Manager proporciona Parameter Store para la configuración, documentos de Automation para los runbooks, Patch Manager para el mantenimiento de líneas base y Session Manager para la resolución de problemas sin bastiones (bastionless). Utilice EventBridge como el bus de eventos central para la automatización desacoplada: enrute los eventos de CloudTrail, Config o de la aplicación a Lambdas o Step Functions para una remediación orquestada. Aplique barreras de protección (guardrails) con reglas de AWS Config y un Config Aggregator para auditar múltiples cuentas, e implemente playbooks de remediación automatizada a través de Systems Manager o EventBridge para los recursos no conformes (noncompliant). Para la observabilidad, instrumente los servicios con métricas y logs de CloudWatch, habilite X-Ray o la AWS Distro for OpenTelemetry para el rastreo distribuido (distributed tracing) y centralice los logs con suscripciones de CloudWatch Logs o Kinesis Firehose en un lago de datos (data lake) en S3 y una pila de análisis centralizados. Las trampas comunes incluyen la retención de logs ilimitada que dispara los costos, las métricas personalizadas de alta cardinalidad que disparan los costos de las métricas, la falta de IDs de correlación que hacen que los rastreos sean inútiles y no probar los runbooks de remediación en entornos de no producción. Las compensaciones giran en torno a la granularidad de la telemetría frente al costo de ingesta y almacenamiento; el muestreo de rastreos y una retención corta reducen los costos, pero pueden ocultar fallas raras y críticas. Diseñe alertas y paneles (dashboards) enfocados en señales accionables para mantener la sobrecarga operativa manejable.

Rendimiento, servicios con estado, seguridad y consideraciones entre regiones

Elija los servicios de almacenamiento y con estado según el patrón de acceso, las necesidades de latencia y los requisitos de consistencia. Las cachés en memoria proporcionan lecturas de submilisegundos; ElastiCache (Redis) admite conjuntos ordenados (ordered sets) ideales para tablas de clasificación (leaderboards) y ofrece replicación, persistencia y Global Datastore para la localidad de lectura entre regiones. DynamoDB es excelente para el almacenamiento duradero y de alta escala, y se puede combinar con DAX para la aceleración de lecturas, aunque DAX es mejor para el acceso a nivel de elemento que se puede almacenar en caché y tiene contrapartidas de consistencia eventual. Para aplicaciones heredadas (legacy) basadas en archivos, considere Amazon FSx for NetApp ONTAP o Amazon EFS con DataSync para compatibilidad de tipo lift-and-shift; para semánticas SMB/NFS, FSx suele ser la opción de menor riesgo. El cifrado y la replicación conllevan trampas sutiles: las claves de AWS KMS son regionales y deben gestionarse por región para la replicación entre regiones de S3, o bien usar claves multirregionales para simplificar los patrones de acceso; tenga cuidado con las políticas de claves (key policies) y los permisos entre cuentas (cross-account grants). Las funciones Lambda en VPC sufren de arranques en frío (cold-starts) debido a la creación de ENI; mitigue esto con VPC endpoints, paquetes de menor tamaño, concurrencia aprovisionada o usando Lambdas fuera de la VPC con RDS Proxy. Sopese el costo frente a la resiliencia: las tablas globales (Global tables) y la replicación entre regiones mejoran el RTO/RPO a un costo mayor; la concurrencia aprovisionada reduce la latencia pero aumenta el gasto base. Considere las necesidades de durabilidad de los datos, los plazos de recuperación ante desastres (DR) y los límites de recursos por cuenta al elegir las arquitecturas.

Problema práctico: Escenario de caso de uso

Escenario: SkyForge Games opera un entorno de AWS existente con cuentas de producción y de ensayo (staging) en dos regiones. La tabla de clasificación (leaderboard) actual está implementada en DynamoDB y es servida por API de Lambda desplegadas a través de CodePipeline; los jugadores esperan una latencia de lectura de microsegundos y un tiempo de inactividad casi nulo durante los frecuentes lanzamientos de nuevas funcionalidades.

Desafío: Ofrecer lecturas de la tabla de clasificación en microsegundos mientras se mantiene la durabilidad y se construye una canalización de CI/CD segura y automatizada que soporte despliegues rápidos y con capacidad de reversión (rollback) entre cuentas y regiones.

Enfoque recomendado:

Aprovisione un clúster de ElastiCache for Redis con el modo de clúster habilitado (Cluster Mode Enabled) en la región principal para la ruta de acceso crítica (hot-path) de la tabla de clasificación, con réplicas en varias AZ y la persistencia de Redis (AOF) activada; configure Global Datastore para la localidad de lectura en la región secundaria.
Mantenga DynamoDB como la fuente de verdad (source of truth); utilice DynamoDB Streams + Lambda (o Kinesis Data Streams) para actualizar Redis de forma asíncrona, garantizando la consistencia eventual y la capacidad de reproducción (replayability) para la recuperación.
Implemente una canalización basada en CDK (CDK Pipelines o CodePipeline activado por Git) que sintetice plantillas, compile artefactos en S3/ECR cifrados y despliegue la infraestructura a través de CloudFormation StackSets en las cuentas/regiones de destino; incluya pruebas de humo (smoke tests) automatizadas y puertas de aprobación (approval gates).
Despliegue los cambios de la aplicación utilizando una estrategia canary o azul/verde (blue-green): use alias ponderados de Lambda o el cambio de grupos de destino (target-group shifting) del ALB con alarmas de CloudWatch y reversión (rollback) automática; instrumente con CloudWatch, X-Ray y comprobaciones sintéticas de tipo canary.

Justificación: Use Redis para obtener lecturas reales de submilisegundos mientras se conserva la durabilidad y la capacidad de reproducción de DynamoDB; la canalización de CI/CD con CDK y StackSets proporciona despliegues multicuenta consistentes y auditables, y el desvío de tráfico (traffic-shifting) junto con la observabilidad permiten lanzamientos iterativos seguros con una rápida capacidad de reversión.

← Optimización de Costos y Gobernanza · Todos los dominios

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