Study guide
13.1 Create Infrastructure with HCP Terraform
HashiCorp Certified: Terraform Associate 004
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Format, Delivery, Retakes, and Recertification 1.3 004 Changes, Terraform 1.12, and Study Plan
2 Infrastructure as Code with Terraform
2.1 What Infrastructure as Code Is 2.2 Advantages of IaC Patterns 2.3 Multi-Cloud, Hybrid, and Service-Agnostic Workflows
3 Terraform Fundamentals: Providers & State
3.1 Install and Version Terraform Providers 3.2 How Terraform Uses Providers 3.3 Configuration with Multiple Providers 3.4 How Terraform Uses and Manages State
4 Core Terraform Workflow: Init & Validate
4.1 The Terraform Write–Plan–Apply Workflow 4.2 Initialize a Working Directory 4.3 Validate a Configuration
5 Plan, Apply, Destroy, and Formatting
5.1 Generate and Review an Execution Plan 5.2 Apply Changes to Infrastructure 5.3 Destroy Terraform-Managed Infrastructure 5.4 Formatting and Style Adjustments
6 Resources, Data Sources, and References
6.1 Resource Blocks vs Data Blocks 6.2 Resource Attributes and Cross-Resource References 6.3 Resource Addressing and Interpolation Patterns
7 Variables, Outputs, and Complex Types
7.1 Input Variables, tfvars, and Precedence 7.2 Output Values 7.3 Complex Types: list, map, object, tuple, set
8 Dynamic Configuration and Dependencies
8.1 Expressions, count, for_each, and dynamic Blocks 8.2 Built-in Functions 8.3 Dependencies, depends_on, and Lifecycle Rules
9 Conditions, Secrets, and Sensitive Data
9.1 Custom Conditions: validation, precondition, postcondition, check 9.2 Sensitive Data Handling 9.3 Vault, Ephemeral Values, and Write-Only Arguments
10 Terraform Modules
10.1 How Terraform Sources Modules 10.2 Variable Scope within Modules 10.3 Using Modules in Configuration 10.4 Managing Module Versions
11 Terraform State Management
11.1 The Local Backend 11.2 State Locking 11.3 Remote State and the backend Block 11.4 Resource Drift and State Operations
12 Maintain Infrastructure with Terraform
12.1 Import Existing Infrastructure 12.2 Inspect State with the CLI 12.3 Verbose Logging and Diagnostics
13 HCP Terraform
13.1 Create Infrastructure with HCP Terraform 13.2 Collaboration and Governance Features 13.3 Workspaces and Projects 13.4 HCP Terraform Integrations
13.1 Create Infrastructure with HCP Terraform
Key Takeaways Explain This Topic AI
HCP Terraform (formerly Terraform Cloud) is HashiCorp's SaaS platform: it stores workspace state and, by default, runs plan and apply on remote workers
The three HCP run workflows are UI/VCS-driven (primary), CLI-driven via a cloud block, and API-driven; each still produces a remote plan before any apply
A terraform cloud block names the organization and selects workspaces by name or by tags (not both); optional project and hostname default to app.terraform.io
Remote execution is the workspace default; Local execution keeps state in the HCP workspace but runs Terraform on your machine and disables policy, cost estimates, and notifications
004 requires the edition split: Terraform Community is the free CLI, HCP Terraform is the hosted product, and Terraform Enterprise is the self-hosted distribution
Last updated: August 2026
13.1 Create Infrastructure with HCP Terraform
Quick Answer: Add a cloud block, run terraform login and terraform init , then start runs from VCS, the CLI, or the API. HCP Terraform stores that workspace's state and, unless you switch the execution mode to Local, performs plan and apply on remote workers. UI/VCS is the primary workflow. Do not put a backend block next to cloud .
Objective 8a on Terraform Associate (004) asks you to use HCP Terraform to create infrastructure. Product version on the exam is Terraform 1.12 . Official references: What is HCP Terraform? , Connect to HCP Terraform , Remote operations , and Terraform Editions .
HashiCorp renamed the hosted product HCP Terraform . Older docs, blogs, and exam stems may still say Terraform Cloud. That is the same SaaS, not a second product. Use HCP Terraform as the current name after this mention.
Community, HCP Terraform, and Terraform Enterprise
004's audience must tell HashiCorp's editions apart. The official editions page lists three products, not three prices:
Edition Where it runs What you get that 004 cares about
Terraform Community Your workstation or CI image Free downloadable CLI. You write HCL, init/plan/apply locally, and manage state yourself (local file or a backend you configure). No hosted run queue, no Sentinel/OPA gate, no HCP private registry, no HCP teams.
HCP Terraform HashiCorp SaaS ( app.terraform.io by default) Remote state, remote operations, VCS hooks, CLI and API workflows, RBAC, a private registry, and optional policy and cost estimation. A Free organization exists; paid Essentials / Standard / Premium editions add collaboration and governance capacity.
Terraform Enterprise You host it A self-hosted distribution of HCP Terraform for air-gapped, private-network, or dedicated-capacity requirements. Feature names match HCP Terraform; install and networking are the Enterprise-only part.
Do not invent dollar amounts or resource-hour rates on the exam. When a feature is edition-gated, HashiCorp's cloud-docs say so next to that feature. Community cannot "turn on Sentinel locally" and call it HCP Terraform. Enterprise is not Community with a bigger laptop.
Why a remote run exists
Community Terraform is a local workflow: the CLI on the machine that invoked it reads the working directory, talks to providers, and writes terraform.tfstate . That is enough for one engineer. A team needs a shared state file, a consistent Terraform version, an audit trail, and a place to approve applies. HCP Terraform is that remote workflow.
A workspace is the remote equivalent of a working directory. It holds the configuration version, the variable set used for the run, the state snapshot, and the run history. Every HCP run happens in a workspace. You cannot manage resources in HCP Terraform without at least one workspace.
By default HCP Terraform performs remote operations on disposable Linux VMs that it owns. You can instead attach HCP Terraform agents (a paid feature) so the same remote-operations contract runs on your private network. You can also set the workspace execution mode to Local , which turns the workspace into a remote state store only.
Remote execution is what unlocks Sentinel or OPA evaluation, cost estimation, run notifications, and VCS-driven applies. Local execution does not evaluate those features.
Three ways to start a run
HashiCorp documents three run workflows. They all produce a plan first, then (if allowed) an apply. They differ in who uploads the configuration and what is allowed to apply .
Workflow How configuration arrives Typical trigger When 004 wants this answer
UI / VCS-driven (primary) HCP Terraform clones the linked repo at a commit Merge to the tracked branch starts a real run; a pull request starts a speculative plan Team source of truth is Git
CLI-driven The local working directory is archived and uploaded terraform plan / terraform apply after a cloud block and terraform init Developer loop, or CI that already speaks the CLI
API-driven An orchestrator uploads a configuration version , then creates a run Your pipeline calls the Runs API Unsupported VCS, custom gates, or non-interactive automation
UI/VCS is the default you should picture first. Connecting a workspace to GitHub, GitLab, Bitbucket, or Azure DevOps registers a webhook. New commits on the workspace branch queue a run. Pull requests get a speculative (plan-only) run so reviewers can see the plan without changing infrastructure.
CLI-driven runs need Terraform 1.1+ for the cloud block (1.12 is well past that). Authenticate with terraform login (preferred) or credentials in the CLI config file. Then:
terraform plan starts a speculative plan in the workspace. It works even on VCS-connected workspaces. It cannot apply.
terraform apply starts a full remote plan-and-apply. HashiCorp allows this only when the workspace is not linked to a VCS repository. The repo is the source of truth; you apply VCS workspaces by merging.
Saved plans ( terraform plan -out then terraform apply <file> ) need CLI 1.6+ and the same non-VCS rule.
API-driven workflow is for an orchestrator that can watch your code and call HCP Terraform. You upload a configuration version, create a run, and optionally apply. It is more flexible and more work. 004 does not ask you to memorize endpoint paths; it asks you to know the API is a first-class third workflow, not a secret back door around state.
A workspace queues runs. A new run stays pending until the current run finishes, because the current apply may change what the next plan would do. Speculative plans are the exception: they do not write state, so they can start without waiting.
The cloud block
The current way to point Terraform 1.12 at HCP Terraform is a cloud block inside terraform { } . It is not a backend block. You cannot combine cloud and backend . terraform {
- cloud {
- organization = "my-org"
- hostname = "app.terraform.io" # optional; this is the default
- workspaces {
- project = "networking-development" # optional
- tags = {
- layer = "networking"
- source = "cli"
- }
- }
- }
- }
Required pieces HashiCorp lists:
organization — the HCP Terraform organization name.
workspaces.name or workspaces.tags — pick one. name pins a single existing (or implicitly created) workspace. tags links the working directory to every workspace in the organization (and optional project) that matches those tags. If none match, terraform init can prompt you to create one.
workspaces.project — optional project name so name/tag matching happens inside that project.
hostname — optional. Default is app.terraform.io . Terraform Enterprise and HCP Europe use a different hostname.
Do not put an API token in the cloud block. Use terraform login .
After you add or change the block, run terraform init . If the working directory already has local or backend state, init migrates it. If the directory was using backend "remote" , replace that block with cloud and keep the same workspace; the prefix argument does not exist on cloud (use tags, and select workspaces by their full HCP names).
CLI-driven remote plan/apply uploads the configuration directory. Add .terraformignore (gitignore syntax) at the root to exclude secrets or huge trees. If the file is missing, Terraform still skips .git/ and .terraform/ (except .terraform/modules ).
Remote versus local execution
Setting Where plan/apply run Where state lives Policy, cost estimate, notifications
Remote (default, or Project Default → Remote) HCP disposable VMs (or an agent pool) The HCP workspace Available
- Local Your laptop or CI runner Still the HCP workspace Not evaluated
- Agent Your self-hosted agent The HCP workspace Remote-operations features; agent is a paid add-on
Local mode is how you keep using terraform plan on a workstation while the snapshot stays locked and versioned in HCP. The workspace still exists. Teammates still read the same state. You just gave up the hosted runner.
HCP Terraform does not remotely execute terraform import . Import (and several state-mutation commands) run locally against the workspace as a remote state store. Import blocks in configuration are the recommended 1.5+ / 1.12 path for bringing objects under management during a remote run.
Scenario: Priya ships the first VPC
Priya's org already has HCP Terraform. She writes a root module, adds a cloud block with organization = "acme" and workspaces { name = "net-prod-use1" } , runs terraform login and terraform init , and sets AWS credentials as workspace environment variables (not on her laptop). terraform plan streams a speculative plan from app.terraform.io . Because this workspace is CLI-driven (no VCS), terraform apply runs the plan remotely, stores state in net-prod-use1 , and leaves a run URL her teammates can open. If she later connects the same workspace to GitHub, terraform apply from her laptop will be refused; merges become the apply path.
004 traps for objective 8a
HCP Terraform is the current product name; Community is the CLI; Enterprise is self-hosted HCP Terraform.
Three workflows: VCS (primary), CLI, API. All of them can create infrastructure; they are not mutually exclusive across an organization.
cloud uses organization + workspaces.name or tags . There is no prefix on cloud .
terraform plan against HCP is speculative. terraform apply is blocked on VCS-connected workspaces.
State lives in the HCP workspace , even when execution is Local.
cloud and backend cannot appear together.