Infrastructure as Code, CI/CD, Change Management, and Rollback

Why deployment design is a Professional skill

SAP-C02 Task 2.1 asks you to design a deployment strategy that meets business requirements. That is not a trivia item about where the CodePipeline console lives. Independent OpenExamPrep teaching in this section treats AWS CloudFormation as the infrastructure control plane, the AWS Cloud Development Kit (AWS CDK) as a generator of CloudFormation templates, and AWS CodePipeline, AWS CodeBuild, and AWS CodeDeploy as the application-release machinery. The Professional tradeoff is always blast radius, review, and rollback before the first production packet moves.

Apex Health runs a 40-account AWS Organizations environment. Every new workload account must receive the same VPC flow-log destination, organization AWS CloudTrail configuration hooks, and an encrypted Amazon Simple Storage Service (Amazon S3) log archive as soon as Account Factory creates the account. That requirement is a StackSet problem. It is not solved by a nested stack that exists only in the management account, and it is not solved by an engineer running cdk deploy forty times from a laptop.

Nested stacks versus StackSets

Nested stacks split one large template into reusable pieces. You declare AWS::CloudFormation::Stack resources whose TemplateURL points at an object in Amazon S3. Nested stacks form a hierarchy: a root stack owns every nested stack; each nested stack has an immediate parent. Package local templates with the AWS Command Line Interface (AWS CLI) cloudformation package workflow so nested TemplateURL values become S3 URLs before deploy.

Treat nested stacks as modules, not as an org-wide rollout mechanism. Updates belong on the root. You must execute or delete nested change sets from the root change set. If a nested stack sticks in UPDATE_ROLLBACK_IN_PROGRESS, the root waits until that nested rollback finishes. CloudFormation does not detect drift on nested stacks when you start drift detection on the parent; start a separate drift operation on each nested stack (or use a drift-aware change set that is built to inspect the hierarchy you include).

StackSets deploy the same template as stack instances in chosen target accounts and AWS Regions. A StackSet is a regional resource: you create and operate it in one Region, even when instances land in many Regions.

Two permission models matter on the exam:

• Self-managed permissions — you create the administrator role and the target-account execution roles. Use this when targets are not all inside your organization, or when Organizations trusted access is not available.
• Service-managed permissions — enable trusted access with Organizations. StackSets creates the required roles. You can turn on automatic deployments so accounts that join (or leave) an organizational unit (OU) receive (or remove) stack instances without a ticket. A delegated administrator member account can own StackSets so the management account is not on the daily path.

StackSet operation preferences show up in scenario stems because they are how you limit a bad template:

• Maximum concurrent accounts as a count or a percentage (percentages round down).
• Failure tolerance per Region: when too many instances fail in a Region, the operation status becomes FAILED and remaining Regions may not start.
• Concurrency mode, including strict failure tolerance that caps concurrency relative to failure tolerance.
• Region concurrency: Sequential (default, one Region at a time in the order you list) versus Parallel.
• Retain stacks on delete so instances become ordinary CloudFormation stacks you manage in the member account.
• Target account gates that call a gate function in the target so a non-compliant account cannot receive the update.
• Parameter overrides on individual stack instances. The template body still updates every instance; you cannot ship template A to half the StackSet and template B to the other half.

Apex Health’s landing-zone team owns a service-managed StackSet in us-east-1 with sequential Regions us-east-1 then eu-west-1, a failure tolerance of two accounts per Region, and automatic deployments on the Workloads OU. Inside each stack instance, nested stacks still package the VPC module and the logging module so application teams do not copy-paste 2,000 lines of YAML. Nested stacks answer “reuse in one account.” StackSets answer “the same baseline in many accounts.”

CDK still deploys CloudFormation

