002 · Domain 5: Terraform Security and Governance · 13% of the exam
Task 5.4: Establish core compliance/policy rules along with Team/Project specific policies
Policy as code across an organization: global and project-scoped policy sets, Sentinel and OPA, enforcement levels, private registry rules, and audit trails.
Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.
Question 1 · choose 2
The security team needs a rule against public storage buckets that blocks every run in the organization with no possibility of override, except in the sandbox project. The payments team also wants its own checks that only warn, applied to its project alone. Which two configurations meet these needs? (Choose TWO.)
AA global Sentinel policy set with the rule soft-mandatory and the sandbox project excluded
BA global Sentinel policy set run as policy checks, the rule hard-mandatory, the sandbox project excluded
CA policy set scoped to the payments project whose policies use the advisory enforcement level
DOne policy set that mixes the Sentinel rule and the payments team's OPA checks
EA copy of the bucket rule committed to each workspace's configuration repository
Show the answer and why
AA global Sentinel policy set with the rule soft-mandatory and the sandbox project excluded
Incorrect
A failed soft-mandatory policy can be overridden by a user with the Manage Policy Overrides permission, which the security team rules out.
BA global Sentinel policy set run as policy checks, the rule hard-mandatory, the sandbox project excluded
Correct
A global set with the sandbox project excluded covers the rest of the organization, and hard-mandatory policy checks cannot be overridden.
CA policy set scoped to the payments project whose policies use the advisory enforcement level
Correct
Scoping the set to the project limits it to payments workspaces, and advisory failures warn without stopping runs.
DOne policy set that mixes the Sentinel rule and the payments team's OPA checks
Incorrect
The two requirements need different scopes and enforcement levels, which one policy set cannot provide at once.
EA copy of the bucket rule committed to each workspace's configuration repository
Incorrect
Policies are enforced through policy sets attached to workspaces; configuration repositories that teams can edit offer no guardrail.
Scope and enforcement level are separate choices. A global set with an exclusion covers the organization-wide rule; a project-scoped advisory set gives the team its own non-blocking checks.
A team connects a VCS repository as an OPA policy set. Its policies.hcl
contains:
policy "no_public_ingress" {
query = "data.terraform.policies.public_ingress.deny"
}
The policy fails on a plan with an open security group, yet the run
continues to apply. Why?
AOPA policies are evaluated only after the apply finishes and can never stop a run
BOPA policy sets connected to VCS run only on speculative plans
CA non-empty result array from the query means the policy passed
DWithout enforcement_level, the policy defaults to advisory, which only warns
Show the answer and why
AOPA policies are evaluated only after the apply finishes and can never stop a run
Incorrect
OPA policies are evaluated after the plan and any run tasks, before the apply.
BOPA policy sets connected to VCS run only on speculative plans
Incorrect
Policy sets apply to runs in their scope, not only to speculative plans.
CA non-empty result array from the query means the policy passed
Incorrect
The policy passes only when the query returns an empty array; a non-empty result is a failure.
DWithout enforcement_level, the policy defaults to advisory, which only warns
Correct
When the enforcement level is not set, HCP Terraform uses advisory, so failures appear as warnings and do not block the run.
Set enforcement_level = "mandatory" in the policy block for an OPA policy that should stop runs.
One Sentinel policy restricts regions, and each project's policy set passes its own list through a Sentinel parameter, allowed_regions = ["eu-west-1", "eu-central-1"]. In what form does the policy receive the value?
AAs a string, which the policy must decode itself
BAs an environment variable that the policy reads
CAs a list, because the value parses as valid JSON
DAs one parameter per list element, numbered from zero
Show the answer and why
AAs a string, which the policy must decode itself
Incorrect
Only values that fail JSON validation are sent as strings.
BAs an environment variable that the policy reads
Incorrect
Sentinel parameters are key-value pairs sent to the Sentinel runtime, not environment variables.
CAs a list, because the value parses as valid JSON
Correct
If a parameter value parses as JSON, HCP Terraform sends it to Sentinel as the corresponding type, such as a list or a map.
DAs one parameter per list element, numbered from zero
Incorrect
Each key-value pair is one parameter, whatever the type of its value.
Parameters let one policy serve several policy sets with different values, so a core rule can carry project-specific settings without copies of the policy.
A Sentinel set contains a hard-mandatory policy, and the set has "This policy set can be overridden in the event of mandatory failures" enabled. What does that mean?
AHard-mandatory policies stay non-overridable
BOnly advisory policies in the set are affected
CAny member of the organization can override any failure
DPermitted users can override even hard-mandatory ones
Show the answer and why
AHard-mandatory policies stay non-overridable
Incorrect
The set option takes precedence over the policy's level.
BOnly advisory policies in the set are affected
Incorrect
Advisory policies never stop runs anyway.
CAny member of the organization can override any failure
Incorrect
Only users with the appropriate permissions can.
DPermitted users can override even hard-mandatory ones
Correct
The option lets users with the right permissions override any failed policy in the set, even hard-mandatory ones.
Leave the option off for sets that hold true guardrails.