HCP Terraform

HCP Terraform (formerly Terraform Cloud) runs the same write, plan, apply workflow you already use from the command line, except the plan and apply execute on HCP Terraform's own disposable virtual machines (VMs) and the state lives remotely in a workspace instead of in a local file. Think of a run as one plan-and-apply cycle the platform manages end to end. Relocating that workflow into one consistent managed place is the whole point: it gives shared run history, cost estimation, policy enforcement, and team collaboration a place to live that a bare local run never has. So carry one mental model through this domain: everything here is either the remote run engine itself or a governance and collaboration capability that rides on it. The trap that model helps you dodge is the word workspace. An HCP Terraform workspace is a whole managed working directory with its own state, variables, and runs, not the Terraform command-line interface (CLI) feature of the same name that only keeps several named state files inside one directory.

The material divides into four jobs (run, govern, organize, connect), and each subtopic owns one. Running infrastructure comes first: how a run executes (its execution mode, one of remote, agent, or local), the ordered stages it passes through, and whether a version control system (VCS), the CLI, or the platform's application programming interface (API) starts it, all covered in Use HCP Terraform to Create Infrastructure. Governing the shared work comes next, splitting who may act (teams and their scoped permissions) from what may be applied (Sentinel or Open Policy Agent (OPA) policy sets), alongside audit trails and the private registry in HCP Terraform Collaboration and Governance. Organizing the work then arranges everything into a hierarchy of an organization, its projects, and their workspaces in Organizing HCP Terraform Workspaces and Projects. Connecting your CLI to all of it comes last, wiring a local configuration to the platform with the cloud block, terraform login, and workspace variables in Configure and Use HCP Terraform Integration.

HCP Terraform's defaults are the managed ones: remote execution, remote per-workspace state, and a manual apply that pauses for human confirmation before touching infrastructure. When a scenario adds shared state, remote runs that no single laptop owns, policy gates, or cross-team review, the answer lives in this domain rather than in a local-CLI mechanism. Two habits resolve most questions here. First, place a feature by the run: cost estimation and policy checks sit between the plan and the apply, so a failing mandatory policy stops a non-compliant run before any change is made. Second, place it by edition: single sign-on (SSO) and the private registry reach every tier including Free, while custom teams, audit trails, and health assessments require a paid edition, and that Free-versus-paid line is what the exam probes most. One rule underpins the access side throughout: permissions attach to teams, never to individual users.