Remote execution model in Terraform - Step-by-Step Execution

Process Flow - Remote execution model

User writes Terraform code

↓

Terraform CLI sends code to Remote Backend

↓

Remote Backend stores state securely

↓

Remote Backend runs Terraform plan/apply

↓

Remote Backend updates state

↓

User receives output and status

Terraform code is sent to a remote backend which securely stores state and runs the plan/apply commands, then updates state and returns results.

Execution Sample

Terraform

terraform {
  backend "remote" {
    organization = "my-org"
    workspaces { name = "my-workspace" }
  }
}

This config sets Terraform to use a remote backend with an organization and workspace for remote execution.

Process Table

Step	Action	Input/State	Output/State Change
1	User runs 'terraform init'	Local config only	Backend configured to remote with org and workspace
2	User runs 'terraform plan'	Code sent to remote backend	Remote backend creates execution plan, state locked
3	User reviews plan output	Plan generated remotely	Plan displayed locally
4	User runs 'terraform apply'	Apply command sent to remote backend	Remote backend applies changes, updates state
5	State updated remotely	State locked during apply	State unlocked and saved remotely
6	User receives apply output	Apply completed remotely	Output shown locally
7	User runs 'terraform destroy' (optional)	Destroy command sent remotely	Resources destroyed, state updated
8	Execution ends	State consistent remotely	User has updated infrastructure and state

💡 Execution stops after state is updated remotely and user receives output.

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	Final
Terraform Code	Local files	Sent to remote backend	Sent to remote backend	Sent to remote backend	Sent to remote backend
State	Local or none	Locked remotely	Locked remotely	Updated remotely	Unlocked remotely
Execution Plan	None	Created remotely	Created remotely	Used remotely	None
Apply Output	None	None	Generated remotely	Generated remotely	Received locally

Key Moments - 3 Insights

Why does the state get locked during remote execution?

State locking prevents multiple users from changing infrastructure at the same time, as shown in steps 2 and 4 of the execution_table.

Where does the Terraform plan get created in remote execution?

The plan is created on the remote backend, not locally, as seen in step 2 where the plan is generated remotely.

How does the user see the output if execution happens remotely?

The remote backend sends the output back to the user's local CLI, shown in step 6 where output is displayed locally.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the state first locked remotely?

A Step 1

B Step 4

C Step 2

D Step 5

💡 Hint

Check the 'Output/State Change' column for when state locking occurs.

According to variable_tracker, what is the state after step 5?

A Unlocked locally

B Updated and unlocked remotely

C Updated and locked remotely

D Locked locally

💡 Hint

Look at the 'State' row and the 'After Step 5' and 'Final' columns.

If the user skips 'terraform init', what impact would it have on the execution flow?

A Remote backend would not be configured, so execution fails early

B Plan and apply run locally instead

C State would be locked remotely anyway

D User still gets remote execution without init

💡 Hint

Refer to step 1 where 'terraform init' configures the backend.

Concept Snapshot

Terraform Remote Execution Model:
- Configure remote backend in terraform block
- 'terraform init' sets backend
- 'terraform plan' and 'apply' run remotely
- State is locked during execution
- Outputs returned to local CLI
- Ensures secure, shared state and execution

Full Transcript

In the Terraform remote execution model, the user writes Terraform code locally and configures a remote backend. When the user runs 'terraform init', the backend is set up. Then, 'terraform plan' sends the code to the remote backend, which locks the state and creates a plan. The user reviews the plan locally. When 'terraform apply' is run, the remote backend applies changes, updates and unlocks the state. Outputs are sent back to the user. This model ensures state is stored securely and execution is centralized, preventing conflicts.

Practice

1. What is the main benefit of using Terraform's remote execution model?

easy

A. It runs Terraform commands on a shared server, keeping state safe and enabling team collaboration.

B. It allows Terraform to run faster on your local machine.

C. It automatically writes code for you.

D. It removes the need for any backend configuration.

Solution

1. Step 1: Understand remote execution purpose

   Remote execution runs Terraform commands on a shared server, not locally.

2. Step 2: Identify benefits of remote execution

   This keeps the Terraform state safe and helps teams avoid conflicts by sharing the same environment.

