terraform_data and Triggers

Scenario: A deployment needs to rerun a small integration step when a release checksum changes, but no provider-managed object represents it.

The built-in terraform_data resource stores values and lifecycle triggers without configuring an external provider. triggers_replace can model when the resource—and attached provisioners if absolutely needed—must be replaced. It improves dependency modeling over legacy null_resource, but it does not make arbitrary scripts observable or declarative.

Analogy: A trigger is a dated work order. It records when to call the contractor, not what happened inside the contractor's van.

A worked configuration

resource "terraform_data" "release_hook" {
  triggers_replace = [filesha256("release.json")]
  provisioner "local-exec" { command = "./publish-release.sh" }
}

Prefer a provider resource or CI pipeline action when the operation has a durable lifecycle. If failure recovery requires manually editing state, the integration likely belongs outside Terraform.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-terraform-data-triggers Terraform lab. Open /labs/terraform and choose slug tf-terraform-data-triggers; the lab runs real Terraform against the offline FakeCloud provider.