Skip to content

Applying Policy in Cluster: KCA practice questions

Applying a policy in a cluster starts with knowing its scope and what a violation will do. A ClusterPolicy applies across all namespaces, while a Policy is namespaced and only affects resources in the namespace where it is created; apart from that the two behave the same.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Applying Policy in Cluster covers in KCA

Applying a policy in a cluster starts with knowing its scope and what a violation will do. A ClusterPolicy applies across all namespaces, while a Policy is namespaced and only affects resources in the namespace where it is created; apart from that the two behave the same. Both belong to the kyverno.io API, which Kyverno 1.19 deprecates in favor of the CEL-based policy types under policies.kyverno.io, with removal planned for 1.20, so creating or updating one returns an admission warning.

For validate rules, the failureAction field decides the outcome. Enforce blocks a non-compliant request; Audit lets it through and records the violation in a policy report. The field now sits on each validate rule; the older spec.validationFailureAction, whose default was Audit, has been deprecated since 1.13. failureActionOverrides set a different action for particular namespaces and are only available in ClusterPolicies. When an Enforce rule is added to a cluster that already has violating resources, updates to those resources are still allowed by default, and validate.allowExistingViolations turns that leniency off.

The documented reporting matrix shows how background scanning and the action interact. With background true and Enforce, new resources only ever appear as passes because violations are blocked, while existing resources are still reported by the scan; with Audit, both new and existing resources are reported. With background false, existing resources are not reported at all. Background scans never block anything, even in Enforce mode. This is why a typical rollout runs a rule in Audit first, reads the reports, fixes violations and only then switches to Enforce.

Rules written for Pods are extended automatically. Kyverno's auto-generation adds equivalent rules for the controllers that create Pods: rules prefixed autogen- cover Deployments, DaemonSets, StatefulSets, Jobs, ReplicaSets and ReplicationControllers, and rules prefixed autogen-cronjob- cover CronJobs. They are listed under status.autogen.rules. The pod-policies.kyverno.io/autogen-controllers annotation narrows the list, for example to Deployment,Job, and the value none disables it. Auto-generation is skipped when the match or exclude block uses names, selector or annotations, when the rule matches kinds other than Pod, and for mutate rules using a JSON patch. When auto-generation is disabled or does not apply, Pods created by controllers are still checked by the Pod rule, and a precondition on the Pod's ownerReferences can exempt them.

After a policy is created, the webhook controller updates Kyverno's webhook configurations so that the API server only sends requests for the resources that installed policies match. Within a policy, rules run in the order they are written, and during admission all mutation happens before validation.

To preview a policy before it is enforced, the Kyverno CLI can evaluate it against live objects with kyverno apply and the --cluster flag, using the current kubectl context, or against local manifests with --resource. In a pipeline the same CLI can block a pull request before anything reaches the cluster.

Key points

  • Enforce blocks violating requests; Audit admits them and records the result in a policy report.
  • failureActionOverrides for specific namespaces exist only on ClusterPolicies.
  • Auto-generated rules for Pod controllers use the autogen- and autogen-cronjob- prefixes.
  • Background scans report on existing resources but never block them.

Three sample questions

8 KCA questions on Applying Policy in Cluster, 8 with explanations. How practice works

Question 1

You edit a ClusterPolicy YAML file on disk to fix a bug in its match block, but forget to run kubectl apply -f afterward. What does the cluster actually enforce?
  1. A.Both versions simultaneously, merged field by field.
  2. B.The fixed version, because Kyverno watches the filesystem for changes.
  3. C.Nothing — Kyverno automatically disables a policy the moment its source file changes.
  4. D.Whatever was last successfully applied to the cluster — your local file edit has no effect until you re-apply it.

Correct answer: D

A ClusterPolicy is a Kubernetes resource stored in etcd, not a live pointer to a file. The cluster only ever reflects what was last successfully kubectl apply'd (or create'd/edit'd) — a local file edit is inert until you re-run kubectl apply -f.

Question 2

You kubectl apply -f a ClusterPolicy file that has both a validate block and a mutate block under the same rule name — a shape Kyverno's schema does not allow. What happens?
  1. A.The policy is accepted but immediately shows as NotReady while running normally in Audit mode.
  2. B.The policy is accepted and applies both actions in the order they're written.
  3. C.The policy is accepted, but only the validate block is ever evaluated.
  4. D.The kubectl apply command itself fails — Kyverno's own admission webhook for policy objects rejects the malformed policy before it ever becomes live.

Correct answer: D

Kyverno validates policy objects against its own schema at apply time via its admission webhook for policy CRDs. A rule combining two action types in one entry is invalid, so the kubectl apply call fails immediately with an admission error — the policy never becomes live at all.

Question 3

A newly-applied ClusterPolicy has validationFailureAction: Audit. A Pod is created that violates its rule. What is true immediately after?
  1. A.The Pod is created normally, and the violation is recorded in a PolicyReport/ClusterPolicyReport — nothing is blocked.
  2. B.The Pod is created, and Kyverno automatically mutates it to become compliant.
  3. C.The Pod is rejected and never created.
  4. D.The Pod is created, then deleted a few seconds later by Kyverno's background controller.

Correct answer: A

Audit admits the resource and records the violation as a finding — that's the entire mechanism. No blocking, deleting, or auto-fixing happens.

Practice this topic

Focus mode keeps every question on Applying Policy in Cluster until you leave it. 10 free guest answers, then a free account; no credit card.

Or open KCA practice across all topics.

Sources

The explanation above was checked against these official documents.

Frequently asked questions

Why does a policy that matches Pods also produce results for Deployments?

Rule auto-generation adds matching rules for Pod controllers such as Deployments and CronJobs. The pod-policies.kyverno.io/autogen-controllers annotation limits which controllers get them, and the value none turns the feature off.