Deployment strategies

Every deployment pattern is a position on one trade-off triangle: how large a blast radius a bad release may have, how much extra cost you pay during the rollout, and how fast you can roll back. Blue/green buys instant rollback by paying for two full environments; all-at-once is free but exposes 100% of users at once; canary trades a small first slice for a monitoring window. The four canonical patterns sit at different corners of that triangle, and the exam expects you to map a scenario's constraints to the right one.

The four patterns

Pattern	Blast radius of a bad release	Rollback speed	Extra cost during deploy	Mixed versions live?
All-at-once	100% immediately	Slowest (full redeploy)	None	No
Rolling / in-place	Grows batch by batch	Slow (redeploy prior batches)	None	Yes
Blue/green	0% until cutover, then 100%	Instant (flip traffic to blue)	High (two full environments)	No
Canary / linear	Small first slice, then grows	Fast (stop shift, auto-rollback)	Low (one extra version / task set)	Yes

All-at-once replaces every target simultaneously. It is the cheapest and fastest path, but a defect reaches 100% of users at once and the only rollback is a second full deployment. Reserve it for dev, low-risk internal tools, or workloads where a brief outage is acceptable.

Rolling (in-place) updates the existing fleet in batches. There is no duplicate fleet to pay for, but two consequences follow: old and new versions run side by side during the rollout (so the versions must be compatible), and rollback means redeploying the previous revision to the already-updated batches, slow.

Blue/green stands up a parallel green environment next to the running blue one and cuts traffic over at the load balancer or via DNS. Because blue keeps running, rollback is an immediate traffic flip with no redeploy, the fastest recovery available. The price is running two full environments during the cutover window, which is why it is the wrong default for cost-sensitive, low-risk work.

Canary and linear expose a small slice of traffic to the new version first, giving a monitoring window in which an alarm can abort before the blast radius grows. A canary shifts one increment (for example 10%), bakes for a fixed interval, then sends the rest; a linear config shifts a fixed percentage on a repeating interval until 100%. Both are the safest way to expose a new version of a serverless or containerized workload.

The coexistence precondition

Canary, linear, and blue/green all assume the old and new versions can run at the same time during the shift. A backward-incompatible (schema-breaking) database change violates this: it breaks the still-running old version the moment the new schema lands. The professional-level answer is the expand/contract (parallel-change) migration: first deploy a backward-compatible schema that both versions tolerate (expand), migrate the code, then remove the old columns/behavior (contract). If you cannot make the change compatible, accept a maintenance-window all-at-once cutover instead. Treat any answer that runs a canary over a schema-breaking migration as wrong.

The non-negotiable: rollback must be automated

The pattern matters less than the rule underneath all of them: a deployment is only safe if it self-aborts on a bad health signal. Wire health alarms to the deployment so the platform reverts without a human in the loop. A release path whose only recovery is a manual redeploy is the anti-pattern the exam consistently penalizes, regardless of how elegant the rollout strategy looks.

CodeDeploy^[8] automates deployments to three compute platforms, and the SAP-C02 traps live in the differences between them.

Three compute platforms, two deployment types

CodeDeploy offers two deployment types, in-place and blue/green, but they are not available everywhere. Only the EC2/On-Premises compute platform can do in-place deployments; AWS Lambda and Amazon ECS deployments cannot use the in-place type and are always blue/green^[8]. For EC2/On-Premises blue/green, CodeDeploy provisions a replacement environment (a new set of instances), installs the revision, optionally pauses for testing, then registers the replacement instances with the Elastic Load Balancing load balancer and deregisters the original ones (which can be terminated or kept running). Blue/green on EC2/On-Premises works with Amazon EC2 instances only, on-premises instances are not supported^[8]; the replacement environment is built either by copying an existing Auto Scaling group or by selecting instances manually.

Predefined deployment configurations per platform

