Remote state data source for cross-project in Terraform - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a remote state data source using Terraform.

Terraform

data "terraform_remote_state" "example" {
  backend = "[1]"
  config = {
    bucket = "my-terraform-state"
    key    = "state.tfstate"
    region = "us-west-2"
  }
}

Drag options to blanks, or click blank then click option'

As3

Blocal

Cgcs

Dazurerm

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'local' instead of 's3' for remote state backend.

Confusing 'gcs' (Google Cloud Storage) with AWS S3.

The backend specifies the remote state storage type. For AWS S3, use s3.

2fill in blank

medium

Complete the code to reference the remote state output named 'vpc_id'.

Terraform

output "vpc_id" {
  value = data.terraform_remote_state.example.[1][0]
}

Drag options to blanks, or click blank then click option'

Avpc_id

Boutputs.vpc_id

Coutputs["vpc_id"]

Doutput.vpc_id

Attempts:

3 left

💡 Hint

Common Mistakes

Using dot notation directly on outputs which is invalid.

Trying to access output without referencing 'outputs' map.

Remote state outputs are accessed as a map using bracket notation, e.g., outputs["vpc_id"].

3fill in blank

hard

Fix the error in the remote state data source block to correctly specify the S3 bucket region.

Terraform

data "terraform_remote_state" "example" {
  backend = "s3"
  config = {
    bucket = "my-terraform-state"
    key    = "state.tfstate"
    region = "[1]"
  }
}

Drag options to blanks, or click blank then click option'

Aus-east-1

Bus-west-2

Cus-west-3

Deu-central-1

Attempts:

3 left

💡 Hint

Common Mistakes

Using a non-existent AWS region.

Typos in the region string.

The correct AWS region for the bucket is us-west-2. Using an invalid region like 'us-west-3' causes errors.

4fill in blank

hard

Fill both blanks to configure the remote state data source for a Google Cloud Storage bucket.

Terraform

data "terraform_remote_state" "example" {
  backend = "[1]"
  config = {
    bucket = "my-gcs-bucket"
    prefix = "[2]"
  }
}

Drag options to blanks, or click blank then click option'

Agcs

Bs3

Cterraform/state

Dstate

Attempts:

3 left

💡 Hint

Common Mistakes

Using 's3' backend for GCS bucket.

Leaving prefix empty or incorrect.

For Google Cloud Storage, the backend is gcs. The prefix is the folder path inside the bucket, e.g., terraform/state.

5fill in blank

hard

Fill all three blanks to correctly reference a remote state output named 'subnet_ids' from an Azure backend.

Terraform

data "terraform_remote_state" "example" {
  backend = "[1]"
  config = {
    resource_group_name  = "myResourceGroup"
    storage_account_name = "mystorageaccount"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
  }
}

output "subnet_ids" {
  value = data.terraform_remote_state.example.[2][[3]]
}

Drag options to blanks, or click blank then click option'

Aazurerm

Boutputs

C"subnet_ids"

Dsubnet_ids

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong backend name like 's3' for Azure.

Accessing outputs without quotes around keys.

The backend for Azure is azurerm. Remote state outputs are accessed via the outputs map, and keys must be quoted strings like "subnet_ids".

Practice

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