A team is about to move a production workspace from Terraform 1.14 to 1.15 and wants evidence that the new core version alone will not change infrastructure. Configuration and provider versions stay the same. What is the most useful test before applying anything with 1.15?
Select an answer to reveal the explanation.
Short Explanation
The cleanest upgrade test is boring on purpose: same code, same providers, new Terraform, and you want the plan to say 'No changes'. Anything else is a surprise you get to explain before it reaches prod. The trap is validate, which checks your code, not what will happen to your infrastructure.
Full Explanation
When only the Terraform core version changes, the safest evidence is a plan produced by the new version against the existing state and configuration. If the plan reports no changes, the upgrade has not altered how Terraform interprets the configuration or the real objects, and the team can proceed with confidence. If it does propose changes, each one should be explained by the release's upgrade notes or changelog before anything is applied. This plan reads state but does not write it, so the test itself is safe. A validate run checks configuration syntax and internal consistency without evaluating state or remote objects, so a clean result says nothing about whether the plan would differ. A refresh-only apply writes a new state snapshot using the new version, which is itself a change; it may make returning to the old version harder, because downgrades are not guaranteed, and it does not evaluate configuration-driven changes anyway. Formatting is cosmetic: terraform fmt rewrites whitespace and layout and never affects plans, so checking it measures nothing about infrastructure impact. Exam caveat: keep provider upgrades out of the same change, otherwise a non-empty plan cannot be attributed to the core upgrade. Operational check: run the plan with 1.15 using -detailed-exitcode in CI and require exit code 0 before merging the version bump.