Kyverno Certified Associate (KCA): Complete 2026 Study Guide

KCA exam facts and blueprint

The Kyverno Certified Associate is a CNCF and Linux Foundation credential focused on a candidate's ability to understand, apply, write, and manage Kyverno policy. It is not a performance-based shell exam. The official page describes an online proctored multiple-choice assessment. That changes the most effective preparation strategy: candidates need fast recognition of correct policy behavior, precise distinctions among closely related features, and enough hands-on experience to reason through YAML and operational scenarios without relying on memorized slogans.

The official Linux Foundation page identifies KCA as beginner level and lists a 90-minute duration. The credential is valid for two years. The current product page also advertises a 12-month eligibility window and one retake with the exam purchase; commercial terms can change, so verify them at checkout instead of treating a study guide as the purchase contract. Read the Candidate Handbook and multiple-choice exam instructions before exam day for identity, environment, scheduling, and proctoring requirements.

The six official domains are unusually useful because they describe an end-to-end operating lifecycle. Fundamentals and installation explain what the engine is and how it runs. The CLI gives a pre-cluster authoring and test loop. Applying Policies covers scope and common settings. Writing Policies is the technical center of gravity. Policy Management covers the evidence and governance required after a policy exists.

The question allocation above is exact for a 50-question practice set: 9 + 9 + 6 + 5 + 16 + 5. It does not claim that the real exam contains exactly 50 questions or uses this same distribution as integer counts. It simply provides a mathematically faithful study bank based on the public percentages. Use the KCA practice surface to time a 90-minute session, but spend more time explaining wrong options than celebrating a score.

The version-awareness problem: curriculum concepts and current APIs

KCA preparation in August 2026 requires a careful distinction. The public curriculum names long-established concepts such as validation rules, mutation rules, generation rules, verifyImages rules, JSON patches, autogen, CleanupPolicy, and policy exceptions. Current Kyverno documentation has also evolved toward CEL. The policy overview states that ValidatingPolicy, MutatingPolicy, GeneratingPolicy, DeletingPolicy, and ImageValidatingPolicy in policies.kyverno.io/v1 are stable. It states that the CEL-based types have full feature parity in Kyverno 1.19.

The same current documentation marks legacy ClusterPolicy, Policy, CleanupPolicy, and the legacy kyverno.io PolicyException deprecated in v1.19, with removal planned for v1.20. This does not make the public curriculum useless. The behavior vocabulary still teaches admission, matching, mutation, generation, images, context, and reporting. It does mean a responsible learner should not turn an exam objective into an unconditional production recommendation.

Use two tracks. For blueprint literacy, recognize the legacy rule structures and semantics named by the KCA competencies. For current engineering, read the policy-type overview, migration guide, release notes, and installed CRDs, then prefer supported stable APIs. In every lab, print the Kyverno version and inspect kubectl api-resources. A correct answer is often version-sensitive, and a production change should always be version-verified.

Domain 1: fundamentals of Kyverno

Kyverno is a cloud-native policy engine. It was built for Kubernetes and now supports policy evaluation beyond a cluster as well. Its core attraction is declarative policy managed with familiar Kubernetes and GitOps tools. A candidate should distinguish Kyverno from the components around it. Kyverno does not schedule Pods, provide the container runtime, allocate Pod IP addresses, or replace etcd. It evaluates or changes configuration according to policy and records results.

In Kubernetes, an API request is authenticated, authorized, and then admitted before persistence. Mutating admission happens before validating admission. This ordering is essential. A mutation can add a label, default a field, rewrite an image reference, or change another allowed part of the object. Validation must evaluate the final object rather than only the pre-mutation manifest. Review-time checks improve feedback, but cluster admission remains the authoritative boundary for requests that reach the webhook.

A policy is a Kubernetes resource with metadata and a specification. In the established ClusterPolicy model, the specification contains one or more rules. Each rule has a name, selects resources through match and exclude logic, can declare context and preconditions, and performs a behavior such as validate, mutate, generate, or verifyImages. Rule selection is not the same as rule success. A resource can be out of scope, excluded, skipped because a precondition is false, pass evaluation, fail evaluation, warn, or encounter an error.

