In Terraform, how does running `terraform destroy` differ from deleting a resource block from the configuration and running `terraform apply`?

## Two different things called "delete" Terraform decides what to do by comparing three things: the configuration, the state, and reality. An object gets destroyed whenever it exists in state but has no corresponding configuration telling Terraform to keep it. Both routes below produce destroys, but they arrive there differently and mean different things. ## Removing the block: a change to desired state Delete an `aws_s3_bucket` block, run `terraform plan`, and you see one destroy. Terraform found a state entry with no configuration behind it and concluded the object is no longer wanted. The important property is that this change is **durable and reviewable**. It is a diff in a pull request, someone approves it, it merges, and from then on the desired state simply does not include that bucket. Nothing will bring it back by accident. This is the normal way to retire infrastructure. ## `terraform destroy`: a lifecycle action on the whole configuration ```bash terraform destroy # equivalent to terraform apply -destroy ``` This proposes destroying **everything** in this configuration's state. The configuration is untouched — which is exactly why the environment comes straight back on the next `terraform apply`. That round-trip property is the point: it is the command for a stack whose whole existence is temporary. Because it is an apply variant, it behaves like one. It shows a plan first and prompts for `yes`, `-auto-approve` skips that prompt, and you can preview or save it: ```bash terraform plan -destroy -out=tfplan terraform apply tfplan ``` Saving a destroy plan is worth knowing — it is the one plan where reading the resource list before executing matters most. ## Ordering and blast radius A destroy walks the dependency graph in reverse: things that depend on other things go first. Terraform only touches what is in **this** configuration's state, so objects created by another root module, by another team, or clicked together in the console are invisible to it and survive. That is a genuine safety property, and it is also why splitting an estate into multiple states limits how much any single destroy can reach. ## The failure story interviewers are listening for The classic incident is someone running `terraform destroy` in the wrong working directory or against the wrong state, because the command looks like it belongs to the environment they had in mind. The guardrails people name in a good answer: - read the plan's resource list and the destroy count before typing `yes` — the confirmation prompt exists for this, - keep production in a separate state with credentials that developers do not routinely hold, - protect irreplaceable objects such as databases and data buckets so a destroy plan errors instead of proceeding, - never wire `-auto-approve` to a destroy in a pipeline that can be triggered against production. ## When you want the object gone from Terraform but *not* deleted There is a third case people conflate with these two: handing a resource over to another configuration or to another team without deleting the real thing. That is neither a destroy nor a plain block deletion — deleting the block alone would destroy the object — and Terraform has dedicated state-level mechanisms for it. Recognising that the case is distinct is the part that matters here; the mechanics belong to state management. ## Summary you can say out loud "Removing the block edits what I want the world to look like, permanently and in review. Destroy is a lifecycle action that removes everything this configuration currently manages while leaving the definition intact, so it can be rebuilt. I use destroy for ephemeral environments and block removal for retiring a component."