In Terraform, what is terraform_data for, and why did it supersede null_resource as the place to hang a provisioner?

## The problem both resources solve A provisioner has to live inside a `resource` block. But plenty of imperative glue is not tied to any single piece of infrastructure — you want to run a command once, or once whenever some value changes, without pretending it belongs to a particular instance. You also occasionally want a node in the dependency graph that carries a value but creates nothing. ## null_resource, the historical answer `null_resource` comes from the `hashicorp/null` provider. It creates nothing; its only meaningful argument is `triggers`, a **map of strings**. Because the values must be strings, non-string data has to be converted — the familiar idiom is `jsonencode(...)` or `md5(...)` around the real value. When any value in the map changes, the resource is replaced, and replacement re-runs the provisioners attached to it. ```hcl resource "null_resource" "reload" { triggers = { config_hash = md5(file("${path.module}/app.conf")) } provisioner "local-exec" { command = "./reload.sh" } } ``` The cost is a dependency: `hashicorp/null` must be resolvable, it appears in `required_providers` and in `.terraform.lock.hcl`, and every `terraform init` — including on air-gapped or restricted CI runners — has to fetch another plugin binary to do nothing. ## terraform_data, added in Terraform 1.4 `terraform_data` is a **built-in** managed resource type. There is no provider to declare and nothing to download; it is part of Terraform itself. It exposes: - `triggers_replace` (optional, any type) — a value stored in state; when it changes, the resource is replaced. Unlike `triggers`, it accepts any value, so a list, a map, or a resource ID works directly without string conversion. - `input` (optional, any type) — a value to store. - `output` — the value of `input` from the most recent apply. - `id` — a generated string identifier. ```hcl resource "terraform_data" "reload" { triggers_replace = [ aws_instance.web.id, filemd5("${path.module}/app.conf"), ] provisioner "local-exec" { command = "./reload.sh ${self.id}" } } ``` ## What input and output are actually for The `input`/`output` pair is the less obvious half. `output` takes the value `input` had at the last successful apply, which lets you pin a value across applies and hand it to something else through a normal dependency reference. A typical use is capturing a value that would otherwise be recomputed every plan, or building an explicit graph edge between two things that have no natural attribute reference. Because `output` is only updated on apply, referencing it gives you last-applied semantics rather than current-configuration semantics. ## Migrating `null_resource` is not deprecated in the sense of being removed — existing code keeps working, and the null provider is still published. But new code has no reason to reach for it. The mechanical differences to watch when converting: `triggers` (map of strings) becomes `triggers_replace` (any value), the resource address changes, and because the address changes the object would be destroyed and recreated. If the resource merely holds a hash and re-running the provisioner is harmless, let it replace; if not, a `moved` block will not help across different resource *types*, so plan the recreation deliberately. ## The honest caveat Swapping `null_resource` for `terraform_data` removes a provider dependency. It does not make the provisioner any better. Everything true of provisioners generally is still true here: the command's effects are not in state, nothing appears in the plan beyond "this resource will be replaced", the script must be idempotent because you cannot control how often replacement happens, and a failure taints the object. A `terraform_data` with a `local-exec` is a perfectly reasonable piece of build glue and a poor substitute for a provider resource that actually models what you are doing. ## Version note `terraform_data` requires Terraform 1.4 or newer. On older versions `null_resource` is the only option, which is worth stating out loud if the interview touches a codebase pinned by `required_version`.