An application server must be replaced whenever local.app_config_hash changes. Adding replace_triggered_by = [local.app_config_hash] to the server's lifecycle block fails validation. Which change achieves the replacement trigger?
Select an answer to reveal the explanation.
![To Create an exciting colorful infographic that explains the concepts in the question: Question: An application server must be replaced whenever local.appconfighash changes. Adding replacetriggeredby = [local.appconfighash] to the server's lifecycle block fails validation. Which change achieves the replacement trigger? Correct Answer: Store the hash in a terraformdata resource's input and reference it in replacetriggeredby Put EVERY visible label in double quotes. No people. No A/B/C/D letters. In one of the four corners put a little "Navy Duck".](/media/hashicorp/terraform-pro-002/TERRAFORM-PRO-002-e1-q027.webp)
Short Explanation
replace_triggered_by only listens to resources, not to plain values. So you give the hash a body: put it in a terraform_data resource, and when the hash changes, that resource changes and the server follows. The trap is reaching for depends_on, which orders things but never replaces anything.
Full Explanation
The replace_triggered_by lifecycle argument accepts references to managed resources or their attributes; a change to any referenced resource instance causes Terraform to plan a replacement of the resource that contains the argument. Plain values such as locals and input variables are not allowed, which is why the original configuration fails. terraform_data closes that gap: its input argument stores an arbitrary value, Terraform plans an update to it whenever the value changes, and listing terraform_data.config_hash in replace_triggered_by therefore replaces the server each time the hash moves. ignore_changes does the opposite of what is wanted; it tells Terraform to disregard differences in listed attributes, and a local is not an attribute of the server anyway. The -replace option is a one-off command-line instruction for a specific address; it has no awareness of whether a value changed and would replace the server on every run that passes it. depends_on establishes ordering between objects and never by itself causes replacement; it also accepts only resource and module references. Exam caveat: terraform_data with triggers_replace is the related pattern when the terraform_data resource itself should be replaced, for example to rerun a provisioner. Operational check: change the hash, run terraform plan, and confirm the server shows a replace action caused by replace_triggered_by.