Scope matters. A namespaced policy applies to namespaced resources in the Namespace where it exists. A cluster-scoped policy can cover many Namespaces and cluster-scoped resources. Choose narrow scope when ownership is delegated, but remember that cluster-wide controls such as Namespace policy or some admission registration behavior require cluster scope. Current CEL-based types also provide namespaced variants.

OCI literacy is part of the domain because image trust is a policy problem. A registry hosts repositories. A repository contains manifests and related content. A tag is a mutable pointer, while a digest identifies exact content. A signature proves integrity under a key or identity. An attestation contains signed claims, such as build provenance or an SBOM statement. None is interchangeable: a digest does not establish trust, a valid signature from an unexpected signer does not authorize production, and an attestation must be bound to the intended subject and checked against policy.

Domain 2: installation, configuration, and upgrades

Official Kyverno documentation recommends Helm for production-grade and highly available installation. The chart installs more than one Deployment. It creates CRDs, Services, controller-specific ServiceAccounts, Roles and ClusterRoles, bindings, ConfigMaps, certificate Secrets, and validating and mutating webhook configurations. Kyverno should run in a dedicated Namespace and should not share that Namespace with unrelated workloads.

The four controllers form a practical architecture map. The admission controller is required. It receives AdmissionReview callbacks, evaluates request-time policies, validates policy resources, manages webhook rules and certificates, and emits intermediate resources for reporting or asynchronous work. The background controller reconciles generate and mutate-existing operations, usually through UpdateRequest resources. The reports controller performs background scans and converts intermediate results into PolicyReport and ClusterPolicyReport resources. The cleanup controller handles scheduled deletion and TTL cleanup paths.

Do not infer scaling behavior from the number of Deployments. Admission webhooks do not use leader election for inbound requests, so multiple admission replicas can process concurrent traffic and improve both availability and scale. Certificate and webhook management still use a leader. The reports controller is leader-elected and one leader processes reports. The background controller similarly has one active processor for final generate or mutate-existing work. Additional replicas of those stateful controllers improve availability, while vertical resources and supported worker settings may affect throughput. The cleanup controller combines leader-elected and non-leader components.

RBAC follows controller ownership. An admission-time API lookup needs admission-controller read access. A generate policy needs the background controller to create, update, delete, or observe target resources. Reports need the reports controller to get, list, and watch evaluated resources. Cleanup needs the cleanup controller to list and delete targets. Kyverno uses aggregated ClusterRoles. The supported extension pattern is to create a supplemental role with explicit resources and verbs and the correct rbac.kyverno.io/aggregate-to-... label. Editing chart-owned default roles is fragile and can be lost during upgrade.

Configuration spans Helm values, the Kyverno ConfigMap, and controller flags. Important concepts include default registry behavior, user and group exclusions, resource filters, webhook Namespace selectors, background scan settings, reporting result filters, policy exceptions, metrics, tracing, image verification cache, registry helpers, client rate limits, TLS settings, and webhook timeouts. Learn which controller owns a flag. A reports interval setting does not tune background generation, and an admission flag does not automatically repair report permissions.

Kyverno manages webhook certificates by default and rotates them before expiry. Bring-your-own certificates shift renewal responsibility to the operator. Webhook availability is a security and operations decision. The default fail-closed posture rejects a request when matching policy cannot be evaluated. This protects against bypass but can block cluster operations if admission is unavailable. HA, narrowly designed Namespace exclusions, protected immutable Namespace labels, monitoring, and a rehearsed recovery process reduce the risk. Excluding system Namespaces improves recoverability but makes those resources outside the webhook's control, so RBAC and other controls must protect the boundary.

