Articles

Gatekeeper Interview Questions: Constraints, Audit Results, and Enforcement Gaps

Practice Gatekeeper interview questions with constraints, admission decisions, audit limits, namespace exemptions, and evidence of real enforcement gaps.

A Gatekeeper constraint says deny, yet an invalid Pod exists in the cluster. That is an investigation prompt, not proof that the policy language is broken. The object might predate the policy, fall outside its scope, arrive through an excluded admission path, or be accepted while the webhook was unavailable.

For Gatekeeper interview questions, separate the policy decision, the admission path, and the evidence from audit. Explain what should be blocked, which component must execute that decision, and what the observed result actually proves.

This article uses official Gatekeeper and Kubernetes documentation, checked on September 30, 2026. The Gatekeeper pages identify version 3.23.x; verify your installed version and rendered configuration separately. The fixtures and preparation recommendations are original. No candidate reports establish an employer's interview format or question frequency.

Add one concrete policy failure to your architecture answer.

What do a ConstraintTemplate and a Constraint each control?

Official fact: a ConstraintTemplate defines policy logic and the parameter schema for a constraint kind. A Constraint instantiates that policy with matching rules, parameters and enforcement behavior. Gatekeeper validation can deny, warn or dry-run admission requests; audit evaluates existing resources and reports violations. Gatekeeper usage documentation

Interview inference: explain the division using a function and its configured arguments. The template describes how to detect missing labels. A constraint selects the objects and names the labels required in this deployment. Installing only the template does not establish the intended constraint instance or its coverage.

For an original exercise, assume a compatible K8sRequiredLabels template has already been installed and accepted. Require an owner label on Pods in namespace prod:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: prod-pods-need-owner
spec:
  enforcementAction: dryrun
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces: ["prod"]
  parameters:
    labels: ["owner"]

This is a documentation-based configuration example, not a locally deployed policy. The empty API group means the core group. The requirement checks label presence; it does not establish that the value names a valid team. A stronger requirement needs a separately defined allowed-value contract and corresponding template logic.

Before changing enforcement, inspect template errors, the generated constraint kind, the actual constraint parameters and the effective resource match. “The YAML applied” proves less than “the expected object was evaluated under the expected policy.”

How is deny different from failurePolicy?

These controls answer different questions. An enforcement action describes what to do with a policy violation. Webhook failurePolicy describes what happens when calling the webhook fails.

Official facts: Gatekeeper's failing-closed documentation describes a default admission webhook failure policy of Ignore and discusses configuring Fail. Kubernetes defines Ignore and Fail for errors calling admission webhooks. Read the actual installed webhook configuration rather than treating a documented default as observed state. Gatekeeper failing closed and Kubernetes admission webhooks

Design inference: a healthy webhook can reject an invalid matching object under deny. An unreachable webhook cannot return that policy decision. With Ignore, the webhook error does not itself reject the request. With Fail, the call error can reject the request even if the object's policy evaluation would have passed.

Likewise, warn is not a denial, and dryrun does not block a violating request. Avoid collapsing “we observed the violation” into “we prevented persistence.” Other admission controls may still reject the request; acceptance by this Gatekeeper path is not a guarantee of final API success.

When discussing fail-closed operation, connect security and availability. A request that cannot be evaluated may stop, but infrastructure needed to recover the webhook may also depend on admission. Propose a tested, authorized recovery procedure and a narrow ownership model for its controls. Do not casually recommend disabling all policy checks during an incident.

What does an audit result actually prove?

Official fact: Gatekeeper audit periodically evaluates existing resources. Constraint status reports the latest audit's violations with a configurable detail limit; totalViolations includes violations beyond the listed details. Audit timestamps, metrics and logs provide evidence about run timing. Gatekeeper audit documentation

Now inspect this original five-object fixture. P1, P2 and P3 are Pods in prod without owner; P4 is a compliant Pod in prod; X is an unlabeled Pod in dev. Assume the audit covers the constraint's matching objects and its detail limit is two.

The expected violation total is three. A status detail list containing only P1 and P2 is compatible with that total. It is not evidence that P3 passed. X is outside this constraint's namespace match, so its absence says nothing about the quality of its labels.

Our local Python filter reproduces total three and two listed details. It models the fixture's counting contract; it does not run Gatekeeper or reproduce the component's ordering of reported details.

An audit at time T0 cannot establish the state of an object created at T1. Our older fixture, before P3 exists, has only two violations. Comparing its total directly with the later inventory confuses snapshots. Attach the run time and examined scope to any compliance statement.

Audit reporting also does not delete or repair the invalid objects it finds. In an answer, assign remediation separately: identify the owner, define an allowed correction, and verify the resulting state in a subsequent observation.

Can you explain eight distinct enforcement outcomes?

