0
0
Terraformcloud~10 mins

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

Choose your learning style9 modes available
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
StepActionInput/StateOutput/State Change
1User runs 'terraform init'Local config onlyBackend configured to remote with org and workspace
2User runs 'terraform plan'Code sent to remote backendRemote backend creates execution plan, state locked
3User reviews plan outputPlan generated remotelyPlan displayed locally
4User runs 'terraform apply'Apply command sent to remote backendRemote backend applies changes, updates state
5State updated remotelyState locked during applyState unlocked and saved remotely
6User receives apply outputApply completed remotelyOutput shown locally
7User runs 'terraform destroy' (optional)Destroy command sent remotelyResources destroyed, state updated
8Execution endsState consistent remotelyUser has updated infrastructure and state
💡 Execution stops after state is updated remotely and user receives output.
Status Tracker
VariableStartAfter Step 2After Step 4After Step 5Final
Terraform CodeLocal filesSent to remote backendSent to remote backendSent to remote backendSent to remote backend
StateLocal or noneLocked remotelyLocked remotelyUpdated remotelyUnlocked remotely
Execution PlanNoneCreated remotelyCreated remotelyUsed remotelyNone
Apply OutputNoneNoneGenerated remotelyGenerated remotelyReceived 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
Test your understanding
Look at the execution_table, at which step is the state first locked remotely?
AStep 1
BStep 4
CStep 2
DStep 5
💡 Hint
Check the 'Output/State Change' column for when state locking occurs.
According to variable_tracker, what is the state after step 5?
AUnlocked locally
BUpdated and unlocked remotely
CUpdated and locked remotely
DLocked 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?
ARemote backend would not be configured, so execution fails early
BPlan and apply run locally instead
CState would be locked remotely anyway
DUser 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.