This chapter covers AWS CodePipeline and the core CI/CD services that enable continuous integration and continuous delivery on AWS. For the CLF-C02 exam, this falls under Domain 3: Cloud Technology Services, Objective 3.5 (approximately 5-10% of the domain). You need to understand how CodePipeline orchestrates the build, test, and deploy phases, and how it integrates with CodeCommit, CodeBuild, and CodeDeploy. The exam tests your ability to identify the correct service for a given scenario, the order of pipeline stages, and the benefits of CI/CD over manual deployment. We'll dive deep into the mechanics, configurations, and common pitfalls.
Jump to a section
Imagine a car manufacturer that wants to build a new model. The old way: a designer draws blueprints, then physically walks them to the parts department, which then manually calls the assembly line to change tooling. Each step requires human handoffs, phone calls, and emails—prone to delays and mistakes. Now consider a modern automated assembly line. A designer uploads the blueprint to a central system. That system automatically triggers the parts department to order components, which then signals the assembly line to reconfigure robots. Each step is connected end-to-end without human intervention. If a part is missing, the system automatically stops the line and alerts the team. AWS CodePipeline works the same way for software. When a developer pushes code to a repository (like AWS CodeCommit or GitHub), CodePipeline automatically detects the change, pulls the code, runs tests (like a quality check on the assembly line), builds the application (like assembling the car), and deploys it to servers (like moving the finished car to the showroom). Each stage is a "phase" in the pipeline, and you can add manual approval gates—like a quality inspector sign-off before the car leaves the factory. The key mechanism is that CodePipeline orchestrates these steps as a series of actions, using AWS services (CodeBuild for building, CodeDeploy for deploying) or third-party tools. It's not just "automation"—it's a state machine that manages transitions, failures, and rollbacks automatically. For a businessperson, think of it as a conveyor belt that only moves when the previous station completes successfully, and if something breaks, it stops the belt and notifies the manager, preventing defective products from reaching customers.
What is AWS CodePipeline and the Problem It Solves
AWS CodePipeline is a fully managed continuous delivery service that helps you automate the release pipeline for fast and reliable application and infrastructure updates. The problem it solves is the manual, error-prone process of building, testing, and deploying code. Without a pipeline, developers must manually trigger builds, run tests, and copy artifacts to servers—leading to inconsistencies, delays, and human error. CodePipeline automates the entire workflow from code commit to production deployment.
How It Works: The Pipeline Mechanics
CodePipeline models your release process as a pipeline, which is a series of stages. Each stage contains actions that are performed in sequence or parallel. The pipeline is defined in a JSON or YAML file, or through the AWS Management Console. Here's the core mechanism:
Source Stage: The pipeline starts when a change is detected in a source repository. Common sources include AWS CodeCommit, Amazon S3, GitHub, and Bitbucket. CodePipeline uses webhooks or periodic polling to detect changes. For CodeCommit, it uses CloudWatch Events to trigger the pipeline on commits.
Build Stage: After the source is retrieved, the pipeline passes the source code to a build service, typically AWS CodeBuild. CodeBuild compiles the code, runs tests, and produces a deployable artifact (e.g., a JAR file, a Docker image). The artifact is stored in an Amazon S3 bucket (the artifact store).
Deploy Stage: The artifact is then deployed to a target environment using AWS CodeDeploy, Elastic Beanstalk, CloudFormation, or ECS. CodeDeploy can deploy to EC2 instances, Lambda functions, or on-premises servers.
Manual Approval: You can add a manual approval action between stages. This requires a human to approve the deployment before it proceeds—useful for production releases.
Invoke: You can also invoke AWS Lambda functions or custom actions at any stage.
Key Tiers, Configurations, and Pricing
Pricing: CodePipeline charges per pipeline per month. The first pipeline is free for 30 days. After that, each active pipeline costs $1.00 per month (as of 2024). There are no upfront fees or commitments.
Limits: You can have up to 300 pipelines per AWS account. Each pipeline can have up to 10 stages, and each stage can have up to 20 actions. The artifact store size is limited to 1 GB per pipeline execution.
Execution History: Pipeline executions are retained for 1 year. You can view the history in the console or via CLI.
Encryption: Artifacts can be encrypted using AWS KMS.
Comparison to On-Premises or Competing Approaches
Traditionally, on-premises CI/CD requires you to manage Jenkins servers, configure plugins, and handle scaling. With CodePipeline, AWS manages the infrastructure—no servers to patch or scale. It's a serverless service that integrates natively with other AWS services. Compared to third-party tools like Jenkins or GitLab CI, CodePipeline offers tighter integration with AWS, but less flexibility in terms of plugins and customizations. The exam focuses on the AWS-native approach.
When to Use CodePipeline vs Alternatives
Use CodePipeline when you need a simple, fully managed CI/CD service for AWS workloads. It's ideal for teams that want to automate deployments without managing infrastructure. For complex workflows (e.g., multi-cloud, custom container builds), consider Jenkins or GitLab CI. For serverless applications, AWS SAM Pipelines or CodePipeline with CodeBuild is common. The exam expects you to know that CodePipeline is the orchestration layer, while CodeBuild and CodeDeploy are the execution services.
Integration with Other Services
CodeCommit: A fully managed source control service. CodePipeline can be triggered by changes in CodeCommit repositories.
CodeBuild: A fully managed build service. It runs builds in isolated environments with customizable compute classes (e.g., 3 GB memory, 2 vCPUs for the default build).
CodeDeploy: A deployment service that handles rolling updates, blue/green deployments, and canary releases. It works with EC2, Lambda, and on-premises instances.
Elastic Beanstalk: For deploying web applications, CodePipeline can directly deploy to Elastic Beanstalk environments.
CloudFormation: For infrastructure as code, CodePipeline can deploy CloudFormation stacks.
Lambda: You can invoke a Lambda function as a custom action for tasks like database migrations or security scans.
Pipeline Structure Example
Here's a simple pipeline definition in JSON:
{
"pipeline": {
"name": "MyAppPipeline",
"roleArn": "arn:aws:iam::123456789012:role/AWS-CodePipeline-Service",
"artifactStore": {
"type": "S3",
"location": "my-artifact-bucket"
},
"stages": [
{
"name": "Source",
"actions": [
{
"name": "Source",
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"provider": "CodeCommit",
"version": "1"
},
"configuration": {
"RepositoryName": "MyAppRepo",
"BranchName": "main"
},
"outputArtifacts": [
{
"name": "source_output"
}
],
"runOrder": 1
}
]
},
{
"name": "Build",
"actions": [
{
"name": "Build",
"actionTypeId": {
"category": "Build",
"owner": "AWS",
"provider": "CodeBuild",
"version": "1"
},
"configuration": {
"ProjectName": "MyBuildProject"
},
"inputArtifacts": [
{
"name": "source_output"
}
],
"outputArtifacts": [
{
"name": "build_output"
}
],
"runOrder": 1
}
]
},
{
"name": "Deploy",
"actions": [
{
"name": "Deploy",
"actionTypeId": {
"category": "Deploy",
"owner": "AWS",
"provider": "CodeDeploy",
"version": "1"
},
"configuration": {
"ApplicationName": "MyApp",
"DeploymentGroupName": "MyDeploymentGroup"
},
"inputArtifacts": [
{
"name": "build_output"
}
],
"runOrder": 1
}
]
}
]
}
}Key Concepts
Artifact: A file or set of files produced by a stage, stored in S3. Artifacts are passed between stages.
Action: A task performed in a stage. Actions can be source, build, test, deploy, approval, or invoke.
Stage: A logical grouping of actions. Stages run sequentially, but actions within a stage can run in parallel.
Transition: The movement from one stage to the next. Transitions can be enabled or disabled manually.
Execution: A specific run of a pipeline. Each execution has a unique ID.
Failure Handling
If an action fails, the pipeline stops and the execution status is set to "Failed." You can configure retry policies for certain actions. The exam may ask about how to handle failures—for example, by adding a manual approval or using CloudWatch alarms to notify.
Security
CodePipeline uses an IAM service role to access other services. The role must have permissions to read from the source repository, trigger CodeBuild, and deploy via CodeDeploy. You can also use KMS to encrypt artifacts at rest.
Create a CodeCommit Repository
Start by creating a Git repository in AWS CodeCommit to store your source code. Navigate to the CodeCommit console, click 'Create repository', enter a name (e.g., 'MyAppRepo'), and optionally a description. CodeCommit is a fully managed source control service that is secure and scalable. Behind the scenes, AWS provisions a Git server and provides HTTPS or SSH endpoints. You'll clone the repository to your local machine using Git commands. For the CLF-C02, remember that CodeCommit is the source control service, analogous to GitHub but within AWS. It integrates natively with CodePipeline without needing external webhooks.
Create a CodeBuild Project
Next, set up a CodeBuild project to compile and test your code. In the CodeBuild console, click 'Create build project'. Provide a name (e.g., 'MyBuildProject'), specify the source provider as CodeCommit and select your repository. Define the environment: choose a managed image (e.g., Ubuntu with Java or Node.js), and specify the compute type (e.g., build.general1.small with 3 GB memory and 2 vCPUs). Then, write a build spec file (buildspec.yml) in your repository that tells CodeBuild what commands to run (e.g., 'mvn clean package'). The build artifacts (e.g., a JAR file) will be stored in S3. CodeBuild runs each build in an isolated container; you pay per minute of build time. The default timeout is 8 hours, but you can set it lower.
Create a CodeDeploy Application
Now, prepare the deployment target. Create a CodeDeploy application and deployment group. In the CodeDeploy console, click 'Create application', give it a name (e.g., 'MyApp'), and choose the compute platform (EC2/On-Premises, Lambda, or ECS). For EC2, you need to install the CodeDeploy agent on your EC2 instances and attach an IAM instance profile. The deployment group defines the deployment configuration (e.g., rolling update with a 50% stop), the target instances (by tag), and load balancer settings. CodeDeploy uses an appspec.yml file in your artifact to define lifecycle hooks (e.g., BeforeInstall, AfterInstall). The exam tests that CodeDeploy handles rolling updates and blue/green deployments.
Create the CodePipeline
Now, create the pipeline to connect everything. In the CodePipeline console, click 'Create pipeline'. Enter a name (e.g., 'MyAppPipeline'). Choose a service role (or let CodePipeline create one). Select the artifact store location (S3 bucket). Add a source stage: choose CodeCommit as the source provider and select your repository and branch. Add a build stage: choose CodeBuild and select the project you created. Add a deploy stage: choose CodeDeploy and select your application and deployment group. Optionally, add a manual approval stage before deploy. Review and create. Behind the scenes, CodePipeline sets up CloudWatch Events to trigger on commits, and creates a state machine to orchestrate the stages. The pipeline will run automatically on each commit.
Test and Monitor the Pipeline
Push a change to your CodeCommit repository to trigger the pipeline. Go to the CodePipeline console and watch the execution progress. Each stage shows a status (In Progress, Succeeded, Failed). If a stage fails, click the details to see logs. For example, if the build fails, you can view CodeBuild logs in CloudWatch. You can also set up notifications via Amazon SNS for pipeline events (e.g., success, failure). The exam may ask about monitoring pipelines—use CloudWatch Events and SNS. You can also manually retry a failed stage or rerun the pipeline. Pipeline executions are stored for 1 year; you can view the history to audit changes.
Scenario 1: E-Commerce Platform with Microservices
A large e-commerce company uses a microservices architecture with dozens of services. Each service is developed by a separate team. They use CodePipeline to automate deployments for each service independently. For example, the 'checkout' service pipeline: source from CodeCommit, build with CodeBuild (Java/Maven), run unit tests, and deploy to an Auto Scaling group via CodeDeploy with a rolling update. The deployment group is configured to stop 50% of instances at a time to maintain availability. They also have a manual approval stage before production deployment, requiring a QA lead to approve. Cost: each pipeline costs $1/month, so 50 pipelines cost $50/month—much cheaper than managing Jenkins servers. A misconfiguration they encountered: they forgot to update the IAM role for CodePipeline to include permissions for the new artifact bucket, causing the pipeline to fail with an access denied error. The fix was to attach the correct S3 policy to the role.
Scenario 2: Serverless Application with Lambda
A startup builds a serverless application using AWS Lambda and API Gateway. They use CodePipeline with a source stage from GitHub (via a webhook), a build stage that runs npm install and runs tests using CodeBuild, and a deploy stage that uses CloudFormation to update the Lambda functions and API Gateway. The CloudFormation template is stored in the repository. They also use a Lambda function as a custom action in the pipeline to run database migrations before deployment. The pipeline automatically creates a new stack for each environment (dev, staging, prod). A common mistake: they initially used the same artifact bucket for all pipelines, and when they cleaned up old artifacts, they accidentally deleted artifacts needed for a running deployment. They learned to use separate buckets per pipeline or enable versioning.
Scenario 3: Compliance-Driven Release Process
A financial services company must have an auditable, gated release process. They use CodePipeline with multiple stages: source, build, unit tests, integration tests, manual approval, security scan (Lambda custom action), and deploy. The manual approval stage sends an email to the release manager via SNS. All pipeline executions are logged in CloudTrail for compliance. They also use encryption with KMS for artifacts. A problem they faced: the pipeline was slow because the build stage was using a small compute type (build.general1.small) for a large Java application. They upgraded to build.general1.large (8 GB memory, 4 vCPUs) and the build time dropped from 20 minutes to 5 minutes. The cost increased slightly but was worth the speed.
What CLF-C02 Tests on This Objective
The exam Domain 3 (Cloud Technology Services) includes Objective 3.5: "Identify the components of the CI/CD pipeline." Specifically, you need to know:
The purpose of CodePipeline, CodeCommit, CodeBuild, and CodeDeploy.
The order of stages in a typical pipeline (Source -> Build -> Test -> Deploy).
Which service is used for what: CodeCommit for source control, CodeBuild for building and testing, CodeDeploy for deploying.
How CodePipeline integrates with other services (e.g., S3 for artifacts, CloudWatch Events for triggers).
The difference between continuous integration (CI) and continuous delivery (CD).
Common Wrong Answers and Why Candidates Choose Them
"CodeDeploy is used for building code." Wrong because CodeDeploy is for deploying, not building. Candidates confuse the names because both start with "Code." Remember: CodeBuild = Build, CodeDeploy = Deploy.
"CodePipeline replaces CodeBuild." No, CodePipeline orchestrates, CodeBuild executes. Candidates think a pipeline includes everything, but it's a misconception.
"You must use all four Code services together." Not true. You can use CodePipeline with GitHub (not CodeCommit) or with Elastic Beanstalk (not CodeDeploy). The exam tests flexibility.
"CodePipeline is only for EC2 deployments." It also supports Lambda, ECS, and on-premises via CodeDeploy.
Specific Terms and Values That Appear on the Exam
Artifact store: S3 bucket used to store pipeline artifacts. Default is an AWS-managed S3 bucket, but you can specify your own.
Stage: A logical group of actions. Stages run sequentially.
Action: A task within a stage. Actions can run in parallel within a stage.
Transition: The link between stages; can be disabled to pause the pipeline.
CloudWatch Events: Used to trigger pipelines on code changes.
Manual approval: An action type that requires human sign-off.
CodeBuild compute types: build.general1.small (3 GB, 2 vCPUs), build.general1.medium (7 GB, 4 vCPUs), build.general1.large (15 GB, 8 vCPUs).
Tricky Distinctions
CodePipeline vs. CodeBuild: CodePipeline is the orchestrator; CodeBuild is the build server. A pipeline can have multiple CodeBuild actions.
CodeDeploy vs. Elastic Beanstalk: CodeDeploy is a general deployment service; Elastic Beanstalk is a PaaS that includes deployment but also manages the environment. CodeDeploy gives more control over deployment strategies (rolling, blue/green).
Continuous Integration vs. Continuous Delivery: CI is about merging code changes and running tests frequently. CD is about automatically deploying to production after CI. The exam may ask which concept is represented by a pipeline that deploys to production automatically.
Decision Rule for Multi-Choice Questions
When asked "Which service should be used for X?" use this elimination strategy:
If the task is storing source code -> CodeCommit (or GitHub if mentioned).
If the task is compiling code or running tests -> CodeBuild.
If the task is deploying to EC2, Lambda, or on-premises -> CodeDeploy.
If the task is orchestrating a multi-stage workflow -> CodePipeline.
If the task is deploying a web application with environment management -> Elastic Beanstalk.
CodePipeline is a fully managed continuous delivery service that automates the build, test, and deploy phases.
A pipeline consists of stages (sequential) and actions (can be parallel within a stage).
Common source providers: CodeCommit, GitHub, Bitbucket, S3.
CodeBuild is the build service; it runs builds in isolated containers and stores artifacts in S3.
CodeDeploy deploys to EC2, Lambda, ECS, and on-premises; supports rolling and blue/green deployments.
Manual approval actions allow human gatekeeping before a deployment proceeds.
CodePipeline charges $1 per active pipeline per month after 30-day free trial; limit of 300 pipelines per account.
Artifacts are stored in an S3 bucket (artifact store); can be encrypted with KMS.
CloudWatch Events can trigger pipelines on source code changes.
The exam tests the distinction between CI (frequent builds/tests) and CD (automated deployment).
These come up on the exam all the time. Here's how to tell them apart.
CodePipeline
Fully managed by AWS; no server to maintain
Native integration with AWS services (CodeCommit, CodeBuild, etc.)
Priced per pipeline per month ($1/pipeline)
Limited to 300 pipelines per account
Supports manual approval and custom actions via Lambda
Jenkins
Self-managed; requires EC2 instance or container to run
Rich plugin ecosystem; supports many tools (Git, Docker, etc.)
Free and open source; pay only for infrastructure
Scalable with master/agent architecture
Highly customizable with Groovy scripts and pipeline as code
CodeBuild
Build and test service; compiles code and runs tests
Produces artifacts (e.g., JAR, Docker image)
Pay per build minute; free tier of 100 build minutes/month
Can be used standalone or within CodePipeline
Supports custom build environments via Docker
CodePipeline
Orchestration service; manages the sequence of stages
Passes artifacts between stages; does not build itself
Priced per pipeline per month ($1/pipeline)
Always used with other services (build, deploy)
Defines the pipeline structure; triggers on code changes
Mistake
CodePipeline is a build service like Jenkins.
Correct
CodePipeline is an orchestration service, not a build server. It coordinates stages but does not compile code. CodeBuild is the build service that compiles and tests code.
Mistake
You must use AWS CodeCommit as the source for CodePipeline.
Correct
CodePipeline supports multiple source providers including GitHub, Bitbucket, and Amazon S3. CodeCommit is just one option.
Mistake
CodeDeploy can only deploy to EC2 instances.
Correct
CodeDeploy supports EC2, on-premises instances, Lambda functions, and Amazon ECS. The compute platform is chosen when creating the application.
Mistake
All stages in a pipeline must have actions in sequence.
Correct
Stages run sequentially, but actions within a stage can run in parallel. For example, you can run unit tests and static code analysis simultaneously in the same stage.
Mistake
CodePipeline is free for unlimited pipelines.
Correct
CodePipeline charges $1 per active pipeline per month after the first 30 days free. There is a limit of 300 pipelines per account.
CodePipeline is an orchestration service that manages the sequence of stages in a release process, such as source, build, test, and deploy. It does not execute builds itself. CodeBuild is a build service that compiles source code, runs tests, and produces software artifacts. In a typical pipeline, CodePipeline triggers CodeBuild to perform the build stage, then passes the artifact to the next stage (e.g., deploy). Think of CodePipeline as the conductor and CodeBuild as the musician.
Yes, absolutely. CodePipeline supports multiple source providers including GitHub (via webhooks), Bitbucket, Amazon S3, and AWS CodeCommit. You can choose any of them as the source stage. For example, many teams use GitHub for source control and still use CodePipeline for orchestration. The exam may present a scenario where a team uses GitHub; the correct answer would still involve CodePipeline for CI/CD.
A manual approval action is a stage action that pauses the pipeline and waits for a human to approve or reject the transition to the next stage. It is commonly used before deploying to production. When the action is reached, an email notification (via SNS) can be sent to approvers. They can approve or reject through the console or CLI. This provides a gate to ensure quality and compliance. On the exam, know that manual approval is an action type in the 'Approval' category.
If any action in a stage fails, the pipeline execution stops and the status is set to 'Failed'. You can view the logs in CloudWatch to diagnose the issue. After fixing the problem, you can retry the failed stage or rerun the pipeline from the beginning. There is no automatic retry by default, but you can configure retry policies for certain actions. For the exam, remember that failures stop the pipeline and require manual intervention.
The artifact store is an Amazon S3 bucket where CodePipeline stores the input and output artifacts for each pipeline execution. Artifacts are files produced by actions (e.g., a compiled JAR from CodeBuild). The default artifact store is an AWS-managed S3 bucket, but you can specify your own. Artifacts are passed between stages by referencing the output artifact name. The exam may ask about the artifact store location (S3) and that it can be encrypted with KMS.
Continuous Integration (CI) is the practice of frequently merging code changes into a shared repository and automatically building and testing each change. Continuous Delivery (CD) extends CI by automatically deploying the tested code to production or staging environments. CodePipeline supports both: a CI pipeline might only include source and build stages, while a CD pipeline includes a deploy stage. The exam may ask you to identify which concept is illustrated by a given pipeline.
Yes, you can use CodeDeploy to deploy to on-premises servers, and CodePipeline can orchestrate that. You need to install the CodeDeploy agent on your on-premises instances and register them as on-premises instances in CodeDeploy. The pipeline works the same way as for EC2 deployments. This is a common exam scenario: CodePipeline is not limited to AWS resources.
You've just covered AWS CodePipeline and CI/CD Services — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?