Plan, Apply, and Destroy

Scenario: A plan reviewed and approved yesterday shows one update; running apply today prompts with three changes instead, because the real infrastructure drifted in the meantime.

You already know conceptually what plan and apply do from Module 1 - now let's read their actual output like an operator. terraform plan refreshes Terraform's view of reality, evaluates every expression in your configuration, and produces a proposed list of operations. Each proposed change gets a symbol: + for create, ~ for update-in-place, - for destroy, and -/+ or +/- for replacement (destroy the existing object and create a new one, because some attribute can't simply be changed in place - certain settings are only allowed at creation time, and changing them means Terraform must throw the old object away and build a fresh one).

Running terraform plan -out=somefile.tfplan saves that exact calculated plan to a binary file. This matters because terraform apply somefile.tfplan will execute precisely those saved operations without recalculating anything - which is what makes "review this plan, then apply exactly this plan" a trustworthy pipeline step, rather than hoping nothing changed between review and execution.

terraform destroy is really just a specialized plan whose only proposed actions are destroys, applied against every resource Terraform manages in that state. You don't need the whole command to destroy something though: simply deleting a resource block from your configuration and running a normal plan will also propose destroying that object (unless you use the moved/removed refactoring tools from a later module to say otherwise).

Analogy: A plan is an itemized construction quote, valid at the moment it was written. If the building site changes overnight - a different crew already poured concrete somewhere - applying yesterday's quote today without re-checking is accepting a quote for a job that no longer matches reality.

A worked configuration

terraform plan -out=release.tfplan
terraform show release.tfplan
terraform apply release.tfplan
# later, deliberately:
terraform plan -destroy

Review replacement operations (-/+) with special care: an attribute you assumed was harmlessly editable may actually be immutable for that resource type, silently turning what looked like a one-line config tweak into real downtime or, for something like a database, potential data loss. Saved plan files contain the full evaluated configuration and values - including anything sensitive - so handle them like secrets: store them briefly, restrict who can read them, and let them expire quickly rather than archiving them indefinitely.

Common mistakes in production

• Reading only the plan's one-line summary ("3 to add, 1 to change, 0 to destroy") without checking which resource is being replaced and why - the summary count says nothing about blast radius.
• Assuming a saved .tfplan file is safe to leave lying around in a CI artifact store - it can contain full resource values, including secrets that were marked sensitive only in the CLI's display.

Goal: destroy does not mean "safely disposable." Providers can delete databases, encryption keys, or certificates irreversibly the moment the command runs. Lifecycle safeguards (a later module) and independent backups outside Terraform's control still matter, especially for anything holding real data. Reinforce this lesson in the tf-saved-plan-replacement Terraform lab. Open /labs/terraform and choose slug tf-saved-plan-replacement; the lab runs real Terraform against the offline FakeCloud provider.