What does `prevent_destroy = true` in a Terraform resource's lifecycle block actually do, and what does it fail to protect against?

## What it does `prevent_destroy` is one of the arguments of a resource's `lifecycle` block: ```hcl resource "aws_db_instance" "primary" { # ... lifecycle { prevent_destroy = true } } ``` When Terraform builds a plan and finds that this resource would be destroyed, it stops with an error naming the resource, and the whole plan fails. Nothing is applied — it is not a per-resource skip that lets the rest of the run proceed. The intent is to make an accidental deletion of something irreplaceable a loud, blocking failure at plan time, which is exactly when a reviewer is still looking. It fires in every situation that involves a destroy: - `terraform destroy` on a configuration containing the resource. - Any change to an attribute the provider cannot update in place, because that plan is a destroy plus a create. This surprises people: they meant to change something small, and the guard blocks them because the provider decided the change forces replacement. The value must be a literal boolean. Terraform processes it too early to evaluate expressions, so `prevent_destroy = var.is_prod` is rejected outright. ## What it does not do This is the more interesting half of the answer, and the half interviewers are usually probing. **It is not protection against removing the resource from the configuration.** The guard lives inside the resource block. Delete the block, and the setting is gone from the configuration that Terraform is comparing against state; the object is simply no longer desired, and the next apply destroys it. Renaming the resource address has the same effect unless the move is recorded, because the old address is gone and the new one is a create. This is the single most common way a "protected" database dies. **It is not protection against anything outside Terraform.** Deleting the object in the cloud console, through the CLI, or via another automation is unaffected — Terraform only learns about it on the next refresh, where it appears as an object that has vanished. Likewise, dropping the resource out of state means Terraform no longer manages it, and the guard no longer applies to it. **It is not a substitute for the provider's own protection.** Many resource types have a real, server-side deletion guard — `deletion_protection` on `aws_db_instance` is the obvious one — which is enforced by the cloud API against every caller, not just against Terraform, and which *can* be set from a variable. The layered answer in an interview is: `prevent_destroy` for the Terraform plan, provider-side deletion protection for the API, IAM denies for the humans, and backups for when all three fail. ## Working with it day to day Because the guard blocks legitimate work too, teams hit the moment where a genuine change forces replacement of a protected resource. The honest options are to change the configuration so replacement is not forced, to ignore the attribute that forces it, or to make a deliberate, reviewed edit removing the guard for that one change and putting it back. What you should not do is quietly leave it off afterwards — the value of the guardrail is that it is always on when nobody is thinking about it. ## Where it sits among the lifecycle arguments `create_before_destroy` changes the *order* of a replacement but does not exempt it from `prevent_destroy`, since a destroy is still part of the plan. `ignore_changes` can stop the replacement being planned at all, which is sometimes the pragmatic way past a guard that is firing on a cosmetic attribute. And unlike a `precondition`, `prevent_destroy` takes no expression and gives no custom message — it is a blunt yes/no.