Amazon DOP-C02: Infraestructura como Código y Gestión de la Configuración — Guía de estudio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Descripción general

La infraestructura como código (IaC) y la gestión de la configuración en AWS proporcionan un aprovisionamiento y una configuración de infraestructura y aplicaciones que son repetibles, auditables y gobernados. CloudFormation y el AWS Cloud Development Kit (CDK) describen los recursos de forma declarativa o mediante código que se sintetiza en CloudFormation. Las capas de configuración como AWS OpsWorks y AWS Systems Manager imponen y reportan el estado deseado en las instancias a través de flotas de EC2 e híbridas. Los secretos, los parámetros y la creación de imágenes (image-baking) completan el ciclo de vida, permitiendo despliegues inmutables y seguros a escala.

Pilas de CloudFormation, control de cambios y gobernanza

Las pilas (stacks) de CloudFormation son la unidad de despliegue. Diseñe las pilas en torno a los límites del ciclo de vida y la propiedad para minimizar el radio de impacto (blast radius). Use los parámetros con moderación y prefiera valores predeterminados bien definidos (opinionated defaults) con mapeos o búsquedas en SSM. Exporte e importe solo valores estables y compartidos a través de Outputs y Fn::ImportValue para evitar un acoplamiento estrecho.

Las pilas anidadas encapsulan componentes reutilizables y mantienen pequeñas las plantillas principales. Una pila principal puede pasar parámetros a las pilas secundarias y consumir sus salidas, lo que permite arquitecturas modulares (por ejemplo, una pila anidada de red compartida consumida por una pila de aplicación). Mantenga las pilas anidadas enfocadas en una única responsabilidad (VPC, capa de datos, capa de aplicación) y gestione sus versiones de forma independiente.

Los StackSets despliegan una única plantilla en múltiples cuentas y regiones. Utilice el modelo de permisos gestionado por el servicio con AWS Organizations para desplegar automáticamente en OUs e incluir automáticamente nuevas cuentas. Configure las preferencias de operación (máximo de cuentas/regiones concurrentes, tolerancia a fallos) para controlar el despliegue. Las anulaciones de parámetros por cuenta o región le permiten adaptar una plantilla estándar a las restricciones locales. Supervise la deriva (drift) de los StackSet y de las instancias de pila para detectar cambios fuera de banda.

Los conjuntos de cambios (change sets) proporcionan actualizaciones seguras y revisables por humanos. Siempre use CreateChangeSet e inspeccione el impacto recurso por recurso, los reemplazos y la posible pérdida de datos antes de usar ExecuteChangeSet. Integre los conjuntos de cambios en canalizaciones automatizadas para aprobaciones controladas.

La detección de deriva (drift) valida que los recursos de la pila coincidan con la plantilla. Ejecute la detección de deriva de forma rutinaria en pilas y StackSets críticos; entienda que no todas las propiedades se evalúan para todos los tipos de recursos (las propiedades no compatibles se reportan como “no verificadas”). Trate la deriva como un incidente: investigue, capture el contexto y corríjala ya sea mediante una actualización de la pila o codificando la deriva y volviendo a aplicarla.

Las políticas de pila (stack policies) son documentos JSON que protegen los recursos críticos durante las actualizaciones. Deniegue las actualizaciones a recursos irremplazables (por ejemplo, bases de datos de producción, zonas de Route 53) y use StackPolicyDuringUpdateBody para abrir temporalmente una vía quirúrgica para un cambio específico, y luego restaure la política más estricta. Combine con la protección contra la terminación y DeletionPolicy (Retain/Snapshot) para tener barreras de protección (guardrails). Para recursos con estado externo (buckets de S3), planifique los comportamientos de eliminación. Si un bucket debe vaciarse antes de su eliminación, implemente un recurso personalizado para purgar los objetos al eliminar la pila.

AWS CDK y extensibilidad de CloudFormation

AWS CDK modela la infraestructura en lenguajes familiares (TypeScript, Python, Java, .NET, Go). Los constructs son los bloques de construcción de CDK:

