Workspaces vs directory-based separation in Terraform - Visual Side-by-Side Comparison

Process Flow - Workspaces vs directory-based separation

Start: Choose separation method

↓

Use Workspaces

↓

Single directory

↓

Switch workspace

↓

Isolate state files

↓

Use directory-based

↓

Multiple directories

↓

Separate configs & states

↓

Manage independently

You start by choosing how to separate your Terraform environments: either by switching workspaces in one directory or by using separate directories for each environment.

Execution Sample

Terraform

terraform workspace new dev
terraform apply
terraform workspace new prod
terraform apply

This code creates a new workspace 'dev', applies infrastructure, then switches to 'prod' workspace and applies infrastructure separately.

Process Table

Step	Action	Workspace/Directory	State File Used	Effect
1	Initialize Terraform directory	default	default.tfstate	Ready to manage infrastructure
2	Create new workspace 'dev'	dev	dev.tfstate	New isolated state created for dev
3	Apply infrastructure in 'dev'	dev	dev.tfstate	Resources created tracked in dev state
4	Switch to workspace 'prod'	prod	prod.tfstate	Switch state to prod, no resources yet
5	Apply infrastructure in 'prod'	prod	prod.tfstate	Resources created tracked in prod state
6	Use directory 'dev_env' instead	dev_env directory	dev_env/terraform.tfstate	Separate config and state for dev_env
7	Apply infrastructure in 'dev_env'	dev_env directory	dev_env/terraform.tfstate	Resources created tracked in dev_env state
8	Use directory 'prod_env' instead	prod_env directory	prod_env/terraform.tfstate	Separate config and state for prod_env
9	Apply infrastructure in 'prod_env'	prod_env directory	prod_env/terraform.tfstate	Resources created tracked in prod_env state
10	End of demonstration	-	-	Separation by workspace or directory completed

💡 Finished showing how workspaces and directory-based separation isolate Terraform states and configurations.

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	After Step 8	Final
Current Workspace/Directory	default	dev	prod	dev_env directory	prod_env directory	prod_env directory
State File Used	default.tfstate	dev.tfstate	prod.tfstate	dev_env/terraform.tfstate	prod_env/terraform.tfstate	prod_env/terraform.tfstate

Key Moments - 3 Insights

Why does switching workspaces not require changing directories?

Because workspaces keep separate state files within the same directory, so you can switch environments without moving folders, as shown in steps 2 to 5 in the execution_table.

How does directory-based separation isolate environments differently from workspaces?

Directory-based separation uses completely separate folders with their own configs and state files, so each environment is fully independent, as seen in steps 6 to 9.

Can workspaces share configuration files?

Yes, all workspaces share the same configuration files in one directory but keep their states separate, unlike directory-based separation where configs differ per folder.

Visual Quiz - 3 Questions

Look at the execution_table, what state file is used after creating the 'dev' workspace?

A default.tfstate

B dev.tfstate

C prod.tfstate

D dev_env/terraform.tfstate

💡 Hint

Check Step 2 in the execution_table where the 'dev' workspace is created.

At which step does the separation method switch from workspaces to directory-based?

A Step 6

B Step 5

C Step 4

D Step 7

💡 Hint

Look for when the workspace name changes to a directory name in the execution_table.

If you apply infrastructure in the 'prod_env' directory, which state file is updated?

A prod.tfstate

B default.tfstate

C prod_env/terraform.tfstate

D dev.tfstate

💡 Hint

Refer to Step 9 in the execution_table for the directory-based separation state file.

Concept Snapshot

Terraform environments can be separated by:
- Workspaces: single directory, multiple state files per workspace
- Directory-based: separate folders, each with own config and state
Workspaces share configs but isolate states.
Directories isolate both configs and states.
Choose based on project complexity and team needs.

Full Transcript

This visual execution compares two ways to separate Terraform environments: workspaces and directory-based separation. Workspaces let you switch between isolated states inside one directory, sharing the same configuration files. Directory-based separation uses different folders for each environment, each with its own configs and state files. The execution table shows creating and switching workspaces, then applying infrastructure, followed by using separate directories for environments. Variable tracking shows how the current workspace or directory and state files change step-by-step. Key moments clarify why workspaces don't need directory changes and how directories isolate configs. The quiz tests understanding of state files and steps where separation methods change.

Practice

1. What is the main difference between Terraform workspaces and directory-based separation?

easy

A. Workspaces require separate folders; directory-based uses one folder with multiple states.

B. Workspaces store state remotely; directory-based stores state locally only.

