In Terraform, how does one root configuration read a value produced by a different configuration's state, and what has to exist on the producing side?

## Why there is a handoff at all Once an estate is split into more than one Terraform root configuration — say `network/` and `platform/` — each has its own state file. Terraform's graph and its interpolation only span a single configuration, so `aws_vpc.main.id` in `network/` is simply not an addressable expression inside `platform/`. Something has to carry the value across the seam, and Terraform's built-in answer is *outputs read through a data source*. ## The producing side: outputs are the public interface The producer declares an `output` block in its **root** module: ```hcl # network/outputs.tf output "vpc_id" { value = aws_vpc.main.id } output "private_subnet_ids" { value = [for s in aws_subnet.private : s.id] } ``` Outputs are recorded into the state file on `apply`, which is what makes them readable later. Treat them as an API rather than as debug printing: once another configuration reads `vpc_id`, renaming it is a breaking change for someone else's plan. A common surprise: `terraform_remote_state` exposes only **root** outputs. If the value is produced inside a child module, the root has to re-export it: ```hcl output "vpc_id" { value = module.vpc.vpc_id } ``` ## The consuming side: the terraform_remote_state data source The consumer declares a data source that names the producer's backend type and the same configuration that backend was initialised with: ```hcl data "terraform_remote_state" "network" { backend = "s3" config = { bucket = "acme-tfstate" key = "network/prod/terraform.tfstate" region = "eu-west-1" } } resource "aws_instance" "app" { subnet_id = data.terraform_remote_state.network.outputs.private_subnet_ids[0] } ``` The address is always `data.terraform_remote_state.<NAME>.outputs.<OUTPUT_NAME>`. There is no way to reach anything else — not resource attributes, not child-module state, not variables. That restriction is deliberate: it keeps the seam to whatever the producer chose to publish. ## What it actually does at plan time The data source reads the remote state **object** directly using the consumer's own credentials. It does not call the producing team's pipeline, and it does not take the producer's state lock — it is a plain read. Two consequences follow. First, permissions. For an S3 backend the consumer's role needs `s3:GetObject` on that state key, plus `kms:Decrypt` if the bucket is encrypted with a customer-managed key. State files contain far more than the outputs, so granting this grants read of everything recorded in the producer's state, including attributes that are secret in practice. Sensitivity marks on outputs propagate into the consumer's plan output, but they are not an access control on the file itself. In HCP Terraform the equivalent is a workspace setting: the producing workspace must explicitly share its state with the consumer. Second, freshness. What you read is what the producer's **last apply** recorded, not what exists in the cloud right now. If someone changed the VPC out of band, or the producer has an unapplied change sitting in a pull request, the consumer happily plans against the recorded value. ## Ordering: the producer applies first Because the read has no way to say "not known yet", ordering across the seam is manual. On a green-field environment the producer must be applied before the consumer is even planned, otherwise the consumer fails with an error about a missing output. Inside a single configuration Terraform derives that ordering from the graph; across configurations, you own it — in the runbook, in the pipeline, or by bootstrapping environments in a fixed order. ## When to reach for something else The data source is the fastest thing to write, and for two configurations owned by the same team it is usually right. It becomes a poor fit when the two sides sit on opposite sides of a trust boundary, because the read is all-or-nothing on the whole state file, or when the consumer is not Terraform at all — an application or a script cannot sensibly parse someone's state. In those cases the value is normally looked up live through a provider data source by tag or name, or published deliberately to a store such as SSM Parameter Store, where the permission can be scoped to that one key.