What does the Terraform lifecycle argument `replace_triggered_by` do, and why is it often paired with a `terraform_data` resource?

## The problem Terraform's dependency graph is built from references: if resource B reads an attribute of resource A, B is created after A, and B is updated when the value it read changes. That covers the case where the dependency is about *data*. It does not cover the case where the dependency is about *freshness* — "whenever the configuration this thing was built from changes, rebuild this thing", even though the change does not appear in any attribute the resource actually reads. The usual workarounds were ugly: a `null_resource` with `triggers` calling a provisioner, or a fake attribute change smuggled into a tag. `replace_triggered_by` makes it a first-class lifecycle setting. ## How it works ```hcl lifecycle { replace_triggered_by = [ terraform_data.app_revision, ] } ``` The list accepts references to managed resources, to a specific instance of one, or to an attribute of one. When the referenced item changes — the attribute takes a new value, or the referenced resource is itself replaced — Terraform plans a replacement of the resource carrying the lifecycle block. In the plan output it shows up with the reason that it is being replaced because of a change in the referenced item, which is much easier to review than a mysterious tag diff. What it does **not** accept is any other kind of expression. Variables, locals, data sources and arbitrary function calls are all rejected. The restriction is deliberate: the reference has to be to something Terraform tracks in state, so it can tell that it changed between runs. ## Why terraform_data `terraform_data` is a built-in resource type — no provider required — introduced in Terraform 1.4 as the modern replacement for the old `null_resource` from the null provider. Its `input` argument stores an arbitrary value in state and exposes it as `output`. That gives you a stateful, referenceable handle for a value that would otherwise be just a variable: ```hcl resource "terraform_data" "app_revision" { input = var.app_revision } ``` Now `terraform_data.app_revision` is a managed resource whose recorded value changes when the variable changes, so it is a legal target for `replace_triggered_by`. Changing `var.app_revision` from `v7` to `v8` updates the `terraform_data` object and, through the trigger, replaces the instance. On Terraform versions before 1.4 the same shape was written with `null_resource` and its `triggers` map. ## When to reach for it, and when not to Good fits are genuinely coupled lifecycles: an instance that must be rebuilt when a bootstrap artefact version changes; a resource that has to follow the replacement of something it is paired with but does not reference; an appliance whose configuration is delivered out of band and only takes effect on recreation. Be careful, though. Every entry is a lever that destroys and recreates real infrastructure on a value change, and it is easy to attach it to something that changes more often than you expect — then an unrelated variable edit rolls the fleet. Two habits help: key on the narrowest attribute rather than a whole resource, and, where the platform can roll the change itself, prefer that to Terraform-driven replacement. ## Version notes `replace_triggered_by` requires Terraform 1.2 or later; `terraform_data` requires 1.4 or later. On older versions the equivalent is `null_resource` with `triggers`. It is worth stating the version assumption in an interview, because this is one of the parts of the language that moved recently.