Terraform Associate (004): HCP Terraform

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: HCP Terraform

A team uses HCP Terraform for remote runs so they get shared state, change review, and consistent variables across environments.

Their configuration includes:

terraform {
  cloud {
    organization = "acme"
    workspaces { name = "network-dev" }
  }
}

The workspace already has the cloud provider credentials. A new engineer runs terraform init locally and gets Error: Required token could not be found for app.terraform.io.

What is the best next action?

Options:

• A. Run terraform login to authenticate the CLI to HCP Terraform.

• B. Replace the cloud block with a local backend.

• C. Put cloud API credentials directly in the provider block.

• D. Create a variable set for the cloud provider credentials.

Best answer: A

Explanation: The failure is about the local Terraform CLI authenticating to HCP Terraform, not about authenticating to the cloud provider. Since the workspace already has provider credentials, the missing step is logging the CLI into HCP Terraform so it can use the remote workspace.

HCP Terraform integration and provider configuration solve different problems. The cloud block connects a configuration to an HCP Terraform organization and workspace for remote state and remote runs, but the local CLI still needs its own credentials to talk to the HCP Terraform service. An error about a missing token for app.terraform.io points to platform authentication, so the right fix is terraform login or equivalent CLI credentials.

Provider credentials are separate. They control how Terraform accesses the target cloud API during planning and applying, but they do not authenticate the CLI to HCP Terraform itself. The key distinction is whether Terraform is failing to reach the managed platform or failing to reach the infrastructure provider.

• Provider credentials mismatch putting cloud API keys in the provider block changes cloud authentication, not HCP Terraform CLI authentication.
• Wrong HCP feature creating a variable set can centralize provider credentials, but the stem already says those credentials exist and are not the failing part.
• Breaks stated goals switching to a local backend removes the shared state and collaboration benefits the team requires.

Question 2

Topic: HCP Terraform

Which HCP Terraform feature applies centrally managed governance rules to runs across multiple workspaces before they can be applied?

Options:

• A. Policy sets

• B. Variable sets

• C. Run triggers

• D. Projects

Best answer: A

Explanation: Policy sets are the HCP Terraform feature for enforcing centrally managed rules during runs. They let organizations apply reusable governance policies across multiple workspaces, and those rules appear as policy checks before apply.

In HCP Terraform, policy sets are used when an organization wants reusable governance rules enforced across teams or workspaces. A policy set groups one or more policies and attaches them to selected workspaces, so each run is evaluated and can be allowed, warned, or blocked based on the policy outcome.

This is different from other collaboration features:

• Variable sets share input values across workspaces.
• Run triggers start downstream runs after upstream changes.
• Projects organize workspaces and help with visibility and access structure.

If the need is centralized rule enforcement during the run itself, policy sets are the best fit.

• Variable sharing fits reusable inputs, not governance checks during a run.
• Run coordination helps chain workspace runs, but it does not evaluate policy rules.
• Workspace grouping with projects improves organization and access boundaries, but it does not enforce compliance logic.

Question 3

Topic: HCP Terraform

A platform team uses HCP Terraform for development, staging, and production workspaces. They need application teams to use the same approved network configuration, consume versioned updates, and avoid copying module code into each repo. Which HCP Terraform capability is the best fit?

Options:

• A. Add a policy set that enforces naming standards

• B. Group the workspaces into a single HCP Terraform project

• C. Enable drift detection on the existing workspaces

• D. Publish the approved module to the HCP Terraform private registry

Best answer: D

Explanation: The HCP Terraform private registry is the governance feature for sharing approved, reusable modules. It lets teams consume versioned configuration across workspaces without copying code, which supports consistency and controlled updates.

In HCP Terraform, the private registry is used to publish and share approved, versioned modules within an organization. That directly matches the scenario: one platform team maintains a standard network module, and multiple application teams reuse it across development, staging, and production workspaces. This improves consistency and makes updates intentional, because each consumer can reference a specific module version instead of copying HCL into separate repositories.

