Bird
Raised Fist0
Terraformcloud~10 mins

Remote state data source for cross-project in Terraform - Step-by-Step Execution

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Process Flow - Remote state data source for cross-project
Start Terraform config
Define remote state backend
Terraform stores state remotely
In another project, define data source
Terraform reads remote state data
Use remote state outputs in current config
Apply configuration with cross-project data
Terraform stores state remotely in one project and reads it from another using a remote state data source to share outputs.
Execution Sample
Terraform
data "terraform_remote_state" "network" {
  backend = "gcs"
  config = {
    bucket = "network-state-bucket"
    prefix = "terraform/state"
  }
}

output "network_vpc_id" {
  value = data.terraform_remote_state.network.outputs.vpc_id
}
This code reads the remote state from a Google Cloud Storage bucket in another project and outputs the VPC ID.
Process Table
StepActionEvaluationResult
1Terraform reads local configDetects remote state data sourcePrepares to fetch remote state
2Connect to GCS bucket 'network-state-bucket'Access remote state file at 'terraform/state'Remote state file found and read
3Parse remote state JSONExtract outputs.vpc_idvpc_id value obtained (e.g., 'vpc-12345')
4Assign output 'network_vpc_id'Set to remote vpc_id valueOutput ready for use in current project
5Apply configurationUse output value in resourcesResources configured with remote VPC ID
6EndNo errorsCross-project remote state data successfully used
💡 Remote state data source successfully fetched and used for cross-project reference
Status Tracker
VariableStartAfter Step 3Final
data.terraform_remote_state.network.outputs.vpc_idundefinedvpc-12345vpc-12345
output.network_vpc_idundefinedundefinedvpc-12345
Key Moments - 3 Insights
Why do we need to specify the backend and config in the remote state data source?
Because Terraform needs to know where and how to access the remote state file. The backend and config tell it the storage location and path, as shown in execution_table step 2.
What happens if the remote state file is missing or inaccessible?
Terraform will fail to read the remote state and throw an error during planning or applying, stopping the process before step 4 in the execution_table.
Can outputs from the remote state be used directly in resource definitions?
Yes, once Terraform reads the remote outputs (step 3), they can be referenced in resource configurations as shown in step 5.
Visual Quiz - 3 Questions
Test your understanding
Look at the execution table, at which step does Terraform obtain the remote output value?
AStep 2
BStep 3
CStep 4
DStep 5
💡 Hint
Check the 'Evaluation' column for when outputs.vpc_id is extracted.
According to the variable tracker, what is the value of 'output.network_vpc_id' after step 3?
Avpc-12345
Bnull
Cundefined
Dempty string
💡 Hint
Look at the 'After Step 3' column for 'output.network_vpc_id' in variable_tracker.
If the GCS bucket name in the config is changed, which step in the execution table would fail?
AStep 2
BStep 1
CStep 3
DStep 4
💡 Hint
Step 2 involves connecting to the GCS bucket; changing the bucket name affects this step.
Concept Snapshot
Terraform remote state data source:
- Use 'terraform_remote_state' data block
- Specify backend and config to locate remote state
- Access outputs from remote state
- Enables sharing data across projects
- Must have read access to remote state storage
Full Transcript
This visual execution shows how Terraform uses a remote state data source to read outputs from another project's state file stored remotely, such as in a Google Cloud Storage bucket. The flow starts with Terraform reading the local config, then connecting to the remote backend to fetch the state file. It parses the state to extract outputs like VPC ID, assigns these to local outputs, and uses them in resource definitions. Variables track the output value as it becomes available. Key moments clarify why backend config is needed, what happens if remote state is missing, and how outputs are used. The quiz tests understanding of when values are obtained and what happens if config changes.

Practice

(1/5)
1. What is the main purpose of using a terraform_remote_state data source in Terraform?
easy
A. To store Terraform state files locally
B. To access outputs from another Terraform project's state
C. To create new resources in a different cloud provider
D. To encrypt Terraform state files automatically

Solution

  1. Step 1: Understand remote state data source role

    The terraform_remote_state data source allows one Terraform configuration to read outputs from another configuration's state file.
  2. Step 2: Differentiate from other options

    It does not store state locally, create new resources, or encrypt state automatically; it only reads existing state outputs.
  3. Final Answer:

    To access outputs from another Terraform project's state -> Option B
  4. Quick Check:

    Remote state data source = Access outputs [OK]
Hint: Remote state data source reads outputs from other projects [OK]
Common Mistakes:
  • Confusing remote state with local state storage
  • Thinking it creates resources instead of reading state
  • Assuming it encrypts state automatically
2. Which of the following is the correct syntax to define a terraform_remote_state data source for a backend stored in an S3 bucket named my-terraform-state?
easy
A. data "terraform_remote_state" "example" { backend = "local" config = { path = "my-terraform-state" } }
B. resource "terraform_remote_state" "example" { backend = "s3" bucket = "my-terraform-state" }
C. terraform_remote_state "example" { backend = "s3" bucket = "my-terraform-state" }
D. data "terraform_remote_state" "example" { backend = "s3" config = { bucket = "my-terraform-state" key = "state.tfstate" region = "us-east-1" } }