• Los constructs L1 (CfnXxx) se generan a partir de la especificación de CloudFormation y se mapean uno a uno con los recursos.
• Los constructs L2 añaden una intención de alto nivel y valores predeterminados sensatos (por ejemplo, ApplicationLoadBalancedFargateService).
• Los “patrones” L3 componen múltiples L2 para arquitecturas listas para usar.

Una aplicación de CDK contiene una o más pilas. Durante cdk synth, la aplicación resuelve las búsquedas de contexto (por ejemplo, ID de VPC), renderiza los activos y produce una plantilla de CloudFormation. Antes de desplegar, cdk bootstrap crea los buckets de activos y los roles del entorno. Use cdk diff para previsualizar los cambios, luego cdk deploy para enviar las plantillas y los activos; CDK utiliza internamente conjuntos de cambios y mostrará y confirmará los cambios sensibles a la seguridad (IAM o reemplazos de recursos). Etiquete las pilas y los recursos a través de Aspects para hacer cumplir el etiquetado en toda la organización. Donde las abstracciones L2 se queden cortas, utilice las vías de escape (escape hatches) (node.defaultChild) o baje al nivel de los constructs L1.

Los recursos personalizados de CloudFormation extienden la IaC a cualquier cosa accesible a través de APIs. Un recurso personalizado respaldado por Lambda recibe eventos Create, Update y Delete con un RequestId, un PhysicalResourceId y propiedades. La función debe:

• Ser idempotente y devolver éxito/fracaso a la ResponseURL pre-firmada dentro del período de tiempo de espera.
• Establecer un PhysicalResourceId estable para rastrear las actualizaciones e impulsar la limpieza en el evento Delete.
• Manejar reintentos y esperas de estabilización para servicios dependientes con consistencia eventual.

Use roles de ejecución de IAM con el mínimo privilegio para la Lambda, incluya un retroceso exponencial (exponential-backoff) en las llamadas a la API y correlacione los registros a través del RequestId. Para operaciones grandes o de larga duración, considere usar Step Functions con un recurso personalizado que espere un token de ejecución. Prefiera el CloudFormation Registry para proveedores reutilizables y versionados cuando sea aplicable.

Secretos y parámetros en la infraestructura como código

Nunca codifiques secretos directamente en las plantillas o el código. Utiliza referencias dinámicas para resolver los valores sensibles en el momento del despliegue:

• Secrets Manager: {{resolve:secretsmanager:secret-id:SecretString:json-key:version-stage}}
• SecureString de Parameter Store: {{resolve:ssm-secure:parameter-name:version}}

Las referencias dinámicas evitan que los secretos se almacenen en la plantilla de la pila o en los eventos. No coloques secretos en las salidas (Outputs) ni en las propiedades de los recursos que CloudFormation registra como texto plano. Otorga al rol de ejecución de CloudFormation permiso para descifrar o recuperar los valores referenciados, y limita el alcance de las CMK de KMS a las entidades principales que necesiten acceso.

Parameter Store es ideal para la configuración no secreta (indicadores de características, ID de AMI, puntos de conexión). Usa parámetros de SSM con versiones para crear reversiones seguras y promociones atómicas entre entornos. En CDK, importa valores con ssm.StringParameter.fromStringParameterName o fromSecureStringParameterAttributes para valores seguros, e integra las lecturas de parámetros en los datos de usuario o en los arranques de la aplicación.

Secrets Manager está diseñado para los controles del ciclo de vida, la rotación y la auditoría. Integra la rotación con los motores compatibles (RDS, Aurora) o con Lambdas personalizadas. Haz referencia a los secretos en tiempo de ejecución en lugar de incrustarlos en las AMI para evitar la proliferación de material obsoleto. Para cargas de trabajo en contenedores o sin servidor, inyecta los secretos a través de variables de entorno respaldadas por referencias de Secrets Manager o móntalos a través de los secretos de ECS/TaskDefinition; rota con un tiempo de inactividad mínimo utilizando grupos de conexiones con TTL cortos y reintentos.

Gestión de la configuración e infraestructura inmutable

