Skip to main content
So far, our journey with Kubernetes has focused on what happens inside a running cluster. We’ve applied admission policies, managed resources in the background, and generated compliance reports. But what if we could catch configuration errors earlier—before resources ever reach the cluster API server? Moving testing and validation earlier in the development lifecycle is commonly called “shifting left,” and it’s exactly what the Kyverno CLI enables. In this lesson you will learn how the Kyverno CLI helps developers validate resources locally and get faster feedback, reducing friction between platform teams and application developers. Let’s put ourselves in Alex’s shoes again, but
The image features an illustration with a person holding a wrench in front of a large monitor displaying coding elements, accompanied by gears. On the right, there is a ring with the text "Kyverno CLI," set against a white background with the heading "Shifting Lift."
this time he is a developer. The platform team has done a great job deploying Kyverno policies to the cluster. But Alex’s new deployment keeps getting blocked by those policies. Alex writes a manifest for his application and, confident it’s correct, runs:
A short time later the API server returns an error: Kyverno’s admission controller has denied the request.
The image illustrates a workflow problem faced by "Alex" while writing a 'deployment.yaml' file and running 'kubectl apply', resulting in an error due to a webhook denial.
Now Alex must read the error, switch back to his editor, attempt a fix, and push the change again. This reactive cycle creates a slow feedback loop because validation happens too late in his workflow. There has to be a better way: how can Alex test this deployment locally before it ever touches the cluster? The Kyverno CLI was built to solve this exact problem by allowing validation, mutation, and testing of resources outside the cluster. To solve Alex’s slow feedback loop and empower developers, this lesson will teach you how to use the Kyverno CLI effectively.
Shifting validation left lets developers catch policy violations locally, shorten development cycles, and reduce failed deployments. The Kyverno CLI provides local validate, apply (for mutation + validation), and test commands to run policy checks before kubectl ever talks to the API server.
First, we’ll cover the basics: what the CLI is for and how to install it. Next, we’ll focus on the most common developer use case: kyverno apply, which lets you validate and mutate manifests locally—directly addressing Alex’s problem. Finally, for policy authors and maintainers, we’ll explore kyverno test, which enables formal test cases and unit-testing practices for your policy-as-code repository. Below is a quick learning agenda of the lesson:
If you rely only on cluster admission for validation, developers will encounter errors late in the cycle. Use kyverno apply and kyverno test locally and in CI to prevent repeated failed deployments.
The image outlines a learning agenda with three key topics: understanding the CLI and installation, validating resources with "kyverno apply," and creating test cases with "kyverno test."

Watch Video