Workspaces and remote state in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Terraform Workspaces

What is the primary purpose of Terraform workspaces?

A To store Terraform configuration files remotely for team collaboration.

B To encrypt sensitive variables in Terraform configurations.

C To automatically back up state files to cloud storage.

D To manage multiple distinct state files within the same configuration, allowing isolated environments like dev and prod.

💡 Hint

Think about how Terraform separates environments using the same code.

Terraform workspaces allow you to use the same configuration but keep separate state files for different environments or instances.

❓ Configuration

intermediate

Remote State Backend Configuration

Which backend configuration snippet correctly sets up Terraform to use an AWS S3 bucket for remote state storage with state locking?

A

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
    dynamodb_table = "terraform-lock"
    encrypt = true
  }
}

B

terraform {
  backend "local" {
    path = "./terraform.tfstate"
  }
}

C

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
    encrypt = false
  }
}

D

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
    dynamodb_table = ""
    encrypt = true
  }
}

💡 Hint

Look for the option that includes state locking and encryption.

Option A correctly configures the S3 backend with encryption and DynamoDB table for state locking, which prevents concurrent state modifications.

❓ Architecture

advanced

Choosing Workspace Strategy for Multiple Environments

You have a Terraform configuration for a web app. You want to deploy it to dev, staging, and production environments. Which approach best uses Terraform workspaces to manage these environments?

A Create three workspaces named dev, staging, and prod. Use the same configuration and switch workspaces to deploy to each environment.

B Create separate Terraform configurations for each environment and use only the default workspace.

C Use a single workspace and pass environment variables to differentiate environments during deployment.

D Use local state files for each environment and avoid workspaces.

💡 Hint

Think about how workspaces isolate state but share configuration.

Using separate workspaces for each environment allows you to reuse the same configuration while keeping state isolated per environment.

❓ security

advanced

Securing Remote State Access

Which practice best secures access to Terraform remote state stored in an AWS S3 bucket?

A Store the state file locally and share it via email to avoid cloud exposure.

B Make the S3 bucket public so all team members can access the state file easily.

C Use IAM policies to restrict access to the S3 bucket and DynamoDB table only to authorized users and roles.

D Disable encryption on the S3 bucket to improve performance.

💡 Hint

Consider AWS best practices for securing sensitive data.

Restricting access with IAM policies ensures only authorized users can read or modify the remote state, protecting sensitive infrastructure data.

❓ service_behavior

expert

Effect of Workspace Switch on Terraform State

Given a Terraform configuration with multiple workspaces, what happens to the state when you run terraform workspace select staging?

A Terraform deletes the current workspace state and replaces it with the 'staging' workspace state.

B Terraform switches to the 'staging' workspace and loads its separate state file, isolating resources from other workspaces.

C Terraform ignores the workspace switch and continues using the default workspace state.

D Terraform merges the 'staging' workspace state with the default workspace state into a single file.

💡 Hint

Think about how workspaces isolate state files.

Switching workspaces loads the state specific to that workspace, keeping resources isolated per environment.

Practice

1. What is the main purpose of Terraform workspaces?

easy

A. To store Terraform state files locally on your computer

B. To manage multiple versions of infrastructure in the same configuration

C. To write Terraform code faster using templates

D. To automatically fix errors in Terraform code

Solution

1. Step 1: Understand what workspaces do

   Workspaces allow you to keep separate state files for the same Terraform configuration, so you can manage different environments or versions.

2. Step 2: Compare options

   Only To manage multiple versions of infrastructure in the same configuration correctly describes this purpose. Options B, C, and D describe unrelated features.

3. Final Answer:

   To manage multiple versions of infrastructure in the same configuration -> Option B

4. Quick Check:

   Workspaces = multiple infrastructure versions [OK]

Hint: Workspaces separate states for different environments [OK]

Common Mistakes:

• Confusing workspaces with local state storage
• Thinking workspaces speed up code writing
• Believing workspaces fix code errors automatically

2. Which command correctly switches to a Terraform workspace named prod?

easy

A. terraform workspace select prod

B. terraform switch workspace prod

C. terraform change workspace prod

D. terraform use workspace prod

Solution

