Deployment strategies and CI/CD pipelines are the system that gets new software features from a developer's laptop into the hands of users, safely and automatically. For the SOA-C02 exam, you must understand how AWS tools like CodeDeploy, CodeCommit, and CodePipeline work together to minimise downtime, reduce human error, and roll back changes when something breaks. This chapter will teach you the exact deployment patterns AWS tests, the traps they set, and how to think like a SysOps administrator who needs to keep applications running while making constant improvements.
Jump to a section
Your favourite restaurant has five private dining rooms. 48 guests arrive tonight for a wedding anniversary party booked into the 'Garden Room'. The restaurant manager has three ways to get that room ready. Option one is the 'all-at-once' method: turn off the entire restaurant, redecorate the Garden Room, and then reopen everything. But 36 other diners in other rooms get kicked out. Option two is 'rolling room service': add a new, identical 'Conservatory' next door, decorate it while the Garden Room stays open, and transfer the party there. The old Garden Room can be renovated or retired later. Option three is 'half-and-half': split the Garden Room in two with a temporary wall, move half the guests into a first section while the second half gets redecorated, then swap them over. No one gets fully kicked out.
This is exactly how software updates work. The 'all-at-once' method is rolling back the entire application. The 'Conservatory' approach is a blue/green deployment: spin up an identical environment, switch traffic over, then retire the old one. The 'half-and-half' method is a canary deployment: send 10% of users to the new version, check for problems, then send the rest. The CI/CD pipeline is the restaurant's checklist of tasks: order new furniture, hire decorators, test the new curtains — all automated so the manager just approves each stage.
When a developer writes new code, that code needs to get to the servers that run the application for users. In the old days, this involved one person manually copying files to a server, hoping nothing went wrong. That process was slow and dangerous. A CI/CD pipeline automates that entire journey.
CI stands for Continuous Integration. Every time a developer makes a change, the code is automatically tested — does it still compile? Do the existing functions still work? This catches mistakes early, before they reach users. CD stands for Continuous Delivery (or Continuous Deployment). Once the code passes tests, it is automatically prepared for release, and in many pipelines, automatically sent to production servers.
AWS provides three core services for this: CodeCommit, CodePipeline, and CodeDeploy. They work together like a factory assembly line. CodeCommit is the source stage — a place where code is stored and versioned, similar to GitHub but inside AWS. Developers push changes to CodeCommit, and that triggers the next stage. CodePipeline is the orchestrator — it defines the series of steps (called stages) that code must pass through: source, build, test, and deploy. Each stage can have multiple actions, like running unit tests or deploying to a staging server. CodeDeploy is the tool that actually pushes the code to the target servers (EC2 instances, Lambda functions, or on-premises machines) and handles the deployment strategy.
There are several deployment strategies that CodeDeploy supports, and the exam will test your ability to choose the right one for a scenario:
- In-Place Deployment: The application is stopped on each server, the new code is installed, and the server is restarted. This is the quickest way but causes downtime while each server is being updated. It is also harder to roll back — you must re-deploy the old version. - Blue/Green Deployment: You create a completely new set of servers (the 'green' environment), deploy the new code there, and then switch the load balancer to send user traffic to the green environment. The old 'blue' environment remains untouched. Rollback is as simple as switching the load balancer back to the blue environment. This has zero downtime but costs double the server resources during the switch. - Rolling Deployment: You update servers in batches. If you have 10 servers, you might update two at a time. This reduces downtime compared to in-place (since most servers stay up), and rollback can be done by re-deploying the old version to the updated batch. - Canary Deployment: A subset of users (often 5-10%) is routed to the new version. You monitor for errors. If everything is fine, you increase the percentage gradually to 100%. This is the safest for critical applications because it limits the blast radius if the new version has a bug. Why do these matter? Imagine an e-commerce site. An in-place deployment on Black Friday would take the site down for minutes — costing millions. A canary deployment lets you test the new checkout flow on a tiny sample of users. If the page breaks, only a handful of customers are affected, and you can immediately route them back to the old version. AWS CodeDeploy manages all this logic. You define a deployment configuration (e.g., 'update 20% of instances every 5 minutes') and CodeDeploy handles the rest: it monitors health checks, stops deployment if too many servers fail, and can automatically roll back if a CloudWatch alarm triggers.
A pipeline in CodePipeline typically looks like this: Source stage (CodeCommit) -> Build stage (AWS CodeBuild compiles the code and runs tests) -> Test stage (run integration tests) -> Deploy stage (CodeDeploy deploys to staging, then to production). Each stage can have approval gates — a human must click 'Approve' before code moves to production. This balances speed with safety.
For the exam, remember that CodeCommit is the code repository, CodePipeline is the workflow orchestrator, and CodeDeploy is the deployment executor. Know which deployment strategy to use when the question says 'zero downtime', 'low risk', 'cost sensitive', or 'fast rollback'.
Push code to CodeCommit
A developer commits new code and pushes it to the master branch of an AWS CodeCommit repository. This triggered the pipeline. The commit ID becomes the source artifact that flows through the pipeline, ensuring every deployment is traceable to a specific code change.
Pipeline detects change and starts
CodePipeline is configured with a CloudWatch Events rule that monitors the CodeCommit repository for new commits. When a change is detected, the pipeline instance starts executing from the Source stage, downloading the code to an S3 artifact bucket.
Build stage runs in CodeBuild
CodePipeline transitions to the Build stage, which launches AWS CodeBuild. CodeBuild compiles the source code, runs unit tests, and produces a deployable artifact (a zip file of the application). If the build fails, the pipeline stops and sends a notification.
Deploy stage executes using CodeDeploy
The pipeline transitions to the Deploy stage. CodePipeline passes the artifact to CodeDeploy, which uses a deployment group (set of servers) and a deployment configuration (e.g., canary 10% for 10 minutes) to roll out the new code. CodeDeploy handles installing the code, running hooks, and monitoring health.
Validation and rollback if necessary
During deployment, CodeDeploy checks CloudWatch alarms. If the error rate exceeds a threshold, CodeDeploy automatically triggers a rollback: it re-deploys the last successful version to the affected servers. If no alarms trigger, the deployment completes, and the pipeline succeeds.
You are a SysOps administrator at a mid-sized online retailer called 'ShopNow'. The developers have just finished a new feature: one-click checkout. Your job is to get this feature into production without breaking the existing site, which processes £50,000 in orders per hour.
Here is what you actually do step by step:
First, open the AWS Management Console and navigate to AWS CodeCommit. The development team has already pushed the new code to a repository called 'shopnow-frontend'. You verify the latest commit and see it triggered the pipeline automatically. This is because you configured a CloudWatch Event that listens for new commits to the master branch and starts the pipeline.
Next, open CodePipeline. The pipeline, named 'ShopNow-Production-Pipeline', has four stages: Source, Build, Test, and Deploy. You look at the Build stage logs in CodeBuild. It compiles the React frontend, runs 200 unit tests — all pass. The Test stage then deploys the build to a staging environment (a smaller version of production) and runs integration tests that simulate a user clicking through the new checkout flow. Those pass too. Now the pipeline is paused at the 'Deploy' stage, waiting for your manual approval.
You approve the deployment, and CodeDeploy takes over. The deployment group is called 'shopnow-prod-asg', which is an Auto Scaling Group behind an Application Load Balancer. The deployment strategy you selected is canary: the deployment configuration sends 10% of traffic to the new version for 10 minutes. CodeDeploy provisions a new set of EC2 instances in the Auto Scaling Group, installs the new one-click checkout code, and attaches them to a separate target group on the load balancer. The load balancer now sends 10% of users to the new instances.
During those 10 minutes, you watch the CloudWatch dashboard. You have alarms set on the error rate and latency for the new target group. Suddenly, the error rate spikes to 5% — the one-click checkout is throwing a database timeout error on high-traffic users. CodeDeploy detects this because you configured a CloudWatch alarm as a deployment trigger. The alarm fires, and CodeDeploy automatically stops the deployment and initiates a rollback.
For the rollback, CodeDeploy reverts the new instances to the previous version (the 'blue' environment) and increases the load balancer traffic back to 100% for the original target group. The new instances are terminated. You notify the development team, who fix the timeout issue by optimising a database query. They push a new commit, and the pipeline runs again. This time, the canary deployment shows zero errors. After 10 minutes, CodeDeploy increases the traffic to 50%, then 100% after another successful 10-minute window.
As the SysOps administrator, you also configured lifecycle hooks. Before an instance is taken out of service during the canary, the 'BeforeAllowTraffic' hook runs a final health check. After traffic is allowed, the 'AfterAllowTraffic' hook sends a notification to your Slack channel that the deployment succeeded. The entire process took 30 minutes, the site never went down, and only 10% of users saw the bug for a few minutes — far better than a full-site outage.
The SOA-C02 exam tests deployment strategies and CI/CD pipelines in several specific ways. You must be able to read a scenario and choose the correct strategy, identify the right AWS service for a job, and spot the incorrect answer that uses a service outside of the AWS ecosystem (like Jenkins or GitHub) unless the question explicitly mentions third-party integration.
Here are the exact topics the exam loves:
- Deployment Strategies: You will be given a scenario with constraints like 'zero downtime required', 'lowest cost', 'fast rollback', or 'minimal risk'. Your job is to pick between In-Place, Blue/Green, Rolling, and Canary. The key trap is that they often imply 'zero downtime' but also mention 'cost sensitive'. If cost is a priority, In-Place is the cheapest but causes downtime. The correct answer might be Rolling (reduced downtime, moderate cost) rather than Blue/Green (zero downtime, high cost due to double infrastructure). - CodeDeploy Lifecycle Hooks: The exam expects you to know the order of hooks: BeforeBlockTraffic, BlockTraffic, AfterBlockTraffic, BeforeAllowTraffic, AllowTraffic, AfterAllowTraffic. They will ask what hook runs before traffic is routed to a new instance, or which hook is used to run a validation script. The trap is swapping 'BeforeAllowTraffic' with 'AfterAllowTraffic'. - CodePipeline Action Types: You must know the difference between a 'source' action (CodeCommit, S3, ECR, GitHub), a 'build' action (CodeBuild, Jenkins), a 'test' action (CodeBuild, 3rd-party tools), and a 'deploy' action (CodeDeploy, CloudFormation, ECS, Elastic Beanstalk). A common trap is using CodeBuild as a deploy action — it is not; CodeBuild builds and runs tests. - Deployment Configurations: CodeDeploy has predefined configurations like 'CodeDeployDefault.AllAtOnce', 'CodeDeployDefault.HalfAtATime', and 'CodeDeployDefault.OneAtATime'. The exam might ask which configuration you choose for a Blue/Green deployment (AllAtOnce is common for the green environment). The trap is that 'HalfAtATime' is for rolling deployments, not Blue/Green. - Rollback Behaviour: CodeDeploy can automatically roll back when a deployment fails or when a CloudWatch alarm triggers. The exam will ask what happens during a rollback: it re-deploys the last successful version. It does not re-run the entire pipeline — it uses the artifact from the previous successful deployment in the S3 bucket. - Approvals: CodePipeline supports manual approval steps. The exam may ask you to set up an approval gate before production deployment. The correct action type is 'Manual approval' with a list of approvers. A specific exam trap: They might describe a scenario where a developer pushes code to CodeCommit, and the pipeline runs tests but skips the deploy stage because tests failed. The question: 'What happens to the pipeline?' The answer is that the pipeline transitions to a 'Failed' state, but you must check the 'Transition to next stage' logic — by default, a failed stage stops the pipeline. They will test that you understand stages are sequential. Another trap: 'Which deployment strategy has the lowest risk?' The answer is often 'Canary' because it exposes a small percentage of users, not 'Blue/Green' which exposes all users at once. But if the question says 'fastest rollback', Blue/Green wins because you just flip the load balancer. Memorise these trade-offs.
AWS CodeCommit is a fully managed source control service that stores code and triggers pipelines on new commits.
AWS CodePipeline orchestrates the CI/CD workflow through sequential stages: source, build, test, and deploy.
AWS CodeDeploy automates code deployment to EC2, Lambda, or on-premises servers using strategies like in-place, blue/green, rolling, or canary.
Blue/green deployment provides zero downtime and instant rollback by switching traffic between two identical environments.
Canary deployment reduces risk by routing a small percentage of users to the new version before a full rollout.
CodeDeploy lifecycle hooks (e.g., BeforeAllowTraffic, AfterAllowTraffic) let you run validation scripts at specific points during deployment.
Manual approval gates in CodePipeline prevent code from reaching production without human sign-off.
Rollbacks in CodeDeploy re-deploy the last successful version automatically if a CloudWatch alarm triggers or the deployment fails.
These come up on the exam all the time. Here's how to tell them apart.
CodeCommit
Stores source code and tracks version history
Acts as a source stage trigger for pipelines
Only handles code storage, not workflow orchestration
CodePipeline
Orchestrates the CI/CD workflow through stages
Does not store code; it pulls artifacts from repositories like CodeCommit
Manages the sequence of source, build, test, and deploy actions
Blue/Green Deployment
Creates a full duplicate environment and switches all traffic at once
Offers instant rollback by switching back to the old environment
Costs more because double the infrastructure runs during the switch
Canary Deployment
Routes a small percentage of traffic to the new version initially
Rollback is slower because you must reduce traffic gradually
Lower infrastructure cost because only a few extra servers are needed
In-Place Deployment
Updates servers all at once or one at a time with no defined batch size
Causes full downtime if done all at once
Simpler to set up but riskier in production
Rolling Deployment
Updates servers in fixed batches (e.g., 20% at a time)
Maintains overall application availability during the update
Uses a deployment configuration like 'HalfAtATime' to control batch size
Mistake
CI/CD pipelines and deployment strategies are the same thing.
Correct
A CI/CD pipeline is the automated workflow that moves code through stages (source, build, test, deploy). A deployment strategy is the method used in the deploy stage to roll out new code to servers (e.g., blue/green, canary). The pipeline uses a strategy.
Beginners often conflate the orchestration (pipeline) with the execution method (deployment strategy) because both are used together in CodePipeline and CodeDeploy. They are separate concepts that work together.
Mistake
CodeDeploy only works with EC2 instances.
Correct
CodeDeploy can deploy to EC2 instances, AWS Lambda functions, and on-premises servers using the on-premises instance feature. It is not limited to EC2.
Many exam guides focus on EC2 examples, leading beginners to assume that is the only target. Lambda deployments with CodeDeploy are a separate feature called 'CodeDeploy for Lambda'.
Mistake
Blue/green deployment always requires a load balancer.
Correct
While blue/green deployments commonly use a load balancer to shift traffic, you can also do blue/green by changing DNS records or Auto Scaling Group configurations. A load balancer is the most common method, but not the only one.
AWS documentation often shows load balancer diagrams, but the exam might test the general concept of swapping environments, not just the load balancer approach.
Mistake
An in-place deployment has no downtime because it updates servers one at a time.
Correct
An in-place deployment does cause downtime on each server during the update (stop, install, restart). Even if you update one server at a time, that single server is down for a period. The application as a whole remains partially available, but not fully. This is different from a rolling deployment, which also has per-server downtime but maintains overall availability.
Beginners hear 'one at a time' and assume zero downtime, but forget that each individual server is briefly non-functional. The exam tests the distinction between 'available overall' and 'zero downtime'.
Mistake
CodePipeline and CodeDeploy handle the entire build and test process automatically.
Correct
CodePipeline orchestrates stages, but it relies on other services (CodeBuild, CodeDeploy, Lambda, etc.) to perform the actual work. CodeDeploy only handles the deploy stage, not building or testing.
The name 'CodePipeline' sounds like it does everything, but it is just a workflow manager. Beginners think it is a monolith, but it is modular.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CodeCommit is a fully managed source control service inside AWS, similar to GitHub. The key difference is that CodeCommit integrates natively with other AWS services like CodePipeline and CodeBuild, and all data stays within the AWS network, which helps with compliance.
Yes, you can use CodeDeploy without a load balancer for in-place or rolling deployments directly to EC2 instances. For blue/green deployments, a load balancer is the standard way to shift traffic, but DNS-based switching is also possible.
If a deployment fails, CodeDeploy can automatically roll back to the last successful version. You can configure this in the deployment group settings. The rollback re-deploys the previous revision, not the one that just failed.
A lifecycle hook is a script that runs at a specific point during deployment, such as 'BeforeInstall' or 'AfterAllowTraffic'. You use hooks to run custom actions like clearing a cache, testing the application, or sending a notification.
No, you can use CodeDeploy independently. You can push a deployment directly through the AWS CLI, SDK, or console. CodePipeline simply automates the process by chaining CodeDeploy with source and build stages.
In an in-place deployment, you stop the application on each server, install the update, and restart — one server at a time or all at once. A rolling deployment is a specific type of in-place deployment where you update servers in batches (e.g., 20% at a time) to minimise user impact.
You've just covered Deployment Strategies and CI/CD Pipelines — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?