Diagnosing an interrupted Terraform apply: what actually got created

Diagnosing an interrupted Terraform apply

Symptom

An apply was killed: CI timeout, Ctrl-C, runner eviction, network drop. You do not know which resources were created, which failed, and what the state file recorded.

Cause

Terraform writes state after each resource operation completes. A kill between operations leaves a consistent but partial state: everything before the kill is recorded, everything after is not. The danger is not corruption, it is not knowing where the boundary is.

Confirmation

1. terraform refresh (or terraform plan -refresh-only) to reconcile state with reality. This is read-only and safe.
2. terraform plan and read every proposed change. Resources the killed run created show as no-change. Resources it never reached show as creates.
3. For anything ambiguous, check the cloud console/API directly. State is a cache; the API is truth.

Fix

1. Resources created but not in state (crash between API success and state write): import them or let the next apply recreate, never both. If the next apply would create a duplicate, import first.
2. Resources half-configured (created but setup steps failed): terraform apply -replace=[address] to rebuild cleanly, or fix in place if the resource supports it.
3. Tainted resources from the failed run: terraform untaint only if you have verified the object is healthy; otherwise replace.

Verification

1. A final terraform plan shows zero changes. That is the definition of done.
2. Spot-check critical resources in the console: the plan being clean plus the objects existing and configured is the full verification.

State is written per resource operation; refresh reconciles state with real infrastructure; -replace forces recreation of a resource. Verified against live docs 2026-09-26.