AWS OpsWorks proporciona una gestión de configuración con un enfoque definido. OpsWorks Stacks utiliza recetarios de Chef y eventos de ciclo de vida (Setup, Configure, Deploy, Undeploy, Shutdown) para orquestar la configuración y los despliegues de aplicaciones, y admite la autorreparación con comprobaciones de estado que detienen/inician o reemplazan instancias. Históricamente, OpsWorks también ofrecía Chef Automate y Puppet Enterprise gestionados; hoy en día, muchos equipos estandarizan en Systems Manager para la orquestación basada en agentes o ejecutan sus propios planos de control de Ansible/Chef/Puppet. Ansible no está integrado de forma nativa con OpsWorks; en su lugar, utilice Systems Manager State Manager para ejecutar playbooks, o AWX/Ansible Automation Platform con conectividad de SSM Session Manager e inventario dinámico de EC2.

AWS Systems Manager es el plano de control moderno para la configuración híbrida:

• State Manager impone el estado deseado a través de asociaciones (Associations) que ejecutan documentos de SSM (YAML/JSON) según una programación, un evento o al iniciar una instancia. Utilice

undefined

,

undefined

,

undefined

y documentos personalizados para hacer converger la configuración. Parametrice las asociaciones y establezca los destinos por etiquetas para realizar cambios en toda la flota.

• La conformidad de la configuración (Configuration compliance) expone el estado de las asociaciones y los resultados de Patch Manager. Utilice líneas base de parches (patch baselines) para definir clasificaciones aprobadas, vincularlas a ventanas de mantenimiento (Maintenance Windows) y hacer un seguimiento del cumplimiento por etiqueta de instancia, grupo de parches o grupo de recursos. Las activaciones híbridas (Hybrid Activations) incorporan nodos locales como instancias gestionadas para una gobernanza uniforme.
• El inventario (Inventory) registra paquetes, archivos y actualizaciones de Windows; la sincronización de datos de recursos (Resource Data Sync) exporta a S3 y Athena para informes empresariales. Combine el cumplimiento de SSM con las reglas de AWS Config y la remediación automática (runbooks de Systems Manager Automation) para cerrar el ciclo desde la detección hasta la corrección.

La infraestructura inmutable elimina la desviación de configuración (drift) y acelera la reversión (rollback). EC2 Image Builder codifica los pipelines de imágenes con:

• Componentes (pasos de instalación, fortalecimiento y validación) expresados como documentos.
• Recetas de imagen que componen componentes e imágenes base.
• Configuraciones de infraestructura que definen subredes, grupos de seguridad, perfiles de instancia y registro.
• Configuraciones de distribución para replicar AMIs en regiones y compartirlas con otras cuentas.

Añada componentes de prueba para validar los benchmarks de CIS, la salud de los agentes (SSM/CloudWatch) y las pruebas de humo (smoke checks) de la aplicación. Versione las imágenes y etiquételas con etiquetas semánticas. Publique los ID de AMI en Parameter Store (por ejemplo, /app/frontend/ami) y haga referencia a ellos en las plantillas de lanzamiento de Auto Scaling. Despliegue con estrategias continuas (rolling) o azul/verde (blue/green); reemplace las instancias en lugar de aplicar parches in situ para preservar la inmutabilidad. Incorpore los análisis de vulnerabilidades (Amazon Inspector) en las puertas de promoción del pipeline. No incruste secretos en las imágenes; recupérelos en el arranque a través del Servicio de Metadatos de Instancia v2 y referencias de SSM/Secrets Manager.

Escenario de un problema práctico

Capital One necesita estandarizar los despliegues multicuenta y multirregión para una plataforma de cara al cliente, al tiempo que impone una gobernanza estricta, gestión de secretos y la eliminación de la desviación de configuración. El entorno abarca cientos de cuentas en AWS Organizations, con controles estrictos sobre el acceso a las bases de datos y el fortalecimiento del sistema operativo.

1. Modelar la infraestructura con AWS CDK y sintetizar a CloudFormation

• Implementar constructos L2/L3 para VPCs, ALBs, grupos de Auto Scaling y Aurora. Usar

undefined

y

undefined

en CI para generar y validar plantillas y conjuntos de cambios.

