In HCP Terraform, an app workspace needs the subnet ID that a network workspace exposes as an output. Security does not want the app workspace's runs to have read access to the network workspace's full state. Which approach fits HashiCorp's recommendation?
Select an answer to reveal the explanation.
Short Explanation
You only want the number on the envelope, not the whole filing cabinet. tfe_outputs hands you just the outputs. terraform_remote_state needs access to the entire state snapshot, secrets and all, even though it only shows you the outputs.
Full Explanation
HashiCorp recommends the tfe_outputs data source from the tfe provider for reading another HCP Terraform or Terraform Enterprise workspace's outputs, because it does not require full access to the workspace's state; it retrieves output values only, and its access depends on the tfe provider's token and that token's permissions. terraform_remote_state also exposes only outputs to configuration, but whoever uses it must be able to read the entire state snapshot, which can include sensitive resource attributes. Opening the network workspace's remote state sharing to every workspace in the organization widens that exposure further and runs against the documented least-privilege advice. Pulling the full state in a pipeline grants exactly the access security wants to avoid, and copying values by hand creates a stale, manual dependency. Granting the Write role lets the app team change variables and apply runs in the network workspace, which is far more than reading one value. Exam caveat: HashiCorp notes that provider-specific data sources, which look objects up directly in the cloud, are often the most resilient way to share data between configurations. Operational check: confirm the token used by the tfe provider has only the access needed to read the network workspace's outputs.