skip to content

How do you correctly retire an ephemeral Terraform CLI workspace, and what happens if you run `terraform workspace delete` while its state still tracks resources?

level: middleimportance: nice to knowfreq 25%

answer

  1. destroy first, delete second
  2. you cannot delete the active workspace
  3. non-empty state blocks the delete
  4. -force drops state, not resources
  5. orphaned resources keep billing

basics

~20 s

Destroy inside the workspace first, then select another workspace and delete it. Terraform refuses to delete a workspace whose state still tracks resources unless you pass -force, which discards the state and orphans the real infrastructure.

solid answer

~40 s

Teardown is two steps in a fixed order. Select the workspace and run `terraform destroy` so the resources are actually removed and the state empties; then switch away — Terraform will not delete the workspace you are currently in — and run `terraform workspace delete pr-1234`. If the state is not empty, the delete is rejected with an error telling you the workspace still manages resources. `-force` overrides that check, but all it does is remove the state object: the cloud resources keep running and nothing now records them, so you are left paying for infrastructure that no plan will ever mention. Also note that `default` cannot be deleted at all. In a per-pull-request pipeline the destroy-then-delete pair belongs in the branch-deleted or PR-closed job, not in a manual runbook.

code

bash · 4 lines
bash
terraform workspace select pr-1234
terraform destroy -auto-approve
terraform workspace select default
terraform workspace delete pr-1234

go deeper

for a junior

Remember the order: destroy the resources inside the workspace first, switch to another workspace, and only then delete it — deleting never removes infrastructure.

for a middle

Explain both built-in guardrails, that -force deletes only the state object, and why orphaned resources with no state are painful to recover — manual deletion or re-import.

for a senior

Show the operational design: teardown driven by the PR-closed pipeline event, resources tagged with the workspace name so orphans are findable, and a periodic reconciliation of the workspace list against open work.

for a principal

Own the lifecycle policy for ephemeral environments — who may create them, their maximum lifetime, what the sweeper deletes and on whose budget the leftovers land when the teardown job silently stops running.

## The order that matters ```bash terraform workspace select pr-1234 terraform destroy -auto-approve # resources go away, state empties terraform workspace select default # you cannot delete the active workspace terraform workspace delete pr-1234 # removes the now-empty state object ``` Two guardrails are built in and both surprise people once: **You cannot delete the workspace you are in.** Terraform rejects deleting the currently selected workspace, so the `select` back to `default` is not optional. **You cannot delete a workspace whose state still tracks resources.** The delete errors out and names the problem. This is deliberate: the workspace's state is the only record that those resources exist, so removing it would sever management of live infrastructure. ## What `-force` really means `terraform workspace delete -force pr-1234` skips the non-empty check. It does **not** destroy anything. The state object is deleted from the backend and the resources it described keep running — EC2 instances, load balancers, an RDS cluster — with no Terraform configuration that knows about them any more. Recovering means either finding the resources by hand and deleting them in the console, or re-importing them into a fresh state, which is far more work than the destroy you skipped. So the honest rule: `-force` is for a workspace whose state you know is junk — a bootstrap attempt that failed before creating anything, a state you have already migrated elsewhere. It is never a shortcut for "destroy is slow". ## Why this matters most for ephemeral workspaces Ephemeral per-pull-request or per-developer workspaces are the one use case where CLI workspaces clearly earn their place, and they are also the one where cleanup is a real operational cost. If the teardown job does not run — the branch was deleted without closing the PR, the pipeline failed, someone created a workspace by hand — you accumulate two kinds of debris: - **Live orphaned resources**, costing money and occupying quota or globally-unique names; - **Stale state objects** in the backend under the `env:` prefix (S3) or `terraform.tfstate.d` (local), which make `terraform workspace list` an increasingly unreliable inventory. Mitigations worth naming in an interview: run destroy-then-delete from the PR-closed pipeline event rather than a manual step; tag everything the ephemeral stack creates with the workspace name so a sweeper can find orphans; and periodically reconcile `terraform workspace list` against what the pipeline believes is open. ## A related trap Destroying inside the wrong workspace is the mirror-image mistake, and it is worse. Always confirm with `terraform workspace show` — or make the pipeline set the workspace explicitly — before any `destroy -auto-approve`. The commands do not care which environment you are in.

  • Does `terraform workspace delete -force` destroy the infrastructure?
    No. It only removes the workspace's state object, skipping the safety check that the state is empty. Every resource that state described keeps running, with nothing tracking it. The only legitimate uses are a state you have already migrated elsewhere or one you are certain never created anything.
  • Where do you put the teardown in a per-pull-request pipeline?
    On the PR-closed or branch-deleted event, so it runs whether the change merged or was abandoned. The job selects the workspace, destroys with `-auto-approve`, switches away and deletes it. Tagging every resource with the workspace name gives you a sweeper for the cases where the event never fired.

saying these in an interview costs you the question

  • Thinks delete also destroys the infrastructure
  • Uses -force to skip a slow destroy
  • Tries to delete the workspace that is currently selected
  • Assumes an empty state means the resources are gone
  • Leaves per-PR workspaces to be cleaned up manually

context

resolving links…