Deployment

Every topic in this 24% domain is a stage on a single path from source code to a running service, so learn the path first and the services slot into it. You build an artifact (the immutable bundle the platform runs, a Lambda .zip or container image) once; you test it on a fidelity ladder (unit tests, then local emulation with the AWS SAM CLI, then a deployed stage); and you let an AWS CodePipeline pipeline promote that exact tested artifact toward production. The DVA-C02 mental model is build-once-promote-many: the bytes that pass test in a staging environment are the identical bytes that reach production, never a fresh rebuild. When a question describes a step (packaging, a local test, a pipeline gate, a traffic shift), place it on this path and the right service follows.

AWS deployment is declarative: you describe the desired stack in a template and let AWS CloudFormation reconcile reality to it, rather than clicking resources into existence. AWS SAM (Serverless Application Model) is not a separate engine: it is a CloudFormation transform (AWS::Serverless-2016-10-31) that expands shorthand serverless resources into full CloudFormation, so anything you know about CloudFormation (parameters, change sets to preview an update, drift detection, nested stacks) still applies. This spine is why the same artifact is reproducible across environments and why a failed update can roll the stack back automatically. Treat the template as the source of truth for what gets deployed; the pipeline below is how it gets there.

Because the artifact is immutable and shared across environments, the same bytes must behave differently in dev, staging, and prod without being rebuilt, so environment-specific values are injected late, never baked in. Configuration that changes per environment comes from SSM Parameter Store (simple named values) or AWS AppConfig (validated config you can flip without redeploying code); secrets are referenced at runtime from AWS Secrets Manager, never packaged into the artifact. The recurring exam trap is any answer that rebuilds per environment or hard-codes a secret into the .zip: both break the build-once principle and the security model at once.

The four deployment strategies (all-at-once, rolling, canary, and linear) are one model with a different increment size: how much traffic moves to the new version per step. A larger increment is faster but leaves a smaller window to catch a bad release; a canary or linear shift exposes a slice first so failing health checks can stop promotion before full exposure. An orthogonal axis is in-place vs blue/green: in-place updates the existing fleet (EC2/on-premises only), while blue/green stands up a new version beside the old and shifts traffic, the only model Lambda and Amazon ECS support, via AWS CodeDeploy weighting an alias between immutable versions. What makes any of this safe is automatic rollback: on a failed alarm or hook, CodeDeploy redeploys the last good revision as a new deployment with no human in the loop. Match the increment to the stated risk tolerance; never pick an in-place option for Lambda or ECS.

The exam maps a fixed vocabulary of pipeline actions onto a small chain of services, and each owns exactly one job. CodePipeline orchestrates: ordered stages of actions that pass artifacts through an S3 artifact store; it runs nothing itself. AWS CodeBuild compiles, tests, and packages per the buildspec.yml phases. It is where tests run and the artifact is produced. CodeDeploy deploys a built artifact onto compute and never compiles. It owns the traffic-shifting and the AppSpec lifecycle hooks. Knowing which service a task belongs to resolves most pipeline questions: a build or test failure is CodeBuild, a traffic-shift or rollback is CodeDeploy, and the stage/gate/approval structure is CodePipeline.