AWS CI/CD for DOP-C02: Complete Guide to CodePipeline, CodeBuild, and CodeDeploy

Introduction

SDLC Automation accounts for 22% of the DOP-C02 exam. This domain tests your ability to design, build, and troubleshoot CI/CD pipelines using AWS-native services. You need more than surface-level knowledge — the exam presents complex scenarios where you must choose the best pipeline architecture, deployment strategy, and integration pattern.

This guide covers everything you need to know about AWS CI/CD services for the DOP-C02 exam, with emphasis on the decision-making skills the exam tests.

AWS CI/CD Service Overview

CodePipeline: The Orchestrator

CodePipeline is the central service that ties your CI/CD workflow together. It doesn’t build, test, or deploy anything itself — it orchestrates the services that do.

Key concepts for the exam:

Stages: Sequential groups of actions (Source, Build, Test, Deploy, etc.)
Actions: Individual tasks within a stage (CodeBuild action, CodeDeploy action, approval action)
Artifacts: Output from one stage passed as input to the next
Transitions: Connections between stages that can be enabled or disabled
Pipeline executions: Each run of the pipeline from start to finish

What the exam tests:

When to use parallel actions vs. sequential actions within a stage
How artifact passing works between stages
How to implement approval gates
Cross-region and cross-account pipeline patterns
Pipeline trigger mechanisms (EventBridge, webhooks, polling)

CodeBuild: The Builder

CodeBuild compiles code, runs tests, and produces artifacts. It’s a fully managed build service that scales automatically.

Key concepts for the exam:

buildspec.yml: The build specification file that defines build phases
Build phases: install, pre_build, build, post_build
Build environments: Managed images or custom Docker images
Caching: S3 caching and local caching for faster builds
Environment variables: Plaintext, Parameter Store, and Secrets Manager references
Reports: Test reports and code coverage reports

buildspec.yml structure the exam expects you to know:

version: 0.2
phases:
  install:
    runtime-versions:
      java: corretto17
  pre_build:
    commands:
      - echo Logging in to ECR
      - aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_REPO
  build:
    commands:
      - docker build -t $IMAGE_TAG .
      - docker push $ECR_REPO:$IMAGE_TAG
  post_build:
    commands:
      - echo Build completed
artifacts:
  files:
    - imagedefinitions.json

What the exam tests:

How to configure buildspec.yml for different scenarios
How to pass secrets securely to build environments
How to cache dependencies for faster builds
How to push Docker images to ECR as part of a build
Troubleshooting failed builds (permissions, missing dependencies, timeout)

CodeDeploy: The Deployer

CodeDeploy automates application deployments to EC2 instances, ECS services, Lambda functions, and on-premises servers.

Key concepts for the exam:

Deployment groups: Sets of instances or targets that receive deployments
Deployment configurations: Rules for how deployments proceed (all-at-once, half-at-a-time, one-at-a-time, custom)
AppSpec file: Defines deployment actions and lifecycle hooks
Lifecycle hooks: Events during deployment where you can run scripts

What the exam tests:

Choosing the right deployment strategy for different scenarios
Configuring automatic rollback triggers
Understanding lifecycle hook execution order
Cross-platform deployment differences (EC2 vs. ECS vs. Lambda)

Deployment Strategies Deep Dive

This is one of the most heavily tested topics. You must understand when to use each strategy, not just how they work.

All-at-Once

How it works: Deploys to all instances simultaneously.

Use when:

Development environments where speed matters more than safety
Non-critical applications with acceptable downtime
Small instance fleets where rolling updates aren’t beneficial

Risks: If the deployment fails, all instances are affected simultaneously. Rollback requires a full redeployment.

Rolling Deployment

How it works: Deploys in batches. Each batch is updated before moving to the next.

Use when:

Production environments that need zero-downtime deployments
Applications that can handle mixed versions temporarily
Cost-conscious deployments (no extra infrastructure needed)

Configuration options:

Batch size: Number or percentage of instances per batch
Minimum healthy hosts: Ensures enough capacity during deployment
Batch pause: Optional wait time between batches for monitoring

Risks: During deployment, both old and new versions serve traffic. Applications must handle version compatibility.

Blue-Green Deployment

How it works: Creates a complete copy of your environment (green), deploys to it, tests it, then switches traffic from the old environment (blue) to the new one.

