Use HCP Terraform to Create Infrastructure
Where a run executes: remote, agent, and local modes
A workspace's execution mode answers one question: where does Terraform actually run? You choose it once per workspace, and it decides whether plan and apply happen on HashiCorp's infrastructure, on a machine you control inside a private network, or on your own laptop. State is a separate matter: it is always stored remotely in the workspace, so the choice is about execution, not storage. From here you will see how each execution mode runs the same plan and apply you already use from the CLI, how a run then moves through its ordered stages to an apply, and how VCS, CLI, and API workflows trigger runs, so you can place a workspace in the right mode and predict what any run will do. The figure groups the three modes by where their run executes and shows the one thing they all share.
Remote mode, the default
In Remote execution mode HCP Terraform performs Terraform runs on its own disposable virtual machines[1], giving every run a consistent managed environment. That managed environment is what makes the run's extra features possible: policy enforcement, cost estimation, and notifications all attach to a remote run. Remote is the default for a new workspace, and it is the mode most of this page assumes.
Agent mode, for private and on-prem infrastructure
Remote mode's shared VMs can only reach infrastructure that is exposed to them over the network, so a target inside an isolated or on-premises network needs a different mode. HCP Terraform agents let you manage isolated, private, or on-premises infrastructure while keeping your network secure[2]: you install a lightweight, self-hosted agent inside the network, and the agent requires only outbound connectivity to HCP Terraform[2], polling it for work and executing runs locally. Agent mode is a paid capability; your HCP Terraform plan determines the number of agents you can use[2].
Local mode, a state backend only
Local execution mode makes the workspace act only as a remote backend for Terraform state, with all execution occurring on your own workstations or continuous integration workers[1]. Because the run no longer happens on HCP Terraform, everything that rides on a managed run goes away: no remote runs, no policy checks, no cost estimation. The predictable misread is that Local mode also keeps state on your disk. It does not. State still lives in the workspace remotely, and only the run moves to your machine.
The run lifecycle: from queue to apply
Every apply-capable run follows the same ordered path, and knowing that order is most of what this objective asks. A run is created in the Pending state, and HCP Terraform processes each workspace's runs in the order they were queued[3], holding a run Pending until every run ahead of it finishes. So each workspace applies one run at a time, in queue order, and editing a variable or the configuration while a run is mid-flight only affects the next run, not the one already planned.
The stages, in order
Once it leaves the queue, the run moves through plan, then cost estimation, then policy check, then apply. Cost estimation appears in the run as an extra phase between the plan and apply[4], and it runs before the policy check. That ordering is the whole point: because the estimate is ready first, a Sentinel policy can read the monthly cost delta the run would introduce[4] and block a change that would spend too much. Cost estimation is enabled per organization and supports the AWS, GCP, and Azure providers[4], reporting a total monthly cost alongside that delta. Reading the order as policy-check-then-cost, or as one combined step, is the classic trap; cost estimation always comes first.
Manual apply versus auto-apply
When the plan and its checks succeed, a run does not apply itself by default. It pauses in a Needs Confirmation state until a user with permission to apply runs takes action[3], clicking Confirm & Apply to proceed or discarding the run. Enabling auto-apply on the workspace removes that pause, so a plan that finishes without error applies automatically. The figure traces the full path from the queue to apply and marks the Needs Confirmation gate that manual apply adds.
Starting runs: VCS, CLI, and API workflows
A run has to be triggered, and HCP Terraform offers three workflows to do it. They differ in what starts the run, not in how the run then executes, and the figure maps each trigger to the kind of run it produces: a full run that can apply, or a speculative plan that cannot.
VCS-driven
HCP Terraform registers webhooks with your VCS provider and automatically queues a Terraform run whenever new commits are merged to that branch of the workspace's linked repository[5]. A pull request is handled differently: HCP Terraform performs a speculative plan when a pull request is opened against that branch and posts a link to the plan in the pull request[5]. A speculative plan is a plan-only preview that can never apply, defined in full below. So a commit or merge produces a full run, while a pull request produces a speculative plan whose result reviewers read in the PR.
CLI-driven
With the cloud block configured, you keep using the Terraform CLI locally while the run executes in HCP Terraform. The two commands split by run type: a terraform apply starts a full run in the workspace, while terraform plan starts a speculative plan using configuration files from your local directory[6], which lets you check results, including Sentinel policy compliance, without copying sensitive variables to your machine.
API-driven
The API-driven workflow uploads a configuration version through the Runs API and is the most flexible, at the cost that it requires you to create some tooling[7] to package and send the configuration. It suits systems that generate configuration or orchestrate runs outside a version-control repository.
Speculative plans
A speculative plan is a plan-only run: it shows possible changes, and the policies affected by those changes, but cannot apply any changes[1]. Because it never touches real infrastructure, it can begin without waiting for other runs to finish[1] and does not take the workspace lock. There is no Confirm & Apply on a speculative plan. To actually change infrastructure you trigger a full run, from a commit, a terraform apply, or an apply-capable API run.
Exam-pattern recognition
TA-004 items on HCP Terraform are mechanical: they test whether you can place a run in the right execution mode, name its stages in order, and tell a full run from a speculative one. No cloud-provider-specific knowledge is required.
An execution-mode stem describes where runs should happen. Map the intent: a consistent managed environment with policy and cost checks is Remote (the default); infrastructure in an isolated or on-premises network is Agent mode; and using the workspace only to hold state while Terraform runs on your own machine is Local mode. The planted error is that Local mode also stores state locally. It does not, because state stays in the workspace remotely in every mode, and only the run location changes.
A lifecycle stem asks for the stage order or where one stage sits. The order is plan, then cost estimation, then policy check, then apply. The favorite trap puts the policy check before cost estimation or merges them; hold the line that cost estimation runs first, which is exactly what lets a Sentinel policy gate on the estimated cost. A companion trap claims a plan applies automatically. By default it does not: a finished plan waits in Needs Confirmation for a Confirm & Apply, unless the workspace has auto-apply enabled.
A queue stem describes two runs or a variable change during a run. Each workspace processes runs one at a time in queue order, and a change made mid-run affects only the next run, not the one already planned.
A workflow stem gives a trigger and asks what happens. A commit or merge to the tracked branch starts a full run that can apply; opening a pull request starts a speculative plan whose result is posted back to the PR. The recurring trap is that a speculative plan can be confirmed into an apply. It cannot: a speculative plan is strictly plan-only, has no Confirm & Apply, takes no workspace lock, and never modifies state.
Execution modes: where the run and state live
| Behavior | Remote (default) | Agent | Local |
|---|---|---|---|
| Where plan and apply run | HCP Terraform VMs | Self-hosted agent in your network | Your workstation or CI |
| Where state is stored | HCP Terraform workspace | HCP Terraform workspace | HCP Terraform workspace |
| Reaches private or on-prem infra | No, needs a reachable API | Yes, from inside the network | Yes, runs where you run |
| Policy checks and cost estimation | Yes | Yes | No, disabled |
| Typical use | Default managed runs | Isolated or private networks | Remote state backend only |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- Remote execution runs Terraform on HCP Terraform VMs
In a workspace using Remote execution mode (the default), HCP Terraform (formerly Terraform Cloud) performs plan and apply on its own disposable virtual machines using that workspace's configuration, variables, and state. Switching a workspace to Local execution mode makes it act only as a remote state backend while runs execute on your own workstation or CI, which disables policy checks, cost estimation, and remote runs.
Trap Assuming Local execution mode also stores state locally — it still stores state remotely; only the run execution moves to your machine.
5 questions test this
- A workspace is left in the default Remote execution mode. An engineer exports an environment variable in their own laptop shell and then queues a run, expecting that value to be present during the run
- An engineer switches an HCP Terraform workspace from its default execution mode to Local execution mode so runs happen on their laptop. They assume the input variables and variable sets they defined i
- A platform team adds a `cloud` block to their configuration, connects it to an HCP Terraform workspace, and leaves that workspace's execution mode at its default setting. When a colleague later queues
- A workspace is reconfigured to use Local execution mode. A teammate expects that Sentinel policy checks and cost estimation will keep running on every new run exactly as they did before. When the next
- During a Remote-mode run, an engineer sees the log download a small helper tool onto the HCP Terraform worker. They assume that tool will remain installed and available on the worker for the workspace
- Agent execution mode reaches private infrastructure
Agent execution mode runs Terraform on self-hosted HCP Terraform agents installed inside a private network, letting HCP Terraform manage runs against isolated or on-premises infrastructure it cannot reach directly.
- State is stored remotely per workspace
HCP Terraform stores Terraform state remotely and separately for each workspace, automatically retaining prior state versions. When you use the cloud integration you do not add a separate backend block, and state is never committed to version control.
Trap Thinking you still need a backend block alongside the cloud integration — the cloud block replaces backend configuration and manages state itself.
10 questions test this
- While integrating a configuration with HCP Terraform, an engineer adds a `cloud` block inside the `terraform` block. Unsure whether state will actually be stored, they ask a senior colleague whether t
- An auditor needs to inspect the current Terraform state and its recent prior versions for a workspace that uses the HCP Terraform cloud integration. Where does that state live, and how should the audi
- An engineer switches an HCP Terraform workspace from its default execution mode to Local execution mode so runs happen on their laptop. They assume the input variables and variable sets they defined i
- Two engineers queue applies against the same HCP Terraform workspace within moments of each other. Concerned about the workspace's shared state, a teammate asks how HCP Terraform keeps the two runs fr
- An engineer adds a `cloud` block to a configuration that currently uses the default local backend, leaving the existing `terraform.tfstate` file in the working directory. They then run `terraform init
- A team connects an HCP Terraform workspace to a Git repository so that pushes to the repository trigger runs. A newly onboarded engineer clones the repository and hunts for the `terraform.tfstate` fil
- A workspace is reconfigured to use Local execution mode. A teammate expects that Sentinel policy checks and cost estimation will keep running on every new run exactly as they did before. When the next
- An organization manages its development and production environments as two separate HCP Terraform workspaces created from the same configuration repository. A newly hired engineer asks how Terraform s
- After a dozen applies over several weeks in an HCP Terraform workspace, an engineer needs to review the state as it existed two applies ago to analyze how the infrastructure changed. What does HCP Ter
- A configuration already connects to an HCP Terraform workspace with a cloud block. To keep a redundant second copy of state, a teammate proposes also adding an S3 backend block to the same configurati
- Remote run stage order
A remote run moves through ordered stages: it queues (pending), executes a plan, then runs cost estimation, then any policy check, and finally performs the apply (plan -> cost estimation -> policy check -> apply). HCP Terraform surfaces the output of both the plan and apply phases on the run's details page.
Trap Thinking the policy check precedes cost estimation, or that they are one combined step; cost estimation always runs first (plan -> cost estimation -> policy check -> apply), which is why a Sentinel policy can gate on the cost estimate.
6 questions test this
- A run has just been queued in an HCP Terraform workspace and is currently sitting in the pending state. Once the run leaves the pending queue and HCP Terraform starts to actually execute it, which of
- While reviewing a run in HCP Terraform, a teammate insists that 'cost estimation and policy check' are a single combined governance step the platform performs together just before the apply. For a wor
- Two runs are queued at almost the same time against a single HCP Terraform workspace. The engineer wants to know how HCP Terraform handles the newly queued run and which stage it enters first once pro
- After a remote run in HCP Terraform has fully completed, an engineer opens the run's details page to review both what Terraform proposed and what it ultimately changed in the infrastructure. What outp
- An engineer is watching a remote run progress on its details page in HCP Terraform and wants to understand the fixed order of the stages that occur between the completed plan and the eventual apply. W
- An engineer is explaining to a teammate how HCP Terraform produces the cost figures they see on a run. Focusing on when the stage runs and what input it consumes, which description of the cost estimat
- Manual apply pauses for Confirm & Apply
With manual apply (the default), a finished plan pauses and a user with apply permission must click Confirm & Apply to proceed or Discard the run. Auto-apply, when enabled on the workspace, automatically applies plans that complete without errors.
Trap Assuming auto-apply is the default — HCP Terraform requires manual confirmation unless auto-apply is explicitly turned on.
5 questions test this
- In an HCP Terraform workspace that uses the default apply settings, a plan has finished and is waiting on the run's page for a decision. A team member who has only read access to the workspace wants t
- An operations team turns on auto-apply for a busy HCP Terraform workspace to reduce the number of manual approvals during routine deployments. Once auto-apply is enabled, how does it change what happe
- A busy HCP Terraform workspace has auto-apply turned on so routine runs apply without waiting for manual approval. During one run, the plan stage finishes but reports an error in the proposed changes.
- A platform engineer queues a run in an HCP Terraform workspace that still uses the workspace's default apply settings. The plan completes successfully with a set of proposed changes. With no other con
- Under default apply settings, an HCP Terraform workspace has a plan that finished and is now waiting for someone to confirm or discard it. Before anyone acts on it, a new commit is pushed to the conne
- Each workspace processes its run queue in order
Every workspace maintains its own run queue and processes apply-capable runs one at a time, in order. Changing variables or configuration only affects future runs, not a run that has already been planned.
- HCP Terraform cost estimation run stage
In an HCP Terraform run, cost estimation is a distinct stage that runs after the plan and BEFORE the policy check (order: plan -> cost estimation -> policy check -> apply), which is why a Sentinel policy can reference the estimate via the tfrun import. It produces the estimated total monthly cost of the resources in the plan plus the monthly delta (the cost change from the proposed run) for supported major providers (AWS, Azure, GCP), and is enabled per-organization in the organization settings.
Trap Assuming cost estimation runs after, or together with, the policy check; it actually runs before the policy check, which is exactly what lets a Sentinel policy gate on the estimated cost.
6 questions test this
- A new engineer asks how the cost figures for a run get produced in an HCP Terraform organization that already has cost estimation enabled - specifically, whether they need to run a separate command or
- While reviewing a run in HCP Terraform, a teammate insists that 'cost estimation and policy check' are a single combined governance step the platform performs together just before the apply. For a wor
- An engineer is watching a remote run progress on its details page in HCP Terraform and wants to understand the fixed order of the stages that occur between the completed plan and the eventual apply. W
- An engineer notices that runs in one HCP Terraform organization display cost estimates while runs in a second organization show none, even though both manage AWS, Azure, and GCP resources. Where is co
- An engineer is explaining to a teammate how HCP Terraform produces the cost figures they see on a run. Focusing on when the stage runs and what input it consumes, which description of the cost estimat
- During a run in an HCP Terraform organization that has cost estimation turned on, an engineer opens the cost estimation stage of the run. Setting aside the itemized per-resource breakdown, what two fi
- Three run workflows: UI/VCS, CLI, and API driven
HCP Terraform can start runs three ways: UI/VCS-driven (webhooks from a connected repository), CLI-driven (running terraform plan/apply locally with the cloud block configured), and API-driven (uploading a configuration version through the Runs API).
6 questions test this
- An organization's internal CI system, rather than a VCS webhook, decides when Terraform configuration has changed and must be run in HCP Terraform. The team wants that system to start each run program
- So that team members can keep typing `terraform plan` and `terraform apply` locally while the operations run remotely in HCP Terraform, an engineer must add one element to the `terraform {}` configura
- With the `cloud` block configured for the CLI-driven workflow, an engineer runs `terraform plan` from their terminal. The command streams plan output to the terminal, but the engineer notices there is
- An engineer new to HCP Terraform asks how the UI/VCS-driven, CLI-driven, and API-driven run workflows relate to one another. Which statement most accurately describes the relationship among these thre
- A platform engineer wants to keep starting runs by typing `terraform plan` and `terraform apply` in a local terminal, but needs each operation to execute remotely in HCP Terraform so it uses the works
- A team lead is mapping each of HCP Terraform's three run workflows to the mechanism that actually starts its runs. Which of the following pairings correctly matches a run workflow to the mechanism tha
- Speculative plans preview but cannot apply
A speculative plan is a plan-only run that previews proposed changes and policy results but can never apply changes or modify state. Because it cannot alter infrastructure, it bypasses the workspace lock and does not block other runs.
Trap Believing a speculative plan can be confirmed into an apply — it is strictly read-only and has no Confirm & Apply.
9 questions test this
- A reviewer triggers a speculative plan on a shared HCP Terraform workspace to preview a proposed configuration change. Afterward a colleague worries that the speculative run may have altered the works
- A new team member is confused: the run that HCP Terraform started from their merged commit to the tracked branch showed a Confirm & Apply button, but the run started earlier from their pull request di
- A developer opens a pull request against the branch tracked by a VCS-connected HCP Terraform workspace, and HCP Terraform posts a speculative plan back to the PR. The developer then pushes two more co
- A long-running apply is currently in progress and holding the lock on an HCP Terraform workspace. While that apply runs, a developer opens a pull request against the tracked branch, which triggers a s
- With the `cloud` block configured for the CLI-driven workflow, an engineer runs `terraform plan` from their terminal. The command streams plan output to the terminal, but the engineer notices there is
- A VCS-connected HCP Terraform workspace tracks the `production` branch. A developer pushes a commit to a separate `feature/logging` branch and, as a separate action, opens a pull request from `feature
- During code review, a teammate opens a plan-only (speculative) run in HCP Terraform to preview the changes a proposed configuration would make. The run succeeds and passes all policy checks. The teamm
- An engineer wants to preview exactly what a proposed configuration change would do in an HCP Terraform workspace with zero possibility that the run applies anything or writes to state. Which HCP Terra
- A VCS-connected HCP Terraform workspace tracks the `main` branch. A developer pushes a commit directly to `main`, not through a pull request, expecting HCP Terraform only to preview the change. Given
- Commit triggers a full run, PR triggers a speculative plan
For a VCS-connected workspace, a commit or merge to the tracked branch triggers a full run (plan then apply), while opening a pull request triggers only a speculative plan whose result is posted back to the PR.
4 questions test this
- A new team member is confused: the run that HCP Terraform started from their merged commit to the tracked branch showed a Confirm & Apply button, but the run started earlier from their pull request di
- A developer opens a pull request against the branch tracked by a VCS-connected HCP Terraform workspace, and HCP Terraform posts a speculative plan back to the PR. The developer then pushes two more co
- A VCS-connected HCP Terraform workspace tracks the `production` branch. A developer pushes a commit to a separate `feature/logging` branch and, as a separate action, opens a pull request from `feature
- A VCS-connected HCP Terraform workspace tracks the `main` branch. A developer pushes a commit directly to `main`, not through a pull request, expecting HCP Terraform only to preview the change. Given