1. Step 1: Recall the correct command syntax

   The correct command to switch workspaces is terraform workspace select <name>.

2. Step 2: Verify options

   Only terraform workspace select prod uses the correct command and syntax. Options B, C, and D are invalid commands.

3. Final Answer:

   terraform workspace select prod -> Option A

4. Quick Check:

   Switch workspace = terraform workspace select [OK]

Hint: Use 'terraform workspace select' to switch workspaces [OK]

Common Mistakes:

• Using 'terraform switch' instead of 'workspace select'
• Confusing workspace commands with other Terraform commands
• Omitting the 'workspace' keyword

3. Given this Terraform backend configuration snippet:

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "envs/${terraform.workspace}/terraform.tfstate"
    region = "us-east-1"
  }
}

What happens when you run terraform workspace select dev and then terraform apply?

medium

A. Terraform stores state in S3 under key 'envs/dev/terraform.tfstate'

B. Terraform stores state in S3 under key 'envs/prod/terraform.tfstate'

C. Terraform throws an error because workspace names cannot be used in backend keys

D. Terraform stores state locally instead of S3

Solution

1. Step 1: Understand backend key interpolation

   The backend key uses ${terraform.workspace} to dynamically set the state file path based on the current workspace.

2. Step 2: Apply workspace selection effect

   After selecting workspace 'dev', the key becomes 'envs/dev/terraform.tfstate', so state is stored there in S3.

3. Final Answer:

   Terraform stores state in S3 under key 'envs/dev/terraform.tfstate' -> Option A

4. Quick Check:

   Workspace name in backend key = state path [OK]

Hint: Workspace name replaces ${terraform.workspace} in backend key [OK]

Common Mistakes:

• Assuming state always stored under 'prod' key
• Thinking workspace names can't be used in backend keys
• Believing state is stored locally despite backend config

4. You run terraform init after changing the backend configuration, but get this error:
Error: Backend reinitialization required
What is the most likely cause?

medium

A. You did not run terraform init after changing backend settings

B. You have multiple state files in the same workspace

C. You switched workspaces without updating the backend

D. You changed the backend configuration but did not confirm reinitialization

Solution

1. Step 1: Understand backend reinitialization

   Changing backend settings requires Terraform to reinitialize and confirm the changes to avoid state corruption.

2. Step 2: Identify cause of error

   The error means Terraform detected backend changes but you did not confirm reinitialization during terraform init.

3. Final Answer:

   You changed the backend configuration but did not confirm reinitialization -> Option D

4. Quick Check:

   Backend change needs confirmed reinit [OK]

Hint: Confirm backend reinit after config changes with terraform init [OK]

Common Mistakes:

• Ignoring the prompt to confirm backend reinitialization
• Confusing workspace switch with backend reinit
• Assuming multiple state files cause this error

5. You want to manage separate infrastructure for dev and prod using the same Terraform code and remote backend. Which setup is best practice?

hard

A. Use one workspace and manually rename state files in the backend

B. Create two separate Terraform configurations with different backend buckets

C. Use Terraform workspaces with backend key including ${terraform.workspace} to separate state files

D. Store all state files locally and switch workspace manually

Solution

1. Step 1: Understand workspace and backend usage

   Workspaces let you use one configuration for multiple environments by separating state files using workspace names.

2. Step 2: Evaluate options for best practice

   Use Terraform workspaces with backend key including ${terraform.workspace} to separate state files uses workspaces and dynamic backend keys to keep states separate and managed centrally, which is best practice.

3. Step 3: Reject other options

   Create two separate Terraform configurations with different backend buckets duplicates code and backend unnecessarily. Use one workspace and manually rename state files in the backend risks state conflicts. Store all state files locally and switch workspace manually loses benefits of remote state.

4. Final Answer:

   Use Terraform workspaces with backend key including ${terraform.workspace} to separate state files -> Option C

5. Quick Check:

   Workspaces + dynamic backend key = best practice [OK]

Hint: Use workspaces with backend key for separate environment states [OK]

Common Mistakes:

• Duplicating configs instead of using workspaces
• Manually renaming state files causing errors
• Storing state locally losing collaboration benefits