Remote state data source in Terraform - Commands & Configuration

Introduction

When you manage infrastructure with Terraform, sometimes you need to use information from another Terraform project. The remote state data source lets you safely access that information stored in a shared place.

When you want to use outputs from one Terraform project in another without copying values manually.

When multiple teams manage different parts of infrastructure but need to share some settings.

When you want to keep your infrastructure code organized by splitting it into smaller projects.

When you want to avoid repeating the same resource definitions in different Terraform configurations.

When you want to build infrastructure that depends on resources created elsewhere.

Config File - main.tf

main.tf

terraform {
  required_version = ">= 1.0"
}

provider "aws" {
  region = "us-east-1"
}

# Access remote state from another Terraform project stored in an S3 bucket
data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "example-terraform-state"
    key    = "network/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  # Use subnet ID from remote state
  subnet_id = data.terraform_remote_state.network.outputs.subnet_id

  tags = {
    Name = "web-server"
  }
}

This file configures Terraform to use AWS in the us-east-1 region.

The terraform_remote_state data source reads the state file stored in an S3 bucket named example-terraform-state under the key network/terraform.tfstate.

The aws_instance resource creates a web server instance using an AMI and instance type. It uses the subnet_id output from the remote state to place the instance in the correct subnet.

Commands

This command initializes the Terraform working directory. It downloads the AWS provider and prepares to use the remote state data source.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding latest version of hashicorp/aws...

- Installing hashicorp/aws v4.0.0...

- Installed hashicorp/aws v4.0.0 (signed by HashiCorp)



Terraform has been successfully initialized!



You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure.

This command shows what Terraform will do. It reads the remote state to get the subnet ID and plans to create the AWS instance in that subnet.

Terminal

terraform plan

Expected Output

Refreshing Terraform state in-memory prior to plan...



An execution plan has been generated and is shown below.

Resource actions are indicated with the following symbols:

  + create



Terraform will perform the following actions:



  # aws_instance.web will be created

  + resource "aws_instance" "web" {

      + ami                          = "ami-0c55b159cbfafe1f0"

      + instance_type                = "t2.micro"

      + subnet_id                    = "subnet-12345678"

      + tags                        = {

          + "Name" = "web-server"

        }

    }



Plan: 1 to add, 0 to change, 0 to destroy.



─────────────────────────────────────────────────────────────────────────────



Note: You didn't specify an "-out" parameter to save this plan, so Terraform

can't guarantee to take exactly these actions if you run "terraform apply" later.

This command applies the planned changes and creates the AWS instance using the subnet ID from the remote state.

Terminal

terraform apply -auto-approve

Expected Output

aws_instance.web: Creating...

aws_instance.web: Still creating... [10s elapsed]

aws_instance.web: Creation complete after 15s [id=i-0abcd1234efgh5678]



Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

→

-auto-approve - Automatically approve the apply step without asking for confirmation

This command shows the subnet ID output from the remote state data source, confirming the value used.

Terminal

terraform output subnet_id

Expected Output

subnet-12345678

Key Concept

If you remember nothing else from this pattern, remember: the remote state data source lets you safely reuse outputs from another Terraform project by reading its stored state.

Common Mistakes

Using a wrong or missing backend configuration for the remote state

Terraform cannot find or read the remote state file, causing errors or missing data.

Ensure the backend config in the data source matches exactly where the remote state is stored, including bucket name, key, and region.

Trying to access outputs that do not exist in the remote state

Terraform will fail with an error because the output key is not found.

Verify the remote state project exports the outputs you want to use, and use the exact output names.

Not running terraform init after adding the remote state data source

Terraform will not download necessary plugins or configure the backend, causing failures.

Always run terraform init after changing backend or data source configurations.

Summary

Configure the terraform_remote_state data source to read another project's state from a shared backend like S3.

Use outputs from the remote state to configure resources in your current Terraform project.

Run terraform init to prepare, terraform plan to preview changes, and terraform apply to create resources using remote state data.

Practice

1.

What is the main purpose of using a terraform_remote_state data source?

easy

A. To read outputs from another Terraform state file

B. To store Terraform state remotely

C. To initialize Terraform backend configuration

D. To create new resources in a remote cloud

Solution

1. Step 1: Understand the role of terraform_remote_state

   This data source is designed to read outputs from a different Terraform state, allowing one configuration to use values from another.

2. Step 2: Differentiate from other Terraform features

   Storing state remotely or initializing backend are separate concepts; terraform_remote_state specifically reads outputs, not stores or initializes.

3. Final Answer:

   To read outputs from another Terraform state file -> Option A

4. Quick Check:

   Remote state data source = read outputs [OK]

Hint: Remote state data source reads outputs, not stores state [OK]

Common Mistakes:

• Confusing remote state data source with backend configuration
• Thinking it stores state instead of reading outputs
• Assuming it creates resources remotely

2.

Which of the following is the correct syntax to define a terraform_remote_state data source to read from an S3 backend?

