A configuration uses a public registry module pinned to version 4.x. The team wants to upgrade to 5.0, whose release notes say several resources were renamed and regrouped inside the module. What is the safest upgrade procedure?
Select an answer to reveal the explanation.
Short Explanation
A major version is the module author telling you to read the label before you swallow it. Read the upgrade notes, pull it in with init -upgrade, and let the plan show you whether the renames come out as moves or as replacements.
Full Explanation
A major version signals breaking changes, so the safe procedure starts with the module's upgrade guide or release notes, which explain renamed inputs, changed outputs and any resource address changes. After updating the version constraint, terraform init -upgrade installs the newest module version matching the new constraint, since init otherwise leaves already-installed modules alone. A well-maintained module ships moved blocks for its internal renames, and a careful review of the plan confirms those resources appear as moves rather than destroy and create, while exposing anything the maintainers did not cover. The lock file records provider selections only, so deleting it does nothing for module versions and needlessly reopens provider selection; applying the result unreviewed skips the essential step. Assuming renames are always handled automatically ignores that address changes are only preserved when the module provides moved blocks, and applying without reviewing the plan could replace stateful resources. Removing everything from state and re-importing is a heavy, error-prone manual migration that discards the module's own refactoring support. Exam caveat: if the plan shows unexpected replacements, add moved blocks in the calling configuration for any addresses the module did not cover. Operational check: save the plan, inspect its JSON for delete actions, and proceed only when every change is expected.