Compute platform	Mechanism	Predefined configs
EC2/On-Premises (in-place)	Minimum-healthy-hosts	CodeDeployDefault.AllAtOnce, HalfAtATime, OneAtATime
AWS Lambda	Alias weighting	LambdaCanary10Percent5Minutes (+10/15/30-min), LambdaLinear10PercentEvery1Minute (+2/3/10-min), LambdaAllAtOnce
Amazon ECS	Weighted target group	ECSCanary10Percent5Minutes, ECSCanary10Percent15Minutes, ECSLinear10PercentEvery1Minutes, ECSLinear10PercentEvery3Minutes, ECSAllAtOnce

The EC2/on-premises configs are governed by a minimum-healthy-hosts value, not traffic weighting, and the default when none is specified is CodeDeployDefault.OneAtATime^[1]. On Lambda, CodeDeploy shifts traffic between function versions by alias weighting; the linear config name ends in the singular "Minute"^[1]. On ECS, the new application deploys as a replacement task set and traffic shifting requires a weighted target group; the ECS linear name ends in the plural "Minutes", and behind a Network Load Balancer only CodeDeployDefault.ECSAllAtOnce is supported^[1]. That NLB restriction is a recurring distractor: if a stem puts an ECS service behind an NLB and offers a canary config, the canary option is impossible.

Lifecycle hooks gate the shift

For Lambda and ECS, the AppSpec hooks section names Lambda validation functions that run at lifecycle events. Lambda deployments expose BeforeAllowTraffic (before traffic shifts to the new version) and AfterAllowTraffic (after)^[9]. ECS deployments add BeforeInstall, AfterInstall, and AfterAllowTestTraffic, the latter running validation against a separate test listener before any production traffic moves^[9]. A failing hook triggers a rollback; if the validation function does not call back Succeeded/Failed within one hour the deployment is treated as failed. This is how you run automated smoke tests against the green version before it ever sees a customer.

Automatic rollback is alarm-driven

CodeDeploy can be configured to automatically roll back when a deployment fails or when a CloudWatch monitoring threshold (alarm) is met, redeploying the last known good revision^[4]. One subtlety the exam rewards: a rollback is itself a new deployment, CodeDeploy redeploys the previous revision with a new deployment ID rather than restoring an old one^[4]. For blue/green the practical effect is faster and more reliable than in-place, because traffic can be routed back to the still-running original instances instead of waiting on a redeploy.

CodeDeploy releases the application; CloudFormation (and its higher-level wrappers) provisions and governs the infrastructure that runs it. The professional change-management story is everything as code, every change previewed, one artifact promoted.

CloudFormation as single source of truth

Modeling infrastructure as a CloudFormation^[3] template makes environments reproducible and auditable. Two governance features matter for deployments:

• Change sets let you preview an update before executing it. A change set shows which resources CloudFormation will add, modify, replace, or delete, and nothing changes until you execute it^[7], surfacing destructive replacements (which can mean data loss) ahead of time. A change set does not guarantee the update will succeed (quotas, permissions, or non-updatable properties can still fail it), and executing one removes all other change sets associated with that stack^[7].
• Drift detection flags resources changed outside CloudFormation. It detects whether a stack's actual configuration differs from its expected (template) configuration, on an entire stack or individual resources^[10]; resources get a drift status of IN_SYNC, MODIFIED, DELETED, or NOT_CHECKED. Only AWS resources that support drift detection are checked, and CloudFormation does not detect drift on nested stacks of a stack you check, you must run drift detection directly on each nested stack^[10]. Reconcile out-of-band console edits back into the template so the IaC stays authoritative.

Nested stacks for reuse

Nested stacks let you split a large template into reusable pieces: a parent template references a child template through the AWS::CloudFormation::Stack resource^[11], and the top-level stack is the root stack while each nested stack has an immediate parent stack. Stack updates should be initiated from the root stack; when you update a root stack, only nested stacks whose template changed are updated^[11]. Use nesting to share a common load balancer or VPC pattern across many stacks instead of copy-pasting resource blocks.

