HashiCorp 004: HCP Terraform Practice Questions

A soft-mandatory policy failure causes the run to halt at the policy check stage and display a 'Policy check soft failed' status — it does not auto-apply (Option 3 is correct). However, unlike a hard-mandatory failure, it CAN be overridden: a user with the 'Manage Policies' permission (typically organization owners or policy managers) can click 'Override & Continue' to allow the apply to proceed despite the failure (Option 1 is correct). — Option A is wrong because the run is not permanently discarded; it remains in a paused state and can be overridden or the plan can be discarded manually. — Option C is wrong because that describes an 'advisory' enforcement level, not soft-mandatory. Advisory policies log the failure but never block the apply. Soft-mandatory DOES block unless overridden. — Option E is wrong because there is no automatic grace period or timer in HCP Terraform policy checks; the run waits indefinitely for a human action. — Option F is wrong because the override permission is tied to the 'Manage Policies' permission at the organization level, not solely to workspace-level admins.

Option A is correct. When an HCP Terraform workspace execution mode is set to 'Local', the Terraform CLI runs plan and apply operations on the local machine (the engineer's laptop or CI runner), but the workspace's remote state backend in HCP Terraform is still used for state storage and locking. This gives teams centralized state management without the overhead of remote execution. Option C is wrong because it inverts the behavior—local mode means local execution, not local state. Option D is wrong because local execution mode does not make the workspace read-only; it remains fully manageable. Option B is wrong because there is no time-based execution mode switching; execution mode is a static workspace setting.

When an HCP Terraform workspace uses Remote execution mode with 'Auto apply' disabled (the default), every run pauses at the 'planned' state after the plan phase and waits for a user with appropriate permissions to click 'Confirm & Apply'. This is the built-in mechanism for requiring human approval before any apply proceeds, regardless of how the run was triggered. — Option D is wrong because enabling 'Auto apply' causes runs to proceed to apply automatically without human confirmation, which is the opposite of what is required. — Option A is wrong because Local execution mode offloads the plan and apply to the engineer's local machine; HCP Terraform only stores state. It does not provide a centralized approval gate inside the platform for team-based review. — Option B is wrong because Sentinel policies gate applies based on policy logic, not on a blanket 'pause for human review' pattern. Sentinel is a policy-as-code governance tool and cannot be configured to simply require an operator comment as a generic approval mechanism; the correct purpose-built feature for approval gates is disabling Auto apply.

Option C is correct. A hard-mandatory Sentinel policy cannot be overridden by anyone, including organization owners. If the policy fails, the run is permanently blocked from proceeding to apply with no override path. Option A (advisory) is wrong because advisory policies log a warning but never block a run—the apply proceeds regardless. Option B (soft-mandatory) is wrong because soft-mandatory policies can be overridden by users with appropriate permissions (typically organization owners or policy override privileges), which does not meet the requirement of 'no circumstances' override. Option D (strict) is wrong because 'strict' is not a valid Sentinel enforcement level in HCP Terraform; the three valid levels are advisory, soft-mandatory, and hard-mandatory.

Option B is correct. The HCP Terraform private module registry allows organizations to publish versioned modules sourced from VCS repositories. Team members can browse and consume them using the app.terraform.io/<org>/<module>/<provider> source format without needing direct VCS access or credentials. Option A (remote state sharing) is wrong because that feature shares output values between workspaces—it is not a module distribution mechanism. Option C is wrong because a workspace is not a valid Terraform module source path and does not provide versioning or a browsable registry UI. Option D (run triggers) is wrong because that feature allows one workspace to trigger a run in another workspace after a successful apply—it is not related to module distribution.