An engineer moves an existing aws_instance.web resource block from the root module into a new child module called web, where it is now named aws_instance.this. The plan proposes destroying the old instance and creating a new one. What should the engineer add to keep the existing instance?
Select an answer to reveal the explanation.
Short Explanation
Terraform tracks objects by address, so a new address looks like a brand-new resource unless you leave it a forwarding note. A moved block is that note, and it can point straight into a module.
Full Explanation
Terraform associates each real object with a resource address in state. Relocating a resource block into a child module changes its address, so without further information Terraform plans to destroy the object at the old address and create one at the new address. A moved block with from set to the old address and to set to the new address inside the module, here aws_instance.web to module.web.aws_instance.this, tells Terraform that the existing object should simply be re-addressed, and the plan reports a move with no destroy or create. Because it lives in configuration, the change is reviewable and applies consistently in every workspace that uses the configuration. A depends_on argument only orders operations between objects; it creates no identity link between addresses. A refresh-only operation reconciles state with real attribute values, but it cannot infer that an object at one address belongs at another. Adding prevent_destroy to the new address does not affect the old address's planned destruction; at best it makes the plan error rather than preserving the instance. Exam caveat: terraform state mv achieves the same outcome imperatively, but it bypasses code review and must be repeated per state. Operational check: rerun the plan and confirm it reports the instance as moved, with zero to add and zero to destroy.