A team runs dev and prod from the same Terraform configuration with separate state for each environment. An engineer runs terraform destroy against the dev state to tear dev down. It is rejected because the database resource sets prevent_destroy = true. A colleague also worries the destroy could have removed prod resources. Which statement is accurate?
Select an answer to reveal the explanation.
Short Explanation
Terraform only knows about what's in the state it's looking at, so a destroy pointed at dev can't reach prod's objects. prevent_destroy, though, is a hard stop, not a warning. It's sitting in the shared configuration, so it blocks dev's teardown too until you take it out.
Full Explanation
terraform destroy builds a plan to destroy every object recorded in the state the working directory is currently using, which here is the dev state. Objects tracked in another state file are invisible to that run, so separate state per environment means a dev destroy cannot remove prod resources. prevent_destroy = true is a lifecycle rule that makes Terraform reject any plan that would destroy the object and return an error; HashiCorp notes that enabling it prevents terraform destroy from operating once such objects exist. Because both environments share the configuration, the rule applies to the dev database as well, so tearing dev down requires deliberately removing the rule (or handling the database separately) for that run. The idea that destroy targets every state using the configuration misunderstands how state scopes Terraform's knowledge. prevent_destroy is not advisory; there is no prompt to confirm past it. Destroy deletes the real infrastructure, not just state entries; forgetting resources without destroying them is what removed blocks with destroy = false or state rm are for. Exam caveat: deleting a resource block entirely also bypasses prevent_destroy. Operational check: run terraform plan -destroy against dev and read the error naming the protected resource.