Introduction
SDLC Automation is the single largest domain on the AWS Certified DevOps Engineer – Professional (DOP-C02) exam at roughly 22% of your score — more than one question in five. It’s also the domain that defines the certification’s identity: the exam isn’t checking whether you know CodePipeline exists, it’s checking whether you can design a pipeline that builds, tests, deploys, and safely rolls back software across environments without a human clicking anything except an approval button.
The questions in this domain are almost always scenarios: “a deployment must shift 10% of traffic, wait, then send the rest — which service and configuration?” or “a failed release must revert automatically when errors spike — how do you wire it?” Recognizing which pattern a scenario describes is the whole skill. This guide walks through everything Domain 1 tests, from pipeline structure to deployment strategies, with the buildspec, appspec, and CLI details the exam expects you to recognize instantly.
If you haven’t mapped the whole exam yet, start with the AWS DevOps Engineer Professional exam guide, which covers all six domains and the logistics. This article is the SDLC automation deep dive; for a broader introduction to pipelines, the CI/CD guide pairs well with it.
What “SDLC Automation” Actually Tests
The domain breaks into a handful of recurring themes. Naming the theme a scenario belongs to is half the battle:
| Theme | What the exam wants you to build |
|---|---|
| CI/CD orchestration | CodePipeline stages, actions, artifacts, cross-account/region flows |
| Build & test automation | CodeBuild buildspec, caching, test reports, quality gates |
| Deployment strategies | In-place, rolling, immutable, blue/green, canary, linear |
| Safe releases | Automatic rollback, CloudWatch alarms, manual approvals |
| Artifact management | S3 artifacts, CodeArtifact, ECR image promotion |
| Source integration | CodeCommit, CodeConnections to GitHub/Bitbucket/GitLab, S3, ECR |
The unifying principle: every step from commit to production should be automated, testable, and reversible. If an answer requires a person to manually copy an artifact, edit a config, or notice a failure, it’s usually wrong.
The AWS Developer Tools Toolchain
Domain 1 revolves around a small set of managed services. Know exactly what each one is so you don’t confuse their roles:
| Service | Role in the pipeline |
|---|---|
| CodePipeline | The orchestrator — models the release as stages and actions |
| CodeBuild | Fully managed build/test compute driven by a buildspec.yml |
| CodeDeploy | Deploys artifacts to EC2/on-prem, Lambda, or ECS with strategies |
| CodeArtifact | Managed package repository (npm, pip, Maven, NuGet) |
| CodeConnections | Connects pipelines to external Git (GitHub, Bitbucket, GitLab) |
| ECR | Container image registry, often the source or deploy target |
A common trap is blurring CodeBuild and CodeDeploy: CodeBuild compiles and tests; CodeDeploy releases. They’re separate stages in a pipeline, and mixing up their responsibilities is a fast way to pick a wrong answer.
CodePipeline: Stages, Actions, and Artifacts
A pipeline is an ordered set of stages; each stage contains one or more actions. Every action belongs to a category:
- Source — pulls code or artifacts (CodeCommit, S3, ECR, or external Git via CodeConnections).
- Build — compiles and tests (typically CodeBuild).
- Test — runs validation (CodeBuild, third-party).
- Deploy — releases (CodeDeploy, CloudFormation, ECS, Elastic Beanstalk, S3).
- Approval — a manual gate that pauses the pipeline for a human.
- Invoke — runs custom logic (Lambda, Step Functions).
Actions pass data through artifacts stored in an S3 artifact bucket. A source action produces an output artifact; a build action consumes it and produces its own; a deploy action consumes that. Two mechanics the exam tests:
- Parallel vs. sequential actions are controlled by
runOrder. Actions with the samerunOrderrun in parallel; a higher number runs after. - Transitions between stages can be disabled to hold a release, then re-enabled — useful for controlling promotion into production.
Multi-Account and Cross-Region Pipelines
A frequent Domain 1 scenario: a single pipeline deploys into separate dev, staging, and production accounts. The exam’s expected design uses cross-account IAM roles — the pipeline in a central tooling account assumes a role in each target account — plus a KMS customer-managed key on the artifact bucket so the other accounts can decrypt artifacts. For cross-region deploys, CodePipeline replicates artifacts into an artifact bucket in each region. If you see “deploy to multiple accounts from one pipeline,” think assume-role + shared KMS key.
CodeBuild: the buildspec.yml
CodeBuild runs your build and test commands in a managed container defined by a buildspec.yml (at the repo root by default). Its phases run in a fixed order:
version: 0.2
phases:
install:
runtime-versions:
nodejs: 20
pre_build:
commands:
- echo Logging in to Amazon ECR...
- aws ecr get-login-password | docker login --username AWS --password-stdin $REPO
build:
commands:
- npm ci
- npm test # tests run here — a failure fails the build
- docker build -t $REPO:$CODEBUILD_RESOLVED_SOURCE_VERSION .
post_build:
commands:
- docker push $REPO:$CODEBUILD_RESOLVED_SOURCE_VERSION
reports:
unit-tests:
files:
- 'junit.xml'
file-format: JUNITXML
artifacts:
files:
- imagedefinitions.json
cache:
paths:
- 'node_modules/**/*'Exam-relevant details:
- Phases run in order:
install→pre_build→build→post_build. If a command in a phase fails, the build fails (unless you allow it to continue). reportspublishes test results (JUnit, Cucumber, etc.) into CodeBuild report groups so you get pass/fail trends — the standard way to add a test quality gate.cache(local or S3) speeds up builds by preserving dependencies between runs.- Environment variables should reference Secrets Manager or SSM Parameter Store for sensitive values, never plaintext in the buildspec.
- Build badges and CloudWatch Logs give visibility; wire failures to alarms.
CodeDeploy: Compute Platforms and Deployment Strategies
CodeDeploy is where most of the deployment-strategy questions live, and it behaves differently across its three compute platforms. This table is worth memorizing:
| Compute platform | In-place? | Blue/Green? | Traffic shifting |
|---|---|---|---|
| EC2 / On-Premises | Yes | Yes | AllAtOnce, HalfAtATime, OneAtATime, custom |
| AWS Lambda | No (versions/aliases) | Yes only | Canary, Linear, AllAtOnce |
| Amazon ECS | No | Yes only | Canary, Linear, AllAtOnce |
EC2/On-Premises Deployments and the appspec.yml
For EC2 and on-prem, the CodeDeploy agent runs on each instance and executes lifecycle hooks defined in an appspec.yml:
version: 0.0
os: linux
files:
- source: /
destination: /var/www/html
hooks:
BeforeInstall:
- location: scripts/stop_server.sh
AfterInstall:
- location: scripts/install_deps.sh
ApplicationStart:
- location: scripts/start_server.sh
ValidateService:
- location: scripts/health_check.shYou choose an in-place deployment (update the existing instances) or blue/green (stand up a new fleet, shift the load balancer, then terminate the old). Deployment configurations control the pace:
CodeDeployDefault.AllAtOnce— everything at once (fastest, riskiest).CodeDeployDefault.HalfAtATime— 50% then 50%.CodeDeployDefault.OneAtATime— one instance at a time (slowest, safest).- A custom config with a minimum healthy hosts value (count or percentage).
Lambda and ECS: Canary vs. Linear vs. All-at-Once
For serverless and containers, CodeDeploy shifts traffic between versions using an alias (Lambda) or a second task set behind a load balancer (ECS). The three canonical patterns:
| Strategy | Behavior | Example config |
|---|---|---|
| Canary | Shift a small % first, wait, then the rest in one step | Canary10Percent5Minutes |
| Linear | Shift equal increments on a fixed interval | Linear10PercentEvery1Minute |
| All-at-once | Shift 100% immediately | AllAtOnce |
Read the name literally: Canary10Percent5Minutes sends 10% of traffic, waits 5 minutes, then sends the remaining 90%. Linear10PercentEvery1Minute adds 10% every minute until it reaches 100%. The Lambda/ECS appspec also supports BeforeAllowTraffic and AfterAllowTraffic hooks — the perfect place to run automated validation (a Lambda that pings the new version) before traffic is fully shifted.
Other Deployment Targets: Beanstalk and CloudFormation
Not every deployment goes through CodeDeploy. The exam also tests deployment policies for other targets:
- Elastic Beanstalk deployment policies: All at once, Rolling, Rolling with additional batch (keeps full capacity during the deploy), Immutable (launch a parallel fresh set of instances), and Blue/Green (via environment URL/CNAME swap).
- CloudFormation / Auto Scaling rolling updates via
UpdatePolicy, or immutable deployments by replacing the group. For infrastructure-as-code specifics, see the CloudFormation guide.
Recognizing that “immutable” means new instances rather than modifying existing ones — and is therefore the safest for consistency — is a recurring exam distinction.
Testing Gates and Manual Approvals
SDLC automation isn’t just deploying fast; it’s deploying safely. The exam expects quality gates:
- Automated tests in CodeBuild — unit and integration tests run in the
build/pre_buildphases; a non-zero exit fails the stage and stops promotion. - Test reports — publish results to report groups for visibility and trend tracking.
- Manual approval actions — an
Approvalaction pauses the pipeline (optionally sending an SNS notification) until a human approves or rejects. Ideal before a production stage. - CodeGuru / static analysis or third-party scanners can run as Test actions to block insecure code.
Automatic Rollback: the Safety Net
The exam loves rollback scenarios. CodeDeploy can automatically roll back a deployment when:
- The deployment fails, or
- A specified CloudWatch alarm fires (for example, elevated 5xx errors or Lambda error rate).
For blue/green and canary/linear deployments, this is powerful: if the new version misbehaves during the wait window, the alarm trips and CodeDeploy reverts traffic to the previous version automatically. When a scenario says “roll back without human intervention if errors spike,” the answer is a CloudWatch alarm tied to CodeDeploy automatic rollback, not a Lambda you write yourself. This complements the broader operational patterns in the resilient cloud solutions and incident response domains.
Common SDLC Automation Traps
| Scenario | The trap | The right call |
|---|---|---|
| Shift 10%, wait, then the rest | Choosing Linear | That’s Canary (one wait, then remainder) |
| Shift 10% every minute | Choosing Canary | That’s Linear (repeated increments) |
| Zero-downtime EC2 release | In-place all-at-once | Blue/green or rolling with min healthy hosts |
| Roll back on error spike | A custom Lambda watcher | CloudWatch alarm + CodeDeploy auto-rollback |
| Deploy to 3 accounts | One role for everything | Cross-account assume-role + shared KMS key |
| Secrets in the build | Plaintext env vars in buildspec | Secrets Manager / SSM Parameter Store |
| Gate before production | Skipping validation | Manual approval action + automated tests |
If you can move through this table without second-guessing, you’ve covered the bulk of Domain 1. Reinforce it with the monitoring and observability guide, since alarms are what make automated rollback and canary validation work.
Practice SDLC Automation Until It’s Reflexive
Domain 1 rewards recognition speed. On exam day you won’t have time to derive whether a scenario calls for canary or linear shifting, or whether blue/green or immutable is the safer fit — you need to read the scenario and know. That fluency comes from working through enough scenario questions that the deployment strategies become reflexive.
Sailor.sh’s AWS DevOps Engineer Professional (DOP-C02) mock exams include full-length, scenario-based exams with detailed explanations across all six domains — including the CodePipeline structure, CodeBuild quality gates, deployment strategy, and automatic-rollback scenarios this guide covered. Working through them is the fastest way to close the gap between “I understand this concept” and “I can pick the right answer under pressure.” To structure your prep, the DOP-C02 study plan sequences the domains week by week, and the free DOP-C02 practice questions let you self-check before committing to a full mock.
Frequently Asked Questions
What is the difference between CodeBuild and CodeDeploy?
CodeBuild is managed build/test compute — it compiles code, runs tests, and produces artifacts based on a buildspec.yml. CodeDeploy takes a built artifact and releases it to EC2/on-prem instances, Lambda functions, or ECS services using a deployment strategy. They’re separate stages in a pipeline: build first, deploy second.
When should I use canary versus linear deployments?
Use canary when you want to expose a small slice of traffic to the new version, pause to observe, then send everything at once (Canary10Percent5Minutes). Use linear when you want to ramp gradually in equal steps over time (Linear10PercentEvery1Minute). Canary has one validation window; linear shifts continuously. Both are available for Lambda and ECS via CodeDeploy.
How do I make a CodeDeploy deployment roll back automatically?
Enable automatic rollback on the deployment group and, ideally, associate a CloudWatch alarm. CodeDeploy rolls back when the deployment fails or when the alarm enters the ALARM state — for example, if the new version’s error rate or latency crosses a threshold. No custom code is required.
Can a single CodePipeline deploy to multiple AWS accounts?
Yes. The pipeline lives in a central tooling account and assumes cross-account IAM roles in each target account. The artifact S3 bucket must use a customer-managed KMS key shared with those accounts so they can decrypt artifacts. For multiple regions, CodePipeline replicates artifacts to a bucket in each region.
What deployment options does Elastic Beanstalk support?
All at once, Rolling, Rolling with additional batch, Immutable, and Blue/Green (via URL/CNAME swap). “Immutable” and “Rolling with additional batch” preserve full capacity during the deploy, making them safer choices when the exam emphasizes zero downtime.
How do I add a manual approval before production?
Add an Approval action (category: Approval) to a stage in CodePipeline. The pipeline pauses at that action until someone approves or rejects it, and you can configure an SNS topic to notify approvers. It’s the standard way to gate a production deployment behind a human sign-off.
Where should build secrets live?
In AWS Secrets Manager or SSM Parameter Store (SecureString), referenced from the buildspec’s env section — never as plaintext environment variables committed to the repository. This keeps credentials out of source control and lets you rotate them independently.
Ready to turn Domain 1 into a strength? Drill realistic, explained scenarios with the Sailor.sh DOP-C02 mock exams, then map your full prep with the AWS DevOps Engineer Professional exam guide.