Free KCA Mock Exam Sample Questions (10 Q&A with Explanations)

Fundamentals of Kyverno

Q1. Which rule types are supported inside a Kyverno policy?

Reveal answer and explanations

A `allow`, `deny`, `log`
Incorrect. `allow`, `deny`, and `log` are not Kyverno rule types; those are common NetworkPolicy-style verbs.
B `accept`, `reject`, `transform` (a Kyverno community proposal that never landed)
Incorrect. Kyverno does not use `accept`, `reject`, or `transform` as rule types.
C `validate`, `mutate`, `generate`, `verifyImages`
Correct. Kyverno rule types are `validate`, `mutate`, `generate`, and `verifyImages`.
D `check`, `patch`, `create`, `sign`
Incorrect. Those verbs do not correspond to Kyverno rule types.

Fundamentals of Kyverno

Q2. Which statement about OCI image references and Kyverno is correct?

Reveal answer and explanations

A `verifyImages` can only check images referenced by tag; digest references are rejected as unverifiable.
Incorrect. `verifyImages` explicitly supports both tag and digest; digests are actually preferred.
B Images pulled from a local `containerd` cache bypass `verifyImages` entirely even when the Pod is matched.
Incorrect. `verifyImages` runs at admission, independent of the node-level image cache.
C Kyverno cannot inspect OCI image metadata; it can only match on the textual image string.
Incorrect. Kyverno fetches and inspects OCI manifests, signatures, and attestations.
D By default `verifyImages` mutates the image reference to pin it to the verified digest.
Correct. `verifyImages` has `mutateDigest: true` by default, which rewrites the image reference to pin it to the verified digest so subsequent pulls are immutable.

Fundamentals of Kyverno

Q3. In Kubernetes, which type of admission controller does Kyverno register with the API server to enforce and mutate resources?

Reveal answer and explanations

A A built-in static admission plugin compiled into `kube-apiserver`. It is the historic mode used before kube-apiserver delegated to webhooks.
Incorrect. Kyverno is an external component; it is not compiled into the API server.
B A CSI driver that filters volume mount requests.
Incorrect. CSI drivers provide storage; they have nothing to do with admission control.
C A CNI plugin that intercepts pod creation at the node level.
Incorrect. CNI plugins handle pod networking, not Kubernetes admission policy decisions.
D A dynamic admission controller via `ValidatingWebhookConfiguration` plus `MutatingWebhookConfiguration`.
Correct. Kyverno registers dynamic validating and mutating admission webhooks with the API server to intercept and act on requests.

Fundamentals of Kyverno

Q4. Given this manifest, what does the policy do when a `Deployment` is created? ```yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: sample spec: rules: - name: only-pods match: any: - resources: kinds: - Pod validate: message: "bad" pattern: spec: containers: - name: "*" ```

Reveal answer and explanations

A Because autogen is on by default, the rule is also evaluated against the `Deployment` via synthesized rules targeting `Deployment` and `DaemonSet`.
Correct. Autogen is enabled by default for pod controllers (`Deployment`, `StatefulSet`, `DaemonSet`, `Job`, `CronJob`, etc.); Kyverno synthesizes additional rules so the check runs on the controller too.
B The rule is only evaluated against the `Pod` itself at Pod creation time, since autogen is off unless explicitly enabled with `pod-policies.kyverno.io/autogen-controllers`.
Incorrect. Autogen is on by default; the annotation is used to narrow or disable it.
C Only `Deployment` is evaluated; Kyverno does not re-check the underlying `Pod`.
Incorrect. Both the controller (via autogen) and the resulting Pod are evaluated.
D Autogen only synthesizes `mutate` rules, not `validate`, so `Deployment` is ignored.
Incorrect. Autogen applies to `validate`, `mutate`, and `verifyImages` rules on pod controllers.

Fundamentals of Kyverno

Q5. Which statement about mutating and validating admission phases is correct?

Reveal answer and explanations

A Validation runs first so mutated fields are never re-validated.
Incorrect. Validation runs after mutation so it operates on the final, mutated object.
B Mutation only runs during background scans, never at admission time.
Incorrect. Mutation runs at admission time; background scans do not mutate resources.
C Both phases run in parallel against the original request payload.
Incorrect. The phases run sequentially, not in parallel.
D Mutation runs first; validation evaluates the mutated object.
Correct. The API server executes mutating webhooks first and then validating webhooks against the mutated object; Kyverno respects this order.

Fundamentals of Kyverno

Q6. A rule contains `match.any` with two resource selectors and `exclude.all` with one selector. When is the rule considered to match a candidate resource?

Reveal answer and explanations

