Day 139 — 🥳How I Cleared the Kyverno Certified Associate Exam: My Preparation Strategy and Practical Guide for Readers

Alok Rahul

10 min read

·

May 19, 2026

--

Listen

Share

18th May 2026, Netherlands — On 18th May 2026 at 6:30 AM, I cleared the Kyverno Certified Associate — KCA exam. This was not an easy attempt. I had to utilize a couple of my vacation holiday to prepare for this certification, but completely worth it 😉

Press enter or click to view image in full size

This certification felt special because Kyverno is not just another Kubernetes tool. It sits at the intersection of Kubernetes security, policy-as-code, automation, governance, and platform engineering. For anyone working as an SRE, DevOps Engineer, Platform Engineer, Kubernetes Administrator, Security Engineer, or AI/MLOps Engineer, Kyverno is becoming a very practical skill.

The KCA exam is an online, proctored, multiple-choice exam. The official CNCF exam domains are: Fundamentals of Kyverno — 18%, Installation, Configuration, and Upgrades — 18%, Kyverno CLI — 12%, Applying Policies — 10%, Writing Policies — 32%, and Policy Management — 10%. (CNCF)

This blog is my personal reflection on how I prepared, what helped me, and how you can prepare with a clear strategy.

Why I Chose Kyverno Certified Associate

As someone working around Kubernetes, reliability, DevOps, platform engineering, and AI workload governance, I see one common problem again and again:

Kubernetes gives teams speed, but without policies, speed can become risk.

A developer may accidentally deploy a container without resource limits.
An ML team may deploy a GPU workload without proper labels.
A namespace may miss required network policies.
A workload may use latest image tags.
Secrets may be copied incorrectly.
Compliance may be checked too late.

Kyverno helps solve these problems by bringing policy-as-code directly into Kubernetes.

The Linux Foundation describes KCA as a certification for professionals who want to prove their skills in managing and securing Kubernetes environments, especially around policy automation and cloud-native security. (Linux Foundation — Education)

For me, this certification was not only about passing an exam. It was about becoming better at thinking like a Kubernetes governance engineer.

My Preparation Mindset

I did not prepare by only reading theory.

My approach was simple:

Read the concept. Write a policy. Apply it. Break it. Fix it. Test it. Repeat.

Kyverno is very YAML-oriented. That is one of its strengths. Unlike some policy engines where you need to learn a new policy language, Kyverno policies are written in Kubernetes-style YAML. This makes it relatable for people already familiar with Kubernetes manifests.

So my preparation strategy was hands-on first.

I focused on these questions while studying:

What problem does this Kyverno feature solve in a real Kubernetes cluster?
Where would an SRE use this in production?
How can this prevent failure before it reaches production?
How does this help in AI and MLOps workload governance?

That mindset made the exam preparation more meaningful.

Exam Section 1: Fundamentals of Kyverno — 18%

This section builds the foundation.

You need to understand what Kyverno is, why it exists, and how it works inside Kubernetes.

Focus areas:

• What is Kyverno?
• Admission control basics
• Policy and ClusterPolicy
• Rules inside a policy
• Match and exclude logic
• Validate, mutate, generate, and verifyImages
• Admission review flow
• Kubernetes-native policy-as-code

My approach was to first understand Kyverno as a Kubernetes admission controller.

When a user runs:

kubectl apply -f deployment.yaml

the request goes to the Kubernetes API server. Kyverno can inspect that request before the resource is accepted. Based on policies, it can allow, deny, mutate, or generate resources.

This is important because many production issues can be prevented at admission time.

For example:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-team-label
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "The label team is required."
        pattern:
          metadata:
            labels:
              team: "?*"

This simple policy ensures that every Pod has a team label.

In a real AI platform, that label may be required for:

• cost allocation
• ownership
• incident routing
• observability dashboards
• GPU usage tracking
• compliance reporting

My suggestion: do not memorize Kyverno fundamentals blindly. Connect every concept with a real platform problem.

Exam Section 2: Installation, Configuration, and Upgrades — 18%

This section is very practical.

You should understand how Kyverno is installed, configured, and upgraded in a Kubernetes cluster.

Focus areas:

• Installing Kyverno
• Kyverno components
• Helm-based installation
• Namespace and deployment structure
• Webhooks
• CRDs
• Configuration options
• Upgrade considerations
• High availability basics
• Policy reports and background scanning

My preparation approach was to install Kyverno in a local cluster and inspect everything.

Commands I practiced:

kubectl create namespace kyverno

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

helm install kyverno kyverno/kyverno -n kyverno

Then I checked:

kubectl get pods -n kyverno
kubectl get deploy -n kyverno
kubectl get crds | grep kyverno
kubectl get validatingwebhookconfigurations
kubectl get mutatingwebhookconfigurations

This helped me understand that Kyverno is not magic. It is a set of Kubernetes controllers, CRDs, and webhooks working together.

For the exam, do not just know that Kyverno can be installed. Understand what gets installed and why it matters.

In production, installation and upgrade knowledge matters because Kyverno sits in a sensitive path. If policy webhooks are misconfigured, they can impact workload admission. As an SRE or platform engineer, you must know how to install it safely, configure it correctly, and upgrade it responsibly.

