State and real infrastructure mapping in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

How Terraform detects drift in infrastructure

Terraform keeps track of your infrastructure state. What happens when you manually change a resource outside Terraform?

Which option best describes Terraform's behavior when you run terraform plan after such a manual change?

A Terraform crashes with an error about state mismatch.

B Terraform ignores the manual change and shows no difference in the plan.

C Terraform deletes the resource automatically without warning.

D Terraform detects the difference and shows the manual change as a drift to be corrected.

💡 Hint

Think about how Terraform compares the saved state with the real infrastructure.

Terraform compares the saved state file with the real infrastructure. If it finds differences, it shows them as drift in the plan, so you can decide how to handle them.

❓ Architecture

intermediate

Best practice for remote Terraform state storage

You want to share Terraform state safely among your team and avoid state conflicts. Which remote backend is the best choice for this purpose?

A Keep the state file in a public GitHub repository.

B Store the state file locally on each developer's machine.

C Use a remote backend like AWS S3 with state locking via DynamoDB.

D Upload the state file manually to a shared email group.

💡 Hint

Think about safe sharing and preventing simultaneous edits.

Using a remote backend like AWS S3 with DynamoDB locking allows safe sharing of state and prevents concurrent changes that could corrupt the state.

❓ Configuration

advanced

Terraform state locking mechanism

Which of the following Terraform backend configurations correctly enables state locking to prevent concurrent modifications?

Terraform

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-west-2"
    # Which option enables locking?
  }
}

A Add <code>enable_locking = true</code> to enable locking.

B Add <code>dynamodb_table = "terraform-lock-table"</code> to enable locking with DynamoDB.

C Add <code>lock = true</code> to enable locking.

D Add <code>lock_table = "terraform-lock-table"</code> to enable locking.

💡 Hint

Look for the exact parameter name for DynamoDB locking in S3 backend.

The S3 backend uses a DynamoDB table for locking. The correct parameter is dynamodb_table to specify the lock table.

❓ security

advanced

Protecting sensitive data in Terraform state

Your Terraform state contains sensitive information like passwords and API keys. What is the best way to protect this data in the state file?

A Encrypt the state file at rest using backend encryption features.

B Store sensitive data in plain text variables inside the state file.

C Remove sensitive data from Terraform configuration completely.

D Store the state file unencrypted but restrict file permissions only.

💡 Hint

Think about encryption and backend capabilities.

Encrypting the state file at rest using backend features (like S3 encryption) protects sensitive data from unauthorized access.

🧠 Conceptual

expert

Terraform state refresh behavior

After running terraform apply, you manually delete a resource in the cloud provider console. What will happen when you run terraform plan next?

A Terraform will show the resource as needing to be created again to match the state file.

B Terraform will ignore the missing resource and show no changes.

C Terraform will delete the resource from the state file automatically.

D Terraform will crash with an error about missing resource.

💡 Hint

Think about how Terraform compares state with real infrastructure.

Terraform detects that the resource is missing in the real infrastructure but present in the state file, so it plans to recreate it to match the state.

Practice

1. What is the main purpose of the Terraform state file?

easy

A. To keep track of real infrastructure resources Terraform manages

B. To store user credentials for cloud providers

C. To define the desired infrastructure configuration

D. To log errors during Terraform runs

Solution

1. Step 1: Understand Terraform state role

   The state file records what resources Terraform has created or manages in the real world.

2. Step 2: Differentiate state from config and logs

   The configuration defines desired setup, but state tracks actual deployed resources. Credentials and logs are separate concerns.

3. Final Answer:

   To keep track of real infrastructure resources Terraform manages -> Option A

4. Quick Check:

   State tracks real resources [OK]

Hint: State file = Terraform's memory of real resources [OK]

Common Mistakes:

• Confusing state file with configuration files
• Thinking state stores credentials
• Assuming state logs errors

2. Which Terraform command shows the current state of resources managed by Terraform?

easy

A. terraform init

B. terraform plan

C. terraform apply

D. terraform state list

Solution

1. Step 1: Identify command to inspect state

   "terraform state list" displays all resources tracked in the current state file.

2. Step 2: Differentiate from other commands

   "terraform plan" previews changes, "apply" makes changes, "init" sets up backend and providers.

3. Final Answer:

   terraform state list -> Option D

4. Quick Check:

   State inspection command = terraform state list [OK]

Hint: Use 'terraform state list' to see tracked resources [OK]

Common Mistakes:

• Using 'terraform plan' to check state directly
• Confusing 'terraform apply' with state inspection
• Thinking 'terraform init' shows state

3. Given this Terraform state snippet showing one AWS instance resource:

{
  "resources": [
    {
      "type": "aws_instance",
      "name": "web",
      "instances": [
        {"attributes": {"id": "i-1234567890abcdef0", "ami": "ami-0abc1234", "instance_type": "t2.micro"}}
      ]
    }
  ]
}

What is the instance type Terraform currently tracks for this resource?

medium

A. t2.micro

B. ami-0abc1234

C. i-1234567890abcdef0

D. aws_instance

Solution

1. Step 1: Locate instance_type attribute in state

   The attribute "instance_type" has value "t2.micro" in the resource's attributes.

2. Step 2: Understand attribute meanings

   "ami" is the image ID, "id" is the instance ID, "type" is resource type, so only "instance_type" matches the question.

3. Final Answer:

   t2.micro -> Option A

4. Quick Check:

   Instance type in state = t2.micro [OK]

Hint: Look for 'instance_type' attribute in state JSON [OK]

Common Mistakes:

• Confusing AMI ID with instance type
• Picking resource type as instance type
• Choosing instance ID instead of type

4. You ran terraform apply but your real infrastructure changed outside Terraform. What should you do to fix the state mismatch?

medium

A. Run terraform destroy to remove all resources

B. Run terraform refresh to update the state file with real resource data

C. Manually edit the state file to match real resources

D. Delete the state file and run terraform init again

Solution

1. Step 1: Understand state drift problem

   When real resources change outside Terraform, state file becomes outdated and causes mismatch.

2. Step 2: Use terraform refresh to sync state

   "terraform refresh" updates the state file to reflect current real infrastructure without changing resources.

3. Final Answer:

   Run terraform refresh to update the state file with real resource data -> Option B

4. Quick Check:

   Sync state with real infra = terraform refresh [OK]

Hint: Use 'terraform refresh' to sync state with real resources [OK]

Common Mistakes:

• Deleting state file causes loss of tracking
• Editing state file manually risks corruption
• Destroying resources is unnecessary for state fix

5. You want to share your Terraform state securely among your team using a remote backend. Which approach best ensures state consistency and safety?

hard

A. Email the state file to team members after each change

B. Store the state file on a shared network drive without locking

C. Use a remote backend like AWS S3 with state locking via DynamoDB

D. Keep the state file local on each developer's machine

Solution

1. Step 1: Identify remote backend with locking

   A remote backend like AWS S3 combined with DynamoDB locking prevents simultaneous edits and keeps state consistent.

2. Step 2: Evaluate other options for safety

   Shared drives without locking risk conflicts, emailing state causes version confusion, local files prevent collaboration.

3. Final Answer:

   Use a remote backend like AWS S3 with state locking via DynamoDB -> Option C

4. Quick Check:

   Remote backend + locking = safe shared state [OK]

Hint: Use remote backend with locking for team state safety [OK]

Common Mistakes:

• Ignoring state locking leads to conflicts
• Sharing state by email causes outdated copies
• Local state prevents team collaboration