An upgrade is not an image-tag change. Releases can change CRDs, served or stored API versions, chart dependencies, RBAC, flags, webhooks, and policy validation. Export values and important resources, read the target release notes and every skipped minor release, review compatibility, render the new chart, rehearse in a disposable cluster, and prepare rollback. Validate admission, mutation, generation, reports, metrics, exceptions, image verification, and cleanup after the change. Current v1.19 guidance also requires planning migration from legacy policy types toward CEL-based APIs.

Domain 3: Kyverno CLI

The CLI closes the feedback loop before cluster admission. Install or download a version compatible with the policies and cluster release being tested, then record it in CI output. A policy evaluated by an unknown or drifting CLI version is difficult to reproduce. The three public curriculum commands—apply, test, and jp—serve different purposes.

kyverno apply evaluates policies against resource files, folders, Git sources, or resources from a selected cluster. It can accept values, context, user information, exceptions, parameter resources, target resources, and registry access. It can show detailed results, write mutated or generated resources, and emit a policy report. Use it while developing a policy or investigating one resource. Avoid making tests depend on an uncontrolled live cluster unless that is the explicit integration test.

kyverno test runs declared cases from a local directory or Git repository. A test describes policies, resources, and expected outcomes, then compares actual evaluation with those expectations. Include passing and failing resources, skipped conditions, mutations, generated resources, exceptions, missing data, array variants, and malformed values. Machine-readable output such as JUnit makes failures visible in CI. Enable a requirement that tests exist so an empty directory cannot produce a misleading green job.

kyverno jp provides a command-line interface to JMESPath plus Kyverno-specific functions. The function command lists available functions, parse displays the expression structure, and query evaluates an expression against input. Use it to confirm array projections, filters, default expressions, quoting for keys containing dashes or slashes, and custom functions before embedding an expression in policy YAML.

Offline evaluation has limits. The cluster supplies CRDs, API discovery, mutation ordering, live object state, RBAC, external API responses, registry credentials, network connectivity, webhook configuration, certificates, flags, and controller behavior. Model required context explicitly in unit tests, then add an integration stage in a disposable cluster. A strong pipeline uses syntax and small unit tests first, complete policy fixtures second, cluster integration third, and a staged Audit-to-Enforce rollout last.

# Illustrative workflow; pin the version and paths used by the project.
kyverno jp parse "request.object.spec.containers[*].image"
kyverno apply policies/ --resource resources/ --detailed-results
kyverno test tests/ --require-tests --output-format junit

Domain 4: applying policies

Applying a policy means more than submitting YAML. First determine whether the API server sends the request to a Kyverno webhook. Webhook Namespace selectors and match conditions can prevent delivery entirely. If the request reaches Kyverno, resource filters may tell the engine to disregard it. Then policy and rule match or exclude logic determines applicability. Preconditions can still skip the body. Understanding this layered path is essential when a policy appears not to run.

Selection can use kinds, API groups and versions, Namespaces, names, label selectors, Namespace selectors, operations, users, groups, subjects, Roles, and ClusterRoles according to the policy API and evaluation mode. Avoid using a mutable user-controlled label as the only enforcement boundary unless another control prevents unauthorized changes to that label. Test selected, excluded, and near-match resources. A typo that causes every result to skip can look quieter than a working policy.

Common settings control rollout and failure. Validation failure action distinguishes Audit from Enforce in legacy validation rules. Audit permits the resource and records a violation; Enforce blocks a violating admission request. emitWarning can surface Audit violations in admission responses. Policy failurePolicy determines what the webhook does when evaluation fails or times out. Background controls whether eligible existing resources are scanned for reporting. Webhook timeout limits admission waiting. There is no universally correct fail-open or fail-closed answer: scope, risk, availability, recovery, and compensating controls determine it.

A safe rollout starts with CLI tests, then Audit in a bounded canary. Examine reports and false-positive causes, fix existing resources, and create only justified exceptions. Monitor latency and errors. Move a selected Namespace or workload set to Enforce, test both allowed and denied operations, and expand gradually. Keep rollback explicit. Do not confuse a background finding with retroactive enforcement: background scans report existing violations but do not go back in time and reject stored objects.