• Publish the reusable module once.
• Let teams reference it from their configurations.
• Promote newer approved versions when teams are ready.

Projects help organize workspaces, policy enforcement checks whether configurations follow rules, and drift detection finds out-of-band changes, but those features do not distribute reusable module code.

• Project organization helps group related workspaces, but it does not provide reusable versioned modules.
• Drift detection identifies infrastructure changes made outside Terraform, not shared configuration reuse.
• Policy enforcement can block noncompliant plans, but it does not publish approved building blocks for teams to consume.

Question 4

Topic: HCP Terraform

A team currently runs Terraform from engineers’ laptops and stores state on disk. They want HCP Terraform to manage state centrally and start runs automatically when code is pushed to their Git repository.

Exhibit:

terraform {
  backend "local" {
    path = "terraform.tfstate"
  }
}

What is the best next step?

Options:

• A. Keep the local backend and authenticate with terraform login.

• B. Use a cloud block, create a VCS-connected workspace, and migrate state.

• C. Publish the configuration as a private registry module.

• D. Use terraform import to rebuild state in HCP Terraform.

Best answer: B

Explanation: The team needs two things at once: centrally managed state and runs triggered by Git commits. That points to an HCP Terraform workspace connected to the repository, with the existing local state migrated into HCP Terraform-managed state.

The deciding clue is the desired workflow, not just the backend snippet. A local backend stores state on disk and does not provide managed remote runs or VCS-triggered collaboration. To move this workflow into HCP Terraform, the team should use HCP Terraform-managed state with a cloud block, create a workspace, and connect that workspace to the Git repository so commits trigger runs. Because the infrastructure is already tracked in local state, the correct migration path is to move that state rather than recreate it.

• Create or choose an HCP Terraform workspace.
• Connect the workspace to the VCS repository.
• Update the configuration to use HCP Terraform.
• Run terraform init and migrate the existing state.

The key takeaway is that VCS-driven HCP Terraform adoption usually combines workspace setup, remote state, and state migration.

• CLI authentication only keeping the local backend with terraform login does not centralize state or move plan/apply execution into HCP Terraform.
• Module reuse instead publishing to a private registry helps share reusable modules, but it does not migrate an existing root module workflow.
• Wrong state action terraform import is for bringing unmanaged resources under Terraform, not for transferring resources already recorded in local state.

Question 5

Topic: HCP Terraform

An organization has separate HCP Terraform workspaces for payments-dev, payments-prod, identity-dev, and identity-prod. It wants to organize these by application ownership without combining their state. Which HCP Terraform feature should it use?

Options:

• A. One shared workspace for each application

• B. Variable sets to organize workspaces

• C. Projects to group related workspaces

• D. The private registry to separate state

Best answer: C

Explanation: Projects are the HCP Terraform feature for grouping workspaces by team, application, or environment. They improve organization and governance while each workspace still keeps its own state and run history.

In HCP Terraform, a workspace is still the unit that holds state and run history for a Terraform configuration. A project is an organizational layer above workspaces, used to group them by application, environment grouping, or ownership boundary. That lets a team keep payments-dev and payments-prod as separate workspaces with separate state, while still placing them under a common project for structure and management. This is important because unrelated infrastructure should not be merged into one workspace just to make it easier to browse. Features such as variable sets and the private registry support reuse and consistency, but they do not organize workspaces into ownership groupings.

• One shared workspace would merge separate environments into a single state, which the stem explicitly wants to avoid.
• Variable sets share input values across workspaces, but they are not containers for workspace organization.
• Private registry is for publishing and reusing modules, not for defining workspace boundaries.

Question 6

Topic: HCP Terraform

A platform team wants every run checked against centrally managed rules, with the ability to block noncompliant changes or require an authorized override. Which feature provides that capability?

Options:

• A. terraform validate

• B. HCP Terraform workspaces

• C. Terraform dependency lock file

