A widely used internal module has accumulated about 30 moved blocks over eight minor releases as resources were renamed and regrouped. A maintainer proposes deleting them all in the next minor release to tidy the code. Several teams still pin versions from a year ago. What should the maintainer do?
Select an answer to reveal the explanation.
Short Explanation
Moved blocks are forwarding addresses for anyone still living at the old place. Rip them out and you leave the team upgrading from last year's version with no forwarding note, so Terraform plans to bulldoze their resources and rebuild.
Full Explanation
A moved block tells Terraform that an object recorded at an old address should now be tracked at a new one. The move is applied whenever a configuration that contains the block is planned against a state still using the old address, which is exactly the situation of a caller upgrading from an older module version. HashiCorp documents that removing a moved block is a breaking change, because configurations that still refer to the old address will plan to delete the existing object instead of moving it, and strongly recommends retaining historical moved blocks in shared modules to preserve the upgrade path. A moved block does not expire after one apply; it remains harmless for states already migrated and essential for those that are not. Removed blocks express something different: they tell Terraform to stop managing, or to destroy, an object, so converting moves into removals would change behavior. The dependency lock file records provider versions and checksums only; it holds no record of module refactoring. Exam caveat: pruning moved blocks can be acceptable for a private module when every caller is confirmed to have upgraded, and it should then ship as a major version. Operational check: plan a caller pinned to the oldest supported version against the new release and confirm only moves appear.