Managing Terraform Variables and Workspaces
Fast recall
Quick revision
Core answer
Whether you know the variable precedence order, understand the limitations of workspaces, and can describe a practical multi-environment strategy.
Relying on workspaces as the primary strategy for environment isolation, which is insufficient because workspaces share the same backend and module code — separate state backends per environment are safer.
Explain the variable precedence order (env vars > .auto.tfvars > -var flags), the workspace limitations for true environment isolation, and the directory-per-environment pattern as an alternative.
Interview-ready guide
Interview answer
Terraform variables and workspaces both address the problem of reusing the same configuration across multiple environments — variables parameterize individual values, workspaces provide isolated state for the entire configuration.
Input variables
- Variables are declared in
variables.tfwith a type, optional description, optional default, and optional validation rules —type = string,type = number,type = list(string), andtype = object({...})give the HCL parser enough information to catch type errors before a plan runs - Pass variable values via:
.tfvarsfiles (terraform.tfvarsauto-loads,production.tfvarsrequires-var-file=production.tfvars), environment variables (TF_VAR_instance_type=t3.large), or-varflags on the command line - Mark sensitive variables with
sensitive = true— Terraform redacts them in plan and apply output and does not write them to logs; they still appear in state (which must itself be encrypted and access-restricted)
Locals — computed values without input
locals { environment_prefix = "${var.environment}-${var.region}" }computes derived values from variables or resource attributes — referenced aslocal.environment_prefix; locals reduce repetition when the same computed expression appears in multiple places- Unlike variables, locals cannot be overridden from outside — they are internal calculations; use them for constants and transformations, not for values that callers need to configure
Workspaces
terraform workspace new stagingcreates an isolated state for the staging environment;terraform workspace select productionswitches to production — each workspace has its own state file in the backend, so staging and production are completely independent- The current workspace name is available as
terraform.workspacein the configuration —instance_type = terraform.workspace == "production" ? "t3.large" : "t3.micro"provides environment-specific sizing without separate variable files - The workspace limitation: they share the same backend bucket and the same configuration; teams with significantly different production and staging configurations (different region, different VPC CIDR, different module sources) are better served by separate directories with separate state — workspaces work best when environments differ only in size or naming, not in structure
Managing Terraform Variables and Workspaces
Direct Answer
Variables accept values via .tfvars files, environment variables, or -var flags (highest precedence). Workspaces provide lightweight namespacing of state but directory-per-environment is safer for true prod/staging isolation.
Code Example
# variables.tf — declare with type and description
variable "environment" {
description = "Deployment environment (dev, staging, prod)"
type = string
validation {
condition = contains(["dev", "staging", "prod"], var.environment)
error_message = "Environment must be dev, staging, or prod."
}
}
variable "instance_count" {
type = number
default = 1
}
variable "db_password" {
type = string
sensitive = true # redacts from plan output and logs
}
# dev.tfvars
environment = "dev"
instance_count = 1
# prod.tfvars
environment = "prod"
instance_count = 5
# Apply with environment-specific values
# terraform apply -var-file=prod.tfvars
# Environment variable override (highest precedence after -var flag)
# export TF_VAR_db_password="secret123"
# Workspaces — separate state per workspace
# terraform workspace new staging
# terraform workspace select prod
# terraform workspace list
# Use workspace name in config
resource "aws_instance" "app" {
count = terraform.workspace == "prod" ? 5 : 1
tags = { Environment = terraform.workspace }
}
Common Mistakes & Pitfalls
Relying on workspaces as the primary strategy for environment isolation, which is insufficient because workspaces share the same backend and module code — separate state backends per environment are safer.
Check your understanding
Answer these without looking back at the article.
- What is the variable precedence order in Terraform?
- When would you use workspaces vs directory-per-environment?
- How do you inject secrets into Terraform without committing them to version control?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.