A When the resource satisfies both selectors in `match.any` and is not covered by `exclude.all`.
Incorrect. `any` is a logical OR, not AND; only one selector needs to match.
B When the resource satisfies at least one selector in `match.any` and does not satisfy every selector in `exclude.all`.
Incorrect. `exclude.all` means every selector in the `all` list must be satisfied for the exclusion to apply; with a single selector, this collapses to the selector itself.
C When the resource satisfies at least one selector in `match.any` and not the single selector in `exclude.all`.
Correct. `match.any` uses OR semantics, and `exclude.all` requires all of its selectors to match; here that is just the single selector, which must not match.
D When the resource satisfies any selector in either `match` or `exclude`.
Incorrect. `exclude` subtracts; it is never added to the match set.

Fundamentals of Kyverno

Q7. Consider this snippet: ```yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: require-labels spec: validationFailureAction: Enforce rules: - name: check-team match: any: - resources: kinds: [Pod] validate: message: "team label required" pattern: metadata: labels: team: "?*" ``` What happens if a Pod without the `team` label is created?

Reveal answer and explanations

A The Pod is admitted and a warning is written to the Kyverno logs.
Incorrect. `validationFailureAction: Enforce` blocks the request rather than merely warning.
B The request is queued until a cluster admin approves it manually.
Incorrect. Kyverno does not implement a human-approval queue; it admits or rejects synchronously.
C The Pod is admitted but silently mutated to add `team: default`.
Incorrect. This policy is a `validate` rule, not a `mutate` rule, so it will not add labels.
D The API server rejects the Pod with the rule's denial message.
Correct. With `validationFailureAction: Enforce`, Kyverno returns a denial with the rule's message, and the API server rejects the Pod.

Fundamentals of Kyverno

Q8. Which Kyverno CRD is created at runtime by the engine to track in-flight generate or update-request work?

Reveal answer and explanations

A `PolicyException`
Incorrect. `PolicyException` is user-authored to grant targeted exemptions.
B `ClusterPolicy`
Incorrect. ClusterPolicy is the cluster-scoped policy resource authored by humans and applied via kubectl or GitOps; the Kyverno engine never creates ClusterPolicy resources on its own — it reconciles against ones a user wrote.
C `CleanupPolicy`
Incorrect. `CleanupPolicy` is user-authored to schedule deletions.
D `UpdateRequest`
Correct. `UpdateRequest` is an internal CRD the engine creates to reconcile pending `generate` or `mutateExisting` work asynchronously.

Fundamentals of Kyverno

Q9. Which statement best describes what Kyverno is?

Reveal answer and explanations

A A general-purpose WebAssembly runtime used to sandbox Kubernetes workloads at the node level.
Incorrect. Kyverno is not a WebAssembly runtime; it is a policy engine built around Kubernetes resources.
B A container image build system that produces OCI-compliant artifacts from Dockerfiles.
Incorrect. Kyverno does not build container images; it validates, mutates, generates, and verifies Kubernetes resources.
C A service mesh proxy that enforces mutual TLS between pods using envoy sidecars.
Incorrect. Service-mesh functionality like mTLS is handled by meshes such as Istio or Linkerd, not by Kyverno.
D A Kubernetes-native policy engine that uses YAML manifests as policies.
Correct. Kyverno is a Kubernetes-native policy engine whose policies are themselves Kubernetes resources written in YAML, enforced via dynamic admission controllers.

Fundamentals of Kyverno

Q10. A team writes a `Policy` (namespaced) that uses `generate` with `synchronize: true` to clone a `ConfigMap` from another namespace. The policy is admitted but generation fails for every matched `Namespace`. Which constraint best explains why a namespaced `Policy` is the wrong choice here?

Reveal answer and explanations

A `Policy` resources cannot declare `synchronize: true` on a clone-based `generate` rule; only the default `false` and a manual resync are allowed.
Incorrect. `synchronize` is a valid field on `generate` rules regardless of policy scope, so it is not what blocks this Policy.
B Namespaced `Policy` objects silently ignore their `generate` rules at admission unless `background: true` is also set on each rule.
Incorrect. `background: true` controls background scanning of existing resources, not whether a `generate` rule executes at admission.
C A namespaced `Policy` can only generate or clone resources within its own namespace; cross-namespace clone or generation requires a `ClusterPolicy`.
Correct. A namespaced `Policy` is confined to its own namespace, so it cannot read a clone source in another namespace or create targets across `Namespace` boundaries; a cluster-scoped `ClusterPolicy` is required for cross-namespace clone/generation.
D `Policy` resources require `validationFailureAction: Enforce` to be set before any `generate` rule in the same policy is allowed to fire.
Incorrect. `validationFailureAction` governs the behavior of `validate` rules, not the execution of `generate` rules.