Use when:

Production environments requiring instant rollback capability
Deployments that need pre-switch validation
Applications that cannot run mixed versions

AWS implementation patterns:

For EC2 (via CodeDeploy):

Creates a new Auto Scaling group with the new version
Shifts traffic from the old ALB target group to the new one
Keeps the old environment for a configurable period for rollback

For ECS (via CodeDeploy):

Creates new ECS tasks with the new task definition
Shifts traffic using ALB listener rules
Supports linear and canary traffic shifting

Risks: Requires double the infrastructure during deployment. Database schema changes need careful handling since both environments share the same database.

Canary Deployment

How it works: Routes a small percentage of traffic to the new version first. If metrics look good, shifts remaining traffic.

Use when:

High-risk deployments where you want early warning of issues
Production systems with strict SLAs
Applications with good monitoring and automated rollback

AWS implementation:

For Lambda:

Canary10Percent5Minutes — 10% traffic for 5 minutes, then 100%
Canary10Percent10Minutes — 10% traffic for 10 minutes, then 100%
Canary10Percent15Minutes — 10% traffic for 15 minutes, then 100%

For ECS:

Similar traffic shifting via CodeDeploy
Custom percentages and intervals

Exam tip: Canary deployments require CloudWatch alarms configured as rollback triggers. Without alarms, there’s no automated way to detect issues during the canary period.

Immutable Deployment

How it works: Launches new instances in a new Auto Scaling group, deploys to them, then swaps them into the existing ASG.

Use when:

You want guaranteed clean instances with every deployment
Configuration drift is a concern
You need clear separation between old and new instances

Risks: Slower than rolling updates. More expensive due to temporary double capacity.

Exam Decision Framework

When a DOP-C02 question asks about deployment strategy, use this framework:

Does the application need zero downtime? If yes, eliminate all-at-once.
Is instant rollback required? If yes, choose blue-green or canary.
Are there mixed-version compatibility concerns? If yes, choose blue-green (avoids running two versions simultaneously under the same load balancer).
Is cost a constraint? If yes, choose rolling (no extra infrastructure).
Is this a high-risk change? If yes, choose canary (test with small traffic first).
Is the target Lambda? If yes, canary or linear via CodeDeploy (blue-green doesn’t apply the same way).

Pipeline Architecture Patterns

Basic Pipeline

Source → Build → Deploy

Suitable for simple applications with a single environment.

Pipeline with Testing and Approval

Source → Build → Test → Manual Approval → Deploy (Staging) → Manual Approval → Deploy (Production)

Standard production pipeline with quality gates.

Multi-Environment Pipeline

Source → Build → Deploy (Dev) → Test → Deploy (Staging) → Approval → Deploy (Prod)

Promotes the same artifact through environments, ensuring what’s tested is what’s deployed.

Cross-Account Pipeline

Account A: Source → Build → Artifacts to S3
Account B: Deploy (Staging)
Account C: Deploy (Production)

Uses cross-account IAM roles and KMS key sharing for artifact encryption.

Exam-relevant details:

The pipeline lives in one account (typically a shared tools account)
CodeDeploy or CloudFormation in target accounts assumes a cross-account role
Artifacts in S3 must be encrypted with a KMS key shared across accounts
EventBridge can route events across accounts for pipeline triggers

Cross-Region Pipeline

CodePipeline supports cross-region actions. Key considerations:

Artifacts are replicated to S3 buckets in each target region
Each region needs its own artifact bucket
KMS encryption keys must exist in each region
Cross-region deployments add latency to pipeline execution

Pipeline Triggers

EventBridge (Recommended)

EventBridge rules detect source changes and start pipeline execution. This is the default and recommended trigger mechanism.

CodeCommit: Detects branch pushes via EventBridge
S3: Detects object creation via EventBridge
ECR: Detects image push via EventBridge

Webhooks

For third-party source providers (GitHub, Bitbucket):

CodePipeline creates a webhook URL
The source provider calls the webhook on push events
Supports filtering by branch and file path

Polling (Discouraged)

CodePipeline periodically checks the source for changes. This is the legacy approach — EventBridge is always preferred on the exam.

Troubleshooting CI/CD Issues

The exam frequently tests your ability to diagnose pipeline failures.

Common CodeBuild Failures

