Everything about Terraform you learn first — init, plan, apply, a terraform.tfstate file on your laptop — works beautifully for one person on one project. It falls apart the moment a team shares infrastructure: state files drift out of sync, two people apply at once, secrets end up in plaintext on disk, and nobody can see who changed what. HCP Terraform is HashiCorp’s answer to that problem, and it’s a testable objective on the exam: understand HCP Terraform capabilities.
The HashiCorp Terraform Associate (003) exam expects you to know what HCP Terraform does, how its remote backend and remote runs work, the difference between its workspaces and the CLI workspaces you already know, and how it enables collaboration and governance. This guide walks all of that with copy-ready config. If you want the full blueprint first, start with the Terraform Associate exam guide for 2026 and the 30-day study plan. Because this is fundamentally about state, it also pays to be solid on state management before diving in.
”Terraform Cloud” and “HCP Terraform” Are the Same Product
First, clear up the naming, because it trips people up. In 2024, HashiCorp renamed Terraform Cloud to HCP Terraform (HCP = HashiCorp Cloud Platform). The product, workflows, and concepts are identical — only the name changed. Older study material, and some exam-adjacent wording, still says “Terraform Cloud.” For the exam, treat the two names as interchangeable and focus on capabilities, not branding. There’s also Terraform Enterprise, the self-hosted version you run in your own environment; it offers the same features for organizations with data-residency or air-gap requirements.
The Problem HCP Terraform Solves
Run Terraform locally on a team and you hit predictable walls:
- State on laptops. The
terraform.tfstatefile holds the mapping between config and real resources — including sensitive values. Passing it around, or committing it to Git, is both fragile and a security risk. - No locking. If two engineers
applyat the same time against the same state, they corrupt it. - No shared history. There’s no record of who ran what, when, or what it changed.
- Secrets in the open. Provider credentials and variables live in shell history,
.tfvarsfiles, or CI logs.
You can solve state alone with a remote backend like S3 + DynamoDB, but you still stitch together locking, secrets, run history, and policy yourself. HCP Terraform bundles all of it into one managed service — which is exactly why the exam frames it as the collaboration-and-governance layer on top of core Terraform.
The Remote Backend: Managed, Locked, Encrypted State
The foundation is that HCP Terraform stores your state for you. You connect to it with a cloud block (the modern form) inside the terraform block:
terraform {
cloud {
organization = "my-org"
workspaces {
name = "my-app-prod"
}
}
}The older equivalent is the remote backend:
terraform {
backend "remote" {
organization = "my-org"
workspaces {
name = "my-app-prod"
}
}
}With either in place, terraform init connects the working directory to HCP Terraform. From then on:
- State is stored and encrypted at rest in HCP Terraform, not on your machine.
- Locking is automatic — concurrent runs queue instead of clobbering each other.
- State is versioned, so you can review history and roll back.
You authenticate the CLI once with:
terraform loginwhich stores an API token at ~/.terraform.d/credentials.tfrc.json. After that, init against the cloud block just works.
Remote Runs: Where plan and apply Execute
The second big shift is where your runs happen. By default, once a directory is connected to HCP Terraform, terraform plan and terraform apply execute remotely on HCP Terraform’s managed run environment, not on your laptop. You still type the commands locally, but the logs stream back from the remote run.
Why this matters for the exam and in practice:
- Consistent execution environment. Everyone’s runs use the same Terraform version and the same variables, eliminating “works on my machine.”
- Centralized credentials. Cloud provider secrets live in the workspace, not on every engineer’s laptop.
- A full audit trail. Every run is recorded with its plan output, who triggered it, and the approval.
For workloads that must run inside your own network (to reach private endpoints), HCP Terraform offers agents — self-hosted runners that pull work from HCP Terraform so runs execute in your environment while HCP Terraform still manages state and orchestration.
HCP Terraform Workspaces ≠ CLI Workspaces
This is the distinction the exam loves, and it catches people who studied CLI workspaces first. The two things share a name but are fundamentally different:
| CLI Workspaces | HCP Terraform Workspaces | |
|---|---|---|
| What it is | Multiple named state files inside one backend and one configuration | A managed container for one configuration’s state, variables, and run history |
| Scope | Same config, different state (e.g. dev/prod from one directory) | Usually maps to a distinct working directory / component / environment |
| Holds variables? | No | Yes — Terraform and environment variables, run history, settings |
| Referenced by | terraform.workspace expression | Its own name and settings in HCP Terraform |
In short: a CLI workspace is just an extra state file; an HCP Terraform workspace is a first-class object that owns state plus variables, run history, permissions, and policy. Most teams map one HCP Terraform workspace to one environment or component. For the CLI-workspace mechanics and when to prefer directories instead, see the Terraform workspaces guide.
The Three Workflows
HCP Terraform can be driven three ways. Knowing which is which is a classic exam point:
| Workflow | How runs are triggered | Best for |
|---|---|---|
| VCS-driven | Commits and pull requests in a connected Git repo | Teams that want Git as the source of truth; PRs get speculative plans |
| CLI-driven | terraform plan / apply from your machine against a remote run | Developers who want the local CLI experience with remote state and runs |
| API-driven | Calls to the HCP Terraform API (or automation tooling) | Custom pipelines and integrations |
The VCS-driven workflow is the flagship: you connect a repository, and thereafter a push to the tracked branch queues a run, while a pull request gets a speculative plan — a plan-only preview of what the change would do, posted back for review before anyone merges. Applies can be set to require manual approval or to run automatically. This is how Terraform becomes a reviewed, GitOps-style process rather than something one person runs from a terminal.
Variables and Secrets
An HCP Terraform workspace stores variables so they’re not scattered across .tfvars files and shells. There are two categories, and the exam expects you to know the difference:
- Terraform variables — the input variables your configuration declares (
var.instance_type). These populate yourvariableblocks. - Environment variables — exported into the run environment (for example
AWS_ACCESS_KEY_ID), used to authenticate providers.
Any variable can be marked sensitive, which write-protects it and hides its value in the UI and logs. To avoid re-entering the same values in every workspace, variable sets let you define a group of variables once and apply it across many workspaces — the clean way to share, say, one set of cloud credentials org-wide. This connects directly to the variables, outputs, and locals fundamentals.
The Private Module Registry
HCP Terraform includes a private module registry for publishing and consuming your organization’s own modules — the internal counterpart to the public Terraform Registry. Modules are versioned, and consumers reference them with a registry-style source address:
module "network" {
source = "app.terraform.io/my-org/network/aws"
version = "1.2.0"
cidr_block = "10.0.0.0/16"
}This gives teams a governed, versioned catalog of approved building blocks instead of copy-pasting module code or pointing at random Git URLs. If you’re shaky on module structure and versioning, the modules complete guide covers the fundamentals the registry builds on.
Governance: Policy as Code with Sentinel
The “governance” half of HCP Terraform is policy as code, and its headline tool is Sentinel, HashiCorp’s policy framework (HCP Terraform also supports OPA/Rego policies). Policies run between plan and apply, inspecting the planned changes and deciding whether the run may proceed. That placement is the key idea: a bad change is stopped before it touches real infrastructure.
Sentinel policies have three enforcement levels:
| Level | Effect |
|---|---|
| advisory | Logs a warning if the policy fails; the run continues |
| soft-mandatory | Fails the policy, but an authorized user can override and proceed |
| hard-mandatory | Fails the policy and blocks the apply — no override |
A trivial Sentinel policy — “all EC2 instances must be a permitted type” — looks like:
import "tfplan/v2" as tfplan
allowed_types = ["t3.micro", "t3.small"]
main = rule {
all tfplan.resource_changes as _, rc {
rc.type is "aws_instance" implies
rc.change.after.instance_type in allowed_types
}
}Related governance features include cost estimation (HCP Terraform estimates the monthly cost delta of a plan before you apply) and run tasks (hooks that call external systems — security or compliance scanners — during a run). Policy enforcement, cost estimation, and similar governance features live on HCP Terraform’s paid tiers; the Free tier still gives you remote state, remote runs, VCS integration, and the private registry, which covers most of what a small team needs. The exam cares about what these features do and where they run, not their pricing.
What the Terraform Associate Exam Actually Asks
Objective 9 is conceptual — you won’t configure a Sentinel policy from scratch under a timer. Focus on being able to answer:
- HCP Terraform stores and locks state remotely and runs plan/apply remotely for a consistent, auditable environment.
- Its workspaces are richer than CLI workspaces — they own variables, run history, and settings.
- It supports VCS-, CLI-, and API-driven workflows, with speculative plans on pull requests.
- It enables collaboration (shared state, variable sets, private registry) and governance (Sentinel/OPA policy as code, cost estimation).
Common Terraform Associate Traps
| Trap | The clarification |
|---|---|
| Confusing CLI workspaces with HCP workspaces | CLI workspaces are extra state files in one config; HCP workspaces own state plus variables, history, and settings |
| Thinking runs still execute locally | With a cloud/remote backend, plan and apply run remotely by default; you just see the streamed logs |
| Assuming Sentinel runs after apply | Policies run between plan and apply, so violations block changes before they reach infrastructure |
Forgetting terraform login | The CLI needs an API token (terraform login) before init can connect to HCP Terraform |
| Believing “Terraform Cloud” is a different product | It’s the former name of HCP Terraform — same service, renamed in 2024 |
| Mixing up variable categories | Terraform variables feed variable blocks; environment variables authenticate providers in the run environment |
Frequently Asked Questions
Is HCP Terraform the same as Terraform Cloud?
Yes. HashiCorp renamed Terraform Cloud to HCP Terraform in 2024. The capabilities, workflows, and concepts are identical — only the name changed. Older documentation and some study material still say “Terraform Cloud,” so treat them as the same product on the exam.
How does HCP Terraform manage state?
It stores your state remotely, encrypted at rest, with automatic locking so concurrent runs can’t corrupt it, and it versions state so you can review history. You connect a configuration to it with a cloud block (or the remote backend) and terraform init, after which state never lives on your local machine.
What’s the difference between a CLI workspace and an HCP Terraform workspace?
A CLI workspace is just an additional named state file within a single backend and configuration, referenced by terraform.workspace. An HCP Terraform workspace is a managed object that owns a configuration’s state, variables, run history, permissions, and policies — usually mapped to one environment or component.
What are the three HCP Terraform workflows?
VCS-driven (runs triggered by commits and pull requests in a connected Git repo, with speculative plans on PRs), CLI-driven (you run terraform plan/apply locally but they execute remotely), and API-driven (runs triggered through the HCP Terraform API for custom automation).
What is Sentinel and when does it run?
Sentinel is HashiCorp’s policy-as-code framework. Its policies run between plan and apply, so they can block a change before it’s applied. Policies have three enforcement levels — advisory (warn), soft-mandatory (override allowed), and hard-mandatory (hard block). HCP Terraform also supports OPA/Rego policies.
Do I need a paid plan to use HCP Terraform?
No. The Free tier covers remote state, remote runs, VCS integration, and the private module registry — enough for a small team. Governance features like Sentinel policy enforcement and cost estimation are on paid tiers. The exam focuses on what the features do, not on pricing.
Conclusion
HCP Terraform is the bridge from Terraform-as-a-personal-tool to Terraform-as-a-team-practice. It takes the three things that break at scale — shared state, safe execution, and governance — and manages them: state is stored, locked, and versioned; plan and apply run in a consistent remote environment; workspaces hold variables and history; the private registry shares approved modules; and Sentinel enforces policy before changes land. For the exam, know the capabilities and the CLI-vs-HCP-workspace distinction cold, and the Objective 9 questions become straightforward.
The fastest way to lock in these concepts is scenario practice under exam conditions. Sailor.sh’s HashiCorp Terraform Associate Mock Exam Bundle includes full-length, exam-style question sets with detailed explanations across every objective — including HCP Terraform, state, and workflow questions like the ones above. Pair it with the Terraform Associate study plan, reinforce the fundamentals through the core workflow and state management guides, and drill your recall with Terraform Associate practice questions.