Reading Plans Like an Operator

Scenario: A reviewer sees a plan summary reading "1 to add, 1 to change, 1 to destroy," judges three small numbers as low-risk, and approves it without ever opening the plan to check which specific resource is being replaced or why.

You've built the individual skills for reading a plan across this whole track - this section is about doing it in the disciplined order an operator actually should, rather than skimming the summary line the way the reviewer above did. Start with the summary for orientation, then deliberately work through: every destructive or replacement action (and the reason the provider gave for requiring replacement - Module 7), anything crossing a sensitive-value boundary (Module 4), any provider version change bundled into this run, any unresolved (known after apply) value and what depends on it, the dependency ordering itself, and finally the outputs that will result.

A genuinely useful diagnostic question for any given proposed change: is it configuration-driven (someone deliberately changed a .tf file), drift-driven (Module 5 - reality diverged from what state expected), provider-version-driven (an upgraded provider changed its own defaults or schema), or state-address-driven (Module 5 again - a rename or refactor changed an address without a moved block)? Each cause implies a different level of concern and a different fix. terraform show -json turns a plan into a machine-readable structure that policy engines and cost-estimation tooling can consume automatically - genuinely useful at scale, but remember it carries the same full sensitive-value content as the human-readable plan, and handling it deliberately (not just piping it into a public dashboard) matters just as much.

Analogy: A surgeon's pre-op count of planned incisions tells you how many cuts will be made - it tells you nothing about whether one of those cuts happens to be near something irreplaceable. In a Terraform plan, the raw count of adds/changes/destroys is the incision count; the identity of what's being replaced and why is what actually determines the real risk.

A worked configuration

terraform plan -out=change.tfplan
terraform show change.tfplan
terraform show -json change.tfplan > change.json

Whoever approves a plan should record, right alongside the approval, what impact is expected, who owns the affected service, what maintenance window (if any) this needs, what the rollback or roll-forward path is if something goes wrong, and how success will be validated afterward. Treat any change in the plan you genuinely can't explain as a hard blocker requiring investigation - never as background noise to wave through because the overall summary numbers looked small.

Common mistakes in production

• Approving a plan based only on the top-line add/change/destroy counts without opening it to check which specific resources are affected and why.
• Treating a terraform show -json export as safe to pipe into a public dashboard or unrestricted tool - it carries the same full sensitive content as the human-readable plan.

Goal: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it. 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.