StackSets for cross-account, multi-Region rollout

CloudFormation StackSets deploy one template as stack instances into many accounts and Regions from a single administrator account^[3]. The permission model is the exam's favorite distinction:

• Service-managed permissions (integrated with AWS Organizations) create the cross-account IAM roles for you and support automatic deployment, so an account later added to a target OU inherits the baseline stack with no manual action.
• Self-managed permissions require you to create the cross-account roles yourself and target individual account IDs, with no auto-deploy to future accounts.

A stack instance is a reference to a stack in a target account/Region and can exist even when its stack failed to create; failure tolerance is evaluated per Region and Region concurrency is Sequential (default) or Parallel^[3]. Those operation preferences give a StackSet the same incremental, fail-fast behavior you want from any production rollout. When a stem says "the baseline must reach every account in the organization, including ones created later," the answer is service-managed StackSets, not a Lambda that copy-deploys templates.

SAM and CDK compile down to CloudFormation

For serverless, AWS SAM is an open-source framework and an extension of CloudFormation: its shorthand syntax declares serverless resources that are transformed into standard CloudFormation during deployment^[12], and a SAM AutoPublishAlias plus DeploymentPreference wires Lambda canary/linear traffic shifting through CodeDeploy with almost no boilerplate. AWS CDK lets you define infrastructure in a general-purpose language and synthesizes the same CloudFormation. Because all three converge on CloudFormation, the change-set, drift, and StackSet behaviors above apply no matter which authoring layer the scenario names.

Beyond CodeDeploy's built-in shifting, SAP-C02 expects you to know the load-balancer and DNS primitives that move traffic, the feature-flag service that decouples release from deploy, and the pipeline that gates the whole path.

Where traffic actually shifts

The lever you reach for is decided by one question: where do the blue and green versions live? Within one Region, weight at the load balancer; across separate stacks or Regions, weight in DNS; for an active/passive cutover, let health checks move traffic for you.

• ALB weighted target groups: an Application Load Balancer can forward to multiple target groups with weights, so a listener rule sending 90% to blue and 10% to green is the mechanism under an ECS canary. Weighting at the ALB shifts within a Region in seconds.
• Route 53 weighted records: for blue/green across whole environments (or Regions) you point traffic with weighted DNS records and lower blue's weight as green proves out. DNS shifting is coarser (bounded by record TTL and resolver caching) and is a control-plane operation, so it is less resilient than a data-plane flip for failover, but it is the standard cross-environment cutover lever.
• Route 53 failover records + health checks: for an active/passive cutover, a failover routing policy backed by health checks moves traffic automatically when the primary is unhealthy.

Use the ALB lever for in-Region task/instance shifting and the Route 53 lever when the blue and green environments are separate stacks or Regions.

AppConfig decouples release from deploy

AWS AppConfig adjusts application behavior in production without full code deployments, using feature flags and dynamic configuration; if a bad change triggers a CloudWatch alarm, AppConfig automatically rolls the change back^[5]. It supports two configuration profile types, feature flags and freeform, and ships safety controls: validators that check a configuration before it deploys, a deployment strategy that releases the change gradually, and alarm-based automatic rollback. An AppConfig deployment strategy has a deployment type (Linear or Exponential), a step percentage (the API calls it growth factor), a deployment-time window, and a bake time during which AppConfig watches the configured CloudWatch alarms after the change reaches 100% of targets and rolls back if one fires^[2] (AppConfig must hold IAM permission to roll back). Reach for AppConfig when runtime behavior must change but the deployed artifact should not: toggling a feature, flipping a throttle limit, or instantly disabling a misbehaving capability without a redeploy.

CodePipeline orchestrates with approval gates

The release path is chained in CodePipeline: CodeBuild builds and tests, then CodeDeploy and/or CloudFormation actions release. A manual-approval action inserted between stages forces a person to gate promotion (for example staging to production)^[6], giving a repeatable, reviewed, auditable change-management path. Two professional disciplines round it out:

