002 · Domain 7: HCP Terraform / Enterprise Operations · 12% of the exam
Task 7.5: Define Policy as Code in a CI/CD pipeline
Policies that run with every plan: policy sets from VCS, enforcement levels and overrides, policy evaluation in the run, and reading results.
Study it
Policy as code in the run: policy sets, enforcement levels and overrides
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.
Question 1 · choose 1
A Sentinel policy uses the tfrun import to block runs that raise monthly cost by more than $500. Cost estimation is enabled for the organization. After the policy set was switched to the HCP Terraform Agent execution mode to pin a newer Sentinel version, the cost rule stopped seeing any cost data. What explains this?
ACost estimation only supports Azure resources, leaving the AWS changes without a cost
Btfrun exposes cost data only to OPA policies, not to Sentinel policies
CCost estimation runs after the apply in agent mode, too late for any policy
DPolicy evaluations, including agent mode, cannot access cost data; only policy checks can
Show the answer and why
ACost estimation only supports Azure resources, leaving the AWS changes without a cost
Incorrect
Cost estimation supports resources from AWS, GCP and Azure.
Btfrun exposes cost data only to OPA policies, not to Sentinel policies
Incorrect
Cost data comes through the tfrun import in Sentinel; OPA policies run as evaluations, which cannot access cost estimates.
CCost estimation runs after the apply in agent mode, too late for any policy
Incorrect
The policy set's execution mode does not change when cost estimation runs; the policy simply cannot read its results.
DPolicy evaluations, including agent mode, cannot access cost data; only policy checks can
Correct
Only policy checks can read cost estimation data; policy evaluations cannot, wherever they run.
The choice of how a Sentinel policy set runs trades features, and cost estimates are readable only from policy checks. A cost rule must stay in a set that runs as policy checks.
An engineer starts a CLI-driven run in HCP Terraform. A mandatory OPA policy fails, and the engineer holds the Manage Policy Overrides permission and has approval to proceed. How can the run continue?
AType override at the CLI prompt, as for a soft-mandatory Sentinel policy
BOpen the run in the HCP Terraform UI and use Override and Continue
CChange the policy to advisory in the VCS repository and let the failed run continue
DRe-run with terraform apply -auto-approve to skip the policy stage
Show the answer and why
AType override at the CLI prompt, as for a soft-mandatory Sentinel policy
Incorrect
Overriding from the CLI works only for soft-mandatory Sentinel policies; the CLI has no support for OPA policy results.
BOpen the run in the HCP Terraform UI and use Override and Continue
Correct
Users with the Manage Policy Overrides permission can override failed mandatory OPA policies from the run details page.
CChange the policy to advisory in the VCS repository and let the failed run continue
Incorrect
Editing the policy set affects later runs; the failed run still needs an override.
DRe-run with terraform apply -auto-approve to skip the policy stage
Incorrect
-auto-approve skips the apply confirmation, not policy evaluation.
OPA mandatory failures can be overridden from the run details page; the CLI prints policy results and accepts overrides only for Sentinel.
Policy changes are merged to a staging branch first and to main after review. A staging policy set, scoped to staging workspaces, must pick up the staging branch while the production set keeps following main. How is this configured?
ASet the VCS branch on the staging policy set to staging
BPoint both sets at main and tag the commits meant for staging
CCreate a run task that copies the branch into the policy set
DUse one policy set; a repository backs only one
Show the answer and why
ASet the VCS branch on the staging policy set to staging
Correct
A VCS-connected policy set can name the branch to import new policy versions from; otherwise it uses the repository's default branch.
BPoint both sets at main and tag the commits meant for staging
Incorrect
A policy set imports new policy versions from its configured branch, so both sets would follow main and never see changes merged only to staging.
CCreate a run task that copies the branch into the policy set
Incorrect
Run tasks call external services during runs; they do not update policy sets.
DUse one policy set; a repository backs only one
Incorrect
A repository can hold several sets, each configured with its own path and branch.
Branch-based policy sets let a team try policy changes on staging workspaces before the same commits reach the production set.