DVA-C03 testing and deployment explained
Testing and Deployment is 22% of DVA-C03. On DVA-C02 the equivalent domain was named Deployment and carried 24%, so the domain now explicitly includes testing. It asks how a developer gets tested code safely into production: building artifacts, running tests, packaging, choosing a deployment strategy and rolling back. The AWS exam guide splits it into three tasks: prepare application artifacts (3.1), implement and automate application testing (3.2) and deploy code with CI/CD services (3.3). The page flags the items AWS lists as added.
What the domain is about
| Area | What to reason about |
|---|---|
| Build and test | CodeBuild and the buildspec file, unit and integration tests, local testing with the SAM CLI |
| Pipelines | CodePipeline stages and actions, manual approvals (see CI/CD explained) |
| Deployment strategies | In-place, rolling, blue/green, canary and linear with CodeDeploy |
| Infrastructure as code | CloudFormation, AWS SAM, change sets, parameters (see declarative versus imperative IaC) |
| Versions and environments | Lambda versions and aliases, API Gateway stages and stage variables, AWS AppConfig |
| Artifacts (3.1) | Dependencies and configuration within packages, container images (ECR, Dockerfiles, tagging, lifecycle policies), code repositories, environment-specific configuration (AppConfig, Parameter Store, Secrets Manager), API Gateway stages and endpoints |
| Testing (3.2) | Tests with SAM, CDK or CloudFormation, mock APIs, test events as JSON payloads, environments such as Lambda aliases, image tags, Amplify branches and Copilot environments |
| Deploying (3.3) | Lambda packaging (zip, container image, layers), ECS task definitions, EKS manifests, Fargate launch types, IaC templates, CodeDeploy, CodePipeline, deployment strategies, rollback, source control labels and branches |
| Containers (new skills) | Images in Amazon ECR, deployment on Amazon ECS, Amazon EKS and AWS Fargate (see Docker basics) |
| AI-assisted work (new skills) | Skill 3.2.5, AI tools to generate tests and automate test runs, analysis and regression testing; skill 3.3.9, AI tools in CI/CD such as automated deployment approvals, environment provisioning and post-deployment validation |
The guide consolidates testing skills from 11 skills across 2 tasks into 5 skills in 1 task. It lists designing and creating CI/CD pipelines as out of scope, so the exam asks you to use pipelines and deployment services, not to architect them. Unit testing with SAM and API Gateway stages moved into this domain from DVA-C02 domains 1 and 3 (the old Task 3.4).
How to think about it
Match the strategy to the risk. In-place deployments update existing instances and are cheapest but have the weakest rollback. Blue/green creates a parallel environment and shifts traffic, which gives fast rollback at the cost of temporary duplicate capacity. Canary shifts a small percentage first and then the rest; linear shifts in equal steps. For Lambda, CodeDeploy shifts the weight of an alias between two published versions, and CloudWatch alarms can trigger an automatic rollback. AWS SAM exposes this through a deployment preference on a function with an auto-published alias.
A Lambda version is an immutable snapshot; an alias is a named pointer to a version, optionally split between two. Callers should reference the alias, so a release is a pointer change. API Gateway stages are named deployments of an API, and stage variables let one API definition point at different aliases or backends per stage.
CloudFormation updates are previewed with change sets; a failed update rolls back to the last known good state by default. SAM is a CloudFormation extension with shorthand resource types, and the SAM CLI can invoke functions locally for testing before deployment. CodeBuild reads a buildspec file with phases (install, pre_build, build, post_build) and artifacts; failing tests in the build phase fail the build and stop the pipeline.
For containers, an image is built, tagged and pushed to a private ECR repository, then run by an ECS task definition or an EKS workload. Fargate is the serverless compute option for ECS and EKS, so there are no instances to manage; it is not a separate orchestrator.
Worked mini-scenario
A team releases a Lambda function behind an API. They want 10% of traffic on the new code for ten minutes and automatic rollback if the error alarm fires.
Reasoning: publish a new version, keep the production alias pointing at the old one, and use CodeDeploy with a canary configuration (10 percent for 10 minutes) attached to the alias, with the error-rate alarm as a rollback trigger. In SAM this is an auto-published alias and a deployment preference plus alarms. Editing the function in place, or deploying to a second function and asking clients to change URLs, gives no gradual shift and no automatic rollback.
Easy-to-confuse pairs
| Pair | Distinction |
|---|---|
| CodeDeploy versus CloudFormation | CodeDeploy releases application revisions and shifts traffic; CloudFormation provisions resources |
| CodePipeline versus CodeBuild | Orchestration of stages versus a build and test runner |
| Version versus alias | Immutable snapshot versus movable pointer |
| Stage variable versus Lambda environment variable | API Gateway stage configuration versus function configuration |
| Parameter Store versus AppConfig | Stored values versus validated, gradually rolled-out feature configuration |
| ECS versus EKS versus Fargate | AWS container orchestrator, Kubernetes service, and the serverless compute that runs tasks or pods |
| Rolling versus blue/green | Replace in batches on the same fleet versus switch to a new fleet |
An exam-style pitfall
Candidates pick the most elaborate option, for example a full blue/green rebuild, when the constraint is cost or a function-level change that an alias with weighted traffic handles. Read for words such as “gradually”, “automatically roll back” and “without new infrastructure”.
Own scenario questions
Question 1. A Lambda function is released through SAM. The team wants 10 percent of traffic on the new version for ten minutes, then the rest, with automatic rollback on a CloudWatch alarm. What should they use?
- A. A CodeDeploy canary deployment preference on an auto-published alias, with the alarm configured
- B. Update the function code in place and watch the dashboard
- C. Delete and recreate the stack
- D. Create a second function and ask clients to change the URL
Show answer
Answer: A
A canary deployment preference with CodeDeploy shifts alias traffic between published versions and rolls back when a configured alarm fires. Editing in place or switching URLs gives neither gradual traffic shifting nor automatic rollback.
Want more questions like this? Full DVA-C03 practice tests →
Question 2. Before each commit, developers want to run a Lambda function against a sample event on their laptop using the same template that is deployed. Which tool fits?
- A. CloudFormation drift detection
- B. CodeDeploy lifecycle hooks
- C. The SAM CLI local invoke command
- D. A CloudWatch Logs Insights query
Show answer
Answer: C
The SAM CLI can invoke a function locally from the template with a test event. Drift detection compares deployed resources with a stack, and the other options do not run function code.
Want more questions like this? Full DVA-C03 practice tests →
Question 3. One API Gateway API must call the dev alias of a Lambda function in the dev stage and the prod alias in the prod stage, without duplicating the API. What is the best approach?
- A. Create two separate APIs and keep them in sync manually
- B. Use a stage variable that holds the alias name and reference it in the integration
- C. Hard-code the prod alias ARN in the integration
- D. Add the alias name to the request headers sent by clients
Show answer
Answer: B
Stage variables let a single API definition reference a different Lambda alias per stage. Separate APIs duplicate configuration, and hard-coded ARNs tie the definition to one alias.
Want more questions like this? Full DVA-C03 practice tests →
Where to go next
Domain 4 covers what happens after release: troubleshooting and optimization explained. The study plan puts about 6.5 hours on this domain.