All guides
Practice now
D7 · Implementation and maintenance

HCP Terraform: workspaces, VCS, and governance

is HashiCorp's SaaS platform for teams. Understanding its organizations/workspaces model, VCS integration, remote execution, and Sentinel policies is essential for the exam.

HCP Terraform overview

HCP Terraform (HashiCorp Cloud Platform Terraform, formerly Terraform Cloud) is HashiCorp's SaaS service that adds collaboration, governance, and automation on top of the Terraform CLI.

URL: app.terraform.io. Access via terraform login.

Remote state

State is stored in HCP with encryption, versioning, and automatic locking.

Remote execution

Plans and applies run on HCP agents, not on your local machine.

VCS integration

Connects to GitHub/GitLab. PRs automatically trigger speculative plans.

Governance

Sentinel and OPA policies to validate changes before the apply.

Variable sets

Reusable sets of variables across multiple workspaces.

Private registry

Publish internal modules accessible from all workspaces in the organization.

Organizations and workspaces

In HCP Terraform, organizations are the top-level container. are isolated working environments within an organization.

ConceptDescription
OrganizationRoot container in HCP. Can have multiple teams, workspaces, and members. Has its own subscription plan.
WorkspaceUnit of work. Has: its own state, its own variables, VCS configuration, run history, and access permissions.
RunExecution of a plan or apply. Recorded with its output, who ran it, and when.
TeamGroup of users with specific permissions over workspaces or projects.
Workspace variableA Terraform variable or environment variable configured directly in the workspace (overrides tfvars).

💡 HCP workspace ≠ CLI workspace

CLI workspaces (terraform workspace new) are simply multiple states in the same directory. HCP Terraform workspaces are full, independent environments with their own , variables, history, VCS, and permissions — they are completely different concepts.

VCS integration

VCS integration connects an HCP Terraform workspace to a code repository (GitHub, GitLab, Bitbucket, Azure DevOps). This is a core exam topic.

Pull Request / Merge Request→ Speculative Plan

When someone opens a PR, HCP Terraform automatically runs a plan that CANNOT be applied. The result is posted as a comment on the PR so the reviewer can see what will change.

Merge to the main branch→ Full plan + apply

When a merge happens, HCP runs a full plan. Depending on the configuration, the apply can be automatic or require manual confirmation.

Push to other branches→ Nothing (configurable)

By default nothing runs. It can be configured to trigger plans on specific branches.

# Configuring a workspace with VCS in HCP Terraform:
# 1. Connect the VCS provider (GitHub App, GitLab, Azure DevOps)
# 2. In the workspace: Settings → Version Control
# 3. Select the repository and branch to monitor

# In the code, connect using the cloud block:
terraform {
  cloud {
    organization = "my-company"
    workspaces {
      name = "prod-infra"  # workspace connected to the repo
    }
  }
}

# For local runs (without VCS, started from the CLI):
# terraform plan  → runs on HCP agents but is started locally

Remote execution and remote state

In HCP Terraform, plans and applies don't run on your local machine but rather on HCP agents (VMs managed by HashiCorp) or on self-hosted agents (for Terraform Enterprise).

Advantages of remote execution

  • • Consistency: all applies use the same environment
  • • No dependency on the developer's local environment
  • • Logs are centralized in HCP
  • • Credentials don't need to live on the local machine
  • • Complete history of all runs

Remote state in HCP

  • • Automatically encrypted at rest
  • • Automatic locking during each run
  • • Full versioning (you can view previous states)
  • • Accessible from other workspaces via terraform_remote_state
  • • No need to manage your own S3 bucket
# Read outputs from another workspace (terraform_remote_state)
data "terraform_remote_state" "networking" {
  backend = "remote"
  config = {
    organization = "my-company"
    workspaces = {
      name = "prod-networking"
    }
  }
}

# Use the outputs from the networking workspace:
resource "aws_instance" "app" {
  subnet_id = data.terraform_remote_state.networking.outputs.private_subnet_id
}

Variable sets

Variable sets are reusable collections of variables that can be applied to multiple workspaces. They avoid duplicating the same configuration (for example, AWS credentials) in every workspace.

Use caseWithout variable setsWith variable sets
AWS credentialsConfigure AWS_ACCESS_KEY_ID in every workspace (50+ workspaces = 50+ configurations)One variable set with the credentials, applied to all workspaces at once
Required tagsDefine TF_VAR_team in every workspaceGlobal variable set with the tagging vars
Region configDuplicate aws_region in every production workspace"prod-config" variable set applied to all prod workspaces

Sentinel and OPA

is HashiCorp's Policy as Code framework. It lets you define policies that are automatically evaluated before every apply to ensure compliance with regulations.

# Example Sentinel policy
# Requires that all resources have the "Environment" tag
import "tfplan/v2" as tfplan

# Get all resources from the plan
all_resources = filter tfplan.resource_changes as _, resource_change {
  resource_change.mode is "managed" and
  (resource_change.change.actions contains "create" or
   resource_change.change.actions contains "update")
}

# Verify they have the required tag
has_env_tag = rule {
  all all_resources as _, resource {
    resource.change.after.tags["Environment"] is not null
  }
}

# The policy passes if the rule is true
main = rule { has_env_tag }
Enforcement levelDescriptionWhat happens if it fails
advisoryInformational. The policy is evaluated but doesn't block anything.The apply continues with a visible warning
soft-mandatoryMandatory but can be bypassed with sufficient permissions.Blocks the apply. A user with permissions can override it.
hard-mandatoryAbsolutely mandatory. Cannot be bypassed by anyone.Permanently blocks the apply until the config complies with the policy

🎯 Sentinel vs OPA for the exam

Sentinel is HashiCorp's native framework (its own language). Available on HCP Terraform (the Free plan includes it with limits) and on Terraform Enterprise. OPA (Open Policy Agent) is an open source framework that HCP Terraform also supports as an alternative to Sentinel. Both are evaluated between the plan and the apply. The exam tends to ask about Sentinel and its enforcement levels.

Tiers and key features

TierManaged resourcesConcurrent runsExtra features
FreeUp to 5001 runUnlimited users, remote state, remote execution, VCS, private registry, SSO, basic policy as code
EssentialsPay per resource3 runsFree without the 500-resource cap: for small teams
StandardPay per resource10 runsCollaboration and governance at scale (teams, policies, workflows)
PremiumPay per resource200 runsMaximum scale and advanced governance and compliance features
Terraform EnterprisePer licenseConfigurableSelf-hosted version on your own infrastructure

💡 Name changes you should know

Terraform Cloud was renamed HCP Terraform in 2024. The exam may use either name. The legacy Free plan (capped at 5 users) was retired on 3/31/2026; the current Free plan is limited by managed resources, not users. Terraform Enterprise is the self-hosted version that gets installed on your own infrastructure (for companies with compliance requirements that prevent them from using SaaS).

Did you get this topic?

Test what you just learned

A team has VCS integration configured between HCP Terraform and their GitHub repository. A developer opens a Pull Request with infrastructure changes. What happens automatically in HCP Terraform?

Ready to test "HCP Terraform: Workspaces, VCS and Governance"?

Put what you learned to the test with original Terraform Associate exam questions.

Start Terraform Associate mock exam

Unlimited mock exams with the Pro plan

Log in to track your progress.