A team refactors a large configuration by renaming resources and moving several into modules, adding moved blocks for each change. Before merging, reviewers want proof the refactor does not touch any real infrastructure. Which evidence is sufficient?
Select an answer to reveal the explanation.
Short Explanation
Only a plan against the real state can tell you what Terraform would actually do. If it shows nothing but moves and zero adds, changes and destroys, the refactor is a pure rename and safe to merge.
Full Explanation
A refactor that is truly safe changes only addresses, so planning it against the current state must show each moved object as a move and the summary must report nothing to add, change or destroy. Because the plan compares the refactored configuration and its moved blocks with the actual state and refreshed infrastructure, it is the only check that proves no real object will be recreated or modified; in CI, terraform show -json on the saved plan lets a script confirm that every resource change is a no-op carrying a previous address. Terraform validate checks syntax and internal consistency of the configuration only and never reads state, so it cannot tell whether addresses still match existing objects. The fmt check enforces canonical formatting and says nothing about the meaning of the code. Comparing resource counts from state listings shows how many objects state holds, not whether the new configuration will replace them; state does not change merely because a branch is checked out, so the counts would match even for a destructive refactor. Exam caveat: a plan run with a stale or wrong workspace proves nothing, so the evidence must come from the state the merge will apply to. Operational check: attach the saved plan's JSON to the pull request and fail the check if any action is other than no-op.