Diagnosing the wrong-state-file problem: plan wants to create everything

Diagnosing the wrong-state-file problem: plan wants to create everything

Symptom

terraform plan proposes creating all resources in a workspace that should already exist. Everything shows as new.

Cause

Terraform is reading the wrong state: wrong workspace selected, backend rebound to a new key, state file lost, or init pointed at a fresh backend.

Confirmation

1. terraform workspace show (or check the backend key). Is this the workspace you think it is?
2. terraform state list | wc -l and terraform state pull | grep serial. Empty list or serial 1 means fresh/empty state.
3. Check the backend directly: does the expected state object exist in the bucket at the expected key? If yes, Terraform is bound to the wrong key. If no, the state is actually gone.
4. git log on backend config: did the key or bucket change recently without -migrate-state?

Fix

1. Wrong workspace: terraform workspace select [correct]. Then plan again.
2. Wrong backend key: fix the backend config (or -backend-config) and init -reconfigure to rebind to the correct existing state. Back up first.
3. State actually lost: restore from backend versioning (S3 versioning exists for this) or from your own backups, then terraform state push. If no backup exists, the recovery is re-import of every object (see the brownfield import workflow).

Verification

1. After rebinding, terraform plan must show no changes (or only expected ones). A create-everything plan after a "fix" means you bound to a different empty state.
2. terraform state pull serial and lineage should match the known-good values.

STOP: never apply a create-everything plan on existing infrastructure. That is how you get duplicates of everything.

Workspaces namespace state per backend; init -reconfigure rebinds backends; state pull/push backs up and restores. Verified against live docs 2026-09-26.