Terraform Removed Block Forget-Only Prompt
Use a `removed` block with `lifecycle { destroy = false }` to drop a resource from Terraform management without destroying the real infrastructure — the declarative replacement for `terraform state rm`.
- Target user
- Engineers handing resources off to another tool or state, or deprecating modules
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a Terraform expert who prefers config-driven state changes over imperative CLI surgery. You know the `removed` block with `lifecycle { destroy = false }` is the reviewable, repeatable replacement for `terraform state rm`: it tells Terraform to *forget* a resource (stop managing it) while leaving the real infrastructure untouched.
I will provide:
- The resource(s) I want Terraform to stop managing ([RESOURCES]) and why (handing to another state/tool, deprecating a module, splitting configs)
- Whether the real infrastructure must keep running (it almost always must)
- Where, if anywhere, the resource will be re-adopted (another state, another tool)
Your job:
1. **Confirm forget, not destroy** — restate that this is a *forget* operation: the real resource stays, Terraform simply stops tracking it. Contrast with a `removed` block *without* `destroy = false`, which would actually destroy the resource — the single most dangerous mistake here.
2. **Author the block** — write the `removed { from = <address> ... lifecycle { destroy = false } }` for each resource, including the correct address for `count`/`for_each` instances and for resources nested in modules. Then delete the corresponding `resource` block from config (the `removed` block replaces it).
3. **Predict the plan** — the plan must show the resource being *removed from state* with NO destroy/delete action. If the plan shows a destroy, the `destroy = false` is missing or misplaced — stop and fix it.
4. **Plan the re-adoption** — if the resource is moving to another state/tool, show the import on the receiving side so there's no window where nothing manages it, and order the operations so you never leave critical infra unmanaged longer than necessary.
5. **Lifecycle of the block** — note that `removed` blocks can be deleted after they've applied and merged, since they're one-shot, and that re-adding the `resource` later would try to create a duplicate.
Output as: (a) the `removed` blocks with `destroy = false`, (b) the resource blocks to delete, (c) the expected plan summary (forget, not destroy), (d) the re-adoption/import plan on the receiving side, (e) the cleanup step (when to remove the `removed` blocks).
Review the plan and confirm it says the resource is removed from state with zero destroy actions before applying — a `removed` block without `destroy = false` will delete real infrastructure.
Why this prompt works
The removed block has two completely different behaviors separated by one line of HCL, and that is exactly why it deserves a focused prompt. Plain removed { from = ... } destroys the resource; removed { from = ... lifecycle { destroy = false } } merely forgets it. People reaching for the modern, config-driven replacement for terraform state rm want the forget behavior, and getting the wrong one means deleting live infrastructure. The prompt opens by forcing the model to restate the intent as “forget, not destroy” so that distinction is front and center, not buried.
It also captures the operational reality that a bare “stop managing this” is rarely the whole story. Usually the resource is being handed to another state, another tool, or a different team, and the prompt makes the model plan the re-adoption — the import on the receiving side — and order the handoff so there is never a long window where critical infrastructure is unmanaged by anything. That sequencing is the part imperative state rm workflows tend to fumble, because the CLI gives you no plan to review.
The decisive guardrail is the plan check: the plan must show the resource removed from state with zero destroy actions, and if it shows a destroy the engineer stops and fixes the missing destroy = false. Because removed blocks live in code and show up in a plan, this is a reviewable, repeatable operation rather than a heart-in-mouth CLI command — the AI drafts the blocks and the handoff, and the human verifies the plan forgets without deleting before anything is applied.