TF-Associate-004 - HCP Terraform (11% of the exam) - Section 8a

Use HCP Terraform to create infrastructure.

HCP Terraform (formerly Terraform Cloud) runs Terraform remotely with managed state and a run pipeline, connected through the cloud block or a VCS workflow. Candidates should know HCP Terraform is the current product name and how a remote run differs from a local apply.

HCP Terraformcloud blockremote runs and managed stateVCS-driven workflow

Practice question for this objective

Free sampleHCP Terraformmedium

A practitioner is migrating a working directory from local state to HCP Terraform (formerly Terraform Cloud) so runs execute remotely and state is managed centrally. They add the block shown to their configuration. After running terraform init and authenticating, what does this configuration cause to happen on the next terraform apply?

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

AThe apply runs on the practitioner's machine while HCP Terraform only stores the resulting state file after the run completes.
BThe plan and apply are executed remotely by HCP Terraform in the networking-prod workspace, and state is stored and managed there rather than on the local disk. Correct
CThe configuration fails to initialise because a cloud block also requires a nested backend block naming the state storage backend.
DTerraform provisions a new workspace on every apply and discards the previous run's state, keeping only the latest execution.

The cloud block connects a working directory to an HCP Terraform workspace, giving remote runs and centrally managed state by default. The cloud block inside the terraform block replaces backend configuration; once initialised, HCP Terraform executes plans and applies remotely in the named workspace and stores versioned state there, so no state file is written to local disk.

Why A is wrong: This describes a state-only remote backend, but the cloud block's default remote execution mode runs the plan and apply on HCP Terraform, not locally.

Why B is correct: The cloud block binds the working directory to the named HCP Terraform workspace, so by default runs execute remotely and state is held in that workspace.

Why C is wrong: It is tempting to assume state needs a backend block, but the cloud block replaces backend configuration entirely and the two cannot be combined.

Why D is wrong: HCP Terraform persists a versioned state history in the workspace; it does not discard prior state, and the workspace is reused rather than recreated each run.

See more TF-Associate-004 practice questions, answers explained.

Exam traps in HCP Terraform

Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.

The operations execute on the developer's laptop, while only the resulting state file is uploaded to the HCP Terraform workspace afterwards.
Why it is wrong: This describes local execution with remote state, which is a valid mode to select, but it is not the default for a cloud block, so the premise that execution stays on the laptop is wrong here.
It installs a local state file alongside the configuration while sending only plan summaries to the HCP Terraform user interface.
Why it is wrong: This is tempting because plans do appear in the user interface, but state is held in the managed workspace, not written to a local file next to the configuration.
Add execution_mode = "local" to the cloud block so Terraform never contacts HCP Terraform for state.
Why it is wrong: The setting name is close, but it belongs to the workspace, and choosing local execution still keeps state in HCP Terraform rather than cutting contact with it.

Use HCP Terraform to create infrastructure.

Practice question for this objective

Exam traps in HCP Terraform

More in this domain