HCP Terraform Workflows and CLI Integration

What it is

HCP Terraform (formerly Terraform Cloud) runs Terraform for you as a hosted service. It stores each workspace's state, keeps variables and credentials secure, runs plans and applies on disposable machines it manages, and records every run.

You create infrastructure in HCP Terraform through one of three workflows, and you connect a local configuration to it with terraform login and the cloud block.

How it works

The three run workflows

In the VCS driven workflow, a pull request triggers a speculative plan: a plan only run that shows the effect of the change and cannot be applied. Merging to the tracked branch queues a real run. A workspace connected to VCS does not accept terraform apply from the CLI; changes must come through the repository.

A run in HCP Terraform

A run moves through stages: plan, then optional cost estimation and policy checks, then apply. Run tasks can call outside tools at set points, such as before or after the plan. If auto apply is off, someone with apply permission must confirm the plan before it is applied.

Every run, its logs and the state it produced stay in the workspace history. Each workspace also selects the Terraform version its runs use, and you upgrade it in the workspace settings.

Logging in from the CLI

terraform login

terraform login opens a browser so you can create an API token, then saves it in the CLI credentials file (credentials.tfrc.json). For Terraform Enterprise, pass the hostname, as in terraform login tfe.example.com. Avoid putting tokens in configuration.

The cloud block

terraform {
  cloud {
    organization = "acme"
    workspaces {
      project = "networking"
      name    = "network-prod"
    }
  }
}

A configuration uses the cloud block or a backend block, never both. Environment variables can fill missing values: TF_CLOUD_ORGANIZATION, TF_CLOUD_HOSTNAME, TF_CLOUD_PROJECT and TF_WORKSPACE. If you rely only on these, you still need an empty cloud {} block, and values in the block take precedence.

Migrating local state to HCP Terraform

Add the cloud block to a configuration that already has local state, then run terraform init. Terraform detects the change and offers to migrate the existing state into the HCP Terraform workspace. After migration, the workspace holds the state and you can remove the local terraform.tfstate file.

Execution modes

In remote mode, terraform plan and terraform apply from the CLI stream output from the remote run, and workspace variables are used. In local mode, HCP Terraform only stores state, and workspace variables and variable sets are not evaluated. Agent mode suits private or on premises infrastructure that HCP Terraform cannot reach directly.

Sharing values between workspaces

A workspace can read another workspace's root outputs with the terraform_remote_state data source, given access. Run triggers connect workspaces so that a successful apply in a source workspace queues a run in the dependent one.

How the exam asks about this

• "Developers must review infrastructure changes as pull requests before anything is applied." Use the VCS driven workflow; pull requests get speculative plans.
• "You want CLI plan and apply but with state and runs in HCP Terraform." Add a cloud block, run terraform login and terraform init.
• "Runs must reach servers in a private data center." Use agent execution mode.