A configuration must run a local migration script every time var.schema_version changes, and the team wants to drop the null provider. Which configuration achieves this with built-in features only?
Select an answer to reveal the explanation.
Short Explanation
Provisioners only fire when a resource is created, so you need something that gets rebuilt when the version changes. terraform_data with triggers_replace is that something: new version, new instance, script runs. The trap is using input, which only updates in place and leaves the provisioner asleep.
Full Explanation
terraform_data is a built-in managed resource, so it needs no provider installation, and it implements the standard resource lifecycle, which makes it the documented replacement for null_resource. Its triggers_replace argument stores a value in state and causes Terraform to replace the resource whenever that value changes. Creation-time provisioners such as local-exec run when the resource is created, so replacing the resource on each schema_version change reruns the script exactly when required. The input argument, by contrast, plans an in-place update when it changes, and creation-time provisioners do not run on updates; adding ignore_changes on input would also hide the change completely. A check block evaluates assertions and its scoped data source reads data; neither runs local commands. replace_triggered_by belongs in a resource lifecycle block and accepts only managed resource references, so it can live neither on a local value nor point at a variable. Exam caveat: provisioners remain a last resort; when a provider offers a native resource or action for the task, prefer that over a local script. Operational check: change schema_version, run terraform plan, and confirm the terraform_data resource is marked for replacement; after apply, confirm the script's output appears in the log.