A company manages its network, databases and dozens of applications from one root configuration with a single state. A typo in an application change recently planned the replacement of a shared subnet, and every plan takes 25 minutes. Which change best reduces the risk and blast radius of routine changes?
Select an answer to reveal the explanation.
Short Explanation
One giant state is like keeping every circuit in the house on one breaker: flip it for the kitchen and the whole place goes dark. Split your state by layer and owner, and an app typo simply can't reach the subnet.
Full Explanation
Blast radius is set by what a single plan and apply can touch, which is everything in one state. Splitting into separate root configurations by layer and ownership, such as network, data and applications, means an application change is planned against application state only, so it cannot propose replacing a shared subnet, and each plan refreshes far fewer objects and runs faster. Upstream values such as subnet IDs flow to downstream layers through outputs consumed with remote state sharing or data sources, and each layer can have its own permissions and review rules. Routine use of -target is documented as an exceptional tool for recovery; relying on it for normal work leaves the configuration and state out of step and hides the real dependency picture. State locking prevents concurrent operations from corrupting state but does nothing to limit what a single run can change. An encrypted, versioned backend improves confidentiality and recovery of the state file, which is valuable, but the infrastructure blast radius of a bad apply stays exactly the same. Exam caveat: splitting introduces cross-state dependencies, so publish only the outputs consumers need. Operational check: after the split, confirm an application plan lists no network or database resources, and that the network workspace's outputs feed the application inputs.