Production was upgraded from Terraform 1.14 to 1.15 and has had several successful applies since. An engineer now wants to switch prod's pipeline back to 1.14 because a colleague prefers its plan output. What should the team understand first?
Select an answer to reveal the explanation.
Short Explanation
Terraform's promise is a one-way street: forward through 1.x, yes; backward, maybe, but no promises. Once newer versions have written your state, going back is a gamble. The trap is reading 'compatibility promises' as working in both directions.
Full Explanation
The v1.x compatibility promises cover upgrading: any v1.x release can be replaced by any later v1.x release. For downgrading, the documentation says you might be able to move to an earlier v1.x release but that it is not guaranteed, because later releases can introduce features earlier versions do not understand, including new state snapshot formats, and a configuration that uses newer language features stops working on releases that predate them. After several applies on 1.15, prod's state was written by 1.15, so switching back is unsupported and must be treated as a risk rather than a preference. The responsible options are to stay on 1.15 or, if a real defect forces a rollback, to restore a state backup taken before the upgrade and accept reconciling any changes made since. The promises do not cover downgrades, so treating them as guaranteed is incorrect. The -upgrade option on init selects newer providers and modules; it does not convert state formats. The state pull command upgrades its local copy to the running version before output, so it cannot reveal which version wrote the remote state. Exam caveat: avoid using new language features until every environment runs a version that supports them. Operational check: before any core upgrade, save a state backup and record the previous version, and keep the version pinned so it changes only deliberately.