Domain 5: validation, preconditions, and background scans

Writing Policies is 32% of the official blueprint, so it deserves repeated hands-on practice. Validation begins with a desired property. A pattern is an overlay that the resource must match. Undefined fields in the pattern are not constrained. A required field missing from the resource fails. Wildcards have semantics: * can match zero or more characters, ? matches one character, and ?* is commonly used to require a present non-empty string.

anyPattern is an OR across several patterns. A resource passes when any entry matches. Do not put pattern and anyPattern in the same validation rule. Anchors add conditional logic. A conditional anchor () acts like an if condition over a field and its children. An equality anchor =() says that when a field exists, its value or children must match. An existence anchor ^() requires at least one list element to match. A negation anchor X() requires a field not to exist, and a global anchor <() can cause the whole rule to skip when its condition is false.

Deny conditions reverse the mental model. A true pattern means validation succeeds; a true deny condition means the request is denied. Deny blocks use key, operator, value, and optional messages inside any or all logic. Kyverno short-circuits the conditions when the result is known. Use deny when the rule needs expressive comparisons, AdmissionReview values, variables, or JMESPath beyond a simple overlay.

Preconditions run after match and exclude and before the rule body. They let a rule match a broad kind but evaluate only when an operation or object property makes the check relevant. A false precondition produces skip rather than pass or fail. This distinction appears in reports and matters when measuring coverage. CEL validation has CEL-specific preconditions that apply to CEL subrules.

Background scanning evaluates existing resources periodically and writes results. It is enabled by default for eligible legacy Policy and ClusterPolicy validation and verifyImages rules. It does not retroactively block existing resources. The reports controller owns these scans, not the background controller. The stored resource can provide object and Namespace state, but it cannot reconstruct request.userInfo, Roles, ClusterRoles, or subjects from the original admission event. Rules requiring those values should disable background or be redesigned.

Kyverno also supports a Pod Security validation subrule that applies Kubernetes Pod Security Standards profiles and can expose fine-grained control exclusions. It reduces the need to hand-author every Pod Security field. Candidates should still understand match scope, profile level, version, exceptions, controllers, and the interaction with Kubernetes Pod Security Admission. If Kubernetes PSA blocks a request before it reaches external admission, Kyverno cannot evaluate that blocked request.

Mutation, JSON Patch, foreach, and ordering

Mutation changes matching requests. Legacy mutate rules commonly use strategic merge or RFC 6902 JSON Patch. Strategic merge resembles a partial Kubernetes resource and understands merge keys for known schemas. When targeting entries in the containers list, identify the entry correctly—often with a name anchor—so the patch applies where intended. Conditional anchors can limit when a merge occurs. The add-if-not-present anchor +() is especially useful for defaults because it preserves an explicit value already supplied by the workload owner.

JSON Patch provides exact add, replace, and remove operations. Paths use JSON Pointer, where a literal tilde becomes ~0 and a slash in a key becomes ~1. A final dash appends to an array. JSON Patch does not support conditional anchors, so use preconditions for gating. A Pod-targeted patchesJson6902 rule is not auto-generated for higher-level controllers; write explicit controller coverage or choose another suitable policy design.

foreach iterates sub-elements such as containers. A list is a JMESPath expression without variable braces. Each iteration exposes element, and JSON Patch loops can use elementIndex. Nested loops can expose numbered elements and indices. Loop order matters when removing array members; descending order avoids index shifts. No internal patches are emitted until loop processing completes, and separate dependent mutations may require carefully ordered cascading rules in one policy.

Kubernetes itself prevents mutation of fields such as name, Namespace, UID, kind, and apiVersion. Mutation should also be idempotent: evaluating the same desired object repeatedly should not append duplicates or oscillate. Test the initial object, an already-mutated object, missing optional arrays, several containers, init containers, ephemeral containers where relevant, and controllers.

Generation and mutate-existing behavior

