KCA — Kyverno Certified Associate

Self-service is the whole promise of a platform: developers ship without asking permission. What makes that promise safe rather than reckless is policy-as-code — rules that live in Git, run at admission time, and say no with a useful message before anything bad reaches a cluster. The Kyverno Certified Associate (KCA) is the CNCF and Linux Foundation credential for exactly that skill, and it is unusually concrete: nearly a third of it is writing policies. This page transcribes the official curriculum, explains what it means, maps it onto lessons already here — and says honestly when to skip it.

What the KCA is, and who it is for

☺ Like you’re 10: A test about one specific tool that guards the door of a Kubernetes cluster.

The KCA is a project-specific associate certification from the CNCF, delivered by The Linux Foundation, covering Kyverno — the policy engine that validates, mutates and generates Kubernetes resources at admission time. It sits in the same family as CAPA for Argo, ICA for Istio, PCA for Prometheus and CCA for Cilium, and it is narrow on purpose: where KCSA surveys the whole security landscape, KCA goes deep on one tool and expects you to know its API by heart. There is little to understand conceptually and a great deal to recognise on sight. Read a lot of YAML, then write a lot of YAML.

Who should sit it — and what it does not test

It suits platform engineers who own the guardrails: if you are the person who answers “can this team run privileged pods?”, this is your daily work formalised. It also suits security engineers moving from policy documents to policy code, and SREs who inherited a cluster with forty policies nobody understands.

Two things it is not. It is not a general Kubernetes security exam — that is KCSA for the knowledge and CKS for the hands-on version. And it is not a comparison exam: nothing asks you to weigh Kyverno against OPA/Gatekeeper. You are tested on this engine’s idioms.

Why a platform engineer might take it — and when to skip

☺ Like you’re 10: Worth it if you actually write the rules. Not worth it if you just want a badge.

The honest case for: policy-as-code is the load-bearing wall of a safe self-service platform, and it is genuinely hard to fake. The CNPE’s Security & Policy Enforcement domain is 15% of that exam and names admission control directly; Governance & Compliance leans on it for every multi-tenant guarantee you make. KCA forces you to learn the whole surface of one engine rather than the three rules you copied from a blog — the generate and verifyImages rule types in particular are things most engineers never touch until a curriculum makes them. It is also one of the few certifications where studying produces artefacts you keep: every policy you write while revising is a policy you can ship.

When to skip it — properly

• Your platform standardised on Gatekeeper or native admission policy. If your guardrails are Rego or ValidatingAdmissionPolicy, KCA certifies a tool you do not run. Read OPA/Gatekeeper and Security & Policy instead; the concepts transfer, the badge does not.
• You are mid-CNPE or mid-CNPA. Finish those. CNPA and CNPE are what a platform hiring manager scans for; KCA is a specialist stripe you add afterwards.
• Kubernetes itself is still new to you. The curriculum assumes CRDs, webhooks, RBAC and Helm are unremarkable. If they are not, do KCNA or CKA first — otherwise you will be learning two things at once and confusing them.
• Nobody will fund it and you write no policy. A credential you never exercise decays faster than its validity window. Spend a weekend on the Kyverno lesson and ship one real ClusterPolicy — that is worth more in a review than the certificate.

The official domains and their weights

☺ Like you’re 10: Six chunks, very unevenly sized — one of them is almost a third of the whole test.

The official Kyverno Certified Associate (KCA) curriculum, published by the CNCF, splits the exam into six weighted domains. The bars below are that blueprint, transcribed exactly and drawn to scale — and the six weights sum to exactly 100% (32 + 18 + 18 + 12 + 10 + 10), so nothing is missing and nothing double-counts:

Where the weight really sits

Writing Policies is 32% and carries eleven competencies — more than the next two domains combined, and by far the most detailed list on the blueprint. If you have limited time, spend it there.

The two 18% domains differ in character. Fundamentals is conceptual and cheap to secure. Installation, Configuration and Upgrades is operational — Helm values, controller flags, RBAC, high availability, upgrade mechanics — and is the domain people underestimate because it is boring. It is worth exactly as much as fundamentals. Kyverno CLI at 12% is the best-value domain on the exam: it names precisely four things, three of which are subcommands, and an afternoon of practice locks it. The two 10% domains sit either side of the interesting part — how a policy gets selected and applied, and how you see what it did afterwards.

Every competency, domain by domain

Domain names, weights and competency wording below are transcribed from the official CNCF curriculum PDF. The bars above and the table below are ordered heaviest-first for study purposes; the PDF itself lists the domains in a different order (Fundamentals, Installation, CLI, Applying, Writing, Policy Management) across two columns — the weights and the competencies under each are unchanged.

Six domains, thirty-one competencies. That is the entire testable surface, and it fits on one page — which is exactly why writing it out by hand once is such a good use of an evening.

What you actually need to know

☺ Like you’re 10: Four kinds of rule — say no, quietly fix it, make a new thing, and check the seal on the box.