Exam Section 3: Kyverno CLI — 12%

The Kyverno CLI is one of the most useful parts of the ecosystem.

The official exam gives 12% weight to the CLI domain, so it is not the biggest section, but it is very important for real-world engineering. (CNCF)

Focus areas:

• kyverno apply
• kyverno test
• validating policies locally
• testing policies before cluster deployment
• policy testing in CI/CD pipelines
• working with resources and policy files

My preparation strategy was to think of Kyverno CLI as a shift-left tool.

Instead of waiting for a policy to fail in the cluster, you can test it earlier on your laptop or in CI/CD.

Example:

kyverno apply require-labels.yaml --resource pod.yaml

This helps answer:

If this policy is applied to this resource, will it pass or fail?

The kyverno test command is even more powerful because it allows structured test cases.

A simple test structure may include:

name: require-labels-test
policies:
  - require-labels.yaml
resources:
  - pod-without-label.yaml
results:
  - policy: require-labels
    rule: check-team-label
    resource: nginx
    kind: Pod
    result: fail

Then run:

kyverno test .

This is extremely useful in AI/MLOps environments.

Imagine a platform team managing policies for GPU workloads. You can test policies before they are merged into Git. This prevents broken policies from reaching production clusters and saves debugging time later.

My suggestion: practice the CLI repeatedly. The CLI gives you confidence because you can see policy behavior before deploying it.

Exam Section 4: Applying Policies — 10%

This section is about how policies are applied and how they behave.

Focus areas:

• Applying Policy vs ClusterPolicy
• Namespace-scoped vs cluster-scoped enforcement
• Audit vs Enforce behavior
• Background scans
• Policy reports
• Resource matching
• Testing policies against workloads

One important concept is the difference between Audit and Enforce.

Example:

spec:
  validationFailureAction: Audit

In Audit mode, Kyverno reports violations but does not block the resource.

spec:
  validationFailureAction: Enforce

In Enforce mode, Kyverno blocks non-compliant resources.

This is very important in real production environments.

A good platform engineering approach is:

1. Start with Audit
2. Observe violations
3. Discuss with application teams
4. Fix common gaps
5. Move to Enforce

This prevents unnecessary disruption.

For AI workloads, this is especially important because teams may already have running pipelines, GPU workloads, batch jobs, model-serving services, and experiment namespaces. Suddenly enforcing strict policies without observation can break delivery.

My advice: understand policy rollout strategy, not just policy syntax.

Exam Section 5: Writing Policies — 32%

This is the largest section of the exam.

The official weight is 32%, which means policy authoring deserves the most preparation time.

Focus areas:

• Validate rules
• Mutate rules
• Generate rules
• Verify image rules
• Match and exclude
• Preconditions
• JMESPath
• Anchors
• Patterns
• Deny rules
• Foreach
• Strategic merge patch
• JSON patch
• Autogen rules
• Pod Security Standards

This is the section where hands-on practice matters most.

Validate Rules

Validate rules check whether a resource follows the expected standard.

Example use cases:

• Require labels
• Require resource limits
• Block privileged containers
• Disallow latest image tag
• Require specific annotations
• Enforce Pod Security Standards

Example:

validate:
  message: "CPU and memory limits are required."
  pattern:
    spec:
      containers:
        - resources:
            limits:
              memory: "?*"
              cpu: "?*"

Mutate Rules

Mutate rules modify resources automatically.

Example use cases:

• Add default labels
• Add annotations
• Set default imagePullPolicy
• Inject node selectors
• Add tolerations
• Standardize metadata

For platform teams, mutation reduces repeated manual work.

In AI workloads, mutation can automatically add:

• cost-center labels
• team ownership labels
• observability annotations
• default resource settings
• scheduling hints

Generate Rules

Generate rules create Kubernetes resources automatically.

Example use cases:

• Create default NetworkPolicy in a namespace
• Generate RoleBinding for a team
• Clone ConfigMaps or Secrets
• Create default resource quotas
• Standardize namespace bootstrap

This is very useful for platform engineering because every new namespace can start with a secure baseline.

Verify Images

Image verification is important for supply-chain security.

In modern software delivery, especially with AI workloads, teams pull images from different registries. Kyverno can help enforce trusted image sources and image signature verification.

My Advice for This Section

Do not try to learn all policy types in one sitting.

Break preparation like this:

Day 1: Validate rules
Day 2: Match, exclude, preconditions
Day 3: Mutate rules
Day 4: Generate rules
Day 5: CLI testing
Day 6: Policy reports and management
Day 7: Mixed revision and mock scenarios

This section becomes easier when you write small policies yourself.

Exam Section 6: Policy Management — 10%

This section focuses on operating policies over time.

Focus areas:

• Policy lifecycle
• Policy reports
• Exceptions
• Background scans
• Managing policy changes
• Troubleshooting policy behavior
• Understanding policy results
• Gradual enforcement
• Governance at scale

In real life, writing a policy is only the first step.

The bigger challenge is:

How do we manage policies without slowing down engineering teams?

