If you cannot deploy new software features to customers quickly and safely, your business falls behind competitors who can. This chapter explains how AWS CodePipeline and CodeDeploy automatically move your code from a developer's laptop to live servers without human errors or late-night emergency rollbacks. For the DOP-C02 exam, mastering these two services is essential because the test expects you to design and troubleshoot automated release pipelines that deliver changes reliably.
Jump to a section
A simple way to picture Continuous Delivery with AWS CodePipeline and CodeDeploy
14 days is the exact lead time for a subscription box service to design, manufacture, and ship a monthly crate to 10,000 subscribers.
Before automation, a warehouse manager named Priya manually handled every step. She received design files by email, printed labels on a shared office printer, walked the printout to the assembly line, watched workers pack boxes, then drove the finished pallets to the shipping dock herself. One missed email, one smudged label, or one traffic jam on the way to the dock delayed the entire batch. Subscribers complained, and Priya worked 14-hour days.
Then the company adopted an automated fulfilment pipeline. Now, when a designer uploads a new crate blueprint to the shared drive (CodePipeline source), a sensor automatically triggers the 3D printer (build stage), the assembly robot picks items from bins (test stage), a label printer fires automatically (deploy stage), and a conveyor belt delivers crates to the right truck bay (production deployment). Every stage has a rollback button — if the label printer jams, the conveyor reverses, and the system alerts Priya on her phone. The pipeline processes the 10,000 crates in 4 hours, not 14 days.
Continuous Delivery (CD) is the practice of automatically preparing every code change for release to production so that a human can approve deployment with one click. AWS CodePipeline and AWS CodeDeploy are the two AWS services that make CD possible.
CodePipeline is a fully managed continuous delivery service. Think of it as a conveyor belt for your software. You define a pipeline that has stages — source, build, test, deploy — and each stage contains one or more actions. When a developer pushes new code to a source repository like GitHub or AWS CodeCommit, CodePipeline automatically detects the change, fetches the code, runs it through each stage, and either deploys it or stops if something fails. You do not have to manage servers or scripts to orchestrate this flow. CodePipeline replaces the old way: a team member manually copying files to a server or running deployment scripts by hand.
CodeDeploy is a deployment service that automates the actual process of putting your application onto compute resources. Those resources can be Amazon EC2 instances (virtual servers), AWS Lambda functions (serverless code), or on-premises servers. CodeDeploy tracks which version of your application is running on each target and can roll back to a previous version if the new deployment fails health checks.
How they work together: CodePipeline triggers CodeDeploy as an action in the deploy stage. CodePipeline passes the built application artifact (a zip file or container image) to CodeDeploy, and CodeDeploy pushes that artifact to the target servers according to a deployment strategy you choose.
Key concepts in CodeDeploy:
Deployment Group: A set of target instances or Lambda functions that receive the same application revision. You can tag EC2 instances with environment names (e.g., 'Production', 'Staging') and CodeDeploy deploys to all instances that match the tag.
Application Revision: The version of your code plus an AppSpec file (a YAML or JSON configuration file) that tells CodeDeploy how to install and start the application.
AppSpec File: The instruction manual. It defines lifecycle event hooks like BeforeInstall, AfterInstall, ApplicationStart, and ValidateService. CodeDeploy runs your custom scripts at each hook.
Deployment Strategies:
In-Place: CodeDeploy stops the application on each instance, installs the new version, and restarts it. Traffic is briefly interrupted.
Blue/Green: CodeDeploy launches a new set of instances (the green environment), installs the new version there, then shifts traffic from the old instances (blue) to the green ones. This allows zero-downtime deployment and easy rollback by switching traffic back.
Canary: A linear or percentage-based traffic shift from old to new instances. Useful for testing new code with a small percentage of users before full rollout.
CodePipeline stages and actions:
Source Stage: Connects to your code repository (CodeCommit, GitHub, Bitbucket, S3). Whenever a new commit or pull request merge occurs, the pipeline starts.
Build Stage: Uses a build service like AWS CodeBuild to compile code, run unit tests, and produce a deployable artifact.
Test Stage: Runs integration tests, security scans, or performance tests using services like AWS CodeBuild or third-party tools.
Deploy Stage: Calls CodeDeploy (or AWS Elastic Beanstalk, AWS CloudFormation, Amazon ECS) to push the artifact to the target environment.
Approvals: You can add manual approval actions between stages. For example, require a senior developer to click 'Approve' before the deploy stage runs.
Why this replaces the old way: Before automated pipelines, teams used scripts that ran on a single engineer's laptop. If that engineer left the company, the deployment process broke. Pipelines also eliminate the risk of 'configuration drift' — when a production server has different software versions than what was tested. CodePipeline ensures every deployment uses the exact artifact that passed all automated tests.
Source Stage Triggered
A developer pushes new code to a GitHub repository. CodePipeline detects the change via a webhook or periodic polling and fetches the code from the repository. This replaces manual file transfers and ensures the pipeline always uses the latest approved code.
Build and Test Stage
CodePipeline invokes AWS CodeBuild (or a third-party build tool like Jenkins). CodeBuild compiles the code, runs unit tests, and produces a deployable artefact (e.g., a .zip file). This stage is critical because it catches errors early, preventing broken code from reaching production.
Artefact Stored in S3
The build output artefact is uploaded to an S3 bucket designated as the pipeline artefact store. By default, artefacts are stored with a version ID. Enabling bucket versioning allows you to retrieve any previous artefact, which is essential for rollback.
Deploy Stage Execution
CodePipeline triggers the deploy action, which calls CodeDeploy. CodeDeploy retrieves the artefact from S3 and pushes it to the target deployment group using the instructions in the AppSpec file. The deployment group could be EC2 instances tagged with 'Environment: Production' or a Lambda alias.
Lifecycle Event Hooks Execute
CodeDeploy runs scripts at each defined hook: BeforeInstall (e.g., backup old version), Install (extract artefact), AfterInstall (set permissions), ApplicationStart (restart service), and ValidateService (check if the application responds correctly). If any hook script fails, the deployment can be configured to roll back automatically.
Traffic Shift and Health Check
For Blue/Green deployments, CodeDeploy registers the new instances with the load balancer and shifts traffic gradually. The load balancer performs health checks on the new instances. If the health check fails, CodeDeploy automatically terminates the new instances and re-routes all traffic to the old ones, completing a rollback.
Final Notification and Clean-up
After successful deployment, CodePipeline can trigger an SNS notification (e.g., email to the release team). For Blue/Green deployments, CodeDeploy can optionally terminate the old instances after a cooldown period to allow quick rollback if needed. The pipeline remains ready for the next code change.
An IT professional, let's call her Maria, works for an e-commerce company that sells handmade furniture. The website runs on 20 Amazon EC2 instances behind an Application Load Balancer. Maria's job is to ensure that every update to the website — new product pages, payment gateway changes, security patches — happens without downtime and without manual copying of files.
Here is how Maria uses CodePipeline and CodeDeploy in her daily work:
Step 1: Maria creates a CodePipeline named 'Website-Release-Pipeline'. The source stage connects to a GitHub repository where the development team stores the website code. Every time a developer merges a pull request to the 'main' branch, the pipeline triggers automatically.
Step 2: The build stage runs a CodeBuild project. CodeBuild compiles the static assets (HTML, CSS, JavaScript) and runs unit tests. If a test fails, the pipeline stops, and Maria receives an email notification from Amazon SNS (Simple Notification Service). She can inspect the logs in CodeBuild to find the failing test.
Step 3: The deploy stage uses CodeDeploy with a Blue/Green deployment strategy. CodeDeploy launches two new EC2 instances (green fleet) from a golden Amazon Machine Image (AMI). It installs the new website code on these instances using the AppSpec file, which runs a script to clear the CDN cache. CodeDeploy then registers the green instances with the load balancer and deregisters the blue instances. The load balancer gradually shifts traffic — first 10%, then if health checks pass, 100%. If the ValidateService hook fails (e.g., the homepage returns a 500 error), CodeDeploy automatically terminates the green instances and re-registers the blue instances, rolling back in under two minutes.
Step 4: Maria monitors the pipeline through the AWS Management Console. She can see a visual flow diagram showing each stage's status — green checkmark for success, red X for failure. She also sets up a CloudWatch alarm that pages her if the pipeline fails more than twice in an hour.
Common tools Maria uses alongside CodePipeline:
AWS CloudFormation: To define the EC2 instances, load balancer, and security groups as infrastructure as code. The pipeline can deploy CloudFormation stacks to update the infrastructure.
AWS Systems Manager Parameter Store: To store database connection strings and API keys. The pipeline retrieves these at deploy time rather than hardcoding them.
AWS CodeArtifact: A package repository for dependencies. The build stage pulls dependencies from CodeArtifact to ensure version consistency.
Maria's real-world benefit: Before pipelines, a deployment took 3 hours and required two people. Now it takes 12 minutes and happens automatically. Maria can focus on improving the deployment playbook rather than babysitting manual steps.
The DOP-C02 exam dedicates a significant portion of questions to CodePipeline and CodeDeploy, especially in the context of designing automated release pipelines. Here is exactly what you need to know.
Exam topics tested:
Pipeline structure and stage types (source, build, test, deploy, approval)
CodeDeploy deployment strategies: In-Place vs Blue/Green vs Canary — when to use each
AppSpec file hooks (BeforeInstall, AfterInstall, ApplicationStart, ValidateService) and their order
Integration with other services: CodeCommit, CodeBuild, CloudFormation, Lambda, EC2, Auto Scaling Groups
Rollback mechanisms: automatic rollback on health check failure vs manual rollback
Cross-account and cross-region pipelines (they love testing this)
Artefact storage: S3 bucket policy requirements for artefacts
Pipeline notifications via SNS and CloudWatch Events even
Traps the exam sets:
They will describe a deployment scenario and ask which strategy achieves zero downtime. The trap: Blue/Green does, In-Place does not unless you use a rolling update with careful health checks.
They will present a scenario where a pipeline stage fails, and ask what happens to the artefact. The correct answer is usually that the artefact remains in the S3 artefact store but the pipeline stops.
They will describe an AppSpec file with hooks in the wrong order (e.g., ApplicationStart before BeforeInstall). The exam tests whether you know the correct sequence.
They will ask about IAM permissions for CodePipeline to access CodeDeploy. The answer involves a service role with a trust policy allowing codepipeline.amazonaws.com and permissions to deploy.
They will test cross-region pipelines: the source region stores artefacts in an S3 bucket in that region, but the deploy stage must have access to a bucket in the target region. The correct pattern is to use separate S3 buckets per region with appropriate bucket policies.
Key definitions to memorise:
Deployment Group: A logical grouping of instances or Lambda functions that receive the same application revision.
Application Revision: A specific version of the application code and AppSpec file. Identified by a label or timestamp.
Lifecycle Event Hooks: Scripts that run at specific points during deployment. The default order is: ApplicationStop, DownloadBundle, BeforeInstall, Install, AfterInstall, ApplicationStart, ValidateService.
Blue/Green Deployment: A deployment method that launches new instances alongside the old ones, shifts traffic, then terminates the old instances.
In-Place Deployment: A deployment that updates the existing instances one by one, stopping the application on each instance during the update.
Question types:
Scenario-based multiple choice: 'A company wants to deploy a new web application to 50 EC2 instances with zero downtime. Which CodeDeploy deployment configuration should be used?'
Troubleshooting: 'A pipeline fails at the deploy stage with an insufficient permissions error. Which IAM role needs to be updated?'
Best practice: 'A team uses an S3 bucket for pipeline artefacts. What configuration prevents accidental deletion of artefacts during deployment?' (Answer: bucket versioning enabled).
What you must memorise: the exact order of AppSpec hooks, the difference between 'run order' and 'fail condition', and the fact that CodePipeline does not perform the deployment itself — it invokes CodeDeploy or another deploy provider.
CodePipeline orchestrates the release workflow but does not deploy code itself — it delegates the deploy action to CodeDeploy or another service.
CodeDeploy uses an AppSpec file (YAML or JSON) to define lifecycle event hooks that run custom scripts during deployment.
Blue/Green deployments launch new instances alongside old ones, then shift traffic, enabling zero-downtime deployments and fast rollback.
In-Place deployments update existing instances one by one, which may cause brief downtime if the application stops during the update.
CodePipeline artefact store is an S3 bucket — you must enable versioning on that bucket to prevent accidental overwrites and support rollback.
When a pipeline stage fails, the pipeline stops and the artefact remains in the S3 bucket; no automatic retry occurs unless you configure a retry action.
Cross-region pipelines require separate S3 artefact buckets in each region with appropriate bucket policies for cross-account access.
Manual approval actions in CodePipeline block the pipeline until a specified approver clicks 'Approve' or 'Reject' — useful for compliance gates.
CodeDeploy can deploy to EC2 instances, on-premises servers, Lambda functions, and Amazon ECS services — not just EC2.
These come up on the exam all the time. Here's how to tell them apart.
CodeDeploy In-Place Deployment
Updates existing instances one by one
Application stops briefly during each instance update
Rollback re-deploys the old version on the same instances
CodeDeploy Blue/Green Deployment
Launches new instances alongside old ones
Zero downtime during traffic shift
Fast rollback by re-directing traffic to the old instances
CodePipeline Source: AWS CodeCommit
Fully managed by AWS within your account
No external webhook configuration needed
Native integration with other AWS services (e.g., IAM)
CodePipeline Source: GitHub
Third-party service external to AWS
Requires a GitHub App or OAuth token for connection
Webhook or polling triggers the pipeline
Manual Deployment via SSH
Requires an engineer to manually copy files
High risk of human error (wrong server, wrong version)
No audit trail of who deployed what
Automated Deployment via CodeDeploy
Fully automated via pipeline triggers
Consistent deployment process every time
Full audit log in CodeDeploy and CloudTrail
CodePipeline Manual Approval Action
Requires a human to click Approve before proceeding
Used for compliance or high-risk changes
Pipeline pauses until approval is granted
CodePipeline Automated Deploy Action
No human intervention needed
Used for routine, low-risk changes
Pipeline proceeds immediately after previous stage succeeds
CodeDeploy EC2 Deployment Group
Targets specific EC2 instances by tag
Uses lifecycle hooks to install/stop/start services
Supports In-Place and Blue/Green strategies
CodeDeploy Lambda Deployment Group
Targets a Lambda function alias
No lifecycle hooks — uses traffic shifting only
Supports Canary, Linear, and All-at-Once strategies
CodePipeline Artefact Store (S3 with versioning)
Preserves every version of the artefact
Enables rollback to any previous artefact
Prevents accidental overwrites
CodePipeline Artefact Store (S3 without versioning)
Only the latest artefact is kept
Cannot roll back to a specific version
Risk of losing artefact if overwritten
Mistake
CodePipeline deploys the application directly to servers without needing any other service.
Correct
CodePipeline orchestrates the flow but does not perform the actual deployment. It passes the artefact to a provider like CodeDeploy, Elastic Beanstalk, CloudFormation, or ECS.
New learners see 'pipeline' and assume it includes the deployment mechanism. In reality, CodePipeline is just the coordinator; you must configure a deploy action that points to a separate service.
Mistake
A Blue/Green deployment in CodeDeploy requires manual traffic switching.
Correct
CodeDeploy automates traffic shifting using the load balancer. You configure a percentage shift or a linear ramp, and CodeDeploy handles the routing.
In some older deployment tools, traffic switching was manual. AWS CodeDeploy fully automates it, so the exam expects you to know this.
Mistake
CodePipeline can only use AWS CodeCommit as the source.
Correct
CodePipeline supports multiple source providers: AWS CodeCommit, GitHub (including GitHub Enterprise), Bitbucket, and Amazon S3.
The exam often presents a scenario with a GitHub repository and asks how to integrate it. Beginners might assume only CodeCommit works, but the exam tests multi-provider awareness.
Mistake
Rollback in CodeDeploy restores the previous version immediately with zero downtime.
Correct
Rollback in CodeDeploy re-deploys the previous revision, which takes time. During the rollback, the application may experience downtime depending on the deployment strategy. Blue/Green rollback is faster because it re-uses the old instances that are still running.
The word 'rollback' sounds instant. But it requires a full deployment cycle, so the exam tests whether you understand the time cost.
Mistake
You must write custom scripts for every deployment action in CodeDeploy.
Correct
CodeDeploy provides built-in actions like 'DownloadBundle' and 'Install' that handle standard tasks. You only need custom scripts in the lifecycle event hooks for special behaviour.
Documentation emphasises the AppSpec file hooks, so beginners think they must script everything. CodeDeploy automates the core steps; hooks are for customisation.
Mistake
CodePipeline stages must run sequentially, one after another.
Correct
You can configure parallel actions within a stage. For example, you can run integration tests and security scans at the same time in the test stage.
The visual pipeline diagram shows a linear flow, so people assume it is strictly serial. The exam tests whether you know that parallel actions are allowed to speed up the pipeline.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CodePipeline is the orchestration service that manages the overall release workflow from source to deployment. CodeDeploy is the service that actually installs your application onto the target compute resources. CodePipeline calls CodeDeploy as one of its actions.
Yes, CodePipeline integrates natively with GitHub, GitHub Enterprise Server, and GitHub Cloud. You set up a connection using a GitHub App or OAuth token, and the pipeline triggers when a new commit or pull request merge occurs on the specified branch.
You can configure automatic rollback in the deployment group settings by specifying a CloudWatch alarm or a failed health check as the rollback trigger. You can also manually trigger a rollback from the CodeDeploy console or CLI. Rollback re-deploys the previous application revision.
CodePipeline uses an IAM service role with a trust policy that allows codepipeline.amazonaws.com. The role must have permissions to call CodeDeploy actions (e.g., CreateDeployment, GetDeployment) and pass the CodeDeploy service role if required.
Yes, CodeDeploy supports Lambda deployments. You create a deployment group for a Lambda alias, and CodeDeploy shifts traffic between the old and new Lambda versions using canary, linear, or all-at-once traffic shifting.
The pipeline stops and does not proceed to the next stage. The artefact remains in the S3 bucket. You can view the failure reason in the pipeline console, fix the issue (e.g., fix a test failure), and retry the stage manually. No automatic retry occurs unless you configure a retry action in the stage.
The AppSpec file is a YAML or JSON configuration file that tells CodeDeploy how to install and start your application. It defines lifecycle event hooks (scripts that run at specific points), file permissions, and container image information for ECS deployments.
Yes, you can add a CloudFormation deploy action in CodePipeline. The pipeline can create or update a CloudFormation stack as part of the deploy stage, allowing you to manage infrastructure and application code together.
You've finished Continuous Delivery with AWS CodePipeline and CodeDeploy. Continue through the DOP-C02 study guide to build a complete picture of the exam.
Done with this chapter?