Remote state data source for cross-project in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding remote state data source usage

What is the primary purpose of using a terraform_remote_state data source in a cross-project setup?

A To share outputs from one Terraform project with another securely and reliably.

B To encrypt Terraform state files using a custom key.

C To automatically backup Terraform state files to a local machine.

D To deploy resources in multiple cloud providers simultaneously.

💡 Hint

Think about how Terraform projects can communicate or share information.

The terraform_remote_state data source allows one Terraform configuration to access the outputs of another configuration's state, enabling cross-project data sharing.

❓ Configuration

intermediate

Correct remote state data source configuration

Which of the following Terraform code snippets correctly configures a remote state data source to read outputs from a different project stored in an S3 backend?

A

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

B

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

C

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

D

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

💡 Hint

Check the syntax for declaring a data source and the backend configuration.

The correct syntax uses data "terraform_remote_state" "name" with a backend and a config block specifying bucket, key, and region.

❓ Architecture

advanced

Cross-project remote state access architecture

In a multi-project Terraform setup, what is the best architectural practice to ensure secure and reliable access to remote state data across projects?

A Store all Terraform states in a single shared backend bucket with strict IAM policies limiting access per project.

B Use local state files and manually copy outputs between projects to avoid backend complexity.

C Allow all projects to use the same AWS IAM role with full access to all state files for simplicity.

D Store state files in separate buckets without any access restrictions to speed up deployments.

💡 Hint

Think about security and access control when multiple projects share state data.

Using a single shared backend bucket with strict IAM policies ensures centralized management and secure access control, preventing unauthorized access while enabling cross-project data sharing.

❓ service_behavior

advanced

Behavior of remote state data source on state changes

What happens to the terraform_remote_state data source when the remote state it references is updated by another project?

A Terraform requires deleting the local state file to detect changes in the remote state.

B Terraform caches the remote state permanently and never updates it unless manually refreshed.

C Terraform fetches the latest remote state data during the next plan or apply operation automatically.

D Terraform throws an error if the remote state changes between runs to prevent inconsistencies.

💡 Hint

Consider how Terraform keeps data sources up to date during runs.

Terraform automatically fetches the latest remote state data during plan or apply, ensuring it uses current outputs from the referenced project.

❓ security

expert

Preventing unauthorized access to remote state in cross-project setups

Which IAM policy configuration best prevents unauthorized access to a Terraform remote state stored in an S3 bucket used by multiple projects?

A

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:*"],
    "Resource": "arn:aws:s3:::terraform-states/*"
  }]
}

B

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::terraform-states/project-a/*",
    "Condition": {
      "StringEquals": {"aws:PrincipalTag/Project": "project-a"}
    }
  }]
}

C

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::terraform-states/project-b/*"
  }]
}

D

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::terraform-states/*"
  }]
}

💡 Hint

Focus on restricting access by project tags and resource paths.

Option B restricts access to only objects under the project-a prefix and requires the IAM principal to have a matching project tag, enforcing least privilege.