An organization runs Terraform 1.9 in dev, stage, and prod, each with its own state. The lead wants to move all three to Terraform 1.15 while limiting risk. Which rollout plan is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Upgrading Terraform is like changing a plane's engines: you test on the trainer before the passenger jet. Read the notes for every release you're skipping over, prove a clean plan in dev, then promote. The trap is thinking you must stop at every version on the way; within 1.x you can jump straight there.
Full Explanation
The Terraform v1.x compatibility promises state that you should be able to upgrade from any v1.x release to any later v1.x release without special upgrade steps, while noting that individual releases can still include behavior changes and upgrade notes. A controlled rollout therefore reads the upgrade notes for every minor release being skipped, because each may contain items that affect the configuration, such as 1.11 deprecating DynamoDB locking arguments in the S3 backend or 1.15 tightening validation and some S3 environment variables. The new version is then used in the least critical environment first: run init and plan, expect no changes beyond those explained by the notes, and only then promote to stage and prod. Upgrading everything at once removes the chance to catch an issue where it is cheap, and reading notes only after failure reverses the order. Stepping through each intermediate release is unnecessary, because 1.15 can read state written by 1.9 directly. Upgrading prod first maximizes impact, and downgrading afterward is not guaranteed to work, since later versions may write state that earlier releases cannot read. Exam caveat: provider upgrades are separate from core upgrades and should not be bundled into the same change. Operational check: in dev, pin the CI image to 1.15, run init and plan, and require an empty plan before merging the version bump for the next environment.