Terraform_remote_state usage - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Terraform remote state data source

What does the terraform_remote_state data source in Terraform allow you to do?

A It creates a backup of the Terraform state file before every apply.

B It automatically synchronizes multiple Terraform state files into one.

C It allows you to access outputs from another Terraform configuration's state file.

D It encrypts the Terraform state file for security purposes.

💡 Hint

Think about how Terraform can share information between separate projects.

The terraform_remote_state data source lets one Terraform configuration read outputs from another configuration's state file, enabling resource sharing.

❓ Configuration

intermediate

Correct usage of terraform_remote_state with S3 backend

Which Terraform code snippet correctly configures terraform_remote_state to read from an S3 backend named prod-state in region us-west-2?

A

data "terraform_remote_state" "prod" {
  backend = "s3"
  bucket = "prod-state"
  region = "us-west-2"
}

B

data "terraform_remote_state" "prod" {
  backend = "s3"
  config = {
    bucket = "prod-state"
    region = "us-west-2"
  }
}

C

terraform_remote_state "prod" {
  backend = "s3"
  config = {
    bucket = "prod-state"
    region = "us-west-2"
  }
}

D

data "terraform_remote_state" "prod" {
  backend = "s3"
  config = {
    bucket = "prod-state"
    region = "us-east-1"
  }
}

💡 Hint

Remember the correct block type and where to put backend configuration.

The terraform_remote_state data source requires a data block with backend and config map specifying bucket and region. Region must match the actual bucket location.

❓ Architecture

advanced

Best practice for sharing remote state outputs securely

You have multiple Terraform projects that need to share outputs securely using terraform_remote_state. Which approach is best to ensure security and least privilege?

A Use separate S3 buckets for each project with bucket policies granting read access only to specific IAM roles used by consuming projects.

B Store all state files in a single S3 bucket with public read access and use <code>terraform_remote_state</code> to read outputs.

C Store state files locally on developer machines and share outputs via manual copy-paste.

D Use a single S3 bucket with no access restrictions and rely on Terraform to handle security.

💡 Hint

Think about controlling who can read state files and limiting exposure.

Using separate buckets with strict IAM policies limits access to only authorized projects, following least privilege and improving security.

❓ service_behavior

advanced

Effect of changing remote state backend configuration

What happens if you change the backend configuration of a terraform_remote_state data source from S3 to local without updating the actual state files?

A Terraform will ignore the backend change and continue reading from S3.

B Terraform will successfully read the remote state from the local path without errors.

C Terraform will automatically migrate the remote state from S3 to local backend.

D Terraform will raise an error because the local path does not contain the expected state file.

💡 Hint

Consider what happens if the backend points to a location without the expected state.

Changing backend to local requires the state file to exist locally. If it doesn't, Terraform errors because it cannot find the state.

❓ security

expert

Preventing sensitive data exposure in terraform_remote_state outputs

You want to use terraform_remote_state to share outputs but avoid exposing sensitive values like passwords. Which Terraform practice ensures sensitive outputs are not exposed?

A Mark sensitive outputs with <code>sensitive = true</code> in the producing module and avoid referencing them in consuming modules.

B Encrypt the entire state file manually before storing it in the backend.

C Store sensitive outputs in plain text but restrict access to the backend bucket.

D Use <code>terraform_remote_state</code> to read all outputs and filter sensitive ones in the consuming module.

💡 Hint

Think about Terraform's built-in way to mark outputs as sensitive.

Marking outputs as sensitive prevents Terraform from showing them in CLI or logs and discourages referencing them in other modules, reducing exposure risk.