Workspaces & Multi-Environment Patterns
Terraform / Infrastructure as Code
Chapter 8 · Workspaces & Multi-Environment Patterns
Chapter 4's .tfvars files and Chapter 7's for_each-over-a-module both hinted at multiple environments. This chapter names the real options directly, and the tradeoffs between them.
The Multi-Environment Problem
Dev, staging, and prod are almost always the same infrastructure shape with different values — smaller instance sizes in dev, different domain names, different scaling targets. The question is how to run one configuration against three genuinely separate sets of real infrastructure without copy-pasting the whole thing three times.
Terraform Workspaces
A workspace gives each named environment its own state file, within the same backend and configuration. terraform.workspace is available inside the configuration itself to vary behavior by environment.
Workspaces vs. Separate State Keys
An alternative to workspace commands entirely: give each environment its own backend key (Chapter 6's S3 key argument) via -backend-config, with no terraform workspace involved. Functionally similar — separate state per environment — but explicit at the backend-configuration level rather than an in-CLI selection that's easy to forget you've made.
Workspaces vs. Separate Directories
The strongest-isolation option: a genuinely separate directory (and root module) per environment — environments/dev/, environments/prod/ — each with its own main.tf calling the same shared modules from Chapter 7's registry pattern, but with entirely separate state, separate backend configuration, and often separate provider credentials.
| Approach | Isolation | Duplication |
|---|---|---|
| Workspaces | Separate state only — same config, backend, credentials | Lowest — one configuration |
| Separate state keys | Separate state, explicit backend config per environment | Low — one configuration, per-env backend files |
| Separate directories | Strongest — state, backend, and often credentials all separate | Highest — a root module per environment |
The Workspace-Isn't-a-Full-Isolation-Boundary Gotcha
Workspaces separate state — nothing else. The configuration, the backend, and the provider credentials are all shared across every workspace. Selecting the wrong workspace by mistake — intending dev but currently sitting in prod — still runs apply against real production infrastructure, using real production credentials, because nothing in the setup itself enforces which workspace "should" be safe to touch right now.
terraform workspace show before running apply is a cheap habit against exactly this mistake — easy to forget which workspace is currently selected, especially after switching between projects.
Hands-On Exercises
Explain precisely what terraform.workspace isolates, and what it does not isolate — and why that makes running apply in the wrong workspace still genuinely dangerous.
Compare workspaces against separate directories in terms of isolation strength and duplication cost. Which would a team managing a genuinely high-stakes production environment likely prefer, and why?
📄 View solutionGiven count = terraform.workspace == "prod" ? 3 : 1, a team creates a third workspace called staging. Explain exactly what count evaluates to while the staging workspace is selected, and why.
Chapter 8 Quick Reference
terraform workspace new/select/list/show— manage and check the current workspaceterraform.workspace— the current workspace name, usable inside configuration- Workspaces isolate state only — configuration, backend, and credentials are shared
- Separate directories — strongest isolation, highest duplication, often preferred for prod
- Always check
terraform workspace showbeforeapply