Linux Foundation / CNCF KCA: Kyverno Certified Associate (KCA)

Last checked November 10, 2026 against the official Linux Foundation / CNCF exam page.

1. Question 1Writing Policies

   A team wants Pods that run containers as root to be rejected. Which rule design expresses this most directly?

   1. AA cleanup policy that removes Pods every hour when they are found to run as root
   2. BA generate rule that creates a companion ConfigMap listing every container in the cluster that is currently running as root
   3. CA mutate rule that deletes any Pod whose image name contains the word root
   4. DA validate rule that matches Pods and requires runAsNonRoot to be set to true in the security context
   Show answer and explanationHide answer

   Correct answer: D

   A validate rule with a pattern can require the runAsNonRoot setting, so non-compliant Pods are rejected at admission. Generate creates other objects, mutate changes objects rather than deleting them, and cleanup removes resources on a schedule instead of blocking creation.

2. Question 2Fundamentals of Kyverno

   A platform team wants every new Namespace to carry a cost-center label. Developers should not be able to create a Namespace without it. Which Kyverno construct expresses this requirement?

   1. AA ConfigMap that lists the required label keys and is read by the scheduler
   2. BA ResourceQuota that caps how many labels and annotations each Namespace is allowed to carry
   3. CA NetworkPolicy that drops network traffic from any Namespace that is missing the required label
   4. DA Kyverno policy with a validate rule that matches Namespaces and checks for the label
   Show answer and explanationHide answer

   Correct answer: D

   A validate rule in a Kyverno policy can match Namespace resources at admission and reject any request whose object lacks the label. A ConfigMap does not enforce anything by itself, a NetworkPolicy controls network traffic rather than object metadata, and a ResourceQuota limits resource consumption, not labels.

3. Question 3Installation, Configuration, and Upgrades

   A cluster operator wants to install Kyverno in a way that can be repeated across clusters, with the settings kept in version control. Which approach fits best?

   1. ARun kyverno apply against the cluster so that it creates the controller Deployments for it
   2. BApply the release manifests with kubectl and then edit each Deployment by hand in the running cluster to set the required values
   3. CCopy the Kyverno controller binary to each node and start it with a systemd unit file
   4. DInstall the official Kyverno Helm chart and pass a values file that is stored in version control
   Show answer and explanationHide answer

   Correct answer: D

   The official Helm chart accepts a values file, which can be versioned and reused for repeatable installs. Manual edits leave no reviewable record, a systemd unit would run the controller outside Kubernetes, and kyverno apply evaluates policies against resources rather than installing controllers.

4. Question 4Kyverno CLI

   A developer wants to check, in a CI job, whether manifests in a Git branch would violate policies stored as files. The CI runner has no access to the cluster. Which Kyverno CLI command fits?

   1. Akyverno test, which deploys the manifests into a temporary Namespace on the cluster
   2. Bkyverno version, which compares the policy files with the controller version installed in the cluster
   3. Ckyverno jp, given the manifest files as the input for a JMESPath query
   4. Dkyverno apply, given the policy files and the manifest files as inputs
   Show answer and explanationHide answer

   Correct answer: D

   kyverno apply evaluates policies against resource files offline and reports the results, so no cluster is needed. kyverno jp only evaluates JMESPath expressions, kyverno test checks results against expectations in a test file rather than deploying anything, and kyverno version only reports the CLI version.

5. Question 5Applying Policies

   An administrator adds a new validation policy to a cluster that already runs many workloads. They want to know which existing Pods violate the policy without waiting for those Pods to be recreated. What should they use?

   1. AThe Kyverno CLI test command, which connects to the cluster and rewrites the running Pods
   2. BThe background scan, which evaluates existing resources and records the results in policy reports
   3. CA cleanup policy, which deletes every existing Pod that does not match the new policy
   4. DThe admission webhook, which re-checks every running Pod each time the scheduler places a new Pod on a node in the cluster
   Show answer and explanationHide answer

   Correct answer: B

   Background scanning evaluates resources that already exist, and the results appear in policy reports. Admission webhooks only see requests as they arrive, the test command works on local files rather than the live cluster, and a cleanup policy deletes resources instead of reporting on them.