# Diagnosing an apply to the wrong workspace or environment
## Symptom
Realization, during or after apply, that the workspace/environment is wrong: dev changes applied to prod, or vice versa. The plan output named the wrong workspace.
## Cause
`terraform workspace select` confusion, CI job misconfiguration, or backend config pointing at the wrong environment's state. The tool did exactly what it was told.
## Confirmation
1. `terraform workspace show` right now. Then check the run history: which workspace did the apply run against?
2. `terraform state pull` from the affected workspace and diff against your backup (you have backups). The serial jumped; the diff shows what changed.
3. Assess reversibility per resource: config-only changes (tags, settings) revert cleanly with a correct apply; destroyed data stores do not.
## Fix
1. Stop the bleeding: fix the workspace selection / CI job / backend config first so the next command targets correctly.
2. Reversible changes: check out the correct config for that environment and apply it to the affected workspace. The plan shows the reverts; review them.
3. Destroyed stateful resources: restore from snapshots/backups, then reconcile Terraform state (import restored objects or remove stale entries).
4. Write down exactly what happened while it is fresh. This becomes the incident record.
## Verification
1. `terraform plan` on the affected workspace is clean against that environment's correct config.
2. The CI job now prints its target workspace/environment before planning (add this if it does not).
3. Prevention: separate backend configs per environment (not workspaces) for prod vs non-prod, so selecting the wrong target requires editing config, not one command.