Policy tests and exceptions

A test needs an expectation

A fixture is a small input prepared for a test. A policy test pairs that input with the result you expect. Merely loading valid YAML proves syntax, not that the rule detects the intended mistake. A negative fixture that is expected to fail the policy can make the overall test suite pass.

Test the failure you intend

An owner policy needs more than a single valid manifest. Test the expected label, a missing label, an incorrect owner, a label only on Deployment metadata, and a resource outside the rule's scope. Make the expected result explicit before running the engine.

Kyverno CLI can evaluate policy fixtures without a cluster. Its test file lists expected results. For a CEL ValidatingPolicy, use the test schema documented for the selected CLI, including isValidatingPolicy: true. Record the CLI version alongside results; a parser-only YAML check cannot evaluate CEL behavior.

Exceptions are changes to the contract

Prefer fixing a missing label over adding an exception. A legitimate exception needs a specific resource and policy, an owner, reason, compensating measure, and review/removal date. Do not assume adding an expiry field to an arbitrary YAML record makes the controller expire it. Automatic expiry requires a mechanism that you implement and test.

Restrict who may create exceptions. A developer who can exempt every workload can bypass the policy. Kyverno's exception APIs and enabling settings depend on the policy type and installed release; verify those before implementing one.

Build a useful test matrix

Use the five questions below to review the lab's fixtures. This is a test-design exercise before running the CLI.

Now reverse the expected result for the valid fixture in a disposable copy. A meaningful test runner should fail the test. Restore it afterward. This deliberate test failure checks your expectations are actually being compared, not ignored.

For an exception exercise, write a proposed record: affected resource, exact rule, reason, owner, review date and removal action. For the MicroBank owner-label rule, correcting a label is normally simpler than granting an exception. If you cannot explain why the fix is unsuitable, do the fix.

An exception record in a Markdown file is a review artifact. It has no enforcement or automatic expiry until a supported mechanism is configured to use it. Keep that difference explicit in your lab notes.

Try it

Use the policy lab's positive and negative fixtures. Deliberately reverse one expected result and confirm the test suite fails, then restore it. This proves the test runner is checking expectations rather than merely loading files.

Write a proposed exception as a review note, not an active exemption, for a hypothetical legacy workload. State why it is unnecessary for MicroBank's simple owner-label rule. Make the exception process available for justified cases while keeping routine fixes straightforward.

Checkpoint and revision

Explain what offline tests prove and what still needs live admission verification. Include scope, evaluation, and report behavior in the answer; passing one fixture does not establish all three.

Compare your reasoning

“Four tests passed” can include three expected validation failures. Explain the input and expected result, not just the green test count. Offline tests exercise policy logic; live admission additionally depends on installed APIs, webhook wiring, matching and authorization.

Sources

Kyverno CLI testing↗, Kyverno exceptions↗.