KCA Study Plan

The KCA blueprint lays out what the exam covers; this page decides when you study each part, and for how long. The Kyverno Certified Associate is unusually lopsided for a six-domain exam: Writing Policies alone is worth 32% and carries eleven of the exam's thirty-one competencies — more than the next two domains combined — while the two 10% domains, Applying Policies and Policy Management, together weigh less than half of it. A plan that gives every domain equal calendar time punishes you twice: too little time on the domain that actually decides the outcome, and too much on the ones that barely move the needle. This plan runs three weeks, spends its calendar by weight rather than by domain count, hands you a day-by-day schedule with an hours budget, original policy examples for all four rule types, and a final timed mock before you book the real exam.

Spend the three weeks where the marks are

☺ Like you're 10: Don't give every topic the same number of days. Give the biggest topic the most days — that's the whole trick.

The KCA curriculum publishes six weighted domains, and this plan does nothing cleverer than turning that percentage straight into a day count and an hours budget. Read the full domain table and competency list on the KCA blueprint first if you haven't already — this page assumes you know what each domain covers and focuses purely on pacing it.

Turned into a twenty-one-day, roughly 42-hour budget, split by weight (32% of the domain-study hours ≈ 12h, and so on down to the two 10% domains at ≈4h each), with three days held back for revision and a timed mock rather than folded into any single domain:

A two-minute readiness check before day one

☺ Like you're 10: Three weeks is a guess that fits most people. If Kubernetes itself is still new, give yourself more runway first.

This plan assumes CRDs, admission webhooks, RBAC and Helm are already unremarkable to you — KCA tests one policy engine deeply, not Kubernetes broadly, and the curriculum leans on that baseline without ever re-teaching it. If any of that is shaky, don't start the clock yet: a short pass through The Kubernetes Baseline You Need on this course, or the sibling Kubernetes course for CKA-depth coverage, pays for itself before day one — otherwise you'll be learning admission control and Kubernetes fundamentals in the same sitting, which is exactly the trap the readiness check on the blueprint also warns about. If you already run Kyverno, OPA/Gatekeeper or another admission controller in production, you can likely compress this to two weeks — most of Fundamentals and a chunk of Applying Policies is muscle memory you already have; reclaim those days for a second pass on Writing Policies instead, since KCA's YAML idioms are specific enough that "I use policy engines" and "I know Kyverno's exact schema" are different skills. If you've never written a line of Kyverno YAML, keep the full three weeks and don't compress week one — it's carrying a third of the exam on hands-on skill alone.

The 21-day schedule

☺ Like you're 10: Here's the whole three weeks on one strip — which days belong to which topic, at a glance.

The bar below is the table beneath it, drawn to scale. Block width is day count, not domain count — a third of the whole strip is Writing Policies alone, and every other domain fits into the remaining two weeks.

Week 1 close-up — the third of the exam that's pure hands-on building

☺ Like you're 10: One week, four kinds of rule: say no, quietly fix it, make a new thing, and check the seal on the box.

Writing Policies carries eleven named competencies — Validation Rules · Preconditions · Background Scans · Mutation Rules · Generation Rules · VerifyImage Rules · Variables & API Calls in Policies · JSON Patches · Autogen Rules · Cleanup Policies · Common Expression Language (CEL) — more than any other two domains combined. The four rule types are the spine; everything else on that list modifies or supports one of them. Spend days 1–3 on validate and mutate, days 4–5 on generate and verifyImages, and days 6–7 folding in preconditions, autogen, CEL and cleanup policies against policies you already wrote.

Start with a validate rule you write yourself rather than copy — the exam rewards recognising the shape, not memorising one example:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-readiness-probe
spec:
  background: true                        # also scan resources that already existed
  rules:
    - name: check-readiness-probe
      match:
        any:
          - resources:
              kinds: [Deployment]
      exclude:
        any:
          - resources:
              namespaces: [kube-system, kyverno]
      preconditions:
        all:
          - key: "{{ request.operation }}"
            operator: AnyIn
            value: [CREATE, UPDATE]
      validate:
        failureAction: Enforce            # without this, the rule only audits — never blocks
        message: "Every container needs a readinessProbe. See the platform runbook."
        pattern:
          spec:
            template:
              spec:
                containers:
                  - readinessProbe: "?*"  # ?* — at least one character, i.e. "something is set"

