HCP Terraform Study Guide — 004

HCP Terraform

This domain covers the hosted and enterprise-grade features that HashiCorp builds on top of core Terraform: collaborative workspaces, remote execution, version-control integration, policy enforcement, cost controls, and module sharing. HashiCorp does not publish objective weightings for Terraform Associate 004, so this is one of the estimated-even-weight topic areas under the current blueprint rather than a confirmed 6%; treat any question-count figure as unverified. Questions test whether you can distinguish HCP Terraform concepts from CLI-only behavior, identify correct tier requirements, and reason through workflow steps in sequence.

HCP Terraform Workspaces vs CLI Workspaces

Core Distinction

CLI workspaces live inside a single backend configuration and share the same Terraform configuration files. They only isolate state. HCP Terraform workspaces are independent units: each has its own state file, variable values, run history, VCS connection, team access, and notification settings.

What "Remote Backend" Means Here

When you configure backend "remote" (or the newer cloud block) in terraform.tf, CLI runs are forwarded to HCP Terraform. The workspace name in the cloud block must match an existing HCP Terraform workspace. Operations appear as runs in the HCP Terraform UI.

terraform {
  cloud {
    organization = "my-org"
    workspaces {
      name = "production-vpc"
    }
  }
}

Common Traps

• The exam frequently presents CLI workspaces as a substitute for HCP Terraform workspaces — they are not equivalent; CLI workspaces do not provide team access or run history.
• A HCP Terraform workspace using the cloud block does not support terraform workspace select to switch between HCP Terraform workspaces from the CLI.
• The workspaces { tags = [...] } option in the cloud block allows a single CLI configuration to target multiple HCP Terraform workspaces by tag, but you must still terraform workspace select among them locally.

Remote Execution: Runs, Plans, Applies

Remote execution means HCP Terraform's worker agents perform plan and apply operations in a managed, isolated environment — not on the operator's local machine.

Run Lifecycle

How an HCP Terraform run progresses from trigger to completion.

Run Types

Execution Modes

HCP Terraform Agents are required (and are a paid HCP Terraform capability, not part of the free offering, or available via Terraform Enterprise) when your infrastructure resides on private networks without internet access.

Auto-Apply

When auto-apply is enabled on a workspace, confirmed plans apply immediately without human approval. When disabled (default), an operator must confirm in the UI or via API. Auto-apply is set per workspace.

Common Traps

• A speculative plan (from a PR) cannot be applied — it is read-only and for review only.
• Disabling auto-apply does not skip policy checks; policy checks always run between plan and apply.
• Remote execution mode is the default for new workspaces; local mode must be explicitly selected.
• Agents run outside HCP Terraform infrastructure — the agent polls HCP Terraform for jobs; HCP Terraform does not push to the agent.

Worked Scenario

Requirement: Your team's AWS infrastructure is in a VPC with no internet gateway. HCP Terraform's SaaS runners cannot reach it. What execution mode do you choose?

Reasoning: Remote execution mode uses HashiCorp-managed workers that must reach your endpoints over the internet. Local mode stores state in HCP Terraform but runs locally — feasible but not automated. Agent mode with a self-hosted agent deployed inside the private VPC is the correct answer; the agent initiates outbound connections to HCP Terraform, so no inbound connectivity is needed.