Symptom	Likely Cause	Fix
Build fails immediately	buildspec.yml missing or malformed	Check file location and YAML syntax
Permission denied errors	CodeBuild service role lacks permissions	Update IAM role policy
Docker pull fails	No ECR login in pre_build phase	Add ECR authentication command
Build times out	Build exceeds timeout (default 60 min)	Increase timeout or optimize build
Out of memory	Build environment too small	Use a larger compute type

Common CodeDeploy Failures

Symptom	Likely Cause	Fix
Deployment stuck	Agent not running on target instance	Install/restart CodeDeploy agent
AllowTraffic fails	Health check failing on new instances	Fix application or health check configuration
Lifecycle hook timeout	Script exceeds timeout	Optimize script or increase timeout
Rollback triggered	CloudWatch alarm breached	Investigate the metric that caused the alarm

Common CodePipeline Failures

Symptom	Likely Cause	Fix
Pipeline doesn’t start	Trigger not configured or EventBridge rule missing	Verify trigger configuration
Cross-account action fails	IAM role assumption failure	Check trust policy and permissions
Artifact not found	Stage expecting artifact from wrong source	Verify artifact names match between stages

Key Services Integration Map

Understanding how services connect is critical for DOP-C02:

CodePipeline + SNS: Pipeline notifications and approval actions
CodePipeline + EventBridge: Pipeline state change events for monitoring
CodeBuild + ECR: Building and pushing Docker images
CodeBuild + Secrets Manager: Injecting secrets into build environments
CodeDeploy + CloudWatch: Deployment rollback triggers based on alarms
CodeDeploy + Auto Scaling: Deployment during scaling events
CodePipeline + CloudFormation: Infrastructure as code deployments
CodePipeline + S3: Artifact storage and cross-account sharing

Practice Scenarios

Test your understanding with these scenarios:

Scenario 1: A team deploys a microservice to ECS Fargate. They want the deployment to automatically roll back if the p99 response time exceeds 2 seconds during the first 10 minutes after deployment.

Answer approach: Use CodeDeploy with ECS blue-green deployment. Create a CloudWatch alarm on the ALB TargetResponseTime metric at the p99 statistic. Configure the alarm as a rollback trigger in the CodeDeploy deployment group. Use a canary or linear traffic shifting configuration.

Scenario 2: A company has 50 EC2 instances behind an ALB. They need to deploy a new version with zero downtime and the ability to quickly roll back. Cost efficiency is important.

Answer approach: Use CodeDeploy with a rolling deployment configuration (e.g., HalfAtATime). Configure minimum healthy hosts to ensure capacity. Set up CloudWatch alarms as rollback triggers. Rolling deployment avoids double infrastructure costs while maintaining availability.

Test Your CI/CD Knowledge

CI/CD is 22% of the DOP-C02 exam. If you can’t confidently answer the practice scenarios above, this domain needs more study time.

Sailor’s DOP-C02 mock exam bundle includes dozens of CI/CD-focused questions covering pipeline architecture, deployment strategies, and troubleshooting scenarios. Use the domain-level scoring to confirm your CI/CD readiness before exam day.

DOP-C02 Exam Guide 2026 — Complete exam format and all five domains
DOP-C02 Practice Questions — 20 realistic questions including CI/CD scenarios
10-Week DOP-C02 Study Plan — Weeks 1-3 cover CI/CD in depth
DOP-C02 Monitoring Guide — The largest exam domain (26%)

AWS CI/CD for DOP-C02: Complete Guide to CodePipeline, CodeBuild, and CodeDeploy

Introduction

AWS CI/CD Service Overview

CodePipeline: The Orchestrator

CodeBuild: The Builder

CodeDeploy: The Deployer

Deployment Strategies Deep Dive

All-at-Once

Rolling Deployment

Blue-Green Deployment

Canary Deployment

Immutable Deployment

Exam Decision Framework

Pipeline Architecture Patterns

Basic Pipeline

Pipeline with Testing and Approval

Multi-Environment Pipeline

Cross-Account Pipeline

Cross-Region Pipeline

Pipeline Triggers

EventBridge (Recommended)

Webhooks

Polling (Discouraged)

Troubleshooting CI/CD Issues

Common CodeBuild Failures

Common CodeDeploy Failures

Common CodePipeline Failures

Key Services Integration Map

Practice Scenarios

Test Your CI/CD Knowledge

Related Resources