AWS Certified CloudOps Engineer Associate Training Course

Writing a template is the easy half. The operational half is knowing what an update will do before you run it, detecting changes someone made outside the template, and diagnosing a deployment that failed at three in the morning. This lesson is the one that most closely matches the day-to-day work SOA-C03 is testing.

Change sets

A change set is a preview. You submit a modified template or new parameter values, and CloudFormation computes what it would do without doing any of it. You then execute the change set or discard it.

What the change set shows you, per resource, is the action — Add, Modify, Remove, or Import — and, for modifications, the crucial Replacement field with a value of True, False, or Conditional. It also lists which properties changed and whether each is the cause of the replacement.

That replacement field is the whole point. A property change you thought was cosmetic can force CloudFormation to delete and recreate a database. Conditional means replacement depends on circumstances CloudFormation cannot fully determine in advance, and it should be treated as a warning to investigate rather than a reassurance.

Make change sets a required step in any pipeline that touches production. A pipeline that runs CreateChangeSet, publishes the result for human review, and then runs ExecuteChangeSet on approval is the pattern the exam expects when a scenario asks how to prevent an update from unexpectedly destroying a resource.

Change sets also cover nested stacks, so a change deep inside a nested template is visible from the parent.

Drift detection

Drift is the difference between a stack's expected configuration and the actual configuration of its resources. It happens when someone changes a resource in the console, when a script modifies it, or when another automation touches it.

Running drift detection compares each supported resource's current properties against the template and reports one of IN_SYNC, MODIFIED, DELETED, or NOT_CHECKED, with a property-level diff for modified resources. The stack itself is DRIFTED or IN_SYNC.

Two limitations matter. Drift detection does not cover every resource type or every property, so IN_SYNC is not an absolute guarantee. And it is a point-in-time operation, not continuous, so detecting drift reliably means running it on a schedule — an EventBridge rule invoking DetectStackDrift, with the result checked and alarmed on.

Drift is dangerous specifically because of what happens next. A subsequent stack update may overwrite the out-of-band change, undoing a fix someone applied manually during an incident, or it may fail because the resource is no longer in the state CloudFormation expects. Neither is a good outcome at deployment time.

The correct response to drift is almost never to update the template to match the drifted state without thought. It is to decide whether the change was legitimate — in which case bring it into the template deliberately — or was not, in which case let the next update revert it. And then to ask why someone was able to change it out of band, which is an IAM question.

Stack policies

A stack policy is a JSON document attached to a stack that governs which resources an update may modify. It looks like an IAM policy but it is not one: it applies only to stack update operations, and it protects resources from being changed by the update, not from being changed by anyone.

The typical policy allows Update:* on everything and denies Update:Replace and Update:Delete on the logical IDs of stateful resources. With that in place, an update that would replace the database fails rather than proceeding.

Three properties to remember. A stack policy cannot be deleted once set, only replaced. To deliberately update a protected resource you supply a temporary override policy with the update request, which applies only to that operation. And a stack policy does not protect against stack deletion — that is what termination protection and DeletionPolicy: Retain are for.

Why deployments fail

Failures cluster into a small number of causes, and recognizing the signature is what the exam asks for.

• Insufficient IAM permissions. The most common by far. Remember that CloudFormation acts with the caller's permissions unless a service role is specified, in which case it uses that role. A service role is the right pattern: it lets operators run deployments without holding the underlying create-and-delete permissions themselves.
• Service quota exceeded. Elastic IP addresses, VPCs per Region, instances of a family. The event message names the limit.
• Resource already exists. A hard-coded name for something that must be unique — an S3 bucket, an IAM role — collides on a second deployment. This is why letting CloudFormation generate names is the default advice, and why templates that must name things should incorporate AWS::StackName.
• No signal received. A CreationPolicy timeout, meaning user data failed or never ran cfn-signal. Look in the instance's log, not in CloudFormation.
• Dependency ordering. An intermittent failure that reproduces only sometimes usually means a missing DependsOn.
• Invalid property or unsupported value. An instance type not offered in the target Availability Zone, an AMI from another Region, an unsupported engine version.
• Custom resource never responded. The Lambda handler errored before signaling, so the stack waits out the full timeout.

Reading stack events

The stack events list is your primary diagnostic, and the technique is specific: sort chronologically and find the first CREATE_FAILED or UPDATE_FAILED event. Everything after it is consequence — other resources being rolled back — and reading the last event tells you nothing useful. The first failure carries the actual status reason, and that reason is usually an unambiguous API error message.

When rollback destroys the evidence, disable rollback on the next attempt so the failed resources remain for inspection. CloudTrail supplies the underlying API calls with their full error responses when the stack event message is too terse.

Recovering a stuck stack

Three specific states and their remedies:

• ROLLBACK_COMPLETE after a failed creation — the stack cannot be updated. Delete it and create it again.
• UPDATE_ROLLBACK_FAILED — call ContinueUpdateRollback, and if a specific resource cannot be rolled back, pass it in the skip list so the rollback can complete. You then reconcile that resource manually.
• DELETE_FAILED — usually a non-empty S3 bucket, a security group still in use by an interface outside the stack, or an ENI left behind by a Lambda function in a VPC. Clear the blocker and delete again, or retain the resource on deletion.

Importing and moving resources

Two operations complete the toolkit. Resource import brings an existing, unmanaged resource under a stack's control by matching it to a logical ID and its physical identifier — the migration path from console-created infrastructure to managed infrastructure without recreating anything. And CloudFormation supports moving resources between stacks, which is how you refactor a monolithic stack into smaller ones without downtime. Both are safer than the alternative most people reach for, which is deleting and redeploying.