CKS Minimize Microservice Vulnerabilities Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The Constraint is missing the 'match' field

  Why it's wrong here

  A Constraint lacking the `match` field does not silently fail to enforce; rather, Gatekeeper's schema validation typically rejects the resource because `match` is a required field in the Constraint spec. In the unlikely event it were accepted, the default behavior would match no resources, meaning zero Pods are selected for evaluation. Either way, the Constraint would either never be created (visible in the cluster) or would be inert — not a hidden cause of non-blocking while the Constraint looks active. Therefore, the missing `match` field would produce an obvious failure, not a subtle dryrun-like behavior.

• ✓

  The Constraint has 'enforcementAction: dryrun'

  Why this is correct

  This is the correct cause: setting `enforcementAction: dryrun` explicitly tells OPA Gatekeeper to run its evaluation and log any violations to the audit status, but to never reject the admission request. The default enforcement action for a Constraint is `deny`, which blocks the request, but overriding it with `dryrun` disables that blocking while keeping the rule visible in reports. In this mode, deploying a violating Pod will succeed, and the violation will only appear as a status entry or in logs — precisely the symptom described. Fixing this requires changing the value to `deny` (or removing the field entirely) to activate active enforcement.

• ✗

  The Constraint is in a different namespace than the pods

  Why it's wrong here

  Gatekeeper Constraints are cluster-scoped custom resources, not namespaced objects, so their physical placement in a namespace has no effect on which resources they apply to. Namespace selection is handled by the `match` field inside the Constraint's spec, which can target specific namespaces (or exclude them) via `namespaces` or `namespaceSelector`. Placing the Constraint in a particular namespace does not limit or redirect its enforcement scope; it is visible and evaluated for all Pods in all namespaces. Therefore, a namespace mismatch cannot explain why violating Pods are being allowed, because the Constraint's namespace is irrelevant to its enforcement.

• ✗

  The ConstraintTemplate is missing the 'violation' rule

  Why it's wrong here

  A ConstraintTemplate defines the Rego policy logic, and the mandatory entry point is a rule named `violation` (e.g., `violation[violation] { ... }`). If this rule is omitted, the template is malformed and the Gatekeeper controller will reject it, so no actual Constraints can be created from that template. The user would see a clear error in the Template's status, and the Constraint itself would not exist — thus it cannot be responsible for letting violating Pods through. Since the Constraint in question is apparently present (it is just not blocking), a missing `violation` rule would have prevented its creation altogether, making this option inconsistent with the observed symptom.

Go deeper

Related to this question