One root configuration holds a core network that changes about once a year and application services that are redeployed several times a day. Each application deploy plans and locks the network resources too, and network changes need a separate approval chain. How should the team restructure?
Select an answer to reveal the explanation.
Short Explanation
Things that change at different speeds, with different owners, want different homes. Give your network its own state and let the apps read its outputs, so a daily deploy can't even see the subnet, let alone break it.
Full Explanation
Separating configurations by rate of change and ownership is a core structuring principle. Putting the core network in its own root configuration and state means application deploys never plan, refresh or lock network resources, network changes follow their own approval chain and permissions, and the application configuration consumes values such as subnet and security group IDs through the network's outputs, read with a remote state data source, the tfe_outputs data source in HCP Terraform, or provider data sources. A child module does not create a separate state or a separate run; resources in child modules are planned and applied together with the root module that calls them. Routine -target usage is an exceptional recovery technique that leaves configuration and state out of step and relies on every operator choosing the right targets every day. The ignore_changes argument only suppresses updates for named attributes; network resources would still be refreshed, planned and locked within each application run, and real drift would be hidden rather than separated. Exam caveat: expose only the outputs downstream consumers need, because remote state access reveals the entire state. Operational check: after the split, confirm an application plan lists no network resources and that changing an application input never queues a network run.