Kyverno’s core idea is that policy is a Kubernetes resource. You do not learn a new language; you write YAML that looks like the YAML you are policing. The engine registers itself as a validating and mutating admission webhook, so every create and update passes through it before persistence — that is the “Admission Controllers” competency, and it explains the rest: a policy can only act where the API server invites it.

The shape of a policy, and how resources get selected

There are two policy kinds. ClusterPolicy (cpol) applies cluster-wide and is the only one that can match cluster-scoped resources like Namespace; Policy (pol) has an identical schema but is confined to its own namespace — the way a tenant owns rules for their own space. Both hold spec.rules[], and every rule needs a match. Resource Selection is its own competency for a reason: match and exclude each take any or all lists of filters that can pin kinds, namespaces, names, label selectors, subjects and operations. Getting the selector wrong is the commonest reason a policy “does nothing.”

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-team-label
spec:
  background: true                      # also evaluate existing resources in background scans
  rules:
    - name: check-team-label
      match:
        any:
          - resources:
              kinds: [Deployment, StatefulSet, DaemonSet]
      exclude:
        any:
          - resources:
              namespaces: [kube-system, kyverno]
      preconditions:                    # cheap gate — skip the rule entirely if false
        all:
          - key: "{{ request.operation }}"
            operator: AnyIn
            value: [CREATE, UPDATE]
      validate:
        failureAction: Enforce          # current per-rule form; the older spec.validationFailureAction
                                        # is deprecated — expect to recognise both on the exam
        message: "Workloads need a team label. Add metadata.labels.team."
        pattern:
          metadata:
            labels:
              team: "?*"                # ?* means "at least one character"

Three details there are worth marks. failureAction: Enforce turns a report into a rejection — without it the rule audits silently. preconditions are the idiomatic way to narrow a rule beyond what match can express. And background: true lets the background controller scan resources that already existed when you installed the policy — the Background Scans competency. Background scanning cannot see admission-only context such as request.userInfo, so a rule that depends on who made the request cannot run in the background.

The other three rule types — and autogen

