YAML Manifests: KCA practice questions

Kyverno policies are ordinary Kubernetes manifests, so most mistakes are YAML mistakes. A legacy policy has apiVersion kyverno.io/v1, kind ClusterPolicy or Policy, metadata with a name, and a spec whose rules list holds the logic; the CEL-based types use apiVersion policies.kyverno.io/v1.

In a validate pattern, structure is meaning. The pattern mirrors the resource, so a required label belongs at metadata.labels.<key> inside the pattern, not at the top level. Fields that the pattern does not mention are not checked, and child values are only checked when their parent matched, so a misplaced key quietly turns a strict check into one that always passes. Anchors are written into the key itself, as in (name) or X(hostPath), and the value side carries wildcards and operators. Kinds in a match block can be written as Kind, Version/Kind or Group/Version/Kind, and kinds is the one mandatory field of a resources filter.

Messages and values can include variables in double braces, which Kyverno resolves with JMESPath before the rule runs, for example {{request.object.metadata.name}}. Plain JMESPath fields, such as a foreach list, do not need braces. Quoting matters: a context name or data key containing dashes or slashes must be quoted inside the expression, as in {{ "roles-dictionary".data."allowed-roles" }}.

Reference data does not have to be hard-coded. A context entry of type configMap loads a ConfigMap by name and namespace at evaluation time, so editing it changes later decisions without touching the policy. The documented example stores an allowed list as a JSON string in a ConfigMap, converts it with parse_json, and uses a deny condition with the AnyNotIn operator to reject other values; parse_yaml handles a YAML block instead. Labelling the ConfigMap with cache.kyverno.io/enabled: "true" lets Kyverno cache it. An apiCall entry reads from the Kubernetes API by urlPath, optionally reshaped with a jmesPath expression, and can fall back to a default value if the call fails.

Manifests can be checked before they reach a cluster with the Kyverno CLI, installable with Homebrew, as a kubectl plugin through Krew, or as a binary. kyverno apply runs one or more policies against resource files given with --resource, which also accepts stdin, and prints mutated output for mutate rules; --policy-report produces a report for validate rules. kyverno test looks for a kyverno-test.yaml file that declares the expected results, pass, fail, skip or warn, and reports a failure whenever the actual result differs, even if the actual result was a skip. The testing guide shows both commands in a pull request pipeline, where a failing step stops the run. Flags such as --audit-warn and --warn-exit-code control how warnings affect the exit code.