In addition to that things can be made even less error prone. Ive done this using yaml pipeline in azure devops. The plan task can be used to set an output variable which indicates if the generated plan contains any changes. That boolean value is used as a condition to trigger a manual verification task which basically prevents apply running if there are any changes without reviewing it first.

As the op mentions, the generated plan is an artifact itself that is used in a following apply task

Unfortunately, I've never been able to get much mileage from the Terraform prevent_destroy lifecycle option because it can't be set from a variable. Most of my configurations use a module and pass different variable values per each environment. I'd want the lifecycle flag in production, but maybe not dev.

There is a trick around this. Code 2 mostly identical resources, one with prevent_destroy true and the other with prevent_destroy false. Give both resources a count. You can make the count dependent on interpolation. And the count can be zero. So depending on the interpolation result you have resource(s) with prevent_destroy or without. For the "wrong" ones you just create 0 of them.

https://stackoverflow.com/questions/53727357/terraform-how-t...

https://stackoverflow.com/questions/53744441/how-to-refer-to...

Plus the combinatorial explosion of all possible conditions.

Not a good trick.

When I want to deploy a test system the resource can be destroyed after I am done.

Of course this is not really elegant code. It violates DRY, I need to make sure that my test resources have identical configuration as my production resources, except this one attribute.

Maybe your use case is different. I never change the prevent_destroy attribute during the lifetime of the resource.