HCP Terraform — Terraform Associate 004 practice questions

Which capability is NOT a reason to adopt HCP Terraform over purely local runs?

1. Policy enforcement applied before applies proceed
2. Elimination of the need to declare providers in configuration
3. A consistent remote execution environment with an audit trail
4. Centralised, versioned and locked state for a team

Answer: B — Elimination of the need to declare providers in configuration

A) Pre-apply policy checks are a governance benefit of the platform. B) Correct — this is the odd one out: required_providers and provider configuration are part of the language and are needed no matter where runs execute. C) Consistent, logged remote runs are a principal benefit. D) Shared state management is a core reason to adopt the platform.

Sentinel in HCP Terraform is best described as:

1. A backup mechanism that snapshots state files before every remote apply
2. A policy-as-code framework enforcing rules on runs at plan time
3. An alternative language to HCL for authoring Terraform configurations
4. A monitoring agent that reports workspace health back to the HCP console

Answer: B — A policy-as-code framework enforcing rules on runs at plan time

B is right: Sentinel policies are evaluated against the plan, letting an organisation block changes such as a publicly readable bucket before anything is created. A confuses governance with the state versioning that HCP Terraform provides separately. C mistakes a policy language for a configuration language. D invents an agent. Policies can be set to advisory, soft-mandatory or hard-mandatory, which decides whether a failure can be overridden.

The same set of cloud credentials variables must apply to twenty workspaces without being retyped. The BEST feature is:

1. A shared private registry module carrying the values
2. A Sentinel policy set that injects the values
3. A variable set scoped to the relevant workspaces or project
4. A run trigger configured on each workspace

Answer: C — A variable set scoped to the relevant workspaces or project

A) Registry modules distribute configuration code, not workspace variable values. B) Sentinel evaluates policy against plans; it does not supply variables. C) Correct — variable sets define variables once and apply them to chosen workspaces or an entire project. D) Run triggers queue runs based on another workspace's apply; they carry no variables.

A regulated team must be able to answer who changed what and when, across all Terraform activity. Which combination BEST supports this?

1. Run history with logs, state version history and policy results
2. Run triggers linking workspaces plus a shared variable set
3. CLI workspaces per environment plus verbose TF_LOG output
4. Sensitive variables plus a private registry of approved modules

Answer: A — Run history with logs, state version history and policy results

A) Correct — retained run records, the state version history and recorded policy outcomes together give the who, what and when an auditor needs. B) These coordinate execution and configuration but produce no audit narrative. C) Local logs are transient, machine-local and not attributable to a user. D) These reduce exposure and standardise code but record little about individual changes.

An engineer runs terraform login and configures a cloud block, then runs terraform apply. Where does the operation execute by default?

1. Locally, because CLI-driven runs are always local
2. On the engineer's machine, with state pushed afterwards
3. On a self-hosted agent chosen automatically
4. On HCP Terraform's remote workers, with output streamed to the terminal

Answer: D — On HCP Terraform's remote workers, with output streamed to the terminal

A) CLI-driven runs are perfectly compatible with remote execution. B) That describes local execution mode, which must be selected deliberately. C) Agents are used only when a workspace is explicitly assigned to an agent pool. D) Correct — with the default remote execution mode, a CLI-driven run is executed on HCP Terraform and its logs stream back to the terminal.

A 'run trigger' in HCP Terraform connects what to what?

1. It queues a run in one workspace after a successful apply in another one
2. It queues an apply whenever a Sentinel policy in the organization changes
3. It posts a notification to a Slack channel when a run is awaiting approval
4. It queues a plan whenever any developer pushes a commit to the repository

Answer: A — It queues a run in one workspace after a successful apply in another one

A is right: a run trigger is an inter-workspace dependency, so finishing an apply in the upstream workspace queues a run downstream — useful when an application layer consumes outputs from a network layer. D describes the VCS-driven workflow, which is the most tempting confusion because it also queues runs automatically. B invents a policy-change hook. C describes notifications, which are configured separately.