The AWS CDK (TypeScript, JavaScript, Python, Java, C#/.NET, and Go) lets teams use language features—loops, conditionals, shared constructs—to define infrastructure. The exam’s mental model is cdk synth: constructs become AWS:: resources, and cdk deploy still submits CloudFormation change sets. You inherit CloudFormation rollback on resource failure, stack policies, drift detection, and termination protection. CDK is not a second provisioner that ignores those controls.

High-level constructs are a double-edged sword. An Application Load Balanced Fargate construct can emit a VPC, subnets, NAT gateways, security groups, an ECS cluster, a service, a load balancer, and IAM roles—often fifty-plus resources. In a regulated pipeline, review the synthesized template (or the change set) the same way you would review hand-written YAML. CDK unit tests and construct libraries improve consistency; they do not replace change-set review when the CAB must see which RDS instance will be replaced.

Change sets, drift, and rollback triggers

A change set lists the creates, updates, replacements, and deletes CloudFormation will perform before you execute. For nested hierarchies, set IncludeNestedStacks (console nested change sets are enabled by default; the API defaults to false). Execute or delete from the root. Deleting a nested change-set hierarchy is asynchronous when nested stacks were created during change-set creation and may still be REVIEW_IN_PROGRESS.

Drift means someone changed a resource outside CloudFormation (console, CLI, or another tool). A stack, stack instance, or StackSet is DRIFTED if any supported resource (or any instance) drifted. StackSet drift is an operation on the StackSet; it is not implied by detecting drift on one nested child. Drift-aware change sets with DeploymentMode=REVERT_DRIFT compare actual state, previous deployment state, and desired template state. If that deployment fails, CloudFormation’s enhanced rollback restores resources toward the actual pre-deployment state, which matters when operators made emergency out-of-band changes you do not want to wipe during a failed reconcile.

Rollback triggers close the gap between “the template created” and “the application is healthy.” You may attach up to five Amazon CloudWatch alarms or composite alarms. CloudFormation monitors them during create/update and for MonitoringTimeInMinutes from 0 to 180 after resources deploy. If any trigger enters ALARM, CloudFormation rolls back the entire stack operation. A missing alarm ARN fails the operation. INSUFFICIENT_DATA does not roll back unless you configured the alarm to treat missing data as breaching. CloudFormation does not monitor rollback triggers while it is already rolling back. For updates, a non-zero monitoring period also delays disposal of old resources, which gives humans a bake window even with no alarms.

Stack policies are a fail-safe, not IAM. After you set a policy, any update that is not explicitly allowed is denied. Typical Professional use: Allow Update:* on *, then Deny Update:* or Update:Replace / Update:Delete on logical IDs such as ProductionDatabase or a customer-managed AWS Key Management Service (AWS KMS) key. Updating a protected resource requires a temporary policy override on that update. Dependent resources that CloudFormation must touch still need policy permission even when their physical ID does not change. Use IAM to decide who may update; use a stack policy to stop an allowed principal from replacing the one resource that must never be replaced by a routine parameter change.

CI/CD plumbing

CodePipeline is continuous delivery: you model stages (source, build, test, deploy), artifacts between stages, and optional manual approvals or stage conditions. CodeBuild compiles and runs tests from a buildspec. CodeDeploy publishes an application revision to an EC2/on-premises compute platform, a Lambda platform, or an Amazon ECS platform using a deployment configuration (minimum healthy hosts, or canary/linear/all-at-once traffic shift).

The regulated CloudFormation pattern that SAP-C02 rewards looks like this: the pipeline creates a change set (including nested stacks) → a change-advisory board (CAB) reviews replacements in the change set → a pipeline approval action continues → execute change set with rollback triggers and a monitoring period. Do not let the pipeline call UpdateStack with no preview when the stem requires review of resource replacement. Application traffic shifting is a separate design choice implemented by CodeDeploy or by dual environments the pipeline promotes.

Blue/green, rolling, and canary at design time

Pick the strategy when you size environments and load balancers, not after the first failed Friday deploy. Extra capacity, rollback speed, and mixed-version risk are architecture properties.

Apex Health’s PCI-scoped claims API is designed as ECS blue/green with a canary shift: 10 percent of listener traffic to green for 15 minutes while rollback triggers watch HTTP 5xx and p99 latency, then the remaining 90 percent. They reject CodeDeployDefault.ECSAllAtOnce for this API (and remember that a Network Load Balancer on ECS supports only the all-at-once predefined configuration—if the stem requires canary, the load balancer choice is part of the design). Overnight batch report jobs can use rolling updates because a mixed-version window is acceptable and idle capacity is not.

On EC2, CodeDeployDefault.AllAtOnce can mark a deployment successful if one instance succeeds. That is the opposite of a regulated cutover. OneAtATime keeps one host unhealthy at a time but still mutates the live environment; rollback is a second deploy, not an instant listener swap.

Change management as architecture

Change management is the human process the AWS tools implement: proposed change (the change set), risk (replace versus in-place), approver, monitoring window, and rollback owner. StackSets add organization-scale risk. Sequential Regions and low concurrency mean a bad template poisons two accounts in us-east-1 and stops, instead of forty accounts in three Regions at once. Automatic deployments are powerful and dangerous: an OU move can delete stack instances from the old OU and create them in the new one, queued behind in-flight operations (QUEUED status for service-managed automatic deployments).

Exam traps: treating CDK as a provisioner that skips CloudFormation rollback; detecting drift only on a parent nested stack and declaring the whole app in sync; executing a nested change set from a child; using self-managed StackSets when the requirement is automatic OU enrollment; skipping rollback triggers because “CloudFormation always rolls back” (resource CREATE_FAILED is not an application latency ALARM); choosing AllAtOnce when the stem asks for canary or instant rollback to a standby environment.