An engineer wants an application instance to be replaced whenever the input variable app_version changes. They added replace_triggered_by = [var.app_version] to the instance's lifecycle block, and Terraform rejects it. Which change achieves the goal?
Select an answer to reveal the explanation.
Short Explanation
replace_triggered_by only listens to resources, the way a doorbell only rings when someone's at the door. A plain variable isn't a resource, so you give it one: park the value in terraform_data and point the trigger at that. A local value won't help, because it's still just plain data.
Full Explanation
replace_triggered_by forces replacement based on planned actions for the referenced managed resources, instances or attributes, so Terraform accepts only references to managed resources there. Plain data values such as input variables and local values are not valid. The documented pattern is a terraform_data resource whose input argument is set to var.app_version: when the variable changes, terraform_data plans an update, and an instance whose replace_triggered_by lists that terraform_data resource is replaced in the same plan. Wrapping the variable in a local value changes nothing, because locals are also plain values. depends_on only orders operations; it never forces replacement. ignore_changes does the opposite of what is needed, telling Terraform to disregard differences in the listed attributes of the resource itself, and it cannot reference variables. Exam caveat: in Terraform 1.15, replace_triggered_by reports an error when given a reference to an attribute that does not exist, so typos in attribute paths fail early instead of being silently ignored. Operational check: change app_version and confirm the plan shows terraform_data updating and the instance marked for replacement because of replace_triggered_by.