A workspace is set to local execution mode. What does HCP Terraform still provide?

1. Automatic VCS-driven runs on every commit
2. Cost estimation for every plan
3. Remote plan and apply on HCP Terraform workers
4. Remote state storage, versioning and locking

Answer: D — Remote state storage, versioning and locking

A) VCS-driven runs require remote execution to perform the operations. B) Cost estimation is computed from remotely executed plans. C) Running on HCP Terraform workers is exactly what remote execution mode provides. D) Correct — local execution keeps operations on the engineer's machine while HCP Terraform continues to store, version and lock the state.

Which describes HCP Terraform's benefits over running Terraform only locally?

1. There are none; a local backend offers every team the same collaboration features
2. It only manages AWS resources, so other providers must still be run from a workstation
3. It only makes plan and apply run faster by giving them more CPU than a laptop has
4. It only reduces cost, by billing per managed resource rather than per user in the org
5. Managed remote state, run history, policy as code, variable sets and VCS-driven runs

Answer: E — Managed remote state, run history, policy as code, variable sets and VCS-driven runs

E is right: HCP Terraform supplies managed state with locking, remote runs, run history, RBAC, policy as code with Sentinel or OPA, variable sets, and workspaces grouped into projects. Terraform Enterprise is the self-hosted equivalent. A denies real capability gaps, and B, C and D each reduce the offering to a single false claim.

Which statement about the open-source Terraform CLI and HCP Terraform is correct?

1. HCP Terraform is required in order to run apply; the CLI on its own can only run plan.
2. The CLI is free and fully functional alone; HCP Terraform adds remote runs and governance.
3. They are independent products, so a configuration written for one cannot be used with the other.
4. HCP Terraform supersedes and replaces the terraform CLI binary on an engineer's workstation.

Answer: B — The CLI is free and fully functional alone; HCP Terraform adds remote runs and governance.

B is right: the CLI provisions infrastructure perfectly well on its own, and HCP Terraform is the collaboration layer around it — remote execution, shared state with locking, VCS-driven runs, policy enforcement and team access control. A is a licensing misconception. C is wrong because the same configuration runs in both, with the cloud block or a remote backend pointing the CLI at the platform. D is wrong: HCP Terraform runs the same CLI on its own workers.

Which benefit BEST describes dynamic provider credentials in HCP Terraform?

1. Short-lived credentials are issued per run instead of static keys being stored
2. Stored credentials are rotated automatically by a scheduled background job each night
3. Credentials are encrypted inside the state file for reuse
4. Credentials are inherited from the engineer's local environment

Answer: A — Short-lived credentials are issued per run instead of static keys being stored

A) Correct — dynamic credentials use a trust relationship so each run receives short-lived credentials, removing long-lived secrets from workspace variables. B) The value is per-run issuance, not a nightly rotation of stored keys. C) Storing credentials in state would be the opposite of the goal. D) Remote runs do not read the engineer's local environment.

In HCP Terraform, what is a workspace and what is a project?

A workspace is the unit of Terraform management: it holds one state file, its own variables, its run history, and its access settings — roughly one working directory's worth of infrastructure. A project is a container that groups related workspaces so that permissions and team access can be granted at the group level rather than workspace by workspace. Note this is a different concept from CLI workspaces, which are only alternate state files in one directory.

Name the HCP Terraform execution modes and what each means.

Remote, where HCP Terraform runs plan and apply on its own managed infrastructure and streams the output back • Local, where the runs happen on your own machine or CI and HCP Terraform is used only for state storage and locking • and Agent, where runs execute on a self-hosted agent inside your own network so private infrastructure can be reached.

Cost estimation in HCP Terraform?

Estimates infrastructure costs from plan. Available in higher tiers.

Multi-user collaboration?

Remote state + locking. CI/CD pipeline. HCP Terraform features.