Valida habilidades avanzadas de DevOps incluyendo entrega continua, automatización y gobernanza de seguridad en AWS.
AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeCommit, Pipelines CI/CD, Amazon ECR
AWS CloudFormation, AWS CDK, AWS Systems Manager, AWS OpsWorks, Amazon EC2 Image Builder, AWS Service Catalog
Diseño Multi-AZ y Multi-Region, Auto Scaling, Conmutación por error de Amazon Route 53, AWS Backup, Estrategias RTO y RPO, Patrones de recuperación ante desastres
Amazon CloudWatch, AWS CloudTrail, Amazon EventBridge, AWS X-Ray, Amazon OpenSearch Service, VPC Flow Logs
Reglas de Amazon EventBridge, Corrección automática con AWS Lambda, Automatización de AWS Systems Manager, Notificaciones de Amazon SNS, AWS Health Dashboard, Respuesta de Amazon GuardDuty
AWS IAM, SCP y límites de permisos, AWS KMS y Secrets Manager, Reglas de AWS Config, AWS Security Hub, Amazon Inspector, Gobernanza de AWS CloudTrail
Prueba preguntas tipo examen del conjunto de muestra gratuito. Cada respuesta incluye una explicación completa.
Una startup de medios implementa y opera manualmente varias aplicaciones monolíticas en instancias EC2.
Con cada despliegue, los ingenieros de operaciones acceden directamente a los servidores para instalar paquetes y modificar archivos de configuración, y las reversiones manuales toman varias horas cuando los despliegues fallan. La gerencia está exigiendo que las aplicaciones sean contenerizadas para garantizar la consistencia del despliegue y construir un pipeline de CI/CD automatizado desde la compilación hasta las pruebas y el despliegue en producción cuando hay cambios de código. Al mismo tiempo, dado que el equipo de operaciones tiene personal limitado, la carga de gestión de la infraestructura de orquestación de contenedores debe minimizarse.
¿Cuál es el enfoque de modernización de CI/CD basado en contenedores MÁS apropiado que cumple con estos requisitos mientras minimiza la sobrecarga operacional?
Respuesta: C. ECS Fargate + CodePipeline + CodeBuild
Para seleccionar la respuesta correcta, primero debe comprender la diferencia en la sobrecarga operacional entre ECS Fargate, ECS EC2 y EKS. Los requisitos clave en este escenario son 'contenedorización', 'CI/CD automatizado desde la compilación hasta el despliegue en producción' y 'minimizar la carga de gestión de la infraestructura de orquestación de contenedores'. La combinación ECS Fargate + CodePipeline + CodeBuild tiene a Fargate delegando completamente el aprovisionamiento, parcheo y escalado de instancias EC2 a AWS, CodePipeline orquestando el pipeline desde el commit de código hasta build, test y deploy, y CodeBuild construyendo imágenes Docker y enviándolas a ECR en un entorno de build sin servidor.
ECS Fargate es un modo de ejecución de contenedores sin servidor donde AWS gestiona completamente las instancias EC2 subyacentes necesarias para ejecutar contenedores — solo especifica la combinación de vCPU (0,25–16 vCPU) y memoria (512MB–120GB) en la definición de tarea, y se aprovisiona automáticamente un entorno aislado dedicado. CodePipeline define etapas Source → Build → Test → Deploy e integra con CodeBuild, ECR y ECS en cada etapa. CodeBuild usa comandos en buildspec.yml para construir imágenes y enviar a ECR, y la integración del despliegue blue/green de CodeDeploy con los servicios ECS automatiza el cambio de tráfico y la reversión.
El ECS EC2 de la Opción 1 requiere gestionar directamente clusters de instancias EC2, generando sobrecarga operacional adicional para parcheo de AMI y gestión de políticas de escalado de instancias. El EKS + Jenkins + Helm de la Opción 2 crea cargas de gestión en tres capas — grupos de nodos del cluster EKS, servidores master/agente de Jenkins y charts Helm — convirtiéndolo en el MÁS distante del requisito 'minimizar carga operacional'. Las imágenes de contenedor Lambda de la Opción 4 son inadecuadas para aplicaciones web monolíticas de larga ejecución debido al límite máximo de tiempo de ejecución de 15 minutos y el límite de tamaño de imagen de 10GB. Cuando 'contenedorización + automatización de CI/CD + minimizar sobrecarga de gestión' aparecen juntos en una pregunta de examen, seleccione Fargate + CodePipeline + CodeBuild primero.
Una empresa de educación en línea opera una aplicación web en un grupo Auto Scaling administrado por CloudFormation.
Cada vez que se lanza una nueva AMI, la plantilla de lanzamiento debe actualizarse y las instancias existentes deben reemplazarse. Sin embargo, si demasiadas instancias se terminan simultáneamente durante el proceso de reemplazo, la capacidad del servicio se vuelve insuficiente y los tiempos de respuesta de los usuarios aumentan drásticamente. El equipo de operaciones desea reemplazar instancias gradualmente mientras siempre mantiene el número mínimo de instancias saludables durante las actualizaciones de la pila de CloudFormation, y este proceso debe realizarse automáticamente sin intervención manual.
¿Cuál es la estrategia de actualización basada en CloudFormation MÁS apropiada que cumple con este requisito?
Respuesta: B. AutoScalingRollingUpdate
Los requisitos MÁS críticos en este escenario son 'durante las actualizaciones de la pila de CloudFormation', 'reemplazo gradual de instancias', 'mantenimiento de un número mínimo de instancias saludables' y 'automatizado sin intervención manual'. La política AutoScalingRollingUpdate de CloudFormation se define bajo el atributo UpdatePolicy, lo que permite la especificación declarativa de MaxBatchSize para el número máximo de instancias a reemplazar a la vez y MinInstancesInService para el número mínimo de instancias saludables a mantener durante el reemplazo. Como función nativa de CloudFormation, el reemplazo gradual se realiza automáticamente solo con actualizaciones de la pila, sin herramientas adicionales.
La política AutoScalingRollingUpdate tiene tres parámetros clave. MaxBatchSize controla el número máximo de instancias reemplazadas simultáneamente, MinInstancesInService especifica el número mínimo de instancias que deben permanecer en servicio durante el reemplazo, y configurar WaitOnResourceSignals en true hace que CloudFormation espere hasta recibir cfn-signal de las nuevas instancias antes de proceder al siguiente lote. CloudFormation ajusta automáticamente el ritmo de reemplazo para evitar que el recuento de instancias caiga por debajo de MinInstancesInService mientras reemplaza instancias en lotes secuencialmente.
Cuando 'CloudFormation', 'reemplazo gradual de instancias' y 'mantenimiento de instancias saludables mínimas' aparecen juntos en una pregunta de examen, seleccione AutoScalingRollingUpdate primero. AutoScalingReplacingUpdate reemplaza todo el grupo existente con un nuevo grupo, requiriendo el doble de capacidad durante el reemplazo, lo cual no es 'reemplazo gradual'. CloudFormation StackSets está especializado en implementaciones multi-cuenta y multi-región y no está relacionado con el reemplazo de instancias dentro de un grupo Auto Scaling en una sola pila.
Una empresa fintech opera una aplicación web con múltiples instancias EC2 detrás de un ALB.
La aplicación depende de una base de datos backend y una API de pago externa. Recientemente, incluso cuando ocurren fallas de conexión con la base de datos, la verificación de estado TCP predeterminada del ALB juzga las instancias como saludables, haciendo que las respuestas de error lleguen a los usuarios. El equipo de operaciones quiere implementar una verificación de estado que refleje no solo la instancia en sí, sino también el estado de conectividad de los servicios dependientes críticos de esa instancia, para que el tráfico hacia la instancia se bloquee automáticamente cuando los servicios dependientes fallen.
¿Qué enfoque mejor cumple este requisito minimizando los cambios en la infraestructura existente?
Respuesta: C. Endpoint de verificación de estado HTTP profunda del ALB
Para seleccionar la respuesta correcta, primero debe comprender la diferencia entre la verificación de estado TCP y HTTP del ALB. Una verificación de estado TCP solo verifica si un puerto está abierto, por lo que si el proceso de la aplicación está activo a pesar de un fallo de conexión con la base de datos, la instancia se juzga como saludable. La verificación de estado HTTP profunda del ALB evalúa el estado de la instancia según el código de respuesta HTTP de una ruta específica implementada por la aplicación. Cuando el endpoint /health confirma la conectividad de la base de datos y la API de pagos y devuelve 503 en caso de fallo, el ALB elimina automáticamente la instancia del grupo de destino. Dado que solo el método de verificación de estado en el Target Group necesita cambiarse a HTTP y agregar un endpoint /health a la aplicación sin cambiar la infraestructura ALB existente, cumple el requisito de 'minimizar cambios en la infraestructura existente'.
La verificación de estado HTTP del ALB configura ruta, rango de código de estado HTTP saludable, intervalo, umbrales saludables/no saludables y tiempo de espera en la configuración del Target Group. Establecer el umbral saludable en 2-3 evita falsos positivos por inestabilidad de conexión transitoria, y las instancias que alcanzan el umbral no saludable se eliminan automáticamente del Target Group. Después de que las verificaciones de estado se recuperen al umbral saludable, las instancias se readicionan automáticamente, implementando un mecanismo de auto-recuperación.
En el examen, es fácil confundir con Route 53 Failover (Opción 1). Route 53 realiza failover a nivel DNS, que no puede controlar granularmente el tráfico a nivel de instancia individual, y el TTL de DNS dificulta el bloqueo inmediato. CloudWatch Alarm + reemplazo de Auto Scaling (Opción 2) reemplaza instancias no saludables con nuevas, tardando minutos, y las nuevas instancias experimentarán el mismo problema mientras persista el fallo del servicio dependiente. Cuando vea requisitos para 'basado en ALB + detección de estado de servicio dependiente + bloqueo inmediato,' el endpoint de verificación de estado HTTP profunda es el patrón clave.
Una institución financiera está operando un pipeline CI/CD usando CodePipeline y CodeBuild.
Durante la etapa de build, el proyecto CodeBuild necesita descargar archivos de bibliotecas de terceros desde un bucket S3 específico, pero el equipo de seguridad requiere la aplicación estricta del principio de privilegio mínimo para que el entorno de build no pueda acceder a otros buckets S3 o recursos de AWS. Además, almacenar credenciales de larga duración en el entorno de build está prohibido por la política de auditoría.
¿Qué enfoque MEJOR cumple con estos requisitos al configurar CodeBuild para acceder de forma segura al bucket S3 específico?
Respuesta: C. CodeBuild Service Role con Privilegio Mínimo
El proyecto CodeBuild de una institución financiera necesita acceder a un bucket S3 específico bajo dos restricciones críticas: el principio de privilegio mínimo que bloquea el acceso a todos los recursos excepto el bucket específico, y una política de auditoría que prohíbe el almacenamiento de credenciales de larga duración en el entorno de build. El enfoque de la Opción 3 de otorgar una política IAM de privilegio mínimo al CodeBuild Service Role satisface ambas condiciones simultáneamente. CodeBuild recibe automáticamente credenciales temporales de AWS STS usando los permisos del Service Role designado durante la ejecución del build, por lo que las credenciales de larga duración nunca se almacenan en el entorno de build.
El CodeBuild Service Role es un rol IAM donde AWS STS (Security Token Service) emite dinámicamente credenciales temporales durante la ejecución del build, permitiendo que CodeBuild acceda a recursos de AWS. Al restringir el campo Resource en la política IAM a un ARN de bucket S3 específico (arn:aws:s3:::my-libs-bucket/*) y otorgar solo el permiso s3:GetObject, el acceso a todos los demás buckets S3 y recursos de AWS se bloquea. Las credenciales temporales son válidas solo para la sesión de build y expiran automáticamente después de completar el build, minimizando el riesgo de filtración.
En el examen, el acceso de CodeBuild a los recursos de AWS siempre se resuelve con Service Role + política IAM. Cuando 'privilegio mínimo' y 'sin credenciales de larga duración' aparecen juntos, el Service Role es la única respuesta correcta. Las Access Keys en variables de entorno violan el almacenamiento de credenciales de larga duración, y las credenciales almacenadas en Secrets Manager siguen siendo credenciales de larga duración y no satisfacen completamente la política de auditoría.
Una gran empresa de e-commerce opera cientos de instancias EC2.
Una revisión regular de costos informa que un número significativo de instancias está sobre-provisionado con una utilización promedio de CPU por debajo del 5%. El equipo de operaciones analiza manualmente las métricas de CloudWatch para cada instancia para determinar los tipos de instancia apropiados, pero este proceso lleva semanas debido al gran número de instancias. La gerencia requiere que las recomendaciones de dimensionamiento de instancias alineadas con las características de la carga de trabajo se deriven automáticamente para la reducción de costos y deben ser aplicables sin degradación del rendimiento.
¿Qué enfoque mejor cumple este requisito minimizando la sobrecarga operacional?
Respuesta: B. Recomendaciones de AWS Compute Optimizer
AWS Compute Optimizer cumple simultáneamente tres requisitos en este escenario: automatización, dimensionamiento sin riesgo de rendimiento y overhead operacional mínimo. Compute Optimizer usa aprendizaje automático para analizar métricas de CloudWatch (utilización de CPU, E/S de red, E/S de disco, memoria — agente CloudWatch requerido) y deriva automáticamente recomendaciones de tipo de instancia óptimo y niveles de riesgo de rendimiento (bajo, medio, alto) para cada instancia. Sin analizar manualmente cientos de instancias durante semanas, puede ver inmediatamente el estado de toda la organización e identificar precisamente las instancias que pueden reducirse sin degradación del rendimiento.
Compute Optimizer analiza un mínimo de 14 días de métricas y puede extenderse hasta 93 días con la opción Enhanced Infrastructure Metrics para capturar patrones de carga de trabajo periódicos. Los resultados de recomendaciones proporcionan tipo actual, tipo recomendado, ahorro de costos estimado y nivel de riesgo de rendimiento por instancia, clasificados en cuatro categorías: sobreprovisionado, óptimo, subprovisionado y datos insuficientes. El opt-in a nivel de organización a través de AWS Organizations permite la gestión centralizada de recomendaciones incluso en entornos multi-cuenta.
En el examen, debe distinguir Trusted Advisor (Opción 3) y Cost Explorer Rightsizing (Opción 4). Trusted Advisor usa reglas de umbral simples basadas en CPU promedio de 14 días por debajo del 10% y no recomienda tipos de instancia de reemplazo específicos, requiriendo planes Business o superiores. Cost Explorer Rightsizing realiza análisis centrado en costos con clasificación de riesgo de rendimiento menos sofisticada. Cuando vea la combinación de palabras clave 'EC2 a gran escala + dimensionamiento automático basado en ML + clasificación de riesgo de rendimiento + operaciones mínimas,' Compute Optimizer es la respuesta correcta.
El examen AWS Certified DevOps Engineer - Professional (DOP-C02) consta de 75 preguntas y tiene un límite de 180 minutos.
La puntuación de aprobación del examen DOP-C02 es de 750 sobre 1000.
El conjunto de muestra de DOP-C02 (20 preguntas con explicaciones completas) es gratuito. El banco completo de más de 280 preguntas está disponible con una suscripción a CloudMasterIT.
La certificación DOP-C02 es válida durante 3 años después de aprobar. Después se requiere recertificación.