Reading Plans Like an Operator

Scenario: A reviewer approves a plan after seeing '1 to add, 1 to change, 1 to destroy' without inspecting which resource is replaced or why.

Start with the summary, then inspect destructive and replacement actions, sensitive boundaries, provider changes, unknown values, dependencies, and outputs. Identify whether a change is configuration-driven, drift-driven, provider-version-driven, or state-address-driven. Machine-readable terraform show -json enables policy and cost tooling, but it contains sensitive values and its schema should be handled deliberately.

Analogy: A surgical count says how many incisions; it does not say whether one reaches the heart. Resource identity and replacement cause determine risk.

A worked configuration

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

Approval should record expected impact, owner, maintenance window, rollback or roll-forward route, and validation. Treat unexplained changes as blockers, not background noise.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: 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.