CKS violation Practice Question
Which ONE of the following is a valid Rego policy construct used in OPA Gatekeeper ConstraintTemplates to enforce security policies?
⚠ Common exam trap
Candidates may mistakenly think that `allow` and `deny` are valid constructs within Gatekeeper ConstraintTemplates. In reality, only the `violation` rule is used to trigger constraint violations. `allow` and `deny` are general Rego rules used in other OPA contexts, but not for defining Gatekeeper constraints.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
violation[{"msg": msg}] { condition }
In OPA Gatekeeper ConstraintTemplates, the only Rego construct that directly triggers a constraint violation is `violation[{"msg": msg}] { condition }`. When the condition evaluates to true, Gatekeeper generates a violation message. The `allow` and `deny` rules are not standard constructs for enforcing constraints in Gatekeeper; they are general Rego rules used in other OPA contexts but not within ConstraintTemplates to report violations. Options D (`audit`) and E (`warn`) are also not valid Rego constructs for Gatekeeper constraints.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
violation[{"msg": msg}] { condition }
Why this is correct
The `violation[{"msg": msg}] { condition }` construct is the canonical rule format for Gatekeeper ConstraintTemplates. Gatekeeper's admission and audit controllers compile the template's Rego and expect a partial set rule named `violation`; whenever the `condition` evaluates to true, the set is non-empty and the constraint's enforcement action (deny, warn, or dryrun) is applied. The `msg` variable binds to a human-readable message that is surfaced in the audit results or admission response. This construct directly fulfills Gatekeeper's internal policy enforcement contract.
- ✗
allow { condition }
Why it's wrong here
`allow { condition }` is a common rule name in generic OPA policies for expressing authorization decisions, but it is not a valid construct inside a Gatekeeper ConstraintTemplate. Gatekeeper's policy engine does not search for an `allow` rule when evaluating a constraint; it specifically looks for a rule named `violation`. Even if this rule's condition holds, it produces no constraint violations and has zero effect on admission control or audit results, making it a silent no-op.
- ✗
deny[{"msg": msg}] { condition }
Why it's wrong here
A `deny[{"msg": msg}] { condition }` rule is used in some older or custom OPA authorization frameworks to collect denial reasons, but Gatekeeper's ConstraintTemplate runtime ignores any rule that is not called `violation`. The Rego code may compile successfully, but Gatekeeper only instantiates and evaluates the `violation` partial set from the template's `targets` section. Consequently, a `deny` rule never triggers constraint enforcement, leaving the policy completely ineffective.
- ✗
audit { condition }
Why it's wrong here
`audit { condition }` is not a recognized Rego rule construct inside Gatekeeper ConstraintTemplates; audit is a separate component of Gatekeeper that periodically re-evaluates constraints using the same `violation` rule. Naming a rule `audit` produces a valid Rego rule that compiles, but Gatekeeper does not treat it specially — it does not run an audit check based on a rule's name. Since neither the admission webhook nor the audit controller consumes an `audit` rule, the condition never influences policy outcomes.
- ✗
warn[{"msg": msg}] { condition }
Why it's wrong here
Although `warn[{"msg": msg}] { condition }` might sound plausible because Gatekeeper supports warning-level enforcement, the Rego rule name must always be `violation`; warning behavior is controlled by the constraint's `enforcementAction` field, not by naming a rule `warn`. Gatekeeper's evaluation contract looks for a partial set named `violation` and uses its content to decide whether to apply the configured enforcement action. Therefore, a `warn` rule is never invoked by the policy engine, so the constraint will silently produce no violations or warnings.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 114-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.