• Por qué CDK: Composición y reutilización robustas a través de constructos, políticas programáticas a través de Aspects para etiquetado y barreras de protección (guardrails) a nivel de organización, y integración nativa con CloudFormation para la auditabilidad.

2. Distribuir pilas base de red y barreras de protección mediante CloudFormation StackSets

• Crear StackSets gestionados por el servicio dirigidos a las OU de seguridad y sandbox para desplegar endpoints de VPC compartidos, alarmas de CloudWatch estándar y límites de IAM. Habilitar el despliegue automático en nuevas cuentas con tolerancia a fallos y controles de concurrencia.
• Por qué StackSets: Despliegue consistente a escala de la organización con inclusión automática de nuevas cuentas y detección de desviaciones (drift) integrada.

3. Proteger recursos críticos con políticas de pila y conjuntos de cambios

• Aplicar políticas de pila (stack policies) que denieguen actualizaciones a los clústeres de Aurora y las zonas de Route 53. Requerir

undefined

y aprobación manual antes de

undefined

en el pipeline para producción.

• Por qué políticas de pila/conjuntos de cambios: Imponer mutaciones de mínimo privilegio y proporcionar una revisión humana antes de cambios de alto riesgo.

4. Ampliar la IaC con recursos personalizados respaldados por Lambda

• Implementar un

undefined

para vaciar los buckets de la aplicación al eliminar la pila y un

undefined

que aplica parámetros del motor después de la creación.

• Por qué recursos personalizados: Cerrar brechas funcionales en el aprovisionamiento declarativo mientras se mantiene el ciclo de vida ligado a la pila.

5. Centralizar secretos y configuración con Secrets Manager y Parameter Store

• Almacenar credenciales de bases de datos y claves de API en Secrets Manager con Lambdas de rotación; publicar ID de AMI, indicadores de funcionalidad (feature flags) y endpoints en Parameter Store. Hacer referencia a los valores mediante referencias dinámicas en CloudFormation e importaciones de CDK en tiempo de ejecución para las aplicaciones.
• Por qué estos servicios: Separación de responsabilidades: secretos con rotación y auditoría, parámetros para configuración no secreta y fácil promoción.

6. Imponer el estado deseado y el cumplimiento mediante Systems Manager State Manager

• Crear asociaciones (associations) para instalar agentes, configurar ajustes del SO y aplicar playbooks de Ansible donde sea necesario. Usar Patch Manager con ventanas de mantenimiento (Maintenance Windows) para la aplicación de parches fuera del horario laboral y paneles de cumplimiento agregados por Resource Data Sync.
• Por qué State Manager: Convergencia basada en agentes a través de EC2 y entornos locales con informes continuos de cumplimiento y remediación a escala.

7. Adoptar una infraestructura inmutable con EC2 Image Builder

• Construir AMIs fortalecidas con componentes para las líneas base de CIS, agentes de SSM/Inspector y dependencias de tiempo de ejecución de la aplicación. Ejecutar pruebas, publicar los ID de AMI en Parameter Store y conectar las plantillas de lanzamiento de Auto Scaling a los parámetros versionados. Desplegar mediante actualizaciones continuas (rolling updates); desencadenar una actualización de instancias (instance refresh) al actualizar las AMIs.
• Por qué Image Builder: Imágenes reproducibles y comprobables que eliminan la desviación (drift) y reducen el tiempo medio de recuperación (MTTR) mediante reversiones rápidas.

8. Orquestación y gobernanza del pipeline

• Implementar un pipeline de múltiples etapas que ejecute

undefined

, cree conjuntos de cambios, pause para aprobación y luego ejecute. Usar EventBridge para desencadenar actualizaciones de StackSet ante cambios en el repositorio. Añadir escaneos de detección de desviaciones nocturnos y abrir ítems en OpsCenter para las discrepancias.

• Por qué este enfoque: Entrega continua con promociones auditables, detección proactiva de desviaciones y remediación automatizada a través de responsabilidades de servicio bien definidas.

← Canalizaciones de CI · Todos los dominios · Monitoreo →

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

Explorar Amazon →