Sharing Data Across States

Scenario: A network state exports an entire resource object, coupling every consumer to provider internals and granting broad state access.

Separate states sometimes need narrow integration facts such as network IDs. terraform_remote_state reads root outputs from another state, but access commonly grants visibility to the whole snapshot. HCP Terraform's tfe_outputs can expose outputs with narrower intent. Other patterns publish values to a parameter store, DNS, or provider data source. Avoid cycles between states; establish a directional dependency graph.

Analogy: States are bounded contexts. Share a documented public API between them, not a copy of the neighbor's private database.

A worked configuration

data "terraform_remote_state" "network" {
  backend = "remote"
  config  = { workspace = "network-prod" }
}
locals { network_id = data.terraform_remote_state.network.outputs.network_id }

Minimize outputs, classify them, and consider whether consumers truly need state access. Run triggers can order work but do not remove architectural coupling; shared infrastructure changes need compatibility windows.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-cross-state-outputs Terraform lab. Open /labs/terraform and choose slug tf-cross-state-outputs; the lab runs real Terraform against the offline FakeCloud provider.