Browse AWS Certification Guides

DVA-C02 Deployment Guide

Study DVA-C02 Deployment: key concepts, common traps, and exam decision cues.

Deployment on DVA-C02 is not just “push code to AWS.” AWS wants developers to understand how artifacts are packaged, how environments differ, how tests run before promotion, and how to reduce blast radius when releases fail.

I verified the current DVA-C02 Domain 3 task statements on May 11, 2026. AWS currently expresses this domain as four task statements:

  1. prepare application artifacts to be deployed to AWS
  2. test applications in development environments
  3. automate deployment testing
  4. deploy code by using AWS Continuous Integration and Continuous Delivery (CI/CD) services

Current weight in the exam guide

AWS currently weights Deployment at 24% of scored content.

What this domain is really testing

AWS is not asking you to design the whole platform delivery organization. It is asking whether you understand the developer-visible release path:

  • what gets packaged and versioned
  • what changes between environments
  • how tests prove the right thing before promotion
  • how aliases, stages, configuration, and rollout strategy affect production safety

Work this domain in order

Lesson AWS task fit Why it matters
3.1 Packaging, Dependencies, Repositories & Environment Config Task 3.1 This is the artifact lane: dependency bundles, repositories, image or package identity, and environment-specific config outside the codebase.
3.2 Development Endpoints, Integration Tests & Event-Driven Testing Task 3.2 This is the validation lane: safe endpoints, realistic payloads, isolated dependencies, and non-production behavior checks.
3.3 Automated Test Environments, IaC & Approved Versions Task 3.3 This is the repeatability lane: source-controlled IaC, approved versions, parameterized stacks, and controlled test fixtures.
3.4 CI/CD, Deployment Strategies, Runtime Config & Rollbacks Task 3.4 This is the promotion lane: pipeline flow, staged release strategies, runtime config, alarm-aware rollout, and fast rollback.

Fast routing inside this chapter

If the question is really about… Go first to…
package contents, environment variables, config files, image tags, or repo flow 3.1 Packaging, Dependencies, Repositories & Environment Config
mock APIs, stages, test events, or validating event-driven behavior 3.2 Development Endpoints, Integration Tests & Event-Driven Testing
CloudFormation or SAM changes, approved versions, branches, or isolated test environments 3.3 Automated Test Environments, IaC & Approved Versions
canary, blue/green, rollback, staged release, runtime config, or pipeline triggers 3.4 CI/CD, Deployment Strategies, Runtime Config & Rollbacks

If you keep missing questions in this domain

Symptom What is usually going wrong Fix first
deployment answers all sound operationally plausible you are not separating package prep, test design, and rollout strategy classify the question into 3.1, 3.2, 3.3, or 3.4 before picking a service
you keep choosing “rebuild everything” answers you are ignoring approved versions and targeted promotion paths rework 3.3 and 3.4 with rollback safety in mind
environment questions feel vague you are not distinguishing code artifact, runtime config, and environment-specific infrastructure rework 3.1 and track what changes where
release-strategy distractors keep winning you are not evaluating blast radius and rollback speed first prefer staged traffic shifting, version isolation, and fast reversal paths

What strong answers usually do

  • separate package preparation from release orchestration
  • treat environment drift as a deployment risk, not just an operations concern
  • prefer safe staged rollouts and rollback paths over one-shot high-blast-radius releases
  • keep configuration and versioning explicit instead of hiding them in ad hoc scripts or manual steps

Common DVA-C02 traps in this domain

  • confusing CI/CD tooling knowledge with the exam’s actual focus on safe developer release behavior
  • assuming the most automated answer is automatically the best answer
  • hiding secrets or environment-specific values inside artifacts instead of using runtime configuration
  • forgetting that test environments need to validate event-driven behavior, not just synchronous happy paths

Before you leave this domain

Make sure you can justify:

  1. how the artifact is packaged and versioned
  2. how configuration changes between environments
  3. what gets tested before promotion
  4. how the rollout limits blast radius
  5. how the application rolls back if the release is wrong

Then move to 4. Troubleshooting and Optimization, where AWS expects you to prove you can observe, diagnose, and tune the same systems you just shipped.

In this section

Revised on Monday, June 15, 2026
2. Security
4. Troubleshoot