TF-Associate-004 - HCP Terraform (11% of the exam) - Section 8d
Configure and use HCP Terraform integration.
HCP Terraform integrates with VCS providers, run triggers between workspaces, notifications, and the API or CLI-driven run workflow. Candidates should reason about how a VCS connection drives plans on pull requests and what a run trigger chains.
VCS integrationrun triggersnotificationsCLI-driven and API-driven runs
Practice question for this objective
lock_openFree sampleHCP Terraformmedium
In HCP Terraform, what distinguishes a CLI-driven run from an API-driven run?
AA CLI-driven run is started by running terraform commands locally against a workspace configured with a cloud block, while an API-driven run is triggered by uploading a configuration version through the runs API.check_circle Correct
BA CLI-driven run always skips the plan phase, whereas an API-driven run always performs both plan and apply automatically.
CA CLI-driven run can only execute against local state, while an API-driven run is the sole way to use remote state in a workspace.
DA CLI-driven run requires a connected version control repository, while an API-driven run works without any workspace at all.
CLI-driven runs come from local terraform commands via a cloud block, while API-driven runs upload a configuration version through the API. The workflows differ in how a run is initiated: the CLI maps local commands to a workspace using a cloud block, and the API accepts an uploaded configuration version to create a run, but both plan and apply against the workspace's remote state.
Why A is correct: Correct: CLI-driven runs originate from local terraform commands mapped to a workspace, whereas API-driven runs come from programmatically uploading a configuration version and creating a run via the API.
Why B is wrong: Tempting because the two feel like they should differ in phases, but both workflows run plan and apply; neither skips the plan stage by definition.
Why C is wrong: Plausible if you tie state location to trigger method, but both run types use the workspace's remote state; the trigger mechanism does not determine where state lives.
Why D is wrong: Sounds reasonable given VCS integration exists, but CLI-driven runs do not need a VCS connection, and every run, including API-driven, executes within a workspace.
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.
A run trigger configured on the workspace, which starts a plan in this workspace whenever the connected upstream workspace completes an apply.
errorWhy it is wrong: Run triggers do chain runs automatically, which makes this tempting, but they fire on an upstream workspace's successful apply, not on a pull request, so they do not post plan results to a VCS status check.
HCP Terraform mirrors the repository into its own private git server and requires all future commits to be pushed there rather than to the original remote.
errorWhy it is wrong: Tempting because HCP Terraform does clone repository contents to run against, but it does not replace the origin remote or force commits to a mirror; developers keep pushing to their existing VCS.
As an environment variable exported in the practitioner's local shell before running 'terraform apply'.
errorWhy it is wrong: With the cloud block the plan and apply run on HCP Terraform's remote workers, not on the local shell, so a locally exported variable is not available to the run.