2.1 Deployment Strategy
Official task mapping
SAP-C02 task 2.1: IaC and delivery knowledge; rollout selection and rollback planning. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review CloudFormation, CDK and Systems Manager. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Delivery decisions
CloudFormation/CDK make infrastructure repeatable; review change sets, drift and stateful-resource retention before applying them. CI/CD should build once, test, approve where required and promote traceable artifacts with scoped deployment roles.
Rolling deployment limits temporary duplicate capacity but mixes versions. Blue/green isolates versions with additional capacity during overlap. Canary/linear shifts expose a smaller population first and require meaningful alarms. CodeDeploy support differs between EC2, ECS and Lambda targets.
A DNS change is not instant rollback: TTLs, resolver caches and persistent connections affect convergence. Data/schema changes can outlive a traffic rollback. Prefer backward-compatible expand/contract migrations and an explicit database recovery plan.
OpsWorks is retired; use supported configuration/deployment tools instead. CodeCommit reopened to new customers on November 24, 2025, according to AWS’s announcement; do not preserve the older blanket new-customer prohibition. Select a repository by integration, access and lifecycle requirements rather than assuming it from an old service list.
Infrastructure and delivery components
| Component | Role | Review before deployment |
|---|---|---|
| CloudFormation template/stack | Declare/create resource set | Replacements, retained data, drift and rollback |
| Change set | Preview planned changes | Not proof runtime validation or no disruption |
| StackSets | Coordinate supported account/Region stacks | Execution roles, target OU/accounts and failures |
| CDK | Synthesize CloudFormation from constructs | Generated template, dependencies and version |
| CodeBuild | Build/test artifacts | Build role, untrusted code and artifact provenance |
| CodePipeline | Orchestrate supported stages | Approvals, artifact encryption and per-stage access |
| CodeDeploy | Target-specific rollout | EC2/on-prem, ECS or Lambda mode support |
| Elastic Beanstalk | Managed application environment/deployment | Mode, health gates, version ownership and resource cost |
CDK L1 constructs mirror low-level resources, L2 adds higher-level intent, and patterns compose components; none exempts the synthesized stack from review.
Rollout comparison
| Strategy | Exposure/capacity | Rollback issue |
|---|---|---|
| In-place | Existing fleet updated | Failed hosts/version mixing |
| Rolling | Subset updated at a time | Capacity headroom and compatible versions |
| Blue/green | Parallel environments during overlap | State writes and traffic convergence |
| Canary/linear | Gradual traffic shift | Meaningful alarms and sufficient samples |
Systems Manager Run Command executes authorized commands, State Manager maintains desired configuration, and Patch Manager supports patch workflows. Keep patch windows, IAM scope and logging explicit. OpsWorks Chef/Puppet is retired; choose a supported configuration and deployment workflow.
Elastic Beanstalk is a supported managed application-deployment alternative, not a replacement for every pipeline or node-operation tool. Standard mode uses EC2 and selected platform versions; Cluster mode uses EKS/container images rather than a Beanstalk platform. Keep application/dependency updates, supported-version/image ownership and rollout health gates explicit. Beanstalk adds no service fee, but underlying resources and parallel rollout capacity still cost money. IaC can declare environments, CI/CD can promote artifacts, and Systems Manager handles applicable node operations; these responsibilities can coexist. See the current Beanstalk model.
For a 5% canary among 10,000 requests/minute, only 500 requests/minute test the new version. A rare 0.01% business defect needs more than a few success responses to evaluate. Set gates from business risk and traffic evidence, not a copied “10% then 50%” sequence.
Scenario and rationale
A payments API must deploy weekly with a maximum 1% error rate and irreversible database writes. Use a controlled canary with error/latency/business-metric gates and compatible schema changes. Keep the prior artifact ready and define what happens to writes made by the new version.
Reject all-at-once deployment when one defect could interrupt all payments. Reject “flip DNS and instantly undo everything”: it neither guarantees traffic convergence nor reverses database mutations.
Practice drill
Design a pipeline with unit/integration tests, policy checks, approval and staged traffic. Write stop/rollback criteria for a canary whose HTTP success rate is healthy but payment reconciliation fails. Calculate temporary duplicate-capacity cost and list retained state, quotas and permissions. This is a design drill; no pipeline is deployed.
Compare that design with a small stateless supported-platform web application whose team wants managed environment setup and health/scaling rather than bespoke fleet administration. Identify which responsibilities Beanstalk can absorb, which artifact/security gates stay in the pipeline, and which fleet operations still need Systems Manager. Reject Beanstalk when required platform/runtime or infrastructure controls do not fit the selected mode; reject manual node scripting as the default when it adds avoidable provisioning/patching work. Include resource overlap and state recovery in both alternatives.
References
- Official Domain 2 task guide
- CodeDeploy deployment configurations
- CloudFormation change sets
- Retired service lifecycle
- CodeCommit reopening announcement
Return to Domain 2. The drill is proposed study work, not a claim of a completed deployment.
Across the wiki
- Progressive Delivery Strategies — deployment strategies (Kubernetes)
- Blue-Green Deployments — deployment strategies (Architecture)
- Deployment Strategies — deployment strategies (DevOps)
- Deployments — deployment strategies (Kubernetes)