A generate rule creates a downstream resource in response to a trigger. Common examples include a default NetworkPolicy or ResourceQuota for every tenant Namespace and cloning an image pull Secret or ConfigMap into selected Namespaces. A data source defines the target inline. A clone source copies an existing object. cloneList can select multiple source resources. Data and clone are mutually exclusive within one generate rule.

synchronize controls ongoing reconciliation. With synchronization enabled, changes to downstream state may be reverted, source or policy changes may propagate according to the source form, and loss of the trigger match can remove the downstream resource. The deletion and modification details differ between inline data and clone sources, so do not memorize one universal lifecycle. Build a small matrix and test delete or modify actions for trigger, source, policy, and downstream.

Generation is asynchronous. The admission controller creates an UpdateRequest, and the background controller processes the work. UpdateRequest states such as Pending, Completed, Failed, or Skip help diagnose missing output. Kyverno checks permissions when a policy is installed, but RBAC or other runtime failures can still occur. Inspect the UpdateRequest status, events, background-controller logs, and reconcile metrics.

Creating a RoleBinding has an extra Kubernetes RBAC constraint. A principal cannot bind permissions it does not possess unless authorized for the bind operation. If Kyverno generates a binding to the admin ClusterRole, the background controller must have sufficient authority for that role. This is not a Kyverno-specific quirk; it prevents privilege escalation in Kubernetes authorization.

Mutate-existing also uses the background controller. A trigger can cause changes to an already stored target resource, and the target can differ from the trigger. Target selection must be explicit because match conditions select the trigger and do not automatically constrain targets. Changes are asynchronous, may need additional RBAC, and should be tested for retries, reconciliation, immutable target fields, loops, and interaction with GitOps controllers.

Image verification and supply-chain policy

Legacy verifyImages rules and current ImageValidatingPolicy support supply-chain enforcement. In the legacy model, imageReferences selects static patterns, skipImageReferences excludes patterns, required requires verification, mutateDigest resolves a tag to a digest, and verifyDigest requires a digest. An optional repository can locate signatures separately, while registry credentials can come from configured helpers and Secrets. Current versions can also use appropriately authorized namespaced registry Secrets and Pod imagePullSecrets as documented for the installed release.

An attestor is the authority accepted for a signature or attestation. Sigstore Cosign supports key, certificate, and keyless identity models. Notary is also supported. An attestor set can require a count of successful entries. An attestation is signed metadata whose payload conditions can be evaluated. A policy might require a trusted build identity and verify that a signed statement names the expected environment or source. Never use real production keys in a learning lab.

Image verification occurs in a deliberate order. Other mutation can rewrite an image registry first. Image verification can then resolve and insert a digest during mutation. Validation checks required verification and digest conditions. Auto-generation can extend eligible Pod image checks to higher-level controllers. Test direct Pods and every controller used by the platform.

Verification introduces external dependency and latency. Registry calls may fail, credentials may be missing, signatures can move, and network timeouts can affect admission. Kyverno caches successful image verification outcomes with configurable size and TTL. The cache improves performance, but remote changes may not be reflected until expiry or policy change. Monitor image-policy execution duration, results, registry errors, admission latency, cache settings, and policy readiness. Choose failure policy explicitly and test an outage.

Supply-chain reasoning needs four separate questions. Does the digest identify the expected content? Is the signature cryptographically valid? Is the signer or issuer authorized for this artifact? Do required attestations contain acceptable claims bound to that digest? A policy that answers only the second question can admit an image signed by an unauthorized identity. The third hands-on project deliberately injects unsigned, wrong-signer, wrong-digest, altered-attestation, registry-outage, cache, and RBAC failures.

Variables, API calls, JMESPath, autogen, cleanup, and CEL

Legacy policy variables make rules dynamic. AdmissionReview data includes values such as request.object, request.oldObject, operation, Namespace, and user information where applicable. Image variables provide normalized registry, repository, name, tag, digest, and container maps. Context entries can define literal variables, read ConfigMaps, call the Kubernetes API, call in-cluster services, query image registries, or reference GlobalContextEntry caches.

