Workspaces and remote state in Terraform - Step-by-Step Execution

Process Flow - Workspaces and remote state

Start Terraform

↓

Select Workspace

↓

Load Remote State

↓

Apply Changes

↓

Update Remote State

↓

End

Terraform starts by selecting a workspace, loads the remote state for that workspace, applies changes, then updates the remote state.

Execution Sample

Terraform

terraform workspace new dev
terraform workspace select dev
terraform apply
terraform state pull

Create and select a workspace named 'dev', apply infrastructure changes, then pull the remote state.

Process Table

Step	Action	Workspace	State Loaded	Result
1	Create workspace 'dev'	dev	No (new workspace)	Workspace 'dev' created
2	Select workspace 'dev'	dev	No (just selected)	Workspace 'dev' selected
3	Load remote state	dev	Yes (empty or existing)	State loaded for 'dev'
4	Apply changes	dev	Yes	Infrastructure updated, state changed
5	Update remote state	dev	Yes	Remote state updated with new info
6	End	dev	Yes	Process complete

💡 Process stops after updating remote state and completing apply.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
Workspace	default	dev	dev	dev	dev	dev	dev
State Loaded	No	No	No	Yes	Yes	Yes	Yes
Infrastructure	Initial	Initial	Initial	Initial	Updated	Updated	Updated

Key Moments - 3 Insights

Why does Terraform load a different state after selecting a workspace?

Each workspace has its own separate state file. Selecting a workspace changes which remote state Terraform loads, as shown in step 3 of the execution table.

What happens if you apply changes without selecting a workspace?

Terraform uses the default workspace and its state. This means changes apply to that environment, not to others like 'dev' or 'prod'. See step 2 where workspace selection matters.

How does remote state help when using multiple workspaces?

Remote state stores the current infrastructure info for each workspace separately. This keeps environments isolated and consistent, as shown by the state loaded and updated in steps 3 and 5.

Visual Quiz - 3 Questions

Look at the execution table, what is the workspace after step 2?

A dev

B default

C prod

D None

💡 Hint

Check the 'Workspace' column in row for step 2.

At which step does Terraform load the remote state for the workspace?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look for 'Load remote state' action in the execution table.

If you skip creating a new workspace and apply directly, what workspace is used?

A dev

B default

C prod

D No workspace

💡 Hint

Refer to variable_tracker 'Workspace' start value and key moments about default workspace.

Concept Snapshot

Terraform Workspaces:
- Separate environments with isolated state files
- Use 'terraform workspace new NAME' to create
- Use 'terraform workspace select NAME' to switch
Remote State:
- Stores current infra info remotely
- Keeps state consistent across users
- Each workspace has its own remote state

Full Transcript

Terraform uses workspaces to separate environments like development and production. Each workspace has its own remote state file stored remotely, which Terraform loads when you select that workspace. When you apply changes, Terraform updates the infrastructure and then updates the remote state for that workspace. This keeps environments isolated and consistent. The default workspace is used if no other is selected. Creating and selecting workspaces changes which remote state is loaded and updated.