3. Final Answer:

   It runs Terraform commands on a shared server, keeping state safe and enabling team collaboration. -> Option A

4. Quick Check:

   Remote execution = shared server + safe state + teamwork [OK]

Hint: Remote execution means running Terraform on a shared server, not locally [OK]

Common Mistakes:

• Thinking remote execution speeds up local runs
• Believing remote execution auto-generates code
• Assuming no backend setup is needed

2. Which Terraform block is used to configure remote execution?

easy

A. terraform

B. backend

C. resource

D. provider

Solution

1. Step 1: Recall Terraform configuration blocks

   Terraform uses specific blocks like provider, terraform, resource, and backend for different purposes.

2. Step 2: Identify block for remote execution

   The backend block inside the terraform block is where remote execution is configured, including the remote backend settings.

3. Final Answer:

   backend -> Option B

4. Quick Check:

   Remote execution config in backend block inside terraform block [OK]

Hint: Remote execution setup goes inside the backend block within terraform block [OK]

Common Mistakes:

• Confusing provider block with remote execution
• Choosing terraform block instead of backend block
• Selecting resource block which defines infrastructure

3. Given this Terraform snippet, what happens when you run terraform apply?

terraform {
  backend "remote" {
    organization = "my-org"
    workspaces {
      name = "my-workspace"
    }
  }
}

medium

A. Terraform runs locally and saves state on your machine.

B. Terraform fails because the backend block is missing.

C. Terraform runs remotely but does not save any state.

D. Terraform runs remotely in the specified workspace and stores state in the cloud.

Solution

1. Step 1: Analyze backend configuration

   The snippet configures a remote backend with an organization and workspace name, enabling remote execution.

2. Step 2: Understand apply behavior with remote backend

   When running terraform apply, Terraform runs remotely in the specified workspace and stores the state securely in the cloud.

3. Final Answer:

   Terraform runs remotely in the specified workspace and stores state in the cloud. -> Option D

4. Quick Check:

   Remote backend + workspace = remote run + cloud state [OK]

Hint: Remote backend means apply runs remotely and saves state remotely [OK]

Common Mistakes:

• Assuming Terraform runs locally despite remote backend
• Thinking state is saved locally
• Believing missing backend block causes failure here

4. You configured remote execution but get an error: "No workspace named 'prod' found." What is the likely cause?

medium

A. Terraform is running locally without remote execution enabled.

B. The backend block is missing in the terraform configuration.

C. The workspace 'prod' does not exist in the remote backend.

D. The organization name is incorrect.

Solution

1. Step 1: Understand the error message

   The error says the workspace 'prod' is not found, indicating a missing workspace in the remote backend.

2. Step 2: Identify cause of missing workspace

   This usually means the workspace was not created or named differently in the remote backend configuration.

3. Final Answer:

   The workspace 'prod' does not exist in the remote backend. -> Option C

4. Quick Check:

   Missing workspace error = workspace not created remotely [OK]

Hint: Check if the remote workspace exists before running [OK]

Common Mistakes:

• Assuming backend block is missing
• Thinking Terraform runs locally without remote
• Blaming organization name without checking workspace

5. You want to enable remote execution for your Terraform project with multiple team members. Which configuration ensures safe state sharing and prevents conflicts?

hard

A. Configure the terraform block with a remote backend and use named workspaces for each environment.

B. Run Terraform locally on each machine without backend configuration.

C. Use local backend and share the state file via email.

D. Disable state locking and run Terraform commands simultaneously.

Solution

1. Step 1: Identify best practice for team collaboration

   Using a remote backend with named workspaces allows multiple team members to share state safely and organize environments.

2. Step 2: Evaluate other options for safety and conflicts

   Running locally or sharing state manually risks conflicts and state corruption. Disabling locking causes race conditions.

3. Final Answer:

   Configure the terraform block with a remote backend and use named workspaces for each environment. -> Option A

4. Quick Check:

   Remote backend + workspaces = safe shared state + no conflicts [OK]

Hint: Use remote backend with workspaces to share state safely [OK]

Common Mistakes:

• Sharing state files manually
• Running Terraform locally without backend
• Disabling state locking causing conflicts