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.