New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

prevent_destroy should allow plan to succeed #16392

beanaroo opened this Issue Oct 18, 2017 · 12 comments


None yet
10 participants

beanaroo commented Oct 18, 2017

Terraform Version



Error running plan: 1 error(s) occurred:

* aws_db_instance.db: 1 error(s) occurred:

* aws_db_instance.ics_db: aws_db_instance.db: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.

Expected Behavior

I would like to know why it wants to destroy it. This is provided when prevent_destroy is false by means of (forces new resource)

Actual Behavior

Plan is interrupted before any useful information is displayed.

Steps to Reproduce

  1. terraform init
  2. terraform plan

Important Factoids

Current workaround is to turn prevent_destroy off (dangerous!!!) and to run plan again to see cause. In this case it is due to this open issue


This comment has been minimized.

whereisaaron commented Jan 31, 2018

You're not wrong @beanaroo! prevent_destroy is I think broken and arguably unusable in it's current form. The problem is that prevent_destroy doesn't just keep the flagged resource from being destroyed (i.e. exclude its destruction from plans), instead it blocks planning. Often I want to destroy everything except stateful resources, like a DB or EIPs or pet EBS or EFS or S3 store, terraform can't do that. You have to leave those stateful resources outside of terraform. If you include them you can't use prevent_destroy and plan, so instead you have to manually check plans.

Quite a few people have the same issue, but unfortunately the mod's don't seem to agree it is actually a problem 😢 and keep flagging this issue and an 'enhancement'. See #3874 for a two-year long sad tale of frustrated terraform users 😝


This comment has been minimized.

dguisinger commented Jun 27, 2018

Prevent destroy only works if the resource is still included in the script, also dangerous.

I've been using it for CodeCommit repositories to have consistent Git repos, but there is no way to prevent it from destructively wiping out an entire Git repo or all of the repos with a mistake.
there needs to be a flag you can set on the state that prevents Terraform from ever deleting a resource, unless you specifically tell it you want to release that lock.

Otherwise resources that have user content that is hard to restore should never be put in Terraform, which is a shame.


This comment has been minimized.

tdmalone commented Jul 2, 2018

Potential duplicate of #3874 (and possibly #2159 as well)


This comment has been minimized.

caruccio commented Jul 17, 2018

This flag should be renamed to prevent_plan_or_apply_to_run_on_destroy.


This comment has been minimized.

caruccio commented Jul 17, 2018

It would be useful to have -target to accept reverse match like -target aws_s3_bucket!=my-bucket-i-want-to-keep.


This comment has been minimized.

whereisaaron commented Jul 18, 2018

@dguisinger yes that is what we are doing, only using terraform for resources that are not calamitous if destroyed. Or in one strategy we have two terraform deployments, with one small one that just creates the stateful resources. The issue is quite a thorn.


This comment has been minimized.

SamWhited commented Jul 22, 2018

I would like to throw my support behind this being a bug and not merely a desirable enhancement. In my case I have a stateful machine (postgres) that suddenly decided that it needed to be destroyed. I have no idea why since there are no changes in the commit history to anything that affects postgres that I can see. Unfortunately, it is very difficult to debug since I don't know what property it thinks changed. Please mark this as a bug, prevent_destroy is worse than useless as is, it makes terraform actively difficult to use and debug (but is a safety measure that I can't live without, unfortunately).


This comment has been minimized.

fantomc0der commented Jul 24, 2018

Agreed with the consensus in here. If it's not a bug then it's a poorly designed feature that could use some improvement. My team at work tried using it in the past to protect particular resources (like RDS) but the planning issue mentioned above made it useless. It definitely will act as a last line of defense, but it seems implied that you should never try destroying any root module that can reference a prevent_destroy resource in the first place so it's useless. We ended up preventing it with safety checks in our build script and ensuring that we had no production deployments configured to destroy those resources.

The other issue with prevent_destroy that we encountered is that you can't selectively apply it to a resource. In one of our applications, we had a Terraform module for an RDS cluster which we wanted to prevent_destroy in production; however, for non-production (testing/staging/etc) accounts, we wanted to reference the same module but allow being destroyed since testing environments can come and go.


This comment has been minimized.

davidarmstronglewis commented Jul 24, 2018

I think my biggest grievance with this bug is that I had to come to Github Issues to find enough information on this. In the documentation on the Terraform website, there are no warnings that I have seen of "Hey, you can include pre-existing S3 buckets and other stateful resources in your Terraform plan. If you do that, Terraform can destroy and recreate those resources if it wants to, or - if you are using prevent_destroy - refuse to apply changes to a plan."

If this isn't a bug (which it sounds like it is?), there should be a section in the docs for how to deal with this use-case (immutable stateful storage) and a breakdown of your options:

  1. Is it appropriate to keep this resource outside of Terraform? If so, how can I refer to it within my plan as an immutable global?

  2. If not, how I can I use prevent_destroy while being fully informed of the implications of the Terraform's behavior around that feature.


This comment has been minimized.


ketzacoatl commented Jul 26, 2018

There is also #3874 tracking this discussion as well, one should probably be closed in favor of the other. Ping @jen20 / @phinze / @paddycarver / @radeksimko.


This comment has been minimized.

whereisaaron commented Jul 26, 2018

@ketzacoatl #3874 is the earlier request (2015!) and has the most participants (~40) and +1's (~100), so I would suggest keeping that one.


This comment has been minimized.

tdmalone commented Jul 26, 2018

^ Also #2159

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment