Terraform State & Drift · Terraform systems note
terraform_remote_state Is a Trust Boundary, Not Just a Convenience
Reading outputs from another Terraform state is convenient, but consumers generally need access to the full underlying state snapshot. That couples security and deployment boundaries.
Splitting infrastructure into several states reduces blast radius and lets lifecycles evolve independently. The next problem is how those states exchange data.
Outputs look narrower than backend access
terraform_remote_state exposes only root outputs to configuration, but HashiCorp warns that a caller with enough access to read those outputs generally has access to the whole state snapshot.
If that state contains sensitive values, the trust boundary is broader than the output list suggests.
Availability is coupled too
If application infrastructure cannot plan unless it can read the networking backend, that backend and its credentials become part of the application's deployment path.
Outputs become an API
Once other configurations depend on output names and shapes, changing them is effectively an interface change. Stable outputs deserve versioning discipline.
Sometimes publish data elsewhere
Provider data sources, DNS, parameter stores, service catalogs or HCP-specific output mechanisms can be better for values that need a broader or narrower consumer set.
Use remote state deliberately. The permission to read it is a security decision, not merely a data-flow convenience.