Amazon DVA-C02: Deployment & CI/CD (CodePipeline, CodeBuild, CodeDeploy, Elastic Beanstalk, Containers) — Study Guide

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Part of the AWS Developer Associate DVA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

CI/CD foundations with CodePipeline and CodeBuild: patterns, APIs, and common pitfalls

Design pipelines with clear stages: source, build, test, approval, deploy, and post-deploy verification. CodePipeline coordinates these stages; use a pipeline role that grants minimal, scoped permissions and configure action roles for third-party integrations. Trigger pipelines via CodeCommit webhooks or StartPipelineExecution (AWS SDK: codepipeline.startPipelineExecution) for programmatic kicks. For builds, prefer CodeBuild projects with buildspec.yml defining phases (install, pre_build, build, post_build); invoke builds directly with StartBuild or StartBuildBatch when you need ad-hoc or batch builds. For image builds, use aws ecr get-login-password piped to docker login in the pre_build phase, then docker build/push to ECR and capture the image digest to produce immutable artifact references. Avoid using floating tags like “latest”; instead emit task definitions or manifest files that reference image digests so deployments are deterministic. Watch for common traps: expired ECR auth tokens in long-running scripts, inadequate CodeBuild IAM policies for pushing to ECR or calling AWS APIs, and hard-coding ARNs. Instrument builds to upload artifacts to S3 or to the pipeline artifact store, and use environment variables and Parameter Store/Secrets Manager for sensitive, runtime-only values rather than baking secrets into build artifacts.

Deployment strategies: CodeDeploy, Lambda aliases, and Elastic Beanstalk configuration choices

Choose the deployment model that matches risk tolerance and rollback needs. For Lambda, use versions and aliases; publish a version (lambda.publishVersion) and update aliases with traffic-shifting rules through CodeDeploy by creating a deployment (codedeploy.createDeployment) referencing the Lambda application and deployment group. Use CodeDeploy built-in configs like CodeDeployDefault.LambdaCanary10Percent5Minutes or custom traffic-routing for precise canary or linear shifts. For EC2 and on-prem apps, CodeDeploy supports blue/green with lifecycle hooks for pre-traffic validations and automatic rollback on health-check failures. Elastic Beanstalk provides multiple policies: All at Once (fast, risky), Rolling, Rolling with Additional Batch (safer), and Immutable (safest), and you change these with eb deploy or update-environment API specifying DeploymentPolicy and OptionSettings. Common developer traps include forgetting to configure application health checks (ALB target group health, EB health reporting) which prevents automatic traffic cutover, and insufficient IAM for CodeDeploy to invoke Lambda or update ECS. For database-backed releases, consider backward-compatible schema changes and pre-deploy feature toggles to avoid coupling code and schema in the same transaction.

Container pipelines, ECR, ECS/Fargate, and EKS: build, deploy, and immutable references

A robust container pipeline builds images in CodeBuild, pushes to ECR, and triggers deployment to ECS, Fargate, or EKS. In CodeBuild, do aws ecr get-login-password | docker login –username AWS –password-stdin ${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com, then docker build -t repo:tag ., docker push, and capture the image digest via docker inspect –format=’{{index .RepoDigests 0}}’ image. For ECS/Fargate, register the new task definition (ecs.registerTaskDefinition) with the image digest in containerDefinitions, then update the service (ecs.updateService) to use the new task definition or set forceNewDeployment to trigger replacement; use CodeDeploy for ECS blue/green deployments with traffic shifting at the ALB level. For EKS, update Kubernetes manifests to reference image digests and apply kubectl set image or use declarative GitOps tools; CodeBuild can run aws eks update-kubeconfig and kubectl commands. Typical pitfalls: using mutable tags causing stale deployments, failing to bump task definitions preventing ECS from deploying new images, insufficient CPU/memory or ENI limits on Fargate tasks, and forgetting to grant CodeBuild the ecr:BatchGetImage permission to read pushed images.

Pre-deploy validation, rollbacks, and observability: tests, hooks, and operational safeguards

Integrate automated unit, integration, and smoke tests into pipeline stages. Use CodeBuild to run tests and AWS X-Ray or CloudWatch Logs for tracing and structured logs; annotate X-Ray traces with PutAnnotation in SDKs so downstream queries can filter by user or request attributes. For pre-deploy, employ manual approval actions in CodePipeline or automated validator steps: run Canary checks via CodeBuild that exercise the deployed endpoint, or invoke CloudWatch Synthetics canaries to run scripted verifications. Use CodeDeploy lifecycle hooks (BeforeAllowTraffic, AfterAllowTraffic) to run health checks and registration/unregistration logic. Implement automatic rollback triggers: configure CodeDeploy to rollback on non-zero deployment status or failed alarms (CloudWatch alarms attached to the deployment group), and for Lambda use aliases with traffic shifting to enable rapid rollback by updating the alias to point to the previous version. Developer traps include mismatched timeouts (Lambda timeout shorter than SQS visibility timeout), forgetting to set AppSpec hooks correctly for ECS/CodeDeploy, and relying on success of deployment API calls without validating runtime behavior. Instrument deployments with metrics and alerts, and use immutable identifiers in artifacts for traceability.

Practical Problem: Use-Case Scenario

Scenario: ExampleRetail runs a microservices storefront in AWS across dev/test/prod accounts. They use CodeCommit for source, CodePipeline/CodeBuild for CI, ECR for images, ECS/Fargate for services behind an ALB, and Lambda for async workers.

Challenge: A developer must add a safe, automated pipeline to deploy a new checkout service container with canary traffic shifting and automated pre-deploy validation that will rollback on failure.

Recommended Approach:

1. Create a CodeBuild project that builds the Docker image, runs unit tests, logs into ECR (aws ecr get-login-password | docker login –username AWS –password-stdin ${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com), pushes the image, and emits a JSON artifact containing the image digest.
2. In CodePipeline, add a deploy stage that registers a new ECS task definition via ecs.registerTaskDefinition referencing the image digest, then creates a CodeDeploy ECS deployment by calling codedeploy.createDeployment with an AppSpec that binds the new task definition and a deploymentConfig set for canary (e.g., CodeDeployDefault.ECSCanary10Percent5Minutes).
3. Add a CodeBuild-based validation action or CloudWatch Synthetics canary as a post-deploy test that calls critical checkout endpoints and validates responses; make the pipeline wait for successful validation.
4. Configure CodeDeploy rollback options and a CloudWatch alarm tied to the deployment group (e.g., 5xx error rate or latency) to automatically abort and rollback if thresholds are breached.

Rationale: Building immutable images, registering task definitions with explicit image digests, and using CodeDeploy’s traffic-shifting plus automated validation provides safe canary releases and fast, automated rollback while ensuring deployments are reproducible and observable.

← CloudFormation · All domains · Security →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Amazon →