Deploying and Updating Stacks

The IaC discipline this module has built up has one clear implication for making a change: you change the template, not the running resource. Updating a stack means submitting a changed template, and letting CloudFormation compare it against the stack's current state and apply whatever changes are needed.

Before applying a change to a real stack, CloudFormation can show a preview of the proposed change — what would actually happen if the update were applied. Reviewing this before deploying matters especially because a seemingly small template edit can sometimes cause a resource to be replaced rather than updated in place — deleted and recreated, rather than modified as-is. For a stateless resource that might be a non-event; for something holding real data, an unreviewed replacement could mean real data loss. This lesson deliberately avoids listing which specific property changes always cause replacement for which resource types — that behavior is a service-specific detail that can evolve, and the safe habit is reviewing the actual proposed change every time, not memorizing a fixed list.

If a resource operation fails partway through a deployment, CloudFormation may perform rollback or recovery behavior depending on the specific operation and configuration — but this shouldn't be oversimplified as "everything always returns perfectly to exactly how it was." Stack events are the practical place to actually understand what happened — showing resource creation, updates, and failures as they occur — and reviewing them after any failure is a better habit than assuming a rollback fully undid every effect on its own.

Configuration drift happens when someone manually changes a resource that a stack manages — directly in the Console, say — so the resource's actual state no longer matches what the template declares. This makes the environment genuinely harder to reason about: the template no longer accurately describes reality, and the next stack update might behave unexpectedly because CloudFormation's understanding of the resource's current state has fallen out of sync with what's actually there. The practical habit this lesson leaves you with: make infrastructure changes through the template and a stack update, not by hand against a stack-managed resource — exactly the same discipline Module 9 taught for redeploying a container instead of patching one directly.

Deleting a stack can delete every resource it manages — but depending on a resource's configuration, some data might be retained rather than deleted outright, and some might not be. Before deleting any real stack, review what it actually manages, what data it holds, whether backups exist, and what each resource's deletion behavior is configured to do — the same "verify, don't assume" discipline this course has applied to every earlier module's cleanup step, now applied at the level of an entire stack instead of one resource at a time.

One more distinction worth being precise about: version-controlling a template gives you history, review, and the ability to revert the template's source — but reverting a Git commit does not automatically revert already-deployed AWS infrastructure. A stack only changes when a new deployment actually runs against it. Reverting the source and forgetting to redeploy leaves the real infrastructure exactly where it was, quietly out of sync with what the reverted template now says.