• D. HCP Terraform policy enforcement

Best answer: D

Explanation: HCP Terraform policy enforcement is the governance feature for applying shared rules across team runs. It supports centralized control, including blocking runs or allowing approved overrides, which local CLI features do not provide.

Policy enforcement in HCP Terraform is used when an organization needs shared standards enforced consistently across Terraform runs. Administrators attach policies centrally, and HCP Terraform evaluates those policies during runs so noncompliant changes can be blocked or, in some cases, overridden by authorized users. That makes it a governance and collaboration feature, not just a local correctness check.

By contrast, local CLI features help an individual operator work with configuration on their machine. They can check syntax, format code, or pin provider versions, but they do not give a team centralized enforcement, approvals, or shared control over runs. The key distinction is centralized governance in HCP Terraform versus local tooling in the Terraform CLI.

• Workspaces are not rules because they organize state and runs, but they do not enforce organization-wide standards by themselves.
• Local validation is limited because terraform validate checks configuration correctness locally, not centrally managed governance requirements.
• Version pinning is different because the dependency lock file helps with consistent provider selection, not approvals or policy decisions.

Question 7

Topic: HCP Terraform

A platform team manages production changes in HCP Terraform. They want runs executed centrally, a person to approve production applies, and shared guardrails across teams.

Exhibit:

Workspace: app-prod
Execution mode: Remote
Run trigger: VCS-driven
Apply method: Manual apply
Policy checks: Enabled

Which interpretation is most accurate?

Options:

• A. HCP Terraform provides remote runs, policy checks, and manual approval gates.

• B. A remote backend alone provides approvals and organization-wide policy checks.

• C. Reusable modules alone enforce approval gates across team workspaces.

• D. Local CLI workflows provide the same centralized approvals and governance controls.

Best answer: A

Explanation: The exhibit describes HCP Terraform collaboration and governance features, not just core local Terraform CLI behavior. Remote execution, VCS-driven runs, policy checks, and manual apply together support centralized control, shared guardrails, and human approval before infrastructure changes are applied.

HCP Terraform adds team-oriented workflow controls that the local CLI does not provide by itself. In the exhibit, Execution mode: Remote means runs occur in HCP Terraform, Run trigger: VCS-driven ties runs to version-controlled changes, Policy checks: Enabled indicates governance rules can evaluate the run, and Apply method: Manual apply requires a person to approve the apply step. Together, these features address collaboration, approvals, and shared standards in a centralized workflow.

Local commands such as terraform plan, terraform apply, terraform validate, and terraform fmt are still useful, but they do not by themselves create an HCP-managed approval gate or organization-wide policy enforcement. A remote backend or reusable module can help with state or reuse, but neither replaces HCP Terraform governance features.

• Local CLI only can preview or apply changes, but it does not create centralized HCP approval gates or policy checks.
• Remote backend only helps store and coordinate state; it is not the same as HCP Terraform governance controls.
• Modules for reuse standardize configuration structure, but they do not by themselves require human approval before apply.

Question 8

Topic: HCP Terraform

An engineer runs Terraform from a workstation and sees this output:

$ terraform apply
Running apply in HCP Terraform. Output will stream here.
Preparing the remote apply...

What is the best interpretation of this output?

Options:

• A. Terraform is executing the apply remotely in HCP Terraform.

• B. Terraform is running locally and using HCP Terraform only for state.

• C. Terraform has switched to a local workspace on the workstation.

• D. Terraform is only downloading dependencies from HCP Terraform.

Best answer: A

Explanation: This output shows a remote run in HCP Terraform, not a local apply. The CLI is streaming logs while HCP Terraform performs the run, which reflects its role as HashiCorp’s managed collaboration and remote-run platform for Terraform workflows.

The key clue is the wording Running apply in HCP Terraform followed by Preparing the remote apply. That means the Terraform run is being executed by HCP Terraform, while the local CLI session is acting as a client that starts the run and streams output back to the engineer.

