A workspace was upgraded from Terraform 1.12 to 1.15 and a successful apply ran. A week later an engineer wants to switch the workspace back to 1.12 because a colleague prefers its output format. What is the correct guidance?
Select an answer to reveal the explanation.
Short Explanation
Upgrades in Terraform are a one-way street with no U-turn sign promised. Moving forward within 1.x is supported; going back after newer state is written might work for you, but nobody guarantees it.
Full Explanation
Terraform's v1.x compatibility promises say an upgrade from any 1.x release to any later 1.x release should work without special steps. They also say a downgrade to an earlier 1.x release might be possible but is not guaranteed, because later releases can introduce features earlier versions cannot understand, including new storage formats for state snapshots, and configurations that use newer language features will not work on older releases. After the 1.15 apply, the workspace's state was written by 1.15, so the safe operating stance is to treat the upgrade as one-way, test upgrades before production, and resolve issues by fixing forward. Claiming downgrades are always safe misreads the promise, which only covers moving forward. terraform state replace-provider changes provider source addresses recorded in state; it does not convert state to an older format. The dependency lock file records provider versions and checksums, not the Terraform version, so reverting it has no effect on state compatibility. Exam caveat: a preference about output format is not a reason to change versions; output differences are best handled in tooling. Operational check: before any future upgrade, record the current state version, run the new version's plan on a non-production workspace, and confirm the team agrees the change is one-way before applying.