C. Workspaces and directory-based separation are exactly the same.

D. Workspaces use one folder with multiple states; directory-based uses separate folders for each environment.

Solution

1. Step 1: Understand workspace concept

   Workspaces allow multiple states inside the same folder by switching context.

2. Step 2: Understand directory-based separation

   Directory-based separation uses different folders, each with its own code and state files.

3. Final Answer:

   Workspaces use one folder with multiple states; directory-based uses separate folders for each environment. -> Option D

4. Quick Check:

   Workspaces = one folder, multiple states [OK]

Hint: Workspaces = one folder, directory = multiple folders [OK]

Common Mistakes:

• Confusing workspace with directory-based separation
• Thinking workspaces require multiple folders
• Assuming directory-based uses one state file

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

easy

A. terraform workspace select dev

B. terraform select workspace dev

C. terraform switch workspace dev

D. terraform workspace change dev

Solution

1. Step 1: Recall Terraform workspace commands

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

2. Step 2: Match command to options

   Only terraform workspace select dev matches the correct syntax exactly.

3. Final Answer:

   terraform workspace select dev -> Option A

4. Quick Check:

   Switch workspace = terraform workspace select [OK]

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

Common Mistakes:

• Using incorrect command order
• Using non-existent commands like 'switch' or 'change'
• Confusing workspace commands with other terraform commands

3. Given this folder structure:

envs/
  ├─ dev/
  │    └─ main.tf
  └─ prod/
       └─ main.tf

and using directory-based separation, what happens if you run terraform apply inside envs/dev?

medium

A. Terraform applies changes to both dev and prod environments simultaneously.

B. Terraform applies changes only to the dev environment using its own state.

C. Terraform throws an error because state is missing.

D. Terraform applies changes to the prod environment instead.

Solution

1. Step 1: Understand directory-based separation behavior

   Each folder has its own Terraform code and state, so running inside envs/dev affects only dev.

2. Step 2: Analyze command effect

   terraform apply in envs/dev applies changes only to dev environment's resources.

3. Final Answer:

   Terraform applies changes only to the dev environment using its own state. -> Option B

4. Quick Check:

   Directory-based apply affects current folder environment [OK]

Hint: Apply runs in current folder's environment only [OK]

Common Mistakes:

• Assuming apply affects all environments
• Thinking state is shared across folders
• Expecting errors due to missing state

4. You created a new workspace named staging but when running terraform apply, changes apply to the default workspace instead. What is the likely cause?

medium

A. You forgot to run terraform workspace select staging before applying.

B. The staging workspace does not exist.

C. Terraform does not support multiple workspaces.

D. You need to rename the default workspace to staging.

Solution

1. Step 1: Check workspace usage

   Creating a workspace does not switch to it automatically; you must select it explicitly.

2. Step 2: Identify missing command

   If you don't run terraform workspace select staging, Terraform stays in default workspace.

3. Final Answer:

   You forgot to run terraform workspace select staging before applying. -> Option A

4. Quick Check:

   Must select workspace before apply [OK]

Hint: Always select workspace before applying changes [OK]

Common Mistakes:

• Assuming workspace auto-switches after creation
• Thinking workspace names must be renamed
• Believing Terraform lacks workspace support

5. You want to manage three environments: dev, staging, and prod. You want to keep code DRY (Don't Repeat Yourself) and share most configuration but keep states isolated. Which approach is best?

hard

A. Use one folder and switch backend configuration files for each environment.

B. Create three separate folders, each with full copies of code and state.

C. Use one folder with Terraform workspaces for each environment.

D. Use one folder and manually rename state files for each environment.

Solution

1. Step 1: Analyze DRY and state isolation needs

   Sharing code but isolating state fits well with workspaces, which share code folder but separate states.

2. Step 2: Compare options

   Use one folder with Terraform workspaces for each environment uses workspaces to keep one codebase and separate states per environment, avoiding code duplication.

3. Step 3: Evaluate other options

   Create three separate folders, each with full copies of code and state duplicates code, violating DRY. Use one folder and manually rename state files for each environment is error-prone and manual. Use one folder and switch backend configuration files for each environment requires backend changes, complex to manage.

4. Final Answer:

   Use one folder with Terraform workspaces for each environment. -> Option C

5. Quick Check:

   Workspaces = shared code, separate states [OK]

Hint: Workspaces share code, separate states for DRY environments [OK]

Common Mistakes:

• Duplicating code in multiple folders unnecessarily
• Trying manual state file renaming
• Switching backend configs frequently