Solution

  1. Step 1: Identify correct resource type and syntax

    The terraform_remote_state must be declared as a data block, not a resource.
  2. Step 2: Check backend and config structure

    For S3 backend, the config requires bucket, key, and region inside a config map.
  3. Final Answer:

    data "terraform_remote_state" "example" { backend = "s3" config = { bucket = "my-terraform-state" key = "state.tfstate" region = "us-east-1" } } -> Option D
  4. Quick Check:

    Correct syntax = data "terraform_remote_state" "example" { backend = "s3" config = { bucket = "my-terraform-state" key = "state.tfstate" region = "us-east-1" } } [OK]
Hint: Use data block with backend and config map for remote state [OK]
Common Mistakes:
  • Using resource instead of data block
  • Missing required config keys like key or region
  • Using wrong backend type like local for S3
3. Given this Terraform snippet accessing remote state:
data "terraform_remote_state" "network" {
  backend = "gcs"
  config = {
    bucket = "tf-state-bucket"
    prefix = "network"
  }
}

output "vpc_id" {
  value = data.terraform_remote_state.network.outputs.vpc_id
}

What will output.vpc_id contain?
medium
A. The entire remote state file content as a string
B. An error because prefix is not a valid config key for GCS backend
C. The VPC ID output from the remote state stored in the GCS bucket under prefix 'network'
D. Null because outputs cannot be accessed from remote state

Solution

  1. Step 1: Understand remote state data source usage

    The data source reads the remote state from the GCS bucket with the given prefix, making outputs available.
  2. Step 2: Confirm output access

    The output vpc_id is accessed correctly via data.terraform_remote_state.network.outputs.vpc_id, so it returns the VPC ID value.
  3. Final Answer:

    The VPC ID output from the remote state stored in the GCS bucket under prefix 'network' -> Option C
  4. Quick Check:

    Remote output access = VPC ID value [OK]
Hint: Remote state outputs accessed via data.<name>.outputs.<key> [OK]
Common Mistakes:
  • Confusing prefix usage for GCS backend (it is valid)
  • Expecting entire state file instead of outputs
  • Assuming outputs cannot be read remotely
4. You have this Terraform remote state data source:
data "terraform_remote_state" "app" {
  backend = "azurerm"
  config = {
    resource_group_name = "rg-state"
    storage_account_name = "stterraform"
    container_name = "tfstate"
    key = "app.terraform.tfstate"
  }
}

When running terraform plan, you get an error: Failed to load remote state. What is the most likely cause?
medium
A. Incorrect or missing permissions to access the Azure storage account
B. The backend type should be s3 instead of azurerm
C. The key parameter is not supported in azurerm backend
D. Terraform remote state data source cannot be used with Azure

Solution

  1. Step 1: Verify backend and config correctness

    The backend azurerm with given config keys is valid for Azure Blob Storage remote state.
  2. Step 2: Identify common causes of load failure

    Most common cause is missing or incorrect permissions to access the storage account or container.
  3. Final Answer:

    Incorrect or missing permissions to access the Azure storage account -> Option A
  4. Quick Check:

    Access permissions issue = Load failure [OK]
Hint: Check storage permissions if remote state load fails [OK]
Common Mistakes:
  • Assuming backend type is wrong when it is correct
  • Thinking key parameter is unsupported in azurerm backend
  • Believing remote state cannot be used with Azure
5. You manage two Terraform projects: network and app. The network project stores its state remotely in an S3 bucket with key network/terraform.tfstate. You want the app project to use the VPC ID output from network. Which configuration correctly sets up the remote state data source in app to access network outputs securely and follows best practices?
hard
A. data "terraform_remote_state" "network" { backend = "s3" config = { bucket = "my-tf-state-bucket" key = "network/terraform.tfstate" region = "us-west-2" } }
B. data "terraform_remote_state" "network" { backend = "s3" config = { bucket = "my-tf-state-bucket" key = "app/terraform.tfstate" region = "us-west-2" } }
C. data "terraform_remote_state" "network" { backend = "local" config = { path = "../network/terraform.tfstate" } }
D. resource "terraform_remote_state" "network" { backend = "s3" config = { bucket = "my-tf-state-bucket" key = "network/terraform.tfstate" region = "us-west-2" } }

Solution

  1. Step 1: Confirm correct backend and key for remote state

    The remote state is stored in S3 bucket with key network/terraform.tfstate, so the data source must match this.
  2. Step 2: Ensure data source type and security best practices

    Use a data block (not resource) with backend = "s3", specify region, and avoid incorrect keys.
  3. Final Answer:

    Data source with backend s3, correct bucket/key, and region -> Option A
  4. Quick Check:

    Correct backend and secure config = data "terraform_remote_state" "network" { backend = "s3" config = { bucket = "my-tf-state-bucket" key = "network/terraform.tfstate" region = "us-west-2" } } [OK]
Hint: Match backend/key exactly and use data block [OK]
Common Mistakes:
  • Using wrong key path for remote state
  • Using resource block instead of data block
  • Using local backend instead of remote S3
  • Omitting region config