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

TL;DR: A plan that wants to create every resource from scratch usually means Terraform is looking at an empty or wrong state file. The procedure confirms the backend binding before anyone applies. 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. Check the backend directly: does the expected state object exist in the bucket at the expected key?

The error

text
?

## Fix

1. Wrong workspace:

The fix

TL;DR: A plan that wants to create every resource from scratch usually means Terraform is looking at an empty or wrong state file. The procedure confirms the backend binding before anyone applies. 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. Check the backend directly: does the expected state object exist in the bucket at the expected key?

The error

?

## Fix

1. Wrong workspace:

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.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Diagnosing the wrong-state-file problem.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

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