mutate rewrites the resource on its way in, via a strategic merge patch (patchStrategicMerge) or an RFC 6902 JSON patch (patchesJson6902) — both named competencies — and can also mutate existing resources via targets. generate creates a companion resource when a trigger appears, using data (inline) or clone (copy a source object), with synchronize to keep the copy in step. verifyImages demands a valid cosign signature or attestation before a pod runs.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: platform-defaults
spec:
  rules:
    # MUTATE — an RFC 6902 JSON patch
    - name: default-pull-policy
      match:
        any:
          - resources: {kinds: [Pod]}
      mutate:
        patchesJson6902: |-
          - op: add
            path: "/spec/containers/0/imagePullPolicy"
            value: IfNotPresent

    # GENERATE — every new namespace gets a default-deny NetworkPolicy
    - name: default-deny-per-namespace
      match:
        any:
          - resources: {kinds: [Namespace]}
      generate:
        apiVersion: networking.k8s.io/v1
        kind: NetworkPolicy
        name: default-deny
        namespace: "{{ request.object.metadata.name }}"   # a variable, resolved at runtime
        synchronize: true
        data:
          spec:
            podSelector: {}
            policyTypes: [Ingress, Egress]

    # VERIFYIMAGES — no signature, no pod
    - name: verify-signed-images
      match:
        any:
          - resources: {kinds: [Pod]}
      verifyImages:
        - imageReferences: ["ghcr.io/acme/*"]
          mutateDigest: true            # rewrite tag → digest once verified
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/acme/*"
                    issuer: "https://token.actions.githubusercontent.com"

Two subtleties the exam likes. First, autogen: when a rule matches Pod, Kyverno automatically generates equivalent rules for the pod controllers — Deployment, StatefulSet, DaemonSet, Job, CronJob — so the rule is enforced where the error message is actually visible to the user. Steer or disable it with the pod-policies.kyverno.io/autogen-controllers annotation. Second, verifyImages runs in the mutating phase, because a successful verification rewrites the tag to the digest you verified, closing the tag-mutation race — a security control that works by mutating, which is exactly the kind of fact multiple-choice exams are built from.

Rounding out the 32%: variables and API calls ({{ ... }} JMESPath expressions over request, plus context entries that read ConfigMaps or call the Kubernetes API mid-rule), CEL as an alternative expression language inside validate — the same language the API server uses natively for ValidatingAdmissionPolicy — and CleanupPolicy / ClusterCleanupPolicy, which delete matching resources on a cron schedule. Cleanup policies are the odd one out: separate CRDs served by their own controller, not a fifth rule type.

Installing, configuring and upgrading — the 18% people skip

A modern Kyverno install is four deployments: the admission controller (the only one in the request path), the background controller (background scans, generate, mutate-existing), the reports controller and the cleanup controller. Knowing which is which turns a confusing outage into a fast diagnosis, and it is why high availability means scaling the admission controller first. Helm is the named installation method.

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

# high availability — the admission controller is 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 kyverno/kyverno` is the authority, not any blog
helm show values kyverno/kyverno | grep -A4 extraArgs

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

# upgrades: CRD handling on upgrade has varied between chart versions, so read the
# release notes for your target version and do not skip minor versions
helm search repo kyverno/kyverno --versions | head            # pick a real version first
helm upgrade kyverno kyverno/kyverno -n kyverno --version YOUR_TARGET_VERSION

Two exam-shaped facts live here. Kyverno dynamically configures its own webhook rules to cover only the kinds your installed policies reference — install one Pod policy and the API server only calls Kyverno for Pods. And generate and mutate-existing rules need the background controller to hold RBAC for whatever they create or modify; a generate rule that silently does nothing is very often a missing permission, not a broken rule.

The CLI, and seeing what your policies did

The standalone kyverno binary is what makes policy safe to change, because it evaluates rules against manifests without a cluster. The curriculum names exactly three subcommands.

# apply — "what would these policies do to these resources?"
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 pasting it into a rule
kyverno jp query -i pod.yaml 'spec.containers[*].image'
kyverno jp function                                     # list the custom functions

# in-cluster: the report card, the exceptions, and the metrics endpoint
kubectl get polr -A -o wide                             # PolicyReports, one per namespace
kubectl get cpolr                                       # cluster-scoped results
kubectl get polex -A                                    # PolicyExceptions in force
kubectl -n kyverno port-forward svc/kyverno-svc-metrics 8000:8000

That last group is the Policy Management domain in three lines. PolicyReports (polr) and ClusterPolicyReports (cpolr) hold machine-readable pass/fail/warn/skip/error results per resource per rule — how you measure a fleet before enforcing anything. PolicyExceptions (polex) are declarative, reviewable carve-outs: one workload skips one rule, through Git and code review rather than a Slack message and a weakened policy. And Kyverno metrics are ordinary Prometheus metrics — kyverno_policy_results_total, admission counts and latencies — so guardrails land on the same dashboards as everything else.

How to prepare using this site

☺ Like you’re 10: Nearly every KCA topic already has a page here. This table is the shortcut.

Work the heaviest domain first. The Kyverno deep-dive is the spine of this plan and covers the majority of the blueprint on its own; the other pages fill in the context the curriculum assumes you already have.

Three weeks is enough if you have a cluster. Week 1: read Kyverno beside the official curriculum, write all six domains and thirty-one competencies out by hand, and install the engine and CLI. Week 2: write one policy per rule type — validate, mutate with a JSON patch, generate, verifyImages — with unit tests for each, and read the official policy library until the idioms feel familiar. Week 3: the operational domain — upgrade a running install, scale it for HA, read its RBAC, break the webhook on purpose — then drill with the flashcards, quiz and glossary. The security practice set, the security lab and the wider lab track go deeper than KCA needs, but nothing cements a rule type like using it in anger once — and know cold is the last-night list.

Exam logistics — and go verify them yourself

☺ Like you’re 10: Here is what is published. Numbers move — look them up before you pay.

The KCA is administered by The Linux Foundation on behalf of the CNCF. Every row below is sourced from the official Linux Foundation and CNCF KCA pages and is only “true at the time this page was written” — where those pages publish nothing, this table says so rather than guessing. Check the official page before you spend anything:

Do not confuse the tiers. The KCA sits with the CNCF associate-tier, project-specific exams — CAPA, ICA, PCA, CCA, CGOA, OTCA, CBA — and all of them, like KCNA and KCSA, are multiple-choice knowledge exams. The performance-based exams, where you are dropped into a real terminal against real clusters and graded on what you build, are a different animal: CKA, CKAD, CKS and the CNPE. Preparing for KCA as if it were hands-on wastes time; preparing for CKA as if it were multiple choice fails you.

Book on the official Linux Foundation KCA page, and take the curriculum from the CNCF KCA page — the PDF is versioned, and the version in force on your exam date is the one linked there, not the one in anyone’s course. Read the Certification Candidate Handbook once for ID and proctoring rules, and keep the Kyverno documentation open throughout your study.

Where it sits in the ladder, and what to do next

☺ Like you’re 10: A specialist stripe, not a first badge and not a final one.

Place the KCA honestly. It is an associate-tier, project-specific credential: it says you know one tool properly — a useful signal for a platform team that runs that tool, and close to noise for one that does not. It is not a rung on the Kubernetes ladder the way CKA → CKS is; it sits beside that ladder with CAPA, ICA and CGOA, as evidence of depth in one part of the stack.

Three sensible next moves. For platform breadth: CNPA for the map, then CNPE, where everything here pays into the 15% Security & Policy domain and quietly into self-service and governance too. For security depth: KCSA for the wider context, then CKA and CKS — hands-on, harder, and the ones that change how people read your CV. For delivery: CGOA or CAPA, because policies you cannot ship through GitOps are policies that drift.

The durable takeaway is not the badge. It is the habit of turning every “please don’t do that” into a rule that runs by itself, with a message telling the developer how to fix it — because a guardrail that scales is one no human has to enforce. The full map of what to take, and in what order, is on the certifications hub.