data "terraform_remote_state" "example" {
  backend = "s3"
  config = {
    bucket = "my-bucket"
    key    = "path/to/terraform.tfstate"
    region = "us-west-2"
  }
}

easy

A. data "terraform_remote_state" "example" { backend = "local" config = { path = "my-bucket/path/to/terraform.tfstate" } }

B. resource "terraform_remote_state" "example" { backend = "s3" config = { bucket = "my-bucket" key = "path/to/terraform.tfstate" region = "us-west-2" } }

C. data "terraform_remote_state" "example" { backend = "s3" config = { bucket = "my-bucket" key = "path/to/terraform.tfstate" region = "us-west-2" } }

D. data "terraform_state" "example" { backend = "s3" config = { bucket = "my-bucket" key = "path/to/terraform.tfstate" region = "us-west-2" } }

Solution

1. Step 1: Identify correct resource type and backend

   The data source must be declared with data "terraform_remote_state" and backend set to "s3" for S3 remote state.

2. Step 2: Check config block correctness

   The config block must include bucket, key, and region keys correctly for S3 backend.

3. Final Answer:

   Correct syntax uses data source with backend "s3" and proper config -> Option C

4. Quick Check:

   Correct syntax = data + backend s3 + config keys [OK]

Hint: Use data "terraform_remote_state" with backend and config keys [OK]

Common Mistakes:

• Using resource instead of data block
• Wrong backend name like "local" instead of "s3"
• Misspelling data source name as "terraform_state"

3.

Given this Terraform code snippet, what will be the output of output "vpc_id"?

data "terraform_remote_state" "network" {
  backend = "local"
  config = {
    path = "../network/terraform.tfstate"
  }
}

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

medium

A. The VPC ID value from the remote state output named "vpc_id"

B. An error because local backend cannot be used with remote state data source

C. Null because outputs are not accessible from remote state

D. The entire remote state file content as a string

Solution

1. Step 1: Understand remote state data source with local backend

   The local backend can be used to read a remote state file stored locally, so the data source reads outputs from that file.

2. Step 2: Access the specific output value

   The output block references data.terraform_remote_state.network.outputs.vpc_id, which fetches the "vpc_id" output from the remote state.

3. Final Answer:

   The VPC ID value from the remote state output named "vpc_id" -> Option A

4. Quick Check:

   Remote state outputs accessible = VPC ID value [OK]

Hint: Remote state outputs accessed via data.terraform_remote_state.outputs [OK]

Common Mistakes:

• Assuming local backend is invalid for remote state data source
• Expecting entire state file instead of specific output
• Thinking outputs are inaccessible from remote state

4.

What is the likely cause of this error when using terraform_remote_state?

Error: Failed to read remote state

  on main.tf line 5, in data "terraform_remote_state" "example":
   5: data "terraform_remote_state" "example" {

Could not find state file at configured path

Given this snippet:

data "terraform_remote_state" "example" {
  backend = "local"
  config = {
    path = "../nonexistent/terraform.tfstate"
  }
}

medium

A. The backend "local" is not supported for remote state data source

B. The path to the remote state file is incorrect or file does not exist

C. Terraform version is outdated and cannot read remote state

D. The remote state file is corrupted and unreadable

Solution

1. Step 1: Analyze the error message

   The error says it could not find the state file at the configured path, indicating a missing or wrong file path.

2. Step 2: Check the config path in the data source

   The path is set to "../nonexistent/terraform.tfstate" which likely does not exist or is mistyped.

3. Final Answer:

   The path to the remote state file is incorrect or file does not exist -> Option B

4. Quick Check:

   Missing or wrong path causes file not found error [OK]

Hint: Check file path carefully for remote state data source [OK]

Common Mistakes:

• Assuming backend "local" is unsupported
• Blaming Terraform version without checking path
• Ignoring file existence and permissions

5.

You have two Terraform projects: network creates a VPC and outputs vpc_id. app needs to use that vpc_id. How should you configure app to safely get vpc_id using remote state?

// In app/main.tf

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "my-terraform-states"
    key    = "network/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_instance" "app_server" {
  subnet_id = data.terraform_remote_state.network.outputs.vpc_id
  # other config
}

What is the best practice to ensure this setup works correctly?

hard

A. Use local backend in app to avoid remote state complexity

B. Run Terraform apply in app before network to create the state file

C. Copy the VPC ID manually into app variables instead of using remote state

D. Ensure the S3 bucket and key exist and the app project has read access to the state file

Solution

1. Step 1: Verify remote state backend accessibility

   The S3 bucket and key must exist with the network project's state file, and app must have permission to read it.

2. Step 2: Understand dependency order and security

   Network must be applied first to create the state file. Using remote state avoids manual copying and keeps data consistent.

3. Final Answer:

   Ensure the S3 bucket and key exist and the app project has read access to the state file -> Option D

4. Quick Check:

   Remote state requires accessible backend and permissions [OK]

Hint: Check backend existence and permissions before using remote state [OK]

Common Mistakes:

• Running app before network causing missing state file
• Manually copying outputs causing drift
• Using local backend ignoring remote state benefits