Terraform Associate
Deep Dive
HCP Terraform (formerly Terraform Cloud) is HashiCorp's SaaS platform for teams. Understanding its organizations/workspaces model, VCS integration, remote execution, and Sentinel policies is essential for the exam.
Contents
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.
In HCP Terraform, organizations are the top-level container. Workspaces are isolated working environments within an organization.
| Concept | Description |
|---|---|
| Organization | Root container in HCP. Can have multiple teams, workspaces, and members. Has its own subscription plan. |
| Workspace | Unit of work. Has: its own state, its own variables, VCS configuration, run history, and access permissions. |
| Run | Execution of a plan or apply. Recorded with its output, who ran it, and when. |
| Team | Group of users with specific permissions over workspaces or projects. |
| Workspace variable | A 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 state, variables, history, VCS, and permissions — they are completely different concepts.
VCS integration connects an HCP Terraform workspace to a code repository (GitHub, GitLab, Bitbucket, Azure DevOps). This is a core exam topic.
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.
When a merge happens, HCP runs a full plan. Depending on the configuration, the apply can be automatic or require manual confirmation.
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 locallyIn 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
Remote state in HCP
# 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 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 case | Without variable sets | With variable sets |
|---|---|---|
| AWS credentials | Configure AWS_ACCESS_KEY_ID in every workspace (50+ workspaces = 50+ configurations) | One variable set with the credentials, applied to all workspaces at once |
| Required tags | Define TF_VAR_team in every workspace | Global variable set with the tagging vars |
| Region config | Duplicate aws_region in every production workspace | "prod-config" variable set applied to all prod workspaces |
Sentinel 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 level | Description | What happens if it fails |
|---|---|---|
| advisory | Informational. The policy is evaluated but doesn't block anything. | The apply continues with a visible warning |
| soft-mandatory | Mandatory but can be bypassed with sufficient permissions. | Blocks the apply. A user with permissions can override it. |
| hard-mandatory | Absolutely 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.
| Tier | Managed resources | Concurrent runs | Extra features |
|---|---|---|---|
| Free | Up to 500 | 1 run | Unlimited users, remote state, remote execution, VCS, private registry, SSO, basic policy as code |
| Essentials | Pay per resource | 3 runs | Free without the 500-resource cap: for small teams |
| Standard | Pay per resource | 10 runs | Collaboration and governance at scale (teams, policies, workflows) |
| Premium | Pay per resource | 200 runs | Maximum scale and advanced governance and compliance features |
| Terraform Enterprise | Per license | Configurable | Self-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?
Put what you learned to the test with original Terraform Associate exam questions.
Start Terraform Associate mock examUnlimited mock exams with the Pro plan
Log in to track your progress.