Terraform.workspace interpolation - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding workspace interpolation in resource naming

Given the Terraform configuration below, what will be the name of the AWS S3 bucket created when the workspace is production?

Terraform

resource "aws_s3_bucket" "example" {
  bucket = "myapp-${terraform.workspace}-bucket"
  acl    = "private"
}

A myapp-production-bucket

B myapp-bucket-production

C myapp-default-bucket

D myapp-bucket

💡 Hint

Remember that terraform.workspace returns the current workspace name exactly as it is.

The terraform.workspace interpolation inserts the current workspace name into the bucket name. Since the workspace is production, the bucket name becomes myapp-production-bucket.

❓ Architecture

intermediate

Workspace usage in environment-specific infrastructure

You want to deploy separate AWS VPCs for dev and prod environments using Terraform workspaces. Which configuration snippet correctly uses terraform.workspace to create unique VPC CIDR blocks for each workspace?

A cidr_block = terraform.workspace ? "10.0.0.0/16" : "10.1.0.0/16"

B cidr_block = "10.${terraform.workspace}.0.0/16"

C cidr_block = terraform.workspace == "prod" ? "10.0.0.0/16" : "10.1.0.0/16"

D cidr_block = "10.0.0.0/16"

💡 Hint

Use a conditional expression to select CIDR blocks based on workspace name.

Option C uses a conditional expression to assign different CIDR blocks for prod and other workspaces. Option C is invalid because you cannot interpolate a string directly into an IP address like that. Option C uses a fixed CIDR block, ignoring workspace. Option C uses an invalid conditional syntax.

❓ security

advanced

Preventing workspace name leakage in resource tags

Consider a Terraform configuration that tags AWS resources with the current workspace name using terraform.workspace. What is a potential security risk of this practice?

A Workspace names might reveal sensitive environment details to unauthorized users via resource metadata.

B Using terraform.workspace in tags causes Terraform to fail during plan.

C Workspace interpolation encrypts the workspace name, preventing any risk.

D There is no risk; workspace names are always safe to expose.

💡 Hint

Think about what information resource tags can expose to users with access to cloud resources.

Tagging resources with workspace names can expose environment details (like 'prod' or 'dev') to anyone who can view resource metadata, which might be sensitive information. Options B, C, and D are incorrect because they misunderstand the behavior or risk.

❓ Configuration

advanced

Correct use of terraform.workspace in backend configuration

Which backend configuration snippet correctly uses terraform.workspace to create separate state files per workspace in an S3 backend?

A key = "state/terraform.tfstate"

B key = "state/terraform.workspace/terraform.tfstate"

C key = "state/${workspace}/terraform.tfstate"

D key = "state/${terraform.workspace}/terraform.tfstate"

💡 Hint

Use interpolation syntax to insert the workspace name dynamically.

Option D correctly uses ${terraform.workspace} to interpolate the current workspace name into the key path, creating separate state files per workspace. Option D treats terraform.workspace as a literal string. Option D uses an undefined variable workspace. Option D does not separate states by workspace.

✅ Best Practice

expert

Handling workspace interpolation in module calls for multi-environment setups

You have a Terraform module that creates resources and you want to deploy it in multiple workspaces. Which approach correctly passes the workspace name to the module to customize resource names?

Terraform

module "app" {
  source = "./modules/app"
  env    = terraform.workspace
}

A Use terraform.workspace only inside the root module; modules cannot access it.

B Pass terraform.workspace as a variable to the module and use it inside the module for naming.

C Hardcode the workspace name inside the module to avoid passing variables.

D Set env = "default" in the module call and ignore workspace.

💡 Hint

Modules can receive variables from the root module, including workspace names.

Option B is correct because passing terraform.workspace as a variable allows the module to customize resources per environment. Option B is false; modules can receive variables. Option B is inflexible and breaks multi-environment use. Option B ignores workspace, defeating the purpose.

Practice

1. What does terraform.workspace return when used inside a Terraform configuration?

easy

A. The name of the current workspace as a string

B. The current Terraform version

C. The list of all workspaces

D. The current directory path

Solution

1. Step 1: Understand the purpose of terraform.workspace

   terraform.workspace is a built-in Terraform variable that returns the name of the workspace currently in use.

2. Step 2: Identify what terraform.workspace returns

   It returns a string representing the workspace name, which helps differentiate environments.

3. Final Answer:

   The name of the current workspace as a string -> Option A

4. Quick Check:

   terraform.workspace = current workspace name [OK]