That is where policy management matters.

For example, you may have a strict policy that blocks containers running as root. But one legacy workload may need temporary exception while the team fixes the image.

In this case, you should understand when to use exceptions, when to use exclusions, and how to avoid making policies too broad or too weak.

My personal view: policy management is where SRE thinking becomes important.

A good SRE does not just block everything.
A good SRE builds safe guardrails.
A good platform engineer helps teams move fast without creating unnecessary risk.

My Practical Preparation Strategy

Here is the preparation method that worked for me.

1. Start with Kubernetes Basics

Before Kyverno, be comfortable with:

• Pods
• Deployments
• Namespaces
• ConfigMaps
• Secrets
• ServiceAccounts
• RBAC basics
• Admission controllers
• YAML structure

Kyverno is Kubernetes-native, so weak Kubernetes basics will make the exam harder.

2. Install Kyverno Locally

Use a local cluster like:

• kind
• minikube
• k3d

Then install Kyverno and inspect its components.

Do not only read installation commands. Run them.

3. Practice Small Policies

Start with simple policies:

• require labels
• block privileged containers
• require resource limits
• disallow latest image tag
• add default labels
• generate default NetworkPolicy

Small policies build confidence.

4. Use Kyverno CLI Early

Do not wait until the end to learn the CLI.

Use:

kyverno apply

and:

kyverno test

These commands help you learn faster because they give immediate feedback.

5. Read Policy Reports

After applying policies, check the results.

kubectl get policyreport -A
kubectl get clusterpolicyreport

Policy reports help you understand what Kyverno is seeing inside the cluster.

6. Learn Through Scenarios

Instead of studying only definitions, create real scenarios.

Example:

A data science team deploys a model-serving Pod without memory limits. What Kyverno policy can prevent this?

Example:

A team creates a namespace for an AI experiment. How can Kyverno generate default NetworkPolicy and ResourceQuota?

Example:

A workload uses nginx:latest. How can Kyverno block mutable image tags?

Scenario-based learning is much more powerful than memorization.

How Readers Can Prepare and Clear the Exam

Here is a simple preparation plan.

Week 1: Foundation

Learn:

• What is Kyverno?
• Why policy-as-code?
• Policy vs ClusterPolicy
• Admission controller flow
• Validate, mutate, generate, verifyImages

Practice:

• Install Kyverno
• Apply simple validate policy
• Test with compliant and non-compliant Pods

Week 2: Policy Authoring

Learn:

• Match and exclude
• Preconditions
• Patterns
• Deny rules
• Mutate rules
• Generate rules
• Anchors
• JMESPath basics

Practice:

• Write 10 small policies
• Break them intentionally
• Fix YAML errors
• Observe policy behavior

Week 3: CLI and Exam Revision

Learn:

• Kyverno CLI
• kyverno apply
• kyverno test
• Policy reports
• Exceptions
• Audit vs Enforce
• Troubleshooting

Practice:

• Create test cases
• Run mock questions
• Review weak areas
• Revise official exam domains

The official CNCF page also points candidates to exam resources such as the candidate handbook, FAQ, important instructions, and curriculum overview. (CNCF)

Mistakes to Avoid

1. Do Not Only Read Documentation

Reading is important, but Kyverno becomes clear only when you write policies.

2. Do Not Ignore YAML Structure

Many Kyverno concepts are easy, but YAML indentation mistakes can confuse beginners.

3. Do Not Skip CLI

The CLI helps you understand policy behavior before cluster deployment.

4. Do Not Memorize Without Context

Instead of memorizing, ask:

What production problem does this solve?

5. Do Not Study Validate Only

Validate rules are important, but also learn mutate, generate, verifyImages, reports, and exceptions.

Why This Certification Matters in the Age of AI Workloads

AI workloads are expensive, fast-moving, and security-sensitive.

They often involve:

• GPU nodes
• model-serving workloads
• experiment namespaces
• secrets and API keys
• container images from different registries
• high compute cost
• sensitive datasets
• strict compliance requirements

Without governance, AI platforms can become risky and expensive.

Kyverno helps platform teams enforce standards such as:

• every workload must have owner labels
• GPU workloads must have resource limits
• only trusted registries are allowed
• privileged containers are blocked
• default network policies are generated
• required annotations are added automatically
• non-compliant workloads are reported before enforcement

This is why Kyverno is not just a security tool. It is also a reliability, governance, and cost-control tool.

Final Thoughts

Clearing the Kyverno Certified Associate exam on 18th May 2026 at 6:30 AM was a proud moment for me.

But the bigger value was the learning journey.

This exam helped me think more clearly about Kubernetes governance, policy automation, security controls, and platform reliability.

My advice to every reader is simple:

Do not prepare only to pass.
Prepare to become better at running Kubernetes safely.

Start small.
Write policies.
Test them locally.
Use the CLI.
Understand reports.
Think like an SRE.
Think like a platform engineer.
Think like someone responsible for safe production systems.

Kyverno is a practical skill, and KCA is a great way to structure your learning journey.

Certification is the milestone.
The real achievement is becoming confident with Kubernetes policy-as-code.