Kyverno Certified Associate (KCA)
The policy-as-code certification for Kubernetes — a third of the marks on writing validation, mutation, generation and image-verification rules, plus the CLI that lets you test them before a cluster does.
- src
- Linux Foundation Training & Certification — Kyverno Certified Associate (KCA) certification page (training.linuxfoundation.org)
- chk
Policy as code is the part of platform engineering that turns a security wish into something a cluster refuses to do. Kyverno is the CNCF engine for it, and the KCA is the only certification that examines the practice.
Where the marks actually are
Writing Policies is 32% of the exam, and the blueprint lists eleven competencies beneath it: validation, preconditions, background scans, mutation, generation, image verification, variables and API calls, JSON patches, autogen, cleanup policies and CEL. No other domain comes close — the next two are 18% each.
That matters because the common way to meet Kyverno is to apply somebody else's policy from the community library. That is the Applying Policies domain, and it is 10%.
The exam is about authorship. Not "can you enforce a rule" but "can you write one that mutates a resource, generates a companion object, verifies a signature and does not break every deployment in the cluster at once".
The deprecation you have to study around
Kyverno's documentation has moved to a newer set of policy types — ValidatingPolicy, MutatingPolicy, GeneratingPolicy — and now marks the older ClusterPolicy model as deprecated.
The published curriculum still names the ClusterPolicy rule types. It also names CEL, which is what the new types are built on.
So the honest preparation is both models. Reading only the current documentation leaves you fluent in a syntax the exam does not centre on; reading only older material leaves you unable to answer the CEL competency. This is a live gap between a project and its exam, and it is the single most useful thing to know before booking.
Against the CKS
They are not competitors. The CKS asks what a secure cluster looks like, across supply chain, runtime and network. The KCA asks how you express one of those answers as code that a controller enforces on every admission request.
Taken in order — CKS then KCA — the second one stops being about a tool and becomes about how governance survives contact with a hundred engineers who did not attend your meeting.
Before you book
Write a mutation rule and a generation rule. They are the two that reveal whether you understand admission control or have only read about it, and between them they carry a large share of the heaviest domain.
Learn the CLI as a CI step. apply, test and jp are 12% of the exam and roughly 100% of how you avoid shipping a policy that blocks production.
75% is the bar, applied across the Linux Foundation's multiple-choice exams rather than published per exam. Valid two years, renewed by sitting it again.
New to Linux and the command line?
This path assumes fundamentals you may not have yet. Our Foundations Pack is out and free — Linux, the shell and Git, with exercises that mark your work and explain why you got it wrong. We're writing an agents pack next; leave your email if you want to hear when it ships.
One email when the pack launches. No spam, unsubscribe any time.
Exam domains
Writing Policies
32%Fundamentals of Kyverno
18%Installation, Configuration, and Upgrades
18%Kyverno CLI
12%Applying Policies
10%Policy Management
10%Preparation path
- 1
Understand admission control before you write a single policy
Kyverno is a Kubernetes admission controller with a YAML front end, and the 18% fundamentals domain is really asking whether you know what intercepts a request and when. Get this wrong and mutation rules will never make sense.
~6 hours - 2
Write all five rule types by hand — this is 32% of the exam
Validation, mutation, generation and image verification are separate competencies, and so are preconditions, variables and JSON patches. Write each one against a real cluster. This is the largest domain by a wide margin and the only one practice fully covers.
~30 hours - 3
Learn CEL alongside the older rule syntax, not instead of it
The blueprint lists Common Expression Language inside the policy-writing domain, and Kyverno's newer policy types are built on it. The exam still names the rule types the documentation now marks deprecated, so you need both models in your head.
~10 hours - 4
Install it three ways and upgrade it once
Helm installation, CRDs, controller flags, RBAC and a high-availability layout are 18% between them, and upgrading is its own competency. Run the upgrade on a cluster with policies already enforcing, which is where the interesting failures are.
~12 hours - 5
Use the CLI the way a pipeline would
Only 12%, but three named subcommands — apply, test and jp — and it is the cheapest domain to secure. It is also the one that matters most at work: testing policies in CI is what stops a bad rule from blocking every deployment in the cluster.
~8 hours - 6
Read a policy report and grant an exception
Reports, PolicyExceptions and metrics are the last 10%, and they are the part of policy-as-code that decides whether a platform team is trusted. An exception with an expiry is the difference between governance and an obstacle.
~6 hours
Frequently asked questions
Career Roadmaps
- Platform Engineer RoadmapThe path DevOps engineers move into — building an internal developer platform as a product, covering Kubernetes as substrate, IaC at scale, GitOps, golden paths, portals, policy, multi-tenancy and adoption.
- Cloud Security Engineer RoadmapA path into cloud security as an engineering discipline, covering the shared responsibility model, identity, network segmentation, encryption, workload hardening, detection, governance as code, threat modelling and incident response.
- DevOps Engineer RoadmapA structured path from Linux fundamentals through cloud infrastructure, automation, containers, and monitoring to a production-ready DevOps engineering career.