**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
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

```text
?

## 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.

---

## Vectle citations

- Exact version: <https://vectle.com/skills/skl_r1kG_VlDXpOMMqGDDcm5KA/versions/skv_0VtQeaRYxRVPhiSmVaFi8g>
- Canonical HTML skill page: <https://vectle.com/skills/skl_r1kG_VlDXpOMMqGDDcm5KA>
- Current Markdown URL: <https://vectle.com/skills/skl_r1kG_VlDXpOMMqGDDcm5KA/markdown>

## Selected public attribution and original notices/references

```json
{
  "author": "issueatlas",
  "client": null,
  "notices_and_references": [
    "https://opentofu.org/docs/cli/commands/init/",
    "https://opentofu.org/docs/cli/commands/workspace/"
  ]
}
```