A producer workspace publishes network outputs, and five consumer workspaces read them with terraform_remote_state. All six are on Terraform 1.10 and will move to 1.15 on different days. Which sequencing minimises the risk of consumers failing to read the producer's state?
Select an answer to reveal the explanation.
Short Explanation
Think of it like file formats: new software opens old files fine, but old software might choke on a file saved by the new version. If you upgrade the readers first and the writer last, nobody gets a file they can't open.
Full Explanation
Terraform's compatibility promises guarantee that moving from any 1.x release to a later 1.x release works, but they explicitly do not guarantee that an earlier release can read state written by a later one, because new releases may introduce new storage formats for state snapshots. terraform_remote_state reads the producer's latest state snapshot, so the risky combination is a producer already writing state with a newer release while consumers still run an older one. Upgrading consumers first, or all six together, means each reader runs a version at least as new as the writer, the direction the promises cover. Upgrading the producer first creates exactly the unguaranteed situation and is a choice to discover breakage in production rather than to avoid it. Keeping consumers on 1.10 forever leaves them permanently on the unsupported side of the gap, and terraform_remote_state reads the state snapshot itself, not a separate outputs-only API. Deleting historical state versions destroys recovery points and does nothing to make the newest snapshot readable by older binaries. Exam caveat: many 1.x upgrades write state that older 1.x releases can still read, but planning should rely on the documented guarantee rather than on that history. Operational check: after upgrading consumers, run their plans and confirm they read the producer's outputs, then upgrade the producer and rerun one consumer plan.