Use this original coverage ledger. Unless the row changes an assumption, the request reaches a healthy webhook, matches the constraint and violates its label requirement. Outcomes describe this enforcement path only.

Changed condition	Expected Gatekeeper-path result
Action is `deny`	Reject the evaluated violation
Action is `warn`	Allow with a warning
Action is `dryrun`	Allow without enforcing denial
Webhook unreachable; `Ignore`	Call error does not reject
Webhook unreachable; `Fail`	Reject because evaluation failed
API server excludes webhook call	This webhook never evaluates
Healthy webhook; constraint does not match	This constraint does not reject
Webhook called but unreachable; `Fail`, with a would-be unmatched object	Call error still rejects

The last row catches a subtle mistake. An object that would be excluded inside Gatekeeper may still depend on reaching Gatekeeper. Do not evaluate the constraint's match before an unavailable component has had a chance to receive the request.

The local decision model checks all eight rows, plus a valid matching object. It intentionally excludes Kubernetes authentication, other webhooks and native policies. A complete cluster test must observe those layers as well.

This ledger is more useful than memorizing one product default. An interviewer can change reachability, scope or enforcement mode, and you can identify which branch changes without inventing a different architecture.

Why do exemptions and enforcement points create different gaps?

Official fact: Gatekeeper documents namespace exclusions for particular processes and an admission-webhook exemption mechanism. A webhook exemption does not automatically exclude a resource from audit. API-server exclusion avoids the webhook call; Gatekeeper's internal exclusion is evaluated after the call reaches it. Namespace exemption documentation

Diagnostic inference: record whether the object was excluded from admission, audit, synchronization or only one constraint. A phrase such as “this namespace is exempt” is insufficient. Ask which configuration created the exemption and who can modify it.

Official fact: current Gatekeeper documentation supports scoped enforcement actions for specific enforcement points. enforcementAction: scoped activates that configuration; audit must be included explicitly or through the wildcard if it is meant to participate. Enforcement points

Interview inference: a policy assigned only to audit can report violations while providing no admission denial through the validating webhook. Conversely, a scoped policy without audit coverage may block new requests without producing the periodic resource evidence you expected.

Draw the intended coverage before debugging policy logic. Mark the validating webhook, audit process and any native Kubernetes policy as separate execution points. Verify which points actually exist in the deployment; a supported feature is not necessarily enabled.

Which policies cannot be reconstructed from stored objects?

Official limitation: Gatekeeper audit reviews cannot populate the original request's userInfo; policies depending on those user details are not auditable in the same way as object-only checks. Audit request-context limitation

Design inference: separate “this Pod has required labels” from “this caller is allowed to create this Pod.” A stored object can support the first predicate. It cannot, by itself, reconstruct the authenticated identity and circumstances of the original request.

For request-sensitive policy, preserve suitable admission evidence under the organization's logging and access rules. Do not infer caller authorization from a later clean object audit. Explain which question each evidence source can answer and which context is missing.

Referential checks introduce another boundary. If a policy reads replicated objects, the evaluator's view of those objects matters. Ask whether the needed kinds are synchronized, whether audit uses API reads or its cache, and how a stale view affects the decision. The current audit documentation describes both API-based evaluation and an optional cache-based mode; neither should be asserted as this cluster's observed configuration without inspection.

Keep the interview answer concrete: name the referenced object, the required freshness and the response to missing data. “We use policy as code” does not define those choices.

How would you investigate and roll out a repair?

Begin with one named invalid object and its creation or update time. Preserve the relevant configuration and observations before proposing changes. Determine whether it predates the constraint, whether the operation and resource match the webhook, and whether the constraint would match inside the evaluator.

Then inspect enforcement mode, execution-point configuration, webhook health and admission responses. Compare audit completion time and scope with the object inventory. Read totalViolations separately from the displayed details. This sequence distinguishes missed execution from a predicate that ran and returned the wrong answer.

For an original rollout proposal, use controlled valid and invalid fixtures in the intended namespaces. Add an out-of-scope namespace and a realistic workload resource so that “Pod-only” coverage is visible. Test both create and update paths covered by the configuration. Retain the actual responses and policy version.

During a nonblocking rollout, agree on which violations need correction and which exemptions are intentional. Promote enforcement only after checking false rejections, resource coverage and recovery ownership. Observation duration should follow the workload's change frequency; a fixed seven-day schedule would not establish coverage.

Measure admission errors and latency, audit age, expected versus evaluated kinds, and unresolved violations. A reduction in reported violations could mean remediation, but could also mean a narrower match or stale audit. Keep enough configuration history to tell those explanations apart.

Rehearse failure and recovery in an authorized test setting. Define the stop condition, who can change policy controls, and how restored enforcement is verified afterward. Our examples provide a reasoning harness, not evidence that this operational exercise has been performed on a cluster.