Then chain the other three rule types in one policy, because the exam expects you to read a multi-rule manifest fluently, not just single-rule snippets:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: golden-astronaut-defaults
spec:
  rules:
    # MUTATE — strategic-merge form here; practice the JSON-patch form
    # (patchesJson6902) on the same rule too, since the exam expects both
    - name: default-grace-period
      match:
        any:
          - resources: {kinds: [Pod]}
      mutate:
        patchStrategicMerge:
          spec:
            terminationGracePeriodSeconds: 30

    # GENERATE — every new namespace gets a starter ResourceQuota
    - name: default-quota-per-namespace
      match:
        any:
          - resources: {kinds: [Namespace]}
      generate:
        apiVersion: v1
        kind: ResourceQuota
        name: default-quota
        namespace: "{{ request.object.metadata.name }}"   # a variable, resolved at runtime
        synchronize: true
        data:
          spec:
            hard:
              requests.cpu: "4"
              requests.memory: 8Gi

    # VERIFYIMAGES — only images signed by our own pipeline may run
    - name: verify-pipeline-images
      match:
        any:
          - resources: {kinds: [Pod]}
      verifyImages:
        - imageReferences: ["registry.example.dev/golden-astronaut/*"]
          mutateDigest: true               # rewrite tag → digest once verified
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/example-org/golden-astronaut-pipeline/*"
                    issuer: "https://token.actions.githubusercontent.com"

Two facts worth pinning to memory while this is fresh. Autogen means a rule that matches Pod is automatically cloned onto the pod controllers (Deployment, StatefulSet, DaemonSet, Job, CronJob) so the error message actually reaches the person who ran kubectl apply; steer it with the pod-policies.kyverno.io/autogen-controllers annotation. And verifyImages runs in the mutating phase, because a passing verification rewrites the tag to the digest you just verified — a security control that works by mutating, and exactly the kind of fact multiple-choice questions are built from.

Week 2 close-up — fundamentals, operations, and the CLI

☺ Like you're 10: Now the second-biggest chunks: what Kyverno actually is, how you install and run it, and the three commands that check your work before it ever touches a cluster.

Fundamentals (days 8–9) is conceptual and cheap to secure: Kyverno registers as a validating and mutating admission webhook, so every create and update passes through it before the API server persists anything — that single sentence explains why match/exclude work the way they do and why background scans can't see admission-only context like request.userInfo. Policies are ordinary Kubernetes resources (ClusterPolicy/cpol is cluster-wide and the only kind that can match a Namespace; Policy/pol is confined to its own namespace) written in the same YAML you already read for everything else.

Installation, Configuration & Upgrades (days 10–12) is operational rather than conceptual, and it's the domain people skip because it's boring — despite being worth exactly as much as Fundamentals. A modern install is four deployments: admission (the only controller in the request path), background (scans, generate, mutate-existing), reports, and cleanup.

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

# high availability — scale the admission controller first, it's the one in the request path
helm install kyverno kyverno/kyverno -n kyverno --create-namespace \
  --set admissionController.replicas=3 \
  --set backgroundController.replicas=2 \
  --set reportsController.replicas=2

# controller configuration with flags — chart values move between versions,
# so `helm show values` is the source of truth, not a blog post
helm show values kyverno/kyverno | grep -A4 extraArgs

# what Kyverno may touch is ordinary RBAC — inspect it, never guess
kubectl get clusterrole | grep kyverno
kubectl get clusterrole kyverno:background-controller -o yaml

# upgrades: read the release notes for your exact target version first —
# CRD handling on upgrade has varied between chart versions
helm search repo kyverno/kyverno --versions | head
helm upgrade kyverno kyverno/kyverno -n kyverno --version YOUR_TARGET_VERSION

Two exam-shaped facts belong here. Kyverno dynamically scopes its own webhook rules to only the kinds your installed policies reference — install one Pod policy and the API server only calls Kyverno for pods. And a generate or mutate-existing rule needs the background controller to hold RBAC for whatever it creates — a rule that silently does nothing is very often a missing permission, not a broken rule, exactly like the drill above.

Kyverno CLI (days 13–14) is the best value on the paper: three subcommands, cheap to lock down.

# apply — "what would these policies do to these resources?", no cluster required
kyverno apply ./policies/ --resource ./manifests/
kyverno apply ./policies/ --resource ./manifests/ --policy-report
kyverno apply ./policies/ --cluster --policy-report      # dry-run against a LIVE cluster

# test — declarative unit tests, discovered recursively as kyverno-test.yaml
kyverno test ./policies/

# jp — debug the expression language before it goes anywhere near a rule
kyverno jp query -i pod.yaml 'spec.containers[*].resources.requests'
kyverno jp function                                       # list the custom functions

The daily study loop — draft, test, read the report, patch

☺ Like you're 10: Study the same way Kyverno itself works: write a rule, run it against examples, read what came back, fix only the gap, repeat.

Rather than inventing a separate study technique, this loop borrows the tool's own workflow and points it at a policy instead of a live cluster. You don't re-read the whole curriculum every evening — you draft one rule, test it against sample manifests, read exactly what passed and failed, and patch only that.

In practice: pick one competency from the eleven under Writing Policies, draft a rule for it without looking anything up, run kyverno test against two or three manifests you also wrote by hand, and read exactly which assertion failed. Patch only that gap and move to the next competency — don't re-read the whole Kyverno documentation every time one assertion is wrong. That discipline is the entire efficiency gain over passive re-reading, and it doubles as real practice for the CLI domain.

Week 3 close-up — applying, managing, and knowing when a rule actually fires

☺ Like you're 10: A correct-looking rule can still do nothing if it's never actually selected — this week is about knowing why, and how you'd prove it after the fact.

Applying Policies (days 15–16) is where "I wrote a correct rule" and "the rule actually fires" split apart. match and exclude each take any or all lists of filters — kinds, namespaces, names, label selectors, subjects, operations — and the commonest reason a policy "does nothing" is a selector that's subtly wrong, not a broken rule body. Common per-rule settings worth drilling cold: background (scan existing resources, with the caveat that admission-only context isn't visible there), and failureAction: Enforce vs. the audit-only default, which is the single highest-leverage setting on the entire exam — a rule without it never blocks anything, it only ever reports.

Policy Management (days 17–18) is how you prove any of this happened, after the fact:

# the report card — one PolicyReport per namespace, cluster-scoped results separately
kubectl get polr -A -o wide            # PolicyReports: pass / fail / warn / skip / error
kubectl get cpolr                      # ClusterPolicyReports

# reviewable, expiring carve-outs instead of a Slack message and a weakened policy
kubectl get polex -A                   # PolicyExceptions in force

# ordinary Prometheus metrics — guardrails land on the same dashboards as everything else
kubectl -n kyverno port-forward svc/kyverno-svc-metrics 8000:8000

PolicyReports (polr) and ClusterPolicyReports (cpolr) are how you measure a whole fleet before you ever flip a rule to Enforce. PolicyExceptions (polex) are a separate, reviewable resource — one named workload skips one named rule, through Git and code review, rather than permanently weakening the rule for everyone. Both connect straight back to Applying Policies: a report full of failures with zero rejections is failureAction left on audit, not a broken policy.

Final three days — revision and a timed mock

☺ Like you're 10: The last three days aren't for learning anything new. They're for finding out, honestly, whether the first eighteen days actually worked.

Day 19: a second pass on Writing Policies specifically — rewrite all four rule types from a blank page, no notes, then check each against what you wrote in week one. It's the heaviest domain and the one most worth revisiting rather than assuming it stuck. Day 20: work the KCA practice question bank at a relaxed pace, untimed, logging every miss by domain rather than just by question — a cluster of misses in one domain tells you exactly where the last few hours should go, and separately, try writing all thirty-one competency names from memory, grouped under their six domains, to find any you've been quietly avoiding. Day 21: sit Mock Exam · Set 1 under real conditions — ninety minutes, no notes, no pausing — then mark it honestly against the published 75% pass mark. Clear it comfortably and you can book the real exam. Land close but not comfortable, and hold your booking one more evening, patch whichever domain the mock exposed, and sit Mock Exam · Set 2 before committing a date — one score near the line is noise, two consistent scores above it is signal.

Exam-day logistics — and what to verify before you book

☺ Like you're 10: Once your three weeks are done, here's what booking the real thing actually involves — and a reminder to double-check every number before you pay.

These figures match the KCA blueprint's own logistics table and come from the Linux Foundation's and CNCF's official KCA pages, read in 2026.

↗ Official KCA page — Linux Foundation ◆ Multiple Choice Exam FAQ (pass mark)