• Promote one immutable artifact. Build the artifact once and promote that same build through staging to production. Rebuilding per environment risks shipping a different artifact to prod than the one that was tested, defeating the purpose of the tested path.
• Gate destructive changes. Combine CloudFormation change-set review (preview replacements) with a manual-approval action so a human sees what will be deleted before prod is touched.

This is the non-negotiable rollback rule from the first section, now wearing its orchestration clothes: ship incrementally, attach health alarms to the deployment, and let the platform revert automatically, here orchestrated by IaC and gated by approvals.

SAP-C02 deployment questions are long scenarios where one constraint silently selects the answer. Train on the stem-to-answer mappings below and on why the plausible distractors fail.

Stem cues and the correct choice

Scenario cue in the stem	Correct choice	Why
"Stateful prod app; must roll back instantly with no redeploy"	Blue/green; keep blue warm and flip the ALB / Route 53	Rollback = traffic flip back to running blue, no redeploy
"Serverless API; expose new version safely, auto-abort on errors"	Lambda canary/linear via CodeDeploy + CloudWatch alarm	Alias weighting shifts a slice first; alarm auto-rolls back
"ECS service behind an NLB; want a 10% canary"	Not possible, only ECSAllAtOnce behind an NLB	Canary needs a weighted target group; NLB can't weight
"Change runtime behavior without redeploying code"	AWS AppConfig feature flag + gradual strategy	Decouples release from deploy; alarm-based rollback
"Baseline must reach every account, incl. future ones"	Service-managed StackSets (Organizations)	Auto-deploys to accounts added to the target OU
"Preview exactly what an update will change/replace"	CloudFormation change set, then execute	Shows add/modify/replace/delete before any change
"Detect resources changed outside the template"	CloudFormation drift detection, reconcile to template	Reports MODIFIED/DELETED vs expected config
"Cost-sensitive internal tool; brief outage OK"	All-at-once or rolling in-place	Blue/green doubles cost for no needed benefit
"Same tested build must reach prod"	Promote one immutable artifact, don't rebuild per stage	Rebuilding risks a different prod artifact
"Backward-incompatible DB migration mid-rollout"	Expand/contract migration first (or windowed cutover)	Canary/blue-green need old+new to coexist

Distractor traps to disarm

• "Run a canary on the ECS service behind the NLB." Wrong: traffic shifting needs a weighted target group, so behind a Network Load Balancer only CodeDeployDefault.ECSAllAtOnce is supported^[1]. The fix is an ALB (or accept all-at-once).
• "Use an in-place deployment for the Lambda function." Wrong: Lambda and ECS cannot use the in-place deployment type, they are always blue/green^[8].
• "Roll back by manually redeploying the previous version when CloudWatch alarms." Inferior: CodeDeploy can roll back automatically when an alarm threshold is met^[4], the answer that wires automatic rollback beats the one that puts a human in the loop.
• "Use self-managed StackSets so new org accounts inherit the stack." Wrong: only service-managed permissions support automatic deployment to accounts added to a target OU^[3]; self-managed has no auto-deploy.
• "Detect drift on the root stack to find changes in its nested stacks." Wrong: drift detection on a stack does not cover its nested stacks^[10]; run it on each nested stack.
• "Just execute the update, change sets guarantee success." Wrong: a change set previews changes but does not guarantee the update will succeed^[7].
• "Canary the schema-breaking migration to limit blast radius." Wrong: canary assumes old and new coexist; a breaking migration takes down the still-running old version. Use expand/contract first.
• "Rebuild the artifact in each environment's pipeline stage." Inferior: promote one immutable artifact so prod runs exactly what was tested.

When two options both technically work, prefer the one that is more automated, smaller blast radius, and faster to roll back, that ranking decides almost every deployment-strategy question on this exam.