In SAP-C02, deployment strategies and business continuity span two domains: D2 (Design for New Solutions) and D3 (Continuous Improvement for Existing Solutions). The exam does not just test whether you know service names. It tests your ability to judge which deployment approach to choose in a given situation. This post works through CloudFormation change management, CI/CD pipelines, Blue/Green deployments, and disaster recovery patterns using real exam scenarios.
CloudFormation Change Management — Change Sets and Stack Policy
The most dangerous moment when managing production infrastructure with CloudFormation is the stack update. Changes that require deleting and recreating a resource — called Replacement changes — can cause data loss. Examples include modifying a DynamoDB key schema, renaming an S3 bucket, or switching an RDS instance to Multi-AZ in some configurations.
Change Sets solve this problem. Before touching the stack, you create a change plan that shows exactly which resources will be Added, Modified, Removed, or Replaced. Items flagged as Replacement: True will be deleted and recreated, so reviewing and approving these before proceeding is essential.
Stack Policy is a JSON document that automatically blocks Replace or Delete operations on specific resources. If Change Sets are the "preview," Stack Policy is the "guardrail." In regulated environments like PCI DSS or SOX, the Change Set history also serves as a change-approval audit trail.
Drift Detection is commonly confused with these tools. Drift Detection finds changes made outside CloudFormation — directly through the console or CLI — after a deployment has already happened. Its purpose is different from preventing replacements before a deployment. Know the distinction for the exam.
| Feature | Purpose | Timing | |---------|---------|--------| | Change Sets | Preview changes (identify Replacements) | Before deployment | | Stack Policy | Automatically block replace/delete on specific resources | During deployment | | Drift Detection | Detect manual changes made outside CloudFormation | After deployment |
CI/CD Pipelines — CodePipeline, CodeBuild, ManualApproval
In the AWS-native CI/CD model, CodePipeline orchestrates the overall pipeline, CodeBuild handles builds and tests, and CodeDeploy performs the actual deployment.
The safe deployment pipeline integrated with CloudFormation follows this flow: Source detection (CodeCommit or GitHub) → Create Change Set → ManualApproval stage where an engineer reviews the Change Set → Approve → ExecuteChangeSet. This pattern implements Segregation of Duties for change management in PCI DSS environments.
Jenkins integration is tested frequently. Organizations migrating to AWS do not always want to replace Jenkins entirely. CodePipeline lets you designate Jenkins as the provider in the build stage, so you retain the existing Jenkins investment while adding AWS pipeline orchestration. CodeBuild is the choice when you want to replace Jenkins. The CodePipeline plus Jenkins combination is the choice when you want to keep Jenkins.
For container CI/CD, ECR image scanning matters. Basic Scanning uses a CVE database. Enhanced Scanning uses Amazon Inspector for deeper vulnerability analysis. ECS deployment options are Rolling Update (sequential instance replacement) and Blue/Green (CodeDeploy-based, zero downtime). When the requirement is zero downtime, choose Blue/Green.
Lambda Progressive Deployment — Alias, Canary, Linear
To safely update a Lambda function, you first need to publish a Version and create an Alias, rather than invoking $LATEST directly. CodeDeploy integration then provides three deployment strategies.
Canary sends a small percentage of traffic (for example 10%) to the new version first. After validation, it switches the remaining 90% all at once. Linear increases traffic to the new version by a fixed percentage every N minutes. AllAtOnce switches everything immediately and is used for low-risk changes where no rollback is expected.
Connecting CloudWatch alarms to CodeDeploy enables automatic rollback to the previous version if the error rate spikes. With SAM, you declare this configuration using the DeploymentPreference property.
| Strategy | Behavior | Auto Rollback | |----------|----------|---------------| | Canary | X% first, then 100% after validation | CloudWatch Alarm | | Linear | X% more every N minutes | CloudWatch Alarm | | AllAtOnce | 100% immediately | Manual only |
!Lambda progressive deployment types
Blue/Green Deployment — Zero Downtime and Instant Rollback
The core principle of Blue/Green deployment is maintaining two parallel environments and switching traffic between them to swap versions. Rollback means switching traffic back to Blue, which completes in under five minutes. Rolling or in-place deployments require redeployment for rollback, which takes just as long as the original deployment.
Each platform implements Blue/Green differently. For EC2 with Auto Scaling, you run a Blue ASG and a Green ASG in parallel, then switch the ALB target group. For ECS, CodeDeploy runs Blue (old version) and Green (new version) tasks in parallel using dual ALB listeners — test traffic on port 8080 and production traffic on port 443. For Elastic Beanstalk, you do an instantaneous CNAME swap between the two environments.
Route 53 weighted routing gives you finer control over traffic switching during Blue/Green transitions. You can start at Blue 90% and Green 10%, then gradually shift the ratio — a canary-style Blue/Green approach.
DR Scenarios — RTO, RPO, and Cost Trade-offs
The most important judgment criteria in business continuity questions are RTO (Recovery Time Objective) and RPO (Recovery Point Objective). Cost and recovery speed are inversely proportional. The SAP-C02 exam asks you to find the minimum-cost solution that meets the stated requirements.
Aurora Global Database achieves RPO below one second through storage-layer replication, and RTO below one minute through secondary region promotion. It suits financial and healthcare systems with strict requirements. Aurora Serverless v2 can be paired with Global Database for multi-region serverless DR.
RDS Cross-Region Read Replica uses asynchronous replication, so RPO is measured in seconds to minutes. It costs less than Aurora Global Database but has a looser RPO. Promotion takes five to ten minutes at failover time. You can automate the promotion process by chaining CloudWatch RDS events, EventBridge, and Lambda.
Route 53 Failover routing combined with Calculated Health Checks drives automatic DR switching. Calculated Health Checks combine multiple child health checks with AND or OR logic to prevent unnecessary failovers caused by false positives.
DynamoDB Global Tables provides a multi-region Active-Active structure where reads and writes are accepted from any region. This contrasts with Aurora Global Database, which is Active-Passive — only the primary region accepts writes. When the scenario requires NoSQL with multi-region write capability, choose DynamoDB Global Tables.
Systems Manager Patch Management
Systems Manager Patch Manager manages not just EC2 instances but also on-premises servers that have the SSM Agent installed. To unify patch management across a hybrid environment, install the SSM Agent on on-premises servers and configure Hybrid Activation. Once that is done, you define Patch Baselines and Maintenance Windows to manage cloud and on-premises servers using the same workflow from the AWS console.
Exam Key Points
"Change Sets Replacement True means" -- the resource will be deleted and recreated (risk of data loss)
"Tools to prevent replacements before deployment" -- Change Sets plus Stack Policy
"Detecting manual changes made outside CloudFormation after deployment" -- Drift Detection
"Send small traffic percentage to new Lambda version first, then switch the rest" -- Canary deployment (CodeDeploy plus Alias)
"Increase Lambda traffic by X% every N minutes" -- Linear deployment
"Why Blue/Green rollback completes within 5 minutes" -- only traffic redirection is needed, no redeployment
"ECS Blue/Green dual listener" -- test (8080) plus production (443) running simultaneously
"Multi-region NoSQL Active-Active writes" -- DynamoDB Global Tables
"RPO under 1 second and RTO under 1 minute for relational DB" -- Aurora Global Database
"Asynchronous replication, 5-10 minute promotion, lower cost" -- RDS Cross-Region Read Replica
"Manage on-premises server patching from the AWS console" -- Systems Manager Patch Manager plus Hybrid Activation
"PCI DSS change management with segregation of duties" -- CodePipeline plus ManualApproval plus Change Sets