Kyverno Certified Associate Exam: Six Domains, One Tool

What is Kyverno, and why does it have its own certification?

Kyverno is a policy engine for Kubernetes that runs as an admission controller, reading every resource on its way into the cluster and deciding whether to allow it, change it or reject it. It has its own credential because policy as code has become a distinct job, and because Kyverno writes its policies in Kubernetes YAML rather than in a separate language.

That last point is the whole reason the project exists. The established alternative expects you to learn a dedicated policy language, which puts a wall between the people who write manifests and the people who write the rules governing them. Kyverno removes the wall, and the consequence is that a platform engineer who already reads YAML can become useful on day one.

The project sits in the CNCF project landscape alongside the rest of the cloud native toolchain, which matters for a credential in a way it would not for a vendor product. A foundation-hosted project has public governance and public roadmaps, so the exam content is anchored to something you can read rather than to a release cycle you cannot see.

What an admission controller actually does

Every request to create or change a resource passes through the Kubernetes API server, and the admission controller stage is where a webhook can intervene before anything is persisted. Kyverno registers itself there. Domain 1 of the exam expects you to know this mechanism, not just the Kyverno syntax that rides on it.

Understanding the sequence explains several things the exam asks about later, including why a policy can mutate a resource before validating it, and why an outage in the webhook can block deployments across a whole cluster if the failure policy is set carelessly.

If you want the credential’s full scope beside the mechanics, the money site’s KCA certification overview sets the six domains and the exam terms out together.

Is the KCA exam hands on or multiple choice?

KCA is an online, proctored, multiple choice exam. This surprises people, because the Linux Foundation’s best-known Kubernetes credentials are performance based and drop you into a live terminal. KCA does not. You answer 60 questions in 90 minutes and need 75 percent, which is 45 correct answers.

The assumption is worth correcting early because it changes how you prepare. A terminal exam rewards muscle memory in the shell; a multiple choice exam at 75 percent rewards precise recall of what each rule type does and what each flag changes. Both need hands-on practice, but for different reasons.

Seventy-five percent is a high bar by certification standards, and it sits oddly next to a beginner label. Ninety seconds a question is comfortable, so the pressure is not time. The pressure is that you can only afford to be wrong 15 times across six domains, three of which carry 10 or 12 percent and therefore only a handful of questions each.

What do the six KCA domains cover?

KCA has six weighted domains: fundamentals of Kyverno at 18 percent, installation configuration and upgrades at 18 percent, the Kyverno CLI at 12 percent, applying policies at 10 percent, writing policies at 32 percent and policy management at 10 percent. The weightings on the money site and on the Linux Foundation’s own page match exactly.

Read the objective lists rather than the domain names, because the names understate the load. Writing policies is not one topic; it is eleven named capabilities, several of which are independent enough to be their own subject.

Why writing policies is nearly a third of the exam

Writing policies carries 32 percent, which is roughly 19 of the 60 questions and more than the next two domains combined. The reason is straightforward: everything else in Kyverno exists to run the policies, and the policies are where the engineering judgement lives.

The objective list names six kinds of rule, and the useful way to hold them is by what each one does to a request rather than by its syntax. Validation rules accept or reject. Mutation rules change a resource on the way through. Generation rules create other resources in response. VerifyImage rules check image signatures and attestations. Cleanup policies remove resources on a schedule.

The parts that sit underneath the rules

Preconditions, variables, API calls and JSON patches are not rule types; they are the machinery that makes a rule conditional or dynamic. Common Expression Language appears here too, which is the newer way of writing those conditions and is the part of the syllabus most likely to be unfamiliar to someone who learned Kyverno two years ago.

Autogen rules are the quiet one. Kyverno can automatically extend a pod-level rule to the controllers that create pods, so a policy written once applies to deployments, jobs and cron jobs without being restated. Candidates who have only written pod policies by hand routinely lose marks here.

Background scans change what a policy means

An admission policy only sees new and changed resources. A background scan applies the same rule to what is already running, which is how you find out that the cluster has been out of compliance since before the policy existed. The distinction between the two modes is a recurring source of exam questions and of production surprises.

The project’s own documentation is effectively this domain written out in prose, and working through it with a cluster open is a better use of study time than any summary.

What the installation and upgrade domain really asks for

Installation, configuration and upgrades carries the same 18 percent as fundamentals, and it is heavier than it sounds. It names Helm-based installation, Kyverno’s custom resource definitions, controller configuration through flags, RBAC roles and permissions, high availability installations, and the upgrade path.

The RBAC half is where security practitioners should pay attention. A policy engine that can mutate and generate resources needs permissions to do so, and those permissions are exactly what an attacker would want. Knowing which service accounts Kyverno runs under, and what each one may touch, is a genuine operational skill rather than exam trivia.

High availability is not optional in practice

Because Kyverno sits in the admission path, its availability is the cluster’s availability for anything that creates resources. The high availability objective exists because a single-replica install in a production cluster is a decision with consequences, and the failure policy that governs what happens when the webhook is unreachable is the setting that decides how bad those consequences are.

Anyone who has worked through the wider Kubernetes security surface on the CKS security specialist exam will recognise the pattern: the control plane component you add for safety becomes something you now have to keep safe and keep running.

What does KCA cost, and what does the price include?

KCA costs USD 250 for the exam on its own. That price includes two attempts, meaning one retake, and 12 months in which to schedule and sit. The certification is valid for two years once earned, and there are no prerequisites to buy first.

The Linux Foundation also sells KCA bundled with its annual subscription at USD 495, which adds access to a large catalogue of courses and skill credentials. Whether that is better value depends entirely on whether you would use the catalogue; as a route to this one credential, the standalone exam is the cheaper path.

The included retake changes the calculation

Two attempts for one price is more generous than it first appears at a 75 percent pass mark. It means a first attempt taken slightly early is a diagnostic rather than a loss, and with a 12 month window there is room to sit, learn what the questions actually look like, and return properly prepared.

That said, the retake is best treated as insurance rather than as a plan. Forty-five correct answers out of 60 is not a bar you clear by accident.

Where does KCA sit next to CKA and CKS?

KCA is narrower than either. The Kubernetes administrator and security specialist credentials cover a whole platform; KCA covers one project inside it, at beginner level, with no prerequisite. The Linux Foundation itself points holders toward the security specialist credential as the natural next step.

The practical question is therefore not which is better but which order makes sense. A platform engineer with no Kubernetes credential at all is usually better served starting with the broad administrator exam, because KCA assumes you already know what a deployment, a service account and a CRD are. A security engineer who already knows Kubernetes and needs policy as code specifically can take KCA directly.

The single-tool credential question

Certifications built around one open source project divide opinion, and the fair criticism is that a tool-specific badge ages with the tool. The counter-argument here is that the underlying skill, expressing governance as code that a cluster enforces automatically, transfers to whatever engine an employer runs, and the concepts in the writing-policies domain map closely onto the alternatives.

It is the same trade-off that runs through the Linux Foundation’s newer associate credentials generally, including the one covered in the PyTorch Associate guide, where a single framework stands in for a whole discipline.

How should you prepare for KCA?

KCA preparation is short by certification standards, usually four to six weeks alongside a job, and almost all of it should happen with a cluster open. A multiple choice format does not change that: the questions ask what a given policy does, and the fastest way to know is to have run it.

1. Install Kyverno with Helm into a throwaway cluster before reading anything else, since the installation domain carries 18 percent and is the cheapest to learn by doing.
2. Write one validation rule that rejects a pod without resource limits, then watch it reject a real deployment, which makes the admission controller mechanism concrete.
3. Work through each rule type in turn, covering validation, mutation, generation, verifyImage and cleanup, and write a small policy for each one rather than reading about it.
4. Practise preconditions, variables and API calls together, because these are what turn a static rule into a conditional one and they are examined as a group.
5. Learn Common Expression Language deliberately, as it is the newest part of the syllabus and the part most likely to be missing from older tutorials.
6. Drill the CLI commands apply, test and jp against your own policies, since the CLI is 12 percent and the commands are few enough to know completely.
7. Turn on background scans and policy reports on a cluster that already has workloads in it, which shows the difference between admission-time and existing-state enforcement.
8. Sit a full timed set of 60 questions in 90 minutes to confirm you are clearing 45 rather than hovering near it.

The official resources worth using

The Linux Foundation names two of its own courses as preparation for this exam, and the official KCA page lists the full competency set alongside them. Between that page and the project documentation you have the entire syllabus without paying for anything beyond the exam.

Frequently Asked Questions

Is the KCA exam hands on?

No. It is an online, proctored, multiple choice exam, unlike the Linux Foundation’s performance-based Kubernetes credentials. Hands-on practice still matters, but the sitting itself is not a terminal exam.

How many questions are on the KCA exam?

Sixty questions in 90 minutes, which is roughly 90 seconds each.

What is the passing score for KCA?

Seventy-five percent, which works out at 45 correct answers out of 60. That is a high bar relative to most associate credentials.

What does the KCA exam cost?

USD 250 for the exam alone, which includes two attempts and a 12 month window to sit. A bundle with the annual subscription is sold at USD 495.

Are there prerequisites for KCA?

None. The Linux Foundation lists the experience level as beginner and requires no prior certification, though practical Kubernetes familiarity makes the syllabus far easier to follow.

How long is KCA valid?

Two years from the date it is earned.

What are the KCA domains and weightings?

Fundamentals 18 percent, installation configuration and upgrades 18 percent, the CLI 12 percent, applying policies 10 percent, writing policies 32 percent and policy management 10 percent.

Should you take CKA before KCA?

If you have no Kubernetes credential at all, usually yes, because KCA assumes you already understand deployments, service accounts and custom resources. A practitioner who already has that grounding can take KCA directly.

Does KCA cover Open Policy Agent or Gatekeeper?

No. The syllabus is entirely Kyverno. The concepts transfer, but nothing in the objectives names an alternative engine.

How long does preparation usually take?

Four to six weeks alongside a job is typical, with most of that time spent writing policies against a real cluster rather than reading.

Conclusion

KCA is a narrow credential and it does not pretend otherwise. Six domains, one project, 60 multiple choice questions, and a third of the marks resting on whether you can write a policy that does what you intended. The beginner label describes the assumed starting point, not the 75 percent you need on the day.

Prepare with a cluster open, work through the rule types by what each one does to a request, and give Common Expression Language and autogen more attention than older tutorials will suggest. Then sit a full 60 question set under the clock and check you are clearing 45 comfortably rather than scraping it.

For anyone whose job now includes stopping bad manifests before they land, this is the shortest credible route to proving it.