En el examen DOP-C02, el dominio de automatizacion del ciclo de vida del desarrollo de software (22%) tiene el mayor peso de los seis dominios. En su nucleo estan CodePipeline, CodeBuild y CodeDeploy trabajando en conjunto. El examen no solo prueba si conoces estos servicios — prueba si puedes identificar la combinacion correcta para requisitos especificos y reconocer las trampas comunes.
Arquitectura profunda de CodePipeline
CodePipeline es un orquestador, no un constructor ni un desplegador. Conecta las etapas de origen, compilacion, prueba y despliegue en un flujo de trabajo automatizado unico, invocando el servicio adecuado en cada paso y esperando los resultados antes de continuar.
Estructura de etapas del pipeline
Un pipeline de produccion tipico tiene este aspecto:
Source: Detecta cambios de codigo en CodeCommit, GitHub (a traves de CodeStar Connections) o S3 y activa el pipeline Build: CodeBuild compila, ejecuta pruebas unitarias, construye imagenes Docker y produce artefactos Test: CodeBuild ejecuta pruebas de integracion, escaneos de seguridad y puertas de calidad Staging Deploy: CodeDeploy o CloudFormation despliega en el entorno de preparacion Approval: Accion de aprobacion manual cuando los requisitos de cumplimiento exigen aprobacion humana Production Deploy: CodeDeploy despliega en produccion con la estrategia de despliegue seleccionada
Acciones paralelas vs secuenciales
Multiples acciones dentro de una sola etapa se ejecutan en paralelo. Por ejemplo, las pruebas unitarias y el analisis estatico de codigo pueden ejecutarse simultaneamente para reducir el tiempo total de ejecucion del pipeline. Las acciones en etapas separadas se ejecutan secuencialmente. Esta distincion importa para disenar pipelines eficientes que minimicen el tiempo de retroalimentacion.
Pipelines de cuentas cruzadas
Un patron comun en grandes empresas — y un tema frecuente en el examen — es ejecutar CodePipeline en una cuenta de herramientas central y desplegar en cuentas de preparacion y produccion separadas. Esto requiere crear roles de IAM de cuentas cruzadas en cada cuenta de destino con permisos de despliegue, otorgar al rol de servicio de CodePipeline permiso para asumir esos roles via STS, y configurar politicas de bucket de S3 y politicas de clave KMS para permitir el acceso desde las cuentas de origen y destino.
Analisis profundo del buildspec.yml de CodeBuild
El archivo buildspec.yml define el proceso de compilacion completo. Un detalle de comportamiento critico: si la fase de compilacion falla, los comandos posteriores en esa fase dejan de ejecutarse — pero post_build siempre se ejecuta independientemente. Esta es la fuente de un error comun del mundo real que el examen prueba directamente.
Estructura del buildspec.yml
Variable de entorno CODEBUILD_BUILD_SUCCEEDING
Este es un tema importante que aparece directamente en el examen. Aunque la fase de build falle por un error en las pruebas unitarias, la fase post_build siempre se ejecuta. Sin una comprobacion explicita, una imagen Docker defectuosa podria ser empujada a ECR y convertirse en candidata de despliegue.
La variable CODEBUILD_BUILD_SUCCEEDING se establece en 1 si todas las fases anteriores tuvieron exito, y en 0 si alguna fase fallo. Usa esta variable en post_build para condicionar el envio de la imagen: si el valor es 0, omite el docker push y termina con codigo de salida 1 para marcar el build como fallido. Este patron evita que imagenes defectuosas lleguen a produccion.
Integracion de secretos y configuracion
CodeBuild admite tres metodos para inyectar secretos:
env.variables: Texto plano (evitar para valores sensibles — visible en CloudTrail y registros) env.parameter-store: Referencia rutas de SSM Parameter Store (apropiado para configuracion no sensible) env.secrets-manager: Referencia IDs de secretos de Secrets Manager (apropiado para credenciales)
El rol de servicio de CodeBuild debe tener permisos de IAM para acceder a las rutas de Parameter Store referenciadas y a los secretos de Secrets Manager. El examen prueba este patron cuando las preguntas involucran a CodeBuild accediendo a credenciales de base de datos o claves de API.
Arquitectura de integracion de pruebas automatizadas
Estrategia de colocacion por tipo de prueba
Las pruebas unitarias pertenecen a la fase de compilacion — se ejecutan en milisegundos a segundos y deben bloquear la compilacion para que no produzca artefactos si fallan. Las pruebas de integracion requieren dependencias externas (bases de datos, APIs, servicios posteriores) y pueden ejecutarse desde minutos hasta horas.
Una pregunta directa de escenarios reales de DOP-C02: "Las pruebas de integracion requieren hasta 2 horas. Como debe manejar esto el pipeline?" La respuesta correcta es anadir un proyecto de CodeBuild dedicado como accion de etapa de prueba. CodePipeline espera automaticamente a que CodeBuild se complete y usa el codigo de salida para determinar el exito o el fracaso. Lambda (maximo 15 minutos de ejecucion) es explicitamente incorrecta en este escenario y aparece como opcion trampa.
CodeGuru Reviewer para puertas de calidad de codigo
Amazon CodeGuru Reviewer se integra con CodeCommit y GitHub para revisar automaticamente las solicitudes de extraccion en busca de problemas de calidad de codigo, vulnerabilidades de seguridad y patrones de uso indebido de la API de AWS. Admite Java y Python. Cuando una pregunta del examen pregunta sobre "revision automatizada de codigo para solicitudes de extraccion" o "deteccion de credenciales codificadas antes de la fusion," CodeGuru Reviewer es el servicio objetivo.
Verificaciones de estado y validacion de despliegue
Hook ValidateService de CodeDeploy
El hook de ciclo de vida ValidateService en appspec.yml se ejecuta despues de que el despliegue se completa. Un script de validacion puede realizar pruebas de humo — verificar si la aplicacion responde a los endpoints de verificacion de estado, verificar la funcionalidad critica o confirmar la conectividad de la base de datos. Si el script de validacion sale con un codigo distinto de cero, CodeDeploy activa el retroceso automatico.
Verificacion de estado ALB y CodeDeploy
En despliegues basados en EC2, ALB realiza verificaciones de estado de cada instancia antes de enviarle trafico de produccion. CodeDeploy se integra con estas verificaciones de estado de ALB como criterio de exito del despliegue. Si una instancia recien desplegada no supera las verificaciones de estado de ALB dentro del tiempo de espera configurado, CodeDeploy marca el despliegue como fallido y activa el retroceso automatico. Esta integracion garantiza que solo las instancias saludables y completamente inicializadas reciban trafico real de usuarios.
Patron de oyente de prueba Blue/Green de ECS
Para los despliegues Blue/Green de ECS, CodeDeploy configura ALB con dos oyentes: el oyente de produccion (puerto 80/443) dirigido al conjunto de tareas Blue, y un oyente de prueba (tipicamente el puerto 8080) dirigido al conjunto de tareas Green. El hook BeforeAllowTraffic ejecuta una funcion Lambda que envia solicitudes de prueba al entorno Green a traves del oyente de prueba. Esto valida la nueva version de forma aislada antes de que cualquier trafico de produccion la toque. Solo despues de que el hook tenga exito CodeDeploy desplaza el trafico de produccion de Blue a Green. Un fallo en cualquier punto activa el retroceso automatico a Blue.
Puntos clave del examen
"bloquear el envio a ECR cuando las pruebas unitarias fallan en CodeBuild" -- verificar la variable CODEBUILD_BUILD_SUCCEEDING en la fase post_build y omitir condicionalmente el comando docker push
"pruebas de integracion que requieren 2 horas en el pipeline" -- proyecto de CodeBuild dedicado en una accion de etapa de prueba (el limite de 15 minutos de Lambda lo hace incorrecto)
"validar el entorno Green antes de la transicion de trafico con retroceso automatico" -- hook BeforeAllowTraffic de CodeDeploy que ejecuta una funcion Lambda para la validacion
"despliegue de pipeline de cuentas cruzadas" -- rol de IAM de cuentas cruzadas en la cuenta de destino + permiso AssumeRole en el rol de servicio de CodePipeline + configuracion de politica de S3 y KMS
"referencias seguras a credenciales de base de datos en CodeBuild" -- seccion env.secrets-manager en buildspec.yml (no env.variables que expone secretos en los registros)
"revision automatizada de codigo de solicitudes de extraccion para Java o Python" -- Amazon CodeGuru Reviewer integrado con CodeCommit o GitHub
"despliegue secuencial en preparacion y luego en produccion con puerta humana opcional" -- unico CodePipeline con etapa de despliegue de preparacion + accion opcional de aprobacion manual + etapa de despliegue de produccion
"ejecucion de pruebas paralelas en el pipeline" -- multiples acciones dentro de la misma etapa del pipeline (cada accion referencia un proyecto de CodeBuild diferente)