HCP Terraform is more than just shared state storage. At a foundational level, it provides a managed workspace for Terraform operations such as:

• remote plan and apply execution
• shared state and locking
• run history and team collaboration
• integration with VCS-driven workflows

A common trap is confusing remote state with remote execution. This excerpt specifically indicates remote execution, not just storing state outside the local machine.

• State only fails because the output says remote apply, which is execution behavior, not just remote state storage.
• Dependencies only fails because provider or module downloads do not mean Terraform is performing the apply in HCP Terraform.
• Local workspace fails because the CLI is reporting a remote run, not a switch to a local-only workflow.

Question 9

Topic: HCP Terraform

In HCP Terraform, which statement correctly defines the roles of a workspace and a run?

Options:

• A. A workspace shares variables across teams; a run stores the latest state snapshot.

• B. A workspace manages a Terraform configuration’s variables and state; a run executes plan and possible apply steps.

• C. A workspace enforces policies; a run defines backend storage settings.

• D. A workspace pins provider versions; a run publishes a module version.

Best answer: B

Explanation: In HCP Terraform, a workspace is the main unit used to organize a Terraform configuration, along with its variables and state. A run is the execution started in that workspace to plan and, if allowed, apply infrastructure changes.

In HCP Terraform, a workspace is the central place for managing one Terraform configuration context, including its variables, settings, and current state. Teams commonly use different workspaces for different environments or applications. A run is a single execution inside a workspace: HCP Terraform performs the plan phase, evaluates any configured checks such as policies or approvals, and can then apply the change if allowed.

• Workspace: organization and state context
• Run: execution of infrastructure changes

The key distinction is that a workspace organizes Terraform work, while a run carries it out.

• The option about sharing variables and storing snapshots mixes up variable sets with Terraform state.
• The option about pinning providers and publishing modules confuses the dependency lock file with module registry publishing.
• The option about enforcing policies and defining storage settings describes policy sets and backends, not workspaces and runs.

Question 10

Topic: HCP Terraform

A team uses the same Terraform code for dev and prod, but today one engineer runs everything from a laptop. They want pull-request-based change review, plans and applies to run in a managed environment with shared visibility, and state stored safely outside local files. What is the best next step?

Options:

• A. Create HCP Terraform workspaces linked to the repo for remote runs

• B. Commit the terraform.tfstate file to the repository

• C. Keep local CLI runs and share saved plan files

• D. Publish the code as a module in the private registry

Best answer: A

Explanation: This scenario calls for HCP Terraform remote workflows, not a local CLI-only process. Linking workspaces to version control gives the team managed execution, shared visibility into runs, and remote state storage without depending on one laptop.

The core concept is choosing HCP Terraform when the requirements emphasize managed execution and team collaboration. A VCS-connected HCP Terraform workspace lets changes start from Git review, then runs plan and apply remotely with a shared run history. HCP Terraform also stores state remotely, which is safer and more collaborative than keeping state on a local machine.

For this scenario, the best fit is:

• connect the configuration repository to HCP Terraform
• use workspaces to represent environments such as dev and prod
• let HCP Terraform perform remote runs and manage state

The closest distractor is continuing with local CLI plans, but that still relies on local execution instead of a managed, shared workflow.

• Local plan sharing: saved plan files do not provide managed remote execution or centralized run visibility.
• State in Git: committing terraform.tfstate is unsafe and is not a proper remote state workflow.
• Module reuse only: a private registry helps share modules, but it does not run plans or store state for this workflow.

Continue with full practice

Use the Terraform Associate (004) Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try Terraform Associate (004) on Web View Terraform Associate (004) Practice Test

Related focused pages

• Free Terraform Associate (004) Full-Length Practice Exam
• IaC with Terraform
• Terraform Fundamentals
• Core Terraform Workflow
• Terraform Configuration
• Terraform Modules
• Terraform State Management
• Terraform Maintenance

Free review resource

Read the Terraform Associate (004) Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.