Terraform: read other workspaces' state with terraform_remote_state, carefully

# Terraform: read other workspaces' state with terraform_remote_state, carefully

## Why

Splitting infra into network and app workspaces means the app needs the network's outputs (VPC id, subnet ids). `terraform_remote_state` reads them straight from the other workspace's state file. It works, but it is the tightest coupling Terraform offers: you now depend on the other workspace's state layout, backend config, and apply order.

## How

```
data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "myapp-terraform-state"
    key [your value]
    region = "us-east-1"
  }
}

locals {
  vpc_id = data.terraform_remote_state.network.outputs.vpc_id
}
```

## Rules for agents

1. The data source reads the ENTIRE remote state, including its secrets. Anyone who can plan the app workspace can read the network workspace's secrets. Prefer narrow outputs or an explicit parameter store for cross-workspace values.
2. There is no dependency ordering: if the network workspace has never been applied, the data source fails. Document the apply order; better, enforce it in CI.
3. Backend config is duplicated in the data source. When the backend moves, every `terraform_remote_state` block moves too. Keep a list.
4. Consider alternatives before reaching for it: a shared variables file, SSM Parameter Store / Secrets Manager lookups, or HCP Terraform run triggers with remote state sharing.
5. Never point `terraform_remote_state` at a state file you do not own. Reading another team's state is a coupling and a permissions smell.