Hint: Remember: terraform.workspace always gives current workspace name [OK]

Common Mistakes:

• Thinking it returns Terraform version
• Confusing it with list of all workspaces
• Assuming it returns file paths

2. Which of the following is the correct syntax to use terraform.workspace inside a resource name in Terraform?

easy

A. name = myapp.${terraform.workspace}

B. name = "myapp-${terraform.workspace}"

C. name = 'myapp-terraform.workspace'

D. name = "myapp.terraform.workspace"

Solution

1. Step 1: Understand string interpolation syntax in Terraform

   Terraform uses ${} inside double quotes to insert variable values into strings.

2. Step 2: Identify correct usage of terraform.workspace

   The correct syntax is "myapp-${terraform.workspace}" to append the workspace name.

3. Final Answer:

   name = "myapp-${terraform.workspace}" -> Option B

4. Quick Check:

   Use ${} inside double quotes for interpolation [OK]

Hint: Use ${terraform.workspace} inside double quotes for interpolation [OK]

Common Mistakes:

• Using single quotes which disable interpolation
• Missing ${} around terraform.workspace
• Using dot notation without quotes

3. Given the Terraform code snippet:

output "env_name" {
  value = "Current workspace is: ${terraform.workspace}"
}

If the active workspace is staging, what will be the output value?

medium

A. An error occurs because output cannot use terraform.workspace

B. "Current workspace is: default"

C. "Current workspace is: production"

D. "Current workspace is: staging"

Solution

1. Step 1: Understand output interpolation with terraform.workspace

   The output value uses string interpolation to insert the current workspace name.

2. Step 2: Substitute the active workspace name

   Since the active workspace is staging, the output string becomes "Current workspace is: staging".

3. Final Answer:

   "Current workspace is: staging" -> Option D

4. Quick Check:

   Output string includes current workspace name [OK]

Hint: Replace ${terraform.workspace} with active workspace name [OK]

Common Mistakes:

• Assuming default workspace always
• Thinking terraform.workspace cannot be used in outputs
• Confusing workspace names

4. You wrote this Terraform resource name:

resource "aws_s3_bucket" "example" {
  bucket = 'mybucket-${terraform.workspace}'
}

But when you run Terraform, you get an error: Invalid reference. What is the likely cause?

medium

A. terraform.workspace is not available in resource blocks

B. terraform.workspace must be assigned to a variable first

C. You used single quotes instead of double quotes around the bucket name

D. You forgot to initialize Terraform workspaces

Solution

1. Step 1: Check string interpolation rules in Terraform

   Terraform requires double quotes for string interpolation; single quotes treat content as literal.

2. Step 2: Identify the error cause

   If single quotes were used, ${terraform.workspace} is not evaluated, causing an invalid reference error.

3. Final Answer:

   You used single quotes instead of double quotes around the bucket name -> Option C

4. Quick Check:

   Use double quotes for interpolation [OK]

Hint: Always use double quotes for strings with ${} interpolation [OK]

Common Mistakes:

• Using single quotes disables interpolation
• Assuming terraform.workspace needs variable assignment
• Not initializing workspaces but error is different

5. You want to create two S3 buckets using the same Terraform code but different names per workspace. You write:

resource "aws_s3_bucket" "bucket1" {
  bucket = "app-${terraform.workspace}"
}

resource "aws_s3_bucket" "bucket2" {
  bucket = "app-${terraform.workspace}"
}

What problem will occur when you apply this configuration in the dev workspace?

hard

A. Terraform will create two buckets with the same name, causing a conflict

B. Terraform will create only one bucket named "app-dev"

C. Terraform will fail because terraform.workspace cannot be used twice

D. Terraform will create buckets with different names automatically

Solution

1. Step 1: Analyze bucket names generated

   Both resources use the same bucket name pattern: "app-${terraform.workspace}". In the dev workspace, both names become "app-dev".

2. Step 2: Understand AWS S3 bucket naming constraints

   S3 bucket names must be unique globally. Creating two buckets with the same name causes a conflict error.

3. Final Answer:

   Terraform will create two buckets with the same name, causing a conflict -> Option A

4. Quick Check:

   Duplicate resource names cause conflicts [OK]

Hint: Ensure unique names per resource even with terraform.workspace [OK]

Common Mistakes:

• Assuming terraform.workspace makes names unique per resource
• Thinking Terraform merges resources automatically
• Believing terraform.workspace cannot be used multiple times