Deployment is the quiet giant of the AWS Certified Developer – Associate exam. Domain 4 is worth 24% of DVA-C02 — essentially tied with Security as the second-largest domain — yet most candidates spend their prep time on Lambda and DynamoDB and walk into the exam unable to say which CodeDeploy hook runs before traffic shifts, or which Elastic Beanstalk policy gives zero downtime at no extra cost. Those are not trick questions. They’re the bread and butter of this domain, and they’re learnable in a focused week.
This guide works through the AWS CI/CD toolchain the way the exam frames it: CodePipeline orchestrates, CodeBuild builds and tests, CodeDeploy releases — and each compute platform (EC2, Lambda, ECS, Elastic Beanstalk) has its own deployment strategies with distinct trade-offs. You’ll get the buildspec and appspec files the exam expects you to read, the traffic-shifting options it expects you to choose between, and the decision patterns that turn scenario questions into pattern matching.
If you’re still mapping the whole exam, start with the AWS Developer Associate Exam Guide 2026 and the full exam topics breakdown, then come back here for Domain 4 depth.
What Domain 4 Actually Tests
The DVA-C02 blueprint breaks Deployment into four tasks:
| Task | What it means in practice |
|---|---|
| Prepare application artifacts | Package code and dependencies; container images to ECR; packages to CodeArtifact |
| Test in development environments | Mock integrations, test stages, environment variables per stage |
| Automate deployment testing | Pipeline test stages, approval gates, API Gateway stages and canaries |
| Deploy code with AWS CI/CD services | CodePipeline, CodeBuild, CodeDeploy, SAM, CloudFormation, Beanstalk |
The mental model the exam rewards: source change → pipeline triggers → build produces an artifact → deploy shifts traffic according to a strategy → hooks validate → automatic rollback on alarm. Nearly every Domain 4 question is asking about one link in that chain.
CodePipeline: The Orchestrator
AWS CodePipeline models a release as a sequence of stages (Source, Build, Test, Deploy — names are yours to choose), each containing actions that run providers like CodeBuild, CodeDeploy, CloudFormation, ECS, S3, or a Lambda function. Key mechanics the exam checks:
- Artifacts move between stages through an S3 artifact bucket. A build stage’s output artifact becomes the deploy stage’s input artifact. If a question mentions a stage can’t find files from a previous stage, the answer involves input/output artifact configuration.
- Source actions support CodeCommit, S3, ECR, and GitHub/Bitbucket via CodeStar Connections (the modern, OAuth-app-free integration). Change detection is event-driven — EventBridge for CodeCommit/S3/ECR, webhooks through the connection for GitHub. Polling is legacy and the wrong answer.
- Manual approval actions pause the pipeline (optionally notifying an SNS topic) until someone approves in the console or via the CLI — the standard answer for “require a human sign-off before production.”
- Actions in the same stage can run in parallel (same
runOrder) or sequentially (increasingrunOrder). A stage only transitions when all its actions succeed. - Cross-account and cross-region deployments work, but the artifact bucket and KMS key must be accessible to the target — a common “why is this failing” scenario.
A minimal pipeline definition fragment showing artifact flow:
{
"name": "Build",
"actions": [{
"name": "BuildApp",
"actionTypeId": { "category": "Build", "provider": "CodeBuild", "owner": "AWS", "version": "1" },
"inputArtifacts": [{ "name": "SourceOutput" }],
"outputArtifacts": [{ "name": "BuildOutput" }],
"configuration": { "ProjectName": "my-app-build" }
}]
}CodeBuild: buildspec.yml in Depth
CodeBuild runs your build in an ephemeral container, driven by a buildspec.yml in the root of your source (or an inline/overridden buildspec configured on the project). The exam expects you to read one fluently:
version: 0.2
env:
variables:
NODE_ENV: production
parameter-store:
DB_HOST: /myapp/prod/db-host
secrets-manager:
DB_PASSWORD: prod/myapp/db:password
phases:
install:
runtime-versions:
nodejs: 20
pre_build:
commands:
- npm ci
- aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_URI
build:
commands:
- npm test
- docker build -t $ECR_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION .
post_build:
commands:
- docker push $ECR_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION
artifacts:
files:
- appspec.yml
- taskdef.json
cache:
paths:
- node_modules/**/*
reports:
unit-tests:
files:
- reports/junit.xmlWhat the exam pulls from this:
- Phases run in order:
install→pre_build→build→post_build. Know what belongs where (dependency install and login early, push and packaging late). If any phase fails, later phases don’t run (post_buildruns in most failure cases — but don’t rely on it for correctness questions; the tested fact is the ordering). - Secrets come from Systems Manager Parameter Store or Secrets Manager via the
envblock — never hardcoded as plaintext environment variables. “How should the build access a database password?” →secrets-manager:reference. - Build logs go to CloudWatch Logs (and optionally S3). Failing builds are debugged from logs; you can also run builds locally with the CodeBuild agent to reproduce issues.
- Caching (S3 or local) speeds up dependency-heavy builds; reports surface test results in the console.
- CodeBuild needs IAM permissions via its service role for everything it touches — ECR pushes, S3 artifacts, parameter reads. Permission errors in builds are service-role questions, not credentials-in-code questions.
CodeDeploy: appspec, Hooks, and Deployment Configs
CodeDeploy deploys to three compute platforms — EC2/on-premises, Lambda, and ECS — and each has a different appspec shape and lifecycle. This is the densest part of Domain 4 and the most reliably tested.
EC2/On-Premises Deployments
The appspec is YAML, lives at the root of the revision bundle, and maps files plus lifecycle event hooks to scripts:
version: 0.0
os: linux
files:
- source: /
destination: /var/www/myapp
hooks:
BeforeInstall:
- location: scripts/stop_server.sh
timeout: 300
AfterInstall:
- location: scripts/configure.sh
ApplicationStart:
- location: scripts/start_server.sh
ValidateService:
- location: scripts/health_check.sh
timeout: 300The hook order for an in-place deployment: ApplicationStop → DownloadBundle → BeforeInstall → Install → AfterInstall → ApplicationStart → ValidateService. You can’t attach scripts to DownloadBundle or Install (those belong to the CodeDeploy agent), and ValidateService is the hook for post-deployment health checks — a recurring correct answer.
Deployment configurations control rollout speed across the fleet: AllAtOnce, HalfAtATime, OneAtATime, or a custom minimum-healthy-hosts setting. EC2 deployments come in two flavors: in-place (update instances where they stand) and blue/green (provision a replacement environment behind the load balancer, then reroute traffic — fastest rollback, since the old fleet is still warm).
Lambda Deployments
Lambda deployments don’t copy files — they shift alias traffic between two function versions. The appspec (YAML or JSON) names the function, the versions, and exactly two available hooks:
version: 0.0
Resources:
- myLambdaFunction:
Type: AWS::Lambda::Function
Properties:
Name: "checkout-service"
Alias: "live"
CurrentVersion: "42"
TargetVersion: "43"
Hooks:
- BeforeAllowTraffic: "validate-before"
- AfterAllowTraffic: "validate-after"The hooks are themselves Lambda functions that must signal success back to CodeDeploy. Traffic shifting follows one of three deployment-config families:
| Strategy | Example configs | Behavior |
|---|---|---|
| Canary | Canary10Percent5Minutes, Canary10Percent30Minutes | Shift a small slice, wait once, then shift the rest |
| Linear | Linear10PercentEvery1Minute, Linear10PercentEvery10Minutes | Shift in equal increments on an interval |
| All-at-once | AllAtOnceLambda (default) | Shift 100% immediately |
Pair the rollout with CloudWatch alarms on the deployment group and CodeDeploy rolls back automatically when an alarm fires mid-shift. With AWS SAM, this whole setup is two properties on the function — AutoPublishAlias: live plus a DeploymentPreference with a type like Canary10Percent5Minutes — which is the exam’s favorite “simplest way to add safe deployments to a serverless app” answer. For the runtime side of versions and aliases (weighted aliases, $LATEST, qualified ARNs), see the DVA-C02 serverless guide.
ECS Deployments
CodeDeploy’s ECS support is blue/green: it stands up a replacement task set, optionally exposes it on a test listener for validation, then reroutes the production listener. The appspec specifies the task definition and container/port mapping, and the hooks are Lambda functions: BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, AfterAllowTraffic. The exam keyword is test listener — validating the green tasks with synthetic traffic before real users arrive.
Elastic Beanstalk Deployment Policies
Beanstalk predates CodeDeploy and brings its own deployment policies — and the exam loves making you choose among them:
| Policy | Downtime | Extra cost | Speed | Rollback | Notes |
|---|---|---|---|---|---|
| All at once | Yes | None | Fastest | Redeploy (slow) | Fine for dev |
| Rolling | No | None | Slow | Redeploy (slow) | Reduced capacity during deploy |
| Rolling with additional batch | No | One extra batch | Slow | Redeploy (slow) | Full capacity maintained |
| Immutable | No | Full second fleet (temporary) | Slowest | Terminate new instances (fast) | New ASG with new instances |
| Traffic splitting | No | Full second fleet (temporary) | Slowest | Reroute traffic (fastest) | Canary testing on % of traffic |
Plus blue/green via CNAME swap: deploy to a second Beanstalk environment, then use “Swap environment URLs” to flip DNS. It’s the answer when the scenario wants production untouched until cutover and instant DNS-level rollback.
The selection heuristics that answer most Beanstalk questions:
- “No downtime, no additional cost, reduced capacity acceptable” → Rolling
- “No downtime, full capacity, cost acceptable” → Rolling with additional batch
- “Never deploy onto existing instances / safest in-environment option” → Immutable
- “Send a percentage of users to the new version first” → Traffic splitting
- “Separate environment, test fully, flip instantly” → Blue/green CNAME swap
API Gateway Stages and Canary Releases
Deployment testing isn’t only about compute. API Gateway lets you run a canary on a stage: a configurable percentage of requests route to a new deployment while the rest hit the stable one, with separate metrics and logs for the canary. Combine that with stage variables (e.g., pointing a stage at a Lambda alias) and you can promote the same API definition through dev → test → prod without editing code. When a question pairs “API Gateway” with “test a new version on a small share of live traffic,” canary release settings are the answer.
Artifacts: ECR and CodeArtifact
Two supporting services round out the domain:
- Amazon ECR stores container images. Builds authenticate with
aws ecr get-login-password, push images tagged per commit, and ECS/Lambda pull from it. Image scanning flags CVEs on push. - AWS CodeArtifact is the managed package repository (npm, pip, Maven, NuGet) with upstream proxying to public registries — the answer for “centralize and control dependency packages across teams.”
The Decision Patterns That Answer Scenario Questions
Domain 4 scenarios nearly always reduce to matching a requirement to a strategy:
| Requirement in the question | Reach for |
|---|---|
| Human approval before prod | CodePipeline manual approval action (+ SNS) |
| Build needs a secret | buildspec env → Secrets Manager / Parameter Store |
| Validate after deploy on EC2 | ValidateService hook |
| Gradual Lambda rollout with auto-rollback | Canary/Linear config + CloudWatch alarm |
| Simplest safe serverless deploys | SAM AutoPublishAlias + DeploymentPreference |
| Zero downtime, zero extra cost on Beanstalk | Rolling |
| Test new ECS tasks before real traffic | Blue/green with a test listener |
| Small % of live API traffic to new version | API Gateway canary (or Lambda weighted alias) |
| Instant rollback requirement | Blue/green (CNAME swap / replacement fleet) |
Read the constraint words — cost, downtime, capacity, rollback speed, approval — and the right deployment strategy usually falls out mechanically.
A 7-Day Domain 4 Study Plan
| Day | Focus | Hands-on goal |
|---|---|---|
| 1 | CodePipeline | Build a 3-stage pipeline: CodeCommit/GitHub → CodeBuild → S3 deploy |
| 2 | CodeBuild | Write a buildspec with phases, a Parameter Store secret, and caching |
| 3 | CodeDeploy EC2 | In-place deploy with all hooks; break ValidateService and watch rollback |
| 4 | CodeDeploy Lambda | SAM canary deployment with a BeforeAllowTraffic hook and an alarm |
| 5 | Elastic Beanstalk | Deploy with rolling, immutable, then a blue/green CNAME swap |
| 6 | API Gateway + artifacts | Stage canary release; push an image to ECR from CodeBuild |
| 7 | Mixed scenarios | Timed practice questions across the whole domain |
Each lab is small, but the muscle memory matters: the exam describes these consoles and files in prose, and having seen them is what makes the descriptions click.
Practice Under Exam Conditions
Domain 4 rewards drilling more than almost any other DVA-C02 domain because its questions are so pattern-shaped — hook names, policy trade-offs, traffic-shifting configs. Once you’ve built the pipelines hands-on, the gap between you and a pass is reps under time pressure.
Sailor.sh’s AWS Certified Developer – Associate (DVA-C02) Mock Exam Bundle includes full-length timed mock exams with detailed explanations across all four domains — including the CodePipeline, CodeDeploy, and Beanstalk scenarios this guide covered — so you can find out which deployment strategies you think you know but actually confuse. Pair it with the free DVA-C02 practice questions for extra reps, and the study plan to schedule the rest of your prep. If serverless or DynamoDB are still shaky, shore those up with the serverless guide and the DynamoDB deep dive — Domains 1 and 2 lean on them heavily.
Frequently Asked Questions
How much of the DVA-C02 exam is about deployment?
Domain 4 (Deployment) is 24% of the scored questions — roughly 12–13 questions on a typical exam. Combined with the CI/CD-adjacent content in Troubleshooting and Optimization, deployment knowledge influences close to a third of the exam.
What’s the difference between CodePipeline, CodeBuild, and CodeDeploy?
CodePipeline is the orchestrator that models stages and moves artifacts between them. CodeBuild compiles, tests, and packages code according to a buildspec. CodeDeploy releases artifacts onto compute (EC2, Lambda, ECS) according to a deployment configuration. A typical pipeline uses all three as stages of one release flow.
Which CodeDeploy hooks exist for Lambda deployments?
Only two: BeforeAllowTraffic and AfterAllowTraffic. Both are Lambda functions that run validation and must report success or failure back to CodeDeploy. The longer EC2 hook list (ApplicationStop through ValidateService) does not apply to the Lambda platform — a classic exam distractor.
What’s the difference between canary and linear traffic shifting?
Canary shifts a small percentage, waits a single bake period, then shifts everything (e.g., Canary10Percent5Minutes). Linear shifts equal increments on a fixed interval until done (e.g., Linear10PercentEvery1Minute). Both support automatic rollback via CloudWatch alarms; all-at-once is the immediate, no-bake option.
Which Elastic Beanstalk policy gives zero downtime without extra cost?
Rolling — it updates instances in batches with no new infrastructure, at the price of temporarily reduced capacity. If full capacity must be maintained, rolling with additional batch adds one batch of instances (small temporary cost). Immutable and traffic splitting provision a full replacement fleet, which is safer but costlier.
How does automatic rollback work in CodeDeploy?
Attach CloudWatch alarms to the deployment group (or deployment) and enable rollback on alarm. If an alarm fires during the deployment — error rates from the new Lambda version, failed health checks on new instances — CodeDeploy stops and reverts to the last known-good version automatically. For Lambda this is near-instant, since the old version still exists and traffic simply shifts back.
Do I need to memorize buildspec and appspec syntax for the exam?
You need to read them, not write them from memory. Know the buildspec phase order and where secrets come from, the EC2 hook sequence, the Lambda hook pair, and what files:/Resources: sections do. Exam questions show fragments and ask what happens or what’s wrong — recognition is enough.
Conclusion
Domain 4 is the most learnable 24% of the DVA-C02. The toolchain has one shape — pipeline orchestrates, build produces artifacts, deploy shifts traffic — and every service hangs predictable details on it: buildspec phases, appspec hooks, deployment configs, Beanstalk policies. None of it is conceptually hard; all of it is precise, which is exactly why hands-on reps beat passive reading here.
Build the pipeline once, break it on purpose, watch a canary roll back from an alarm — then drill timed scenarios until the constraint words in a question (downtime, cost, capacity, rollback) map straight to a strategy. Do that, and the deployment domain flips from the section candidates fear to the section that carries their score.