A ConfigMap context is evaluated dynamically, and selected ConfigMaps can be cached. Keys containing dashes or slashes need correct JMESPath quoting. Array strings stored as JSON or YAML require parsing before membership logic. For Kubernetes API calls, use the correct core /api/v1 or grouped /apis/group/version path. Collection calls return an object containing items. Server-side field or label selectors can bound the response and return an empty collection instead of a not-found error for a missing exact object.

API calls run with controller identity, so grant only required reads or approved POST operations. External service calls must return JSON and should use trusted TLS, bounded response size, allowlists, and an explicit failure strategy. Current documentation describes additional HTTP hardening and a scoped ServiceAccount token when a policy does not set an Authorization header. Treat the ability to create cluster-scoped policies that make HTTP calls as privileged.

Auto-generation translates eligible Pod-only rules into rules for Pod controllers such as Deployment, DaemonSet, StatefulSet, Job, and CronJob, and also covers intermediate controllers in the documented status output. The translated path moves Pod fields under controller templates. The annotation pod-policies.kyverno.io/autogen-controllers can select controllers or disable generation with none. Auto-generation is skipped for mixed resource kinds and certain fields such as names, selectors, and annotations in match or exclude. Pod JSON Patch mutation is also excluded. Inspect generated status rather than assuming coverage.

Cleanup has two conceptual paths in the public material: scheduled deletion policies and the cleanup.kyverno.io/ttl label. Legacy CleanupPolicy and ClusterCleanupPolicy use match, exclude, optional conditions and context, plus a cron schedule. Current v1.19 documentation marks them deprecated and recommends the stable CEL-based DeletingPolicy. The TTL label can express an absolute time or relative duration, subject to cleanup-controller permissions and reconciliation interval. Deletion propagation can be Foreground, Background, or Orphan according to Kubernetes semantics. Test deletion only on synthetic labeled resources.

CEL is now a major Kyverno direction. A legacy validate.cel subrule evaluates expressions against variables such as object, oldObject, request, params, namespaceObject, and authorizer. Variables can make repeated or expensive expressions readable, but declaration order matters because one variable may reference only earlier variables. Parameter resources separate configuration from policy through paramKind and paramRef. Decide what happens when no parameter is found. CEL preconditions refine selection before validations.

Current standalone CEL policy types map behavior to purpose: ValidatingPolicy validates Kubernetes or JSON payloads; MutatingPolicy changes new or existing resources; GeneratingPolicy creates or clones resources; DeletingPolicy removes resources on schedule; ImageValidatingPolicy verifies signatures and attestations. Each has a namespaced variant. Learning CEL does not eliminate the need to understand admission, scope, RBAC, lifecycle, reporting, exceptions, and failure modes.

Domain 6: policy reports, exceptions, and metrics

PolicyReport is namespaced and ClusterPolicyReport is cluster-scoped. Kyverno produces reports from admission and background evaluations and reconciles them per current resource. Results include pass, fail, warn, error, and skip. Pass means an applicable rule evaluated successfully. Fail means the resource violated it. Skip commonly means a precondition did not hold or a PolicyException applied. Error can indicate failed variable substitution or processing. Warn can represent a non-scored failure according to policy configuration.

Reports are not an immutable forensic ledger. When a resource is deleted, its report entry is removed. A violating request blocked in Enforce mode does not create a stored violating resource, so use policy execution metrics and Kubernetes Events or an approved external audit pipeline to understand blocked attempts. Background reports describe current resources and never prove that an existing object was retroactively blocked. Large clusters can restrict which result types are stored to reduce etcd pressure, but the resulting coverage tradeoff must be documented.

PolicyException permits controlled deviations without editing the core policy. Current policies.kyverno.io exceptions work with CEL policy types and can use CEL match conditions and policy references. The legacy exception applies to legacy policy types and is deprecated in current v1.19 guidance. Exceptions are disabled by default in the documented controller configuration and require an exception Namespace setting. Restrict that Namespace, use RBAC and review, scope to exact policy and target, include owner and expiry, and monitor skip outcomes. A wildcard exception that any tenant can create is a policy bypass system.

