Terraform Associate 004 #9 HCP Terraform: Workspaces, Variable Sets, Policies, and Drift Detection

Infrastructure Terraform IaC Certification
5 min read

The last exam area is HashiCorp’s managed platform, HCP Terraform (better known by its old name, Terraform Cloud — the exam and the docs may mix the two names). In the track we only touched it as one row of the platform comparison in Ops #6, but 004 widened this domain’s coverage, so the concept structure deserves a proper build-out. So that the questions can be answered without hands-on practice, we organize everything around structure: what contains what, and what runs where.

Workspace: not the same thing as the CLI command #

Start with the most important distinction. An HCP Terraform workspace shares only its name with the CLI’s terraform workspace command — they are different concepts.

  • CLI workspaces: a local feature that keeps multiple copies of state for the same configuration (the one whose limits we examined and declined to adopt in Practice #9).
  • HCP workspace: the platform’s unit of management. The state, variables, run history, and permissions for one configuration (usually one repository or one directory) are bundled into a single workspace. In local terms, it corresponds to “one backend key plus its operations screen.”

This distinction is itself a staple question. And a project is a higher-level folder that groups multiple workspaces, serving as the permission-management boundary for a team or a service. The structure is three layers: “organization → project → workspace.”

How runs start: VCS, CLI, API #

There are three ways a plan or apply gets started in HCP Terraform, and each has its own character.

  1. VCS-driven: connect a repository to a workspace, and a plan is attached to each PR while merging triggers an apply. It is the built-in version of the flow we assembled by hand with GitHub Actions in Ops #1, and the “team standard” route the exam expects.
  2. CLI-driven: you type terraform commands locally, but execution happens in HCP’s remote environment. The configuration connects through its cloud block.
  3. API-driven: an external system triggers runs through the API. Meant for custom pipelines.

The shared benefits of remote execution are that credentials and state never sit on a local machine, and that run history stays on the platform. For run trigger (a completed apply in one workspace kicking off a run in another workspace), it is enough to know its position: the platform-feature counterpart of the cross-stack dependencies from Ops #5.

Variables and variable sets #

A workspace can hold Terraform variables and environment variables, and both can be marked sensitive. The exam point is the variable set: a bundle of variables injected into multiple workspaces at once, and the standard way to “supply the same cloud credentials to every workspace.” Options that copy and register the values per workspace point toward the wrong answer, and for precedence, workspace-specific variables override a variable set (the narrower scope wins — the same consistent principle we have followed since Basics #3).

Policies: Sentinel, OPA, and two kinds of failure #

Policy as code inserts rule checks between plan and apply. You write policies in HashiCorp’s Sentinel or in OPA, and rules like “instance types only from the allowlist” or “tags are required” are evaluated against the plan result. The exam’s distinguishing point is the severity of a failure.

  • hard-mandatory: a violation always blocks the run. No override.
  • soft-mandatory: a violation blocks the run, but someone with the right permission can explicitly override it and proceed.
  • advisory: only a warning is recorded, and the run proceeds.

Thinking of this as the platform’s built-in edition of the guardrails we assembled as scanners in CI in Ops #4 puts it in the right place.

Drift detection and the rest #

  • Drift detection: the platform periodically compares real infrastructure against state and reports any divergence. It is the built-in edition of the detector we built ourselves with a cron workflow in Ops #2. It is part of health assessments, and comes paired with continuous validation (continuous evaluation of the configuration’s check blocks — the same check from #7).
  • Private registry: a module and provider registry private to the organization. For distributing organization-standard modules, this is the right-answer direction.
  • Terraform Enterprise: the self-hosted edition of HCP Terraform. The features are the same family; only the installation location differs, and that is the distinction the exam draws.

Pricing-tier details are general knowledge more than exam material: a free tier exists, and policy and governance features open up at the higher tiers — that much is enough.

Recap #

What this post covered.

  • An HCP workspace is a different concept from a CLI workspace: a unit of management holding state, variables, and run history, with project as the grouping above it
  • Runs start through three routes — VCS, CLI, and API — and VCS-driven is the team-standard route. Run triggers connect dependencies between workspaces
  • A variable set is the standard way to supply shared variables to multiple workspaces, and workspace-specific variables take precedence
  • Policies written in Sentinel or OPA are evaluated between plan and apply, and the hard-mandatory, soft-mandatory, and advisory severity distinction is an exam axis
  • Drift detection and continuous validation are built-in editions of the mechanisms we assembled by hand in the track, and Enterprise is the self-hosted edition

The next post (#10 practice exam) is the last one. We draw 50 questions from the full range of all nine parts and work through them with explanations.

X