Based on the SOA-C02 exam guideReport an error
Week 7 examined "how to deploy safely" from five perspectives. Beanstalk's PaaS trade-offs, CodeDeploy's narrow responsibility (code only), EC2 Image Builder's immutable infrastructure enforcement, the OpsWorks-to-SSM paradigm shift, and Launch Template + Mixed Instances Policy balancing cost and availability. Though each section covered different tools, they share one fundamental question: "What trade-off is right for this workload?"
This section brings together the five core decision axes from the previous sections and presents 12 problem scenarios showing how SOA-C02 actually tests this material. The goal is not to memorize tables but to develop the decision-making intuition that determines "why A is correct and B is a trap." By reviewing this once more before the exam, the answers will naturally come to mind.
All tools covered this week reduce to five decision axes:
| Decision Axis | Question | Week 7 Tool Mapping |
|---|---|---|
| Downtime allowed? | Must it be zero, or is a few minutes acceptable? | All at once vs Rolling vs Immutable |
| Temporary capacity cost? | Is 2x acceptable, or minimize overhead? | Rolling vs Immutable vs Blue-Green |
| Rollback speed? | Immediate vs redeployment time | Immutable/Blue-Green vs Rolling |
| Infrastructure ownership | Auto-provisioned vs existing resources | Beanstalk vs CodeDeploy vs CloudFormation |
| Change scope | Code only vs entire environment vs AMI | CodeDeploy vs Beanstalk vs Image Builder |
With these 5 axes, you can decompose almost any scenario automatically. For example, "zero-downtime + minimal cost + existing EC2 infrastructure" initially seems ambiguous (CodeDeploy + Blue-Green vs Beanstalk + Rolling with batch?), but the "existing infrastructure" clue points clearly to CodeDeploy.
💡 Related Theory: This decision-axis approach mirrors the Architecture Decision Record (ADR) standard template. Michael Nygard's 2011 ADR format follows Context → Decision → Consequences, explicitly documenting trade-offs for each decision. Practicing scenario decomposition like an ADR is a core cloud architect thought pattern for both exams and real-world work.
| Decision Criteria | Beanstalk | CodeDeploy | CloudFormation |
|---|---|---|---|
| Infrastructure creation | Automatic (EC2/ALB/RDS) | External (user responsibility) | Automatic (all resources) |
| Code deployment | Integrated | Core function | Separate (custom resource) |
| Rollback scope | Entire environment | Revision | Entire stack |
| Deployment hooks | .ebextensions, .platform | AppSpec hooks (13 steps) | UpdatePolicy + WaitCondition |
| Language awareness | Yes (Node/Python/Java/...) | No (language-agnostic) | No (language-agnostic) |
| Use case | Simple web app PaaS | Existing EC2/Lambda/ECS fleet | Complete IaC |
In production, you combine all three. CloudFormation provisions VPC/ALB/ASG infrastructure, CodeDeploy handles code on top of it, and Beanstalk is reserved for small workloads where you want infrastructure bundled with the application. Image Builder creates the AMI for the ASG.
| Policy | Downtime | Temp Capacity | Temp Cost | Rollback Speed | Recommended Use |
|---|---|---|---|---|---|
| All at once | Present | 0% (full stop) | None | Redeploy required | dev/staging |
| Rolling | None | Temporarily reduced | None | Redeploy required | Production without traffic spikes |
| Rolling with batch | None | Maintained | Batch-only | Redeploy required | Balanced production |
| Immutable | None | Maintained | 2x | Fast (old ASG survives) | Production where stability is critical |
| Blue-Green (URL Swap) | None | Maintained | 2x | Immediate (CNAME switch) | Instant rollback required |
Critical trap: "Blue-Green = instant 100% switchover" is incorrect. CNAME switch is instant, but DNS TTL means some users stay on the old environment during the window. Beanstalk's default CNAME TTL is 60 seconds, but some ISPs and internal DNS servers cache longer, so actual 100% switchover can take 5-30 minutes.
EC2 hook sequence:
ApplicationStop → DownloadBundle(auto) → BeforeInstall → Install(auto) →
AfterInstall → ApplicationStart → ValidateService
[Blue-Green only]
→ BeforeBlockTraffic → BlockTraffic(auto) → AfterBlockTraffic →
BeforeAllowTraffic → AllowTraffic(auto) → AfterAllowTraffic
Deployment methods by compute platform:
Two auto-rollback triggers:
[Image Builder Pipeline] (monthly cron)
↓
Create new AMI
↓ (EventBridge)
[Lambda] → Update SSM Parameter
/golden-ami/al2/latest = ami-XXXX
↓
[Launch Template]
ImageId: '{{resolve:ssm:/golden-ami/al2/latest}}'
↓
[Auto Scaling Group]
Next Instance Refresh or scale-out uses new AMI
The elegance of this pattern: reference indirection. If the Launch Template refers to an AMI via SSM Parameter instead of directly, you don't need to create a new Launch Template version each time the AMI changes. Just update the SSM Parameter; the next instance creation automatically uses the new AMI.
| Item | LC (deprecated) | LT (standard) |
|---|---|---|
| Version management | None | $Latest, $Default, etc. aliases |
| Partial updates | Impossible (recreate) | Possible |
| Mixed Instances | Not supported | Supported |
| SSM Parameter reference | Not supported | Supported ({{resolve:ssm:...}}) |
| New EC2 features | Unsupported (frozen) | Supported |
| New console creation | Impossible after 2022.12 | Standard |
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: web-lt
Version: $Latest
Overrides:
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: m6i.large
InstancesDistribution:
OnDemandBaseCapacity: 2 # Minimum on-demand guaranteed
OnDemandPercentageAboveBaseCapacity: 30
SpotAllocationStrategy: capacity-optimized # or price-capacity-optimizedSpot Allocation Strategy priority:
Spot interruption graceful shutdown:
EC2 Spot Instance Interruption Warning) → Lambda → ALB deregister + SSM Run Command for graceful shutdown signal/latest/meta-data/spot/instance-action detects faster (~10 seconds) than EventBridgeOpsWorks Stacks EOL: May 26, 2024. AWS-recommended migration:
aws:applyChefRecipes action: Reuse existing Chef cookbooksLong-term, Image Builder-based immutable infrastructure is the recommended path.
| Item | Service Catalog | AWS Proton |
|---|---|---|
| Target audience | IT users (general infra requests) | Developers (entire service workflow) |
| IaC | CloudFormation | CloudFormation, Terraform |
| CI/CD integration | None (separate) | Built-in (CodePipeline) |
| Abstraction | Product (single stack) | Environment + Service (separated) |
| Use case | "Create one VPC for me" | "Git push my microservice → infra + CI/CD auto-provisioned" |
💡 Related Theory: Proton is AWS's native implementation of Spotify's Backstage "Internal Developer Platform (IDP)" concept. It aligns with CNCF Platform Working Group reference architecture — Platform Engineers define the golden path, Developers self-serve within it.
Click a choice to reveal the answer and explanation.
Question 1
You need production deployment with zero downtime, maintaining capacity, and minimizing additional cost. Which Beanstalk deployment policy is best?
Question 2
You want to route 10% traffic to a new Lambda version for 5 minutes of validation, then 100% switchover. Operations team demands automatic validation and rollback. Best approach?
Question 3
In AppSpec.yml, which hook runs right after new version files are copied to the destination directory, where you set permissions, create symlinks, and substitute environment-specific config?
Question 4
Company wants to build a new Golden AMI monthly; new ASG instances should auto-use it without manual intervention. What's the AWS-recommended standard pattern?
Question 5
Beanstalk environment termination deleted the embedded RDS database and caused data loss. How to prevent this?
Question 6
Auto Scaling Group needs minimum 2 on-demand instances guaranteed, above that 30% on-demand + 70% Spot for cost reduction, and minimize Spot interruptions.
Question 7
CodeDeploy deployment should auto-rollback to previous version if CloudWatch HighErrorRate Alarm triggers. Configuration?
Question 8
Automate graceful shutdown (ALB Target Group deregister, complete pending requests, backup logs) 2 minutes before Spot instance interruption.
Question 9
OpsWorks Stacks reaches EOL May 26, 2024. Migrate existing Chef cookbook assets to AWS with minimal infrastructure management burden.
Question 10
Platform Engineering team building IDP where developers Git push and automatically get standard Fargate Service + ALB + RDS + CodePipeline provisioned. Best AWS-native tool?
Question 11
Apply new Launch Template version (new Golden AMI reference) to running ASG, safely gradually replace all instances, auto-rollback if CloudWatch Alarm triggers mid-process.
Question 12
ASG scale-out cold start (AMI fetch + cloud-init + app startup) takes 3-5 minutes; too slow for traffic spikes. Reduce to 30-60 seconds without major cost increase. Also, predictable patterns (weekday 09:00 spikes) need additional policy.
Week 7 covered five seemingly different tools (Beanstalk, CodeDeploy, Image Builder, OpsWorks/SSM, Launch Template/ASG), but the core question remained constant: trade-offs across five axes. Downtime tolerance, temporary capacity cost, rollback speed, infrastructure ownership model, and change scope. Exam scenarios test these axes. Developing fast decomposition intuition — "which axis is decisive in this scenario?" — is stronger than memorizing tool names and hook sequences for both exams and real-world architecture.
Next week (Week 8) transitions to networking operations: VPC troubleshooting, Flow Logs, VPC Endpoints, Transit Gateway — 18% of the CloudOps exam domain. Deployment automation was "how to safely push code;" networking is "how to safely flow traffic."
💡 Networking troubleshooting is the trickiest CloudOps domain. NACL vs SG stateless/stateful distinction, VPC Endpoint policies, Transit Gateway route precedence are high-frequency test topics.