Metrics answer operational questions that reports cannot. kyverno_admission_requests_total counts requests by allowed status, webhook, resource, Namespace, and operation. Admission review histograms show latency. Policy result counters and execution histograms show rule outcomes and cost. Controller reconcile, requeue, and drop counters help troubleshoot asynchronous work. Cleanup counters show deletion and errors. Client-query metrics reveal API load. kyverno_info exposes version. Use rates and histogram quantiles correctly rather than averaging counters.

A practical dashboard should answer: Are webhook endpoints ready? Is admission p95 within its service objective? Did deny or error rates change? Which policy or rule is slow? Are image verifications failing? Are UpdateRequests failed or backed up? Is report freshness within target? Are controller drops increasing? Which policies are not ready? Are certificates approaching expiry? Did the running version or policy inventory change unexpectedly? Operational confidence comes from several signals, not a single green Pod.

Three projects that convert knowledge into evidence

The KCA projects include architecture, prerequisites, at least nine steps each, security validation, failure injection, cost notes, and cleanup. They are designed for local disposable infrastructure. If a hosted cluster or registry is used, set a budget, expiry, and deletion checklist before creating anything. Never copy a production kubeconfig, registry credential, signing key, or workload into the lab.

A six-week preparation plan

1. Week 1—fundamentals: Read the official exam page and curriculum, introduction, admission guide, and policy overview. Draw request and artifact flows. Complete the nine Fundamentals questions and relevant flashcards.
2. Week 2—operations: Complete project 1. Install a pinned chart, map controllers and RBAC, inspect flags and webhooks, observe HA, inject failure, and rehearse an upgrade. Complete the nine installation questions.
3. Week 3—CLI: Create a small policy repository and use apply, test, and jp daily. Add positive, negative, skip, mutation, generation, exception, and error fixtures. Complete six CLI questions.
4. Week 4—application: Practice match, exclude, selectors, preconditions, failure settings, Audit, reports, and staged Enforce. Complete five Applying Policies questions.
5. Week 5—authoring: Complete projects 2 and 3. Rotate through validate, mutate, generate, image verification, variables, API calls, JSON Patch, foreach, autogen, cleanup, and CEL. Complete sixteen Writing Policies questions.
6. Week 6—management and simulation: Operate reports, exceptions, metrics, failures, recovery, and teardown. Complete five management questions, review all 40 cards, then take the full 50-question bank in 90 minutes.

Do not measure readiness only by score. For each missed or guessed item, write four lines: what the feature does, which controller owns it, whether it runs at admission or asynchronously, and what evidence proves it worked. For YAML questions, identify selection, conditional gate, action, failure behavior, and background compatibility. For operational questions, identify scope, permissions, dependency, signal, and rollback.

Multiple-choice exam strategy

Ninety minutes is enough when terminology is automatic. First pass: answer clear definitions and mark scenarios requiring field-level reasoning. Second pass: parse each YAML or architecture question in a fixed order. Identify the API version and kind, scope, match and exclude, preconditions, behavior, enforcement setting, background mode, controller, and external dependencies. Third pass: revisit multi-select wording and verify the requested number of options.

Eliminate answers that assign work to the wrong component. The reports controller does scans; the background controller does generate and mutate-existing reconciliation. The admission controller handles webhooks and policy validation. The cleanup controller deletes according to cleanup or deletion policy. The CLI can simulate and test, but it does not prove in-cluster RBAC or webhook health. Kubernetes authorization and admission are separate.

Watch for absolute claims. Multiple replicas do not always increase processing throughput. A signature does not always authorize an image. A background scan does not block an existing resource. A report is not permanent history. An Audit failure does not reject admission. A skipped rule did not necessarily pass. A Pod policy does not always auto-generate, and JSON Patch does not support strategic-merge anchors.

Use the question stem's version and context. If it asks about the public KCA concept, answer that concept. If it asks about current Kyverno guidance, account for CEL-based stable APIs and v1.19 deprecations. Avoid inventing a version not in the question. When two answers are technically possible, prefer the one that is least privilege, explicitly scoped, observable, tested, reversible, and documented by the official source.

Common KCA preparation mistakes

• Memorizing YAML without request flow. Trace authentication, authorization, mutation, validation, persistence, asynchronous work, and reporting.
• Calling every asynchronous feature “background scan.” Reports scans and background-controller reconciliation are different systems.
• Ignoring controller-specific RBAC. Grant the exact controller the exact verbs required by the feature.
• Assuming all replicas increase throughput. Leader election changes the scaling model for reports and background processing.
• Editing default roles. Use aggregated supplemental ClusterRoles to preserve upgrade safety.
• Changing only an image tag during upgrade. Review CRDs, APIs, chart values, RBAC, webhooks, and migrations.
• Using only happy-path CLI tests. Add denied, skipped, exception, missing-value, mutation, generation, and dependency failure cases.
• Confusing match, preconditions, and validation. They respectively select, gate, and decide.
• Reading skip as compliant. Inspect whether a precondition, anchor, or exception bypassed evaluation.
• Using request.userInfo in a background rule. Original actor data is not stored with the object for later scans.
• Assuming JSON Patch has strategic-merge behavior. Learn JSON Pointer and explicit add, replace, and remove operations.
• Assuming Pod rules always auto-generate. Mixed kinds, selection fields, and JSON Patch mutation can suppress translation.
• Giving Kyverno cluster-admin. Extend the owning controller with narrow aggregated permissions.
• Trusting any valid signature. Verify exact digest and authorized key or identity, issuer, and required attestations.
• Ignoring registry and cache dependencies. Test credentials, outage, timeout, cache TTL, and policy-change behavior.
• Treating reports as audit history. Store needed historical evidence in an approved external system.
• Creating broad permanent exceptions. Restrict policy, resource, identity, owner, approval, compensating control, and expiry.
• Studying old examples without version context. Compare curriculum vocabulary with current policy APIs and release notes.

Primary official references

• Linux Foundation: Kyverno Certified Associate — current format, duration, level, validity, domains, and registration resources.
• CNCF: KCA certification — program description, weights, and curriculum connection.
• CNCF curriculum repository — public KCA curriculum source.
• Linux Foundation Candidate Handbook — proctoring and candidate policies.
• Linux Foundation multiple-choice instructions — exam environment guidance.
• Kyverno introduction — policy management and capabilities.
• Kyverno policy types — current CEL APIs, supporting resources, and deprecation schedule.
• Kyverno installation — Helm, components, HA, and security-versus-operability.
• Kyverno configuration — certificates, RBAC, ConfigMap keys, flags, webhooks, filters, and HTTP controls.
• Kyverno high availability — controller ownership, concurrency, and leader election.
• Kyverno upgrades — supported methods, release changes, APIs, and migration.
• kyverno apply reference, test reference, and jp reference.
• Selecting resources and policy settings.
• Validate rules and preconditions.
• Mutate rules and generate rules.
• Image verification overview and Sigstore verification.
• Auto-generation, external data, and legacy cleanup and migration direction.
• Policy reports, PolicyExceptions, and metrics.

Use all four learning surfaces

Start with the six-week KCA roadmap. Take the 50 original KCA questions under a 90-minute timer. Review the 40 KCA flashcards until controller ownership, policy flow, and failure behavior are automatic. Complete all three KCA projects and retain sanitized diagrams, test results, metrics, failure evidence, recovery notes, cost decisions, limitations, and cleanup proof.

Continue with other technical roadmaps, engineering guides, cloud-native roles, and the PrepKloud editorial policy. Treat certification as a structured learning milestone, then maintain skill by reading current release notes and testing policy behavior whenever Kubernetes, Kyverno, registries, or organizational requirements change.