What does `terraform state rm` do to the real cloud object, and when is dropping a resource from Terraform state the right move rather than a mistake?

## What it does, precisely ```bash terraform state rm aws_db_instance.legacy ``` This removes the state entry binding that address to a real object. The provider is not asked to delete anything. After it runs: - The object still exists and still costs money. - Terraform no longer knows about it: it will not appear in plans, will not be refreshed, will not be destroyed by `terraform destroy`. - If the resource block is **still in the configuration**, the very next plan proposes *creating* it — because an address in config with no state entry means "not created yet". On resources with globally or regionally unique names, that create then fails with a name-already-exists error; on resources without that constraint, you get a silent duplicate. That last consequence is the one candidates most often miss, and it is why `state rm` is almost never a complete action on its own. ## The orphan An orphaned object is worse than a deleted one. It is not in any plan, so no drift detection covers it, no policy scan of your code sees it, and no destroy of the environment removes it. It surfaces months later as a line on a bill, or as a security group nobody can explain. Any deliberate `state rm` needs a follow-up: either the object is imported somewhere else immediately, or it is decommissioned by hand and the ticket says so. ## Legitimate uses **Handing a resource to another configuration.** You are splitting one root module into two, or moving a resource from the application state to the platform state. The object must not be recreated, so the sequence is: import it into the target state, confirm that plan is clean, then remove it from the source state. **Deliberately releasing management.** A resource is being taken over by another team or another tool. Remove it from state *and* delete its resource block in the same change. **A state entry whose object genuinely cannot be reconciled.** Rare, and usually a symptom of something else — a provider bug, or a half-completed apply. Worth exhausting other options first. A use that is usually **not** legitimate: the object was deleted in the console and now the plan errors or looks odd. Terraform handles that itself — refresh detects the object is gone and removes the entry, after which the plan simply proposes recreating it, which is what you want. ## The removed block Terraform 1.7 added the declarative equivalent: ```hcl removed { from = aws_db_instance.legacy lifecycle { destroy = false } } ``` You delete the `resource` block and add this in its place. `destroy = false` means forget the object and leave it running; `destroy = true` means actually destroy it. Because it is configuration, the plan shows what will happen before anyone approves, the change is reviewed as a diff, and CI performs it — rather than someone typing a destructive command with no record. It works for module calls too, so an entire module's worth of resources can be released in one declaration. The same lifecycle applies as with `moved` and `import` blocks: once applied everywhere, the block is inert and can be deleted. ## Moving a resource between two states The classic approach was `terraform state mv` with a separate output state, or a pull-edit-push dance. With modern Terraform the cleaner expression is a pair: an `import` block in the target configuration, and a `removed` block with `destroy = false` in the source. Both are reviewable, both show up in their plans, and the order matters — get the import in place and verified before the source stops tracking it, so no window exists where the object is unowned and someone runs a destroy. ## Safety Before any removal: `terraform state show` the address and record the object ID somewhere durable, because after the entry is gone that mapping exists only in your terminal scrollback. With local state, the mutating commands leave a backup file; with a remote backend you are relying on whatever versioning the backend provides, which is not something to discover during an incident. Removal takes the state lock like any other write, so it will not race with a concurrent apply — but it absolutely can race with a *pipeline* that applies just after your merge, which is one more argument for expressing it as a block the pipeline itself applies in order.