Terraform 1.16 moves pre-destroy cleanup scripts into the plan with destroy-time Actions

An Action is its own block. It attaches to a resource through action_trigger inside that resource's lifecycle block, with before_destroy or after_destroy listed in events ^[4][1]. HashiCorp's release post leads with a final backup, deregistering an asset, and cleaning up an external system before the infrastructure goes away, according to a dev.to write-up of the post ^[3]. The write-up's author used to run those steps outside Terraform, in a script called pre-destroy.sh that took a backup, poked an external inventory system and only then let the pipeline run terraform destroy ^[19]. "Everyone on the team was a little scared of it, and nobody ever fully trusted it," the author wrote ^[18].

The trigger hangs off the resource block, and that placement sets the constraint teams will hit first. Delete the block and its action_trigger goes with it, which leaves Terraform no hook to call when it plans the destroy ^[10]. HashiCorp recommends two steps: first put the resource and its trigger configuration at count = 0, and only remove the block in a follow-up change ^[11]. The destroy and the hook run in the first change. The second deletes a block that no longer manages anything ^[10][11]. A reviewer scanning the diff for deleted resource blocks will find none in the change that does the deleting ^[11].

Failure handling needs the same care. Under continue, Action errors become warnings, so a backup that fails during teardown does not stop the destroy ^[12][14]. The taint mode offers no rescue. According to the write-up, taint flags a freshly created resource to be replaced, and it does nothing to let a failed destroy Action be retried ^[13]. For a backup Action I'd keep halt, which stops dependent processing after an error, and accept a stuck pipeline over a teardown with no backup ^[12].

Terraform has long had destroy-time provisioners, set with when = destroy, which run shell commands as a side effect of the destroy ^[15]. "They work, but a provisioner is an escape hatch and reviewers tend to treat it as one," the author wrote ^[21]. CloudFormation covers backups with DeletionPolicy: Snapshot on supported resources and uses custom resources for other cleanup on delete ^[16]. Kubernetes finalizers block deletion of an object until a controller has done its cleanup ^[22]. In Terraform's version, the cleanup step sits next to its resource and shows up at plan time, per the write-up ^[5].

"The second change is quieter, and I think more people will feel it day to day," the author wrote of the import change ^[23]. Previously, an import block was allowed to point at a resource in a child module, yet the block had to be declared in the root module ^[6]. HashiCorp's post calls that "an awkward exception" for modules that are supposed to hide their implementation details ^[7]. In the write-up's example, a log-bucket module declares its own import keyed on a bucket-name variable, and the caller passes only the name, with no resource addresses ^[20].

I'd adopt module-owned imports in a shared catalogue at the next version bump. Destroy Actions fit where cleanup inputs are known at plan time and the team will accept two-step deletions ^[9][11].