Deployment
CI/CD Releases, Deployment Strategies, Promotion, and Rollback
CoreUse an existing AWS CI/CD workflow to package, trigger, promote, configure, deploy, observe, and roll back application releases.
Aligned to AWS Certified Developer - Associate (DVA-C02) Version 2.1, verified August 23, 2026.
Why this matters
Deployment is an end-to-end evidence chain: approved source produces one artifact, tests qualify it, configuration binds it to an environment, a release strategy limits risk, and rollback restores a known-good target. A successful build alone proves little.
Must Know
- Lambda functions use ZIP archives or container images as deployment package types. Select the type from runtime and dependency constraints and follow its build/update workflow.
- An API Gateway stage points to an API deployment and carries stage settings. A custom domain provides client-facing hostname and API mapping; it does not deploy the API.
- Update resources already managed by AWS SAM or CloudFormation through the reviewed template and stack workflow rather than creating console drift.
- Commit or merge to the configured repository source can trigger existing build, test, and deployment actions; follow the commit and artifact through every stage.
- Promote the same immutable artifact across environments and bind approved runtime configuration, stage variables, secrets, and roles at each target.
- Canary exposes a small portion of traffic first, blue/green validates a parallel environment before traffic cutover, and rolling replaces capacity in controlled batches.
- Rollback uses the existing strategy to restore a known-good version or environment; it should not require editing source in production.
- Branches, labels, image tags, Lambda aliases, and environment names identify different lifecycle objects; preserve the mapping among them.
- AWS CodePipeline orchestrates stages and transitions, CodeBuild runs build/test commands, and CodeDeploy automates supported deployments and rollback behavior.
Compare and Distinguish
- ZIP vs container image: package form changes build and dependency handling; it is not merely a filename choice.
- Stage vs custom domain: the stage is a deployment/configuration boundary; the custom domain is a stable hostname and routing mapping.
- Artifact vs runtime configuration: promote tested bytes unchanged and bind approved environment values at deployment/runtime.
- Canary vs blue/green vs rolling: gradual traffic exposure, parallel-environment cutover, and batch capacity replacement have different validation and rollback boundaries.
- Lambda version vs alias: deploy immutable versions and move aliases deliberately for release or rollback.
- CodeBuild vs CodeDeploy vs CodePipeline: execute build/test, perform supported deployment, and orchestrate the multi-stage workflow.
- Branch/tag vs environment: source/release labels do not by themselves create isolated deployed resources or configuration.
Scenario examples
- Scenario: A Lambda release should reach five percent of traffic before expansion. Route a weighted alias to the new version, monitor, then shift or roll back.
- Scenario: A managed application needs a parallel validated environment and fast switchback. Deploy green, validate it, shift traffic, and retain blue during the rollback window.
- Scenario: The same API code needs different backend endpoints by stage. Supply approved stage/runtime configuration instead of branching on hard-coded hostnames.
- Scenario: A deployment fails before traffic shifts. Inspect the failing pipeline or service output and correct that artifact, template, permission, or configuration boundary.
Exam traps
- A custom domain does not create an API deployment or stage.
- Rebuilding separately in each environment breaks the tested-artifact promotion chain.
- Canary, blue/green, and rolling are not interchangeable names for gradual deployment.
- A commit triggering a pipeline does not prove later actions succeeded.
- A branch name, mutable image tag, or alias alone does not prove immutable artifact identity.
- Do not design a CI/CD pipeline from scratch; apply these decisions within an existing repository and workflow.
Key takeaways
- Trace source, artifact, test evidence, configuration, and deployment target as distinct release facts.
- Promote immutable artifacts rather than rebuilding per environment.
- Select a release strategy from exposure, capacity, validation, and rollback requirements.
- Keep IaC as the source of truth for managed resources.
- Plan and verify rollback before shifting full traffic.
How it works
- An approved repository event triggers build and test actions that create an immutable artifact.
- The workflow promotes that artifact with environment-specific IaC, configuration, secrets, and roles.
- The selected strategy changes capacity or traffic while health signals are observed.
- On failure, the existing rollback mechanism restores the prior version, alias, or environment.
When to use it
- Use canary when a small traffic sample should validate a new version before expansion.
- Use blue/green when a separately validated environment and rapid traffic switchback are required.
- Use rolling when capacity should be replaced in controlled batches and mixed versions are acceptable during rollout.
- Use CodePipeline for stage orchestration, CodeBuild for build/test execution, and CodeDeploy for supported automated deployments.
- Use API stages and Lambda aliases as service-specific environment/version surfaces.
Security and governance implications
- Separate build and deployment roles and scope each to required sources, artifacts, stacks, and environments.
- Protect production branches, tags, aliases, configuration, and approval transitions.
- Retrieve secrets at the target environment; do not copy test secrets into artifacts or production.
- Keep deployment logs useful without exposing tokens, environment secrets, or full sensitive configuration.
Failure signals and diagnosis
- Locate the first failed stage and read its service output before rerunning or rolling back.
- For wrong-version deployment, compare commit, build output, artifact digest, alias/tag, and target environment.
- For canary failure, inspect new-version metrics separately and restore the known-good traffic target.
- For API routing errors, separate deployment, stage, base-path/domain mapping, DNS, and runtime configuration.
More detail
- An existing pipeline can be triggered by source changes and can carry one artifact through approval and deployment stages.
- Dynamic deployments read approved environment configuration at deployment or runtime rather than infer it from source code.
- Health and error signals decide whether traffic continues, pauses, or returns to the known-good release.
- Update an existing template and workflow; architecture and pipeline-topology design remain outside the target role.
Ready for the quiz?
- What does a custom domain add that an API stage does not?
- Why should one artifact move across environments?
- Which requirement favors canary, blue/green, or rolling?
- What must a rollback target identify?
- How do CodeBuild, CodeDeploy, and CodePipeline divide responsibilities?
Related objectives
- D3.4 — Deploy code by using AWS Continuous Integration and Continuous Delivery (CI/CD) services
- 3.4.1 — Describe Lambda deployment packaging options
- 3.4.2 — Describe API Gateway stages and custom domains
- 3.4.3 — Update existing IaC templates (for example, AWS SAM templates, CloudFormation templates)
- 3.4.4 — Manage application environments by using AWS services
- 3.4.5 — Deploy an application version by using deployment strategies
- 3.4.6 — Commit code to a repository to invoke build, test, and deployment actions
- 3.4.7 — Use orchestrated workflows to deploy code to different environments
- 3.4.8 — Perform application rollbacks by using existing deployment strategies
- 3.4.9 — Use labels and branches for version and release management
- 3.4.10 — Use existing runtime configurations to create dynamic deployments (for example, using staging variables from API Gateway in Lambda functions)
- 3.4.11 — Configure deployment strategies (for example, blue/green, canary, rolling) for application releases