An application team reads the network team's VPC ID with the terraform_remote_state data source. The network team's state also contains database passwords managed by other resources. What should the network team understand about this access?
Select an answer to reveal the explanation.
Short Explanation
terraform_remote_state is a peephole in the door, but to look through it you need a key to the whole house. Your config only sees the outputs, yet whoever can read them can read every secret in that state. The trap is assuming the backend hands over just the outputs.
Full Explanation
The terraform_remote_state data source retrieves another configuration's latest state snapshot and exposes only its root module output values to the consuming configuration. Access control, however, operates on the snapshot as a whole: the documentation explains that the state is a single object, so any user or service with enough access to read the outputs also has access to the full snapshot, including sensitive attributes such as database passwords. For the network team, granting this access effectively shares all of its state. Backends store and return whole snapshots; there is no filtering of non-output data at the backend layer. Configuration expressions can reference only root outputs, not arbitrary resource attributes, so the producer must still declare outputs. Child module outputs are not exposed either; a value inside a child module must be re-exported by a root output to become visible. Exam caveat: HashiCorp recommends publishing shared values through a dedicated store, such as a parameter store or a DNS record, or using the tfe_outputs data source in HCP Terraform, which does not require full state access. Operational check: list which identities can read the network state's storage location, and replace remote state reads with a narrower mechanism where secrets are present.