Key takeaways
- Writing Policies is 32% of the exam; write at least one rule of each type yourself.
- Most traps are evaluation order and defaults: mutation runs before validation, preconditions run after match, background scanning is on, PolicyExceptions are off.
- The Kyverno CLI (apply, test, jp) needs no cluster, so you can practise rules on any laptop.
- The current docs mark ClusterPolicy and CleanupPolicy deprecated in v1.19 and removed in v1.20; learn the rule model and the CEL types.
- At 75% you need about 45 of 60 correct, with roughly 90 seconds per question.
On this page
- What KCA tests, in numbers
- The rule model in one page
- Evaluation order and defaults: where most points are lost
- Writing Policies: a rule of each type
- Installation, CLI and policy management
- The v1.19 policy-type change
- A three-week KCA plan
- Reading a policy question in the right order
- Frequently asked questions
What KCA tests, in numbers
KCA is delivered online with a remote proctor. It has 60 questions, 90 minutes and a 75% pass mark; the list price is $250 and the certification is valid for 2 years. The weights below are from the CNCF curriculum. The plan below spends most of its time on Writing Policies, the largest domain.
| Domain | Weight | Curriculum topics |
|---|---|---|
| Fundamentals of Kyverno | 18% | Policies and rules; YAML manifests; admission controllers; OCI images |
| Installation, Configuration, and Upgrades | 18% | Helm install; CRDs; controller flags; RBAC; high availability; upgrades |
| Kyverno CLI | 12% | apply; test; jp; installing the CLI |
| Applying Policies | 10% | Applying policy in cluster; resource selection; common rule settings |
| Writing Policies | 32% | Validation, mutation, generation and verify-image rules; preconditions; background scans; variables and API calls; JSON patches; autogen; cleanup; CEL |
| Policy Management | 10% | Policy reports; PolicyExceptions; Kyverno metrics |
The rule model in one page
A Kyverno ClusterPolicy is a collection of rules. Each rule has a match declaration, an optional exclude declaration and exactly one action: validate, mutate, generate or verifyImages. The documentation says a rule can contain only one of those child declarations, so a policy that both mutates and validates needs two rules. Policies are just groupings: two rules in one policy have the same effect as two policies with one rule each.
- validate checks a resource and, depending on failureAction, blocks it (Enforce) or records a result (Audit).
- mutate changes a resource with a strategic merge patch or a JSON patch before it is stored.
- generate creates or clones another resource when a matching one appears, such as a default NetworkPolicy per Namespace.
- verifyImages checks image signatures and attestations, which is where OCI images come into the curriculum.
Evaluation order and defaults: where most points are lost
KCA options are often all valid Kyverno YAML; the right one depends on what runs first and what is on by default. Each item below is stated the way the Kyverno documentation states it.
| Rule of thumb | What the docs say |
|---|---|
| Mutation before validation | Resource mutation occurs before validation, so validation rules should not contradict the mutation |
| Preconditions after match | Preconditions are evaluated after a resource has been matched and not excluded; they narrow, they do not select |
| any is OR, all is AND | match and exclude take an any block (logical OR across filters) or an all block (logical AND) |
| Background is on | The background setting defaults to true, so existing resources are scanned and reported |
| Exceptions are off | PolicyExceptions are disabled by default; enable them with enablePolicyException and set exceptionNamespace |
| Audit is not a block | With failureAction Audit the request is allowed and the violation is reported |
Writing Policies: a rule of each type
The fastest way to learn the largest domain is to write the rules yourself and test them. Each step below is a short exercise that maps to a curriculum topic; together they take a few evenings with the Kyverno CLI.
- Validate: require a team label on every Pod, first with Audit, then with Enforce, and run kyverno apply on a Pod without the label.
- Mutate: add a default label or resource request, then check that a validate rule for the original value would never see it.
- Generate: create a ConfigMap or NetworkPolicy in every new Namespace, and read what synchronize changes.
- Preconditions and variables: limit a rule to Pods in one namespace using request.object values.
- JSON patch: rewrite the mutate rule with patchesJson6902 and compare the two forms.
- Autogen: write a rule for Pods and see the generated rules for Deployments and other controllers.
- CEL: rewrite the validate rule as a ValidatingPolicy with a CEL expression.
- Test: write a kyverno-test.yaml with expected results for each rule and run kyverno test.
Installation, CLI and policy management
The other domains are smaller but concrete. Installation questions ask about the Helm chart, the CRDs it installs, controller flags, the RBAC Kyverno needs and what changes for a highly available install or an upgrade. CLI questions ask which command fits a task. Policy management asks how results are reported and how exceptions are granted.
| Task | Tool or object |
|---|---|
| Run policies against local resource files | kyverno apply |
| Check rules against expected results | kyverno test with a kyverno-test.yaml |
| Try a JMESPath expression | kyverno jp |
| See which resources pass or fail | PolicyReport and ClusterPolicyReport |
| Exempt one workload from a rule | PolicyException, once enabled |
| Watch the engine itself | Kyverno metrics |
The v1.19 policy-type change
The Kyverno documentation now lists CEL-based types as the main policy types: ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy and ImageValidatingPolicy, each with a namespaced variant. ClusterPolicy and CleanupPolicy are listed as legacy types, deprecated in v1.19 and removed in v1.20. The curriculum does not name a version and still lists the classic rule types beside CEL, so the safe approach is to learn the rule model with ClusterPolicy and then learn how the same intent is written with the CEL types. If a question names a version, answer for that version. In practice, that means writing each rule you practise twice in the second week: once as a ClusterPolicy rule and once with the matching CEL-based type. The comparison is also a fast way to learn which concepts carry over and which are new.
A three-week KCA plan
Each day has two parts: questions from the bank and one rule you write and test. GoldenKube has 414 KCA questions; the adaptive order sends you to your weakest area and brings missed questions back until they stick.
Book the exam when two timed mocks a few days apart are above the pass mark and Writing Policies is no longer your weakest domain.
| Week | Main work | Milestone |
|---|---|---|
| 1 | Fundamentals, installation and CLI; first validate and mutate rules | kyverno apply runs your two rules against test manifests |
| 2 | Writing Policies every day: generate, preconditions, variables, JSON patch, autogen, CEL | A kyverno-test.yaml that passes for every rule type you wrote |
| 3 | Applying Policies and Policy Management; timed mocks and review of every miss | Every domain above the pass mark on new questions |
Reading a policy question in the right order
Many KCA questions show a policy and ask what happens to a resource. Reading the YAML from top to bottom wastes time; reading it in the order Kyverno evaluates it gives the answer faster and avoids the usual traps.
Questions about the CLI follow the same idea in reverse: decide whether the task is running policies against files (apply), checking expected results (test) or evaluating an expression (jp), then pick the command.
- Find the rule type: validate, mutate, generate or verifyImages. One rule has exactly one.
- Read match and exclude, and note whether the filters sit under any (OR) or all (AND).
- Check preconditions; they only narrow resources the match already selected.
- For validate, read failureAction: Enforce blocks, Audit allows and reports.
- Check whether a mutate rule in the same policy changes the field before validation sees it.
- Check policy settings such as background, which decide whether existing resources are reported too.
Frequently asked questions
Do I need a Kubernetes cluster to study for KCA?
It helps but is not required for most of the work. kyverno apply runs policies against resource files and kyverno test checks results against expectations in a test file, both without a cluster. A small local cluster is useful for admission behaviour, background scans, policy reports and installation topics.
Should I learn ClusterPolicy or the new CEL policy types?
Both. The curriculum names validation, mutation, generation, verify-image and cleanup rules as well as Common Expression Language, and it does not state a Kyverno version. The current policy types page lists ClusterPolicy and CleanupPolicy as legacy types deprecated in v1.19 and removed in v1.20, replaced by ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy and ImageValidatingPolicy.
Is KCA hard if I already know Kubernetes?
Kubernetes knowledge covers the admission controller and YAML parts. The points are lost on Kyverno specifics: what each rule type may contain, how match and exclude combine, when preconditions run, and what the defaults are. Those need deliberate study even for experienced cluster users.
How long should I study for KCA?
The Linux Foundation publishes no recommended time. The three-week plan here assumes a few hours a week and basic Kubernetes knowledge; someone who already writes Kyverno policies at work can compress it to one or two weeks of focused practice on the less familiar domains.
How does KCA relate to KCSA?
KCSA is broad Kubernetes security, including admission control as one topic among many; KCA goes deep on one policy engine. The comparison page explains which to take first and how much they overlap.
Does KCA count toward Golden Kubestronaut?
Yes, KCA is on the Golden Kubestronaut list. It has no prerequisite, so it can be scheduled whenever it fits your path.
Sources
Every exam fact on this page comes from these pages, read on the date shown.
- Linux Foundation: Kyverno Certified Associate (KCA) certification page, checked
- CNCF curriculum: KCA Curriculum (PDF), checked
- Multiple-choice exam instructions, Linux Foundation certification docs, checked
- Multiple-choice exam FAQ, Linux Foundation certification docs, checked
- Kyverno docs: Policy types overview, checked
- Kyverno docs: ClusterPolicy overview, checked
- Kyverno docs: Mutate rules, checked
- Kyverno docs: Generate rules, checked
- Kyverno docs: Auto-gen rules, checked
- Kyverno docs: Verify image rules, checked
- Kyverno docs: Validate rules, checked
- Kyverno docs: Selecting resources (match and exclude), checked
- Kyverno docs: Preconditions, checked
- Kyverno docs: Policy settings, checked
- Kyverno docs: Policy exceptions, checked
- Kyverno docs: kyverno apply, checked
- Kyverno docs: kyverno test, checked