KCA Practice Questions

Twenty-five single-best-answer questions, built the way the real KCA builds them: one stem, four options, exactly one option that answers this stem better than the other three. They are split across all six domains from the KCA blueprint in rough proportion to their weight — eight on Writing Policies alone, since it is nearly a third of the real paper, down to two on Policy Management — so a strong or weak score in one section tells you something real about where your marks would actually land. This page is untimed and open-book on purpose: work through it slowly, read every explanation even for questions you got right, and only once these twenty-five stop surprising you should you move on to the two full, weighted, timed papers — Mock Exam · Set 1 and Mock Exam · Set 2.

How this bank is built

☺ Like you're 10: The biggest pile of questions covers the biggest part of the real test — almost a third of everything is one single domain.

The KCA curriculum weights its six domains 32 / 18 / 18 / 12 / 10 / 10, and this bank mirrors that shape rather than splitting twenty-five questions evenly into small equal piles. Writing Policies gets eight questions on its own — nearly a third of this bank, matching nearly a third of the real exam — because it carries eleven separate named competencies and is, by a wide margin, where the marks are. The two 18% domains, Fundamentals and Installation/Config/Upgrades, split the next largest share; the operational one gets slightly more questions here on purpose, because it is the domain people underestimate for being "boring," and underestimating it on exam day costs real marks.

Writing Policies — 8 questions

☺ Like you're 10: Four kinds of rule — say no, quietly fix it, make a new thing, check the seal on the box — plus the small print around all four that the exam loves to test.

Thirty-two percent of the real exam is this one domain, and it carries eleven named competencies on its own — more than the next two domains combined. See the KCA blueprint for the full reference on validate, mutate, generate and verifyImages; these eight questions probe the edges of each, plus preconditions, background scans, autogen and cleanup policies.

Q1. A validate rule with a correct pattern block shows up as fail for dozens of resources in kubectl get polr -A -o wide, yet nothing is ever actually rejected at admission time. What is missing?

• A. failureAction: Enforce on the rule (or the older policy-level spec.validationFailureAction: enforce) — without it, the rule audits and reports, but never blocks.
• B. background: true on the rule.
• C. The pattern must never use a wildcard like ?* — replace it with an explicit regex to force enforcement.
• D. spec.enforceMode: strict at the ClusterPolicy level.

Q2. A validate rule should only run when request.object.spec.replicas is greater than 1 — a condition on the incoming resource's own field value, not on its kind, namespace, name, or labels. Which construct expresses this?

• A. preconditions — a JMESPath-based conditional block, evaluated before the rule's main action runs, built exactly for value-based conditions that match/exclude cannot express.
• B. match.any[].resources.selector, a label selector.
• C. This cannot be expressed — write two separate policies, one for replicas: 1 and one for anything higher.
• D. spec.rules[].filter: replicas>1.

Q3. A validate rule checks request.userInfo.username to restrict who may create Secrets in a namespace, and the team sets background: true so existing Secrets get audited too. What happens when the background controller scans a Secret that was created last month?

• A. The rule replays the original AdmissionReview exactly, including the original requester's identity, so the check runs identically to admission time.
• B. The check cannot evaluate meaningfully — request.userInfo and other admission-only context are not available outside a live admission request, so a rule depending on who made the request cannot run correctly in the background.
• C. Background scans only ever run once, at policy install time, and never again after that.
• D. The rule is automatically rewritten to check metadata.annotations instead.

Q4. A mutate rule must insert imagePullPolicy: IfNotPresent as an explicit, reviewable RFC 6902 operation rather than a merged object shape:

mutate:
  patchesJson6902: |-
    - op: add
      path: "/spec/containers/0/imagePullPolicy"
      value: IfNotPresent

Which mutate strategy is this, and why is it the right pick given the "explicit sequence of operations" requirement?

• A. patchesJson6902 — RFC 6902 JSON Patch, with explicit op/path/value entries; the named "JSON Patches" competency, and the right tool when the change needs to read as a precise, ordered sequence of operations.
• B. patchStrategicMerge, since it is the only mutate mechanism Kyverno supports.
• C. generate must be used instead, because mutate can only ever change labels and annotations.
• D. spec.rules[].patch: json-merge, Kyverno's own merge dialect.

Q5. A generate rule creates a default NetworkPolicy in every new Namespace. The platform team wants the generated object kept in ongoing sync with its source: if someone hand-edits the generated NetworkPolicy, Kyverno should revert it, and if the source template later changes, existing copies should update too. Which setting delivers this?

• A. synchronize: true on the generate rule — ties the generated resource's state to its source (data or clone) on an ongoing basis, reverting drift and propagating template updates.
• B. background: true on the rule.
• C. Generation only ever supports clone, copying an existing object — inline data is not a real option.
• D. mode: mirror under generate, a field that mirrors manual edits back into the source Namespace.

Q6. A verifyImages rule uses a keyless attestor (Sigstore Fulcio/Rekor via OIDC) and sets mutateDigest: true. A Pod references ghcr.io/acme/api:v2.3. After verification succeeds, what happens to the image reference before it is persisted?

• A. Kyverno rewrites the tag to the resolved content digest (ghcr.io/acme/api@sha256:...), closing the tag-mutation race — which is exactly why verifyImages runs in Kyverno's mutating admission phase, even though its job is verification.
• B. The tag is left untouched; only a PolicyReport entry records the digest.
• C. verifyImages only supports static, pre-shared public keys — keyless Fulcio verification is not supported.
• D. The Pod is deleted and recreated under a new UID once verification completes.

Q7. A rule's match block lists only kind: Pod. The team deploys exclusively via Deployment, never bare Pods — yet violation messages still appear correctly against failed Deployments. What explains this, and how would the team scope it to skip one specific controller kind?

• A. Autogen — Kyverno automatically derives equivalent rules for Pod-controller kinds (Deployment, StatefulSet, DaemonSet, Job, CronJob) from a Pod-matching rule; scope or disable it per policy with the pod-policies.kyverno.io/autogen-controllers annotation.
• B. background: true silently rewrites the match block to include every Pod-controller kind.
• C. Kyverno always evaluates every rule against every possible kind, regardless of what match specifies.
• D. The cluster's admission webhook redirects all Deployment requests through a hidden Pod proxy object.

Q8. A team wants matching resources deleted automatically on a recurring schedule — for example, purging completed Jobs older than 24 hours — without writing a validate, mutate, generate, or verifyImages rule. What is the correct construct, and how does it relate to the four rule types?

• A. A ClusterCleanupPolicy (or namespaced CleanupPolicy) — a separate CRD served by its own cleanup controller, with its own schedule, match and conditions; it is not a fifth rule type nested inside spec.rules[], it is a standalone resource kind.
• B. Add a fifth entry under spec.rules[] called cleanup, alongside validate, mutate, generate, and verifyImages.
• C. Only generate can ever delete resources, via a negative synchronize value.
• D. validate.cel.deleteOnFail: true, inside a CEL-based validate rule.

Fundamentals of Kyverno — 4 questions

☺ Like you're 10: The words everyone assumes they already know — but the exam checks the exact edge, like which kind of "policy" can and can't see a whole Namespace.

Eighteen percent, conceptual and cheap to secure if you read closely: ClusterPolicy versus Policy, how the admission webhook actually intercepts a request, and what a signature or attestation on an OCI image really proves.

Q9. A team wants one rule that blocks any Namespace lacking a cost-center label, cluster-wide. Which policy kind must they use, and why would a namespaced Policy fail here?

• A. ClusterPolicy — the only Kyverno policy kind that can match cluster-scoped resources such as Namespace; a namespaced Policy shares the identical schema but is confined to matching resources inside its own namespace, and a Namespace object is itself cluster-scoped.
• B. Policy, because Policy objects are evaluated before ClusterPolicy objects and take precedence for namespace-scoped concerns.
• C. Either kind works identically — they differ only in name, not capability.
• D. Neither — Namespace governance requires a separate CRD called NamespacePolicy.

Q10. A cluster has exactly one Kyverno policy installed, matching only kind: Pod. What happens to a request to create a ConfigMap?

• A. The request never reaches Kyverno's admission webhook at all — Kyverno dynamically configures its own webhook rules to cover only the kinds referenced by currently installed policies, so unrelated kinds add zero admission latency.
• B. The request is sent to Kyverno, which returns an empty PolicyReport entry for it.
• C. Kyverno's webhook always intercepts every resource kind in the cluster, regardless of what policies are installed, purely for auditing.
• D. The request is queued and only processed once a matching policy is installed, causing the create to hang.

Q11. A submitted ClusterPolicy rule contains only a validate block — no match block at all. What happens when this is applied?

• A. It is rejected as invalid — every rule requires a match block to identify which resources it applies to; validate/mutate/generate/verifyImages describe what to do, match (and optionally exclude) describes to what.
• B. It applies to every resource kind in the cluster by default, since no match block means "match everything."
• C. It is silently ignored forever, with no error, log line, or report.
• D. Kyverno automatically infers the match block from the structure of the validate pattern.

Q12. What does a valid attestation checked by verifyImages actually prove, as distinct from a bare signature?

• A. A signature proves who signed the image; an attestation is a signed statement of a fact about the image — for example, that it passed a specific SBOM scan, or was built by a specific CI pipeline — and a rule can require either, or both.
• B. That the image's OCI manifest media type is exactly application/vnd.oci.image.manifest.v1+json.
• C. A signature and an attestation are the same thing under a different name.
• D. That the image is stored specifically in Docker Hub — other OCI registries are unsupported.

Installation, Configuration & Upgrades — 5 questions

☺ Like you're 10: The unglamorous domain — Helm values, which of four little robots does what, and reading the instructions before you upgrade anything.

Also 18%, but operational rather than conceptual: Helm as the named install method, the four deployments Kyverno typically runs as, RBAC for what the background controller is allowed to touch, the CRDs that back all of this, and upgrade discipline.

Q13. A cluster shows intermittent admission latency spikes during deploys, but background policy scans and PolicyReport generation are unaffected. Which Kyverno deployment should be scaled first, and why?

• A. The admission controller — of Kyverno's typical four deployments (admission, background, reports, cleanup), only the admission controller sits directly in the live request path as a synchronous webhook; the other three operate asynchronously.
• B. The background controller — it re-evaluates every admission request in real time before allowing it through.
• C. All four deployments must always be scaled together in lockstep, or the installation becomes invalid.
• D. The reports controller, because PolicyReport generation is synchronous and blocks every admission request until the report is written.

Q14. What is the officially documented method for installing and configuring Kyverno, and what does that imply about looking up "Controller Configuration with Flags" for a specific version?

• A. Helm — chart values (and therefore available controller flags) can move between chart versions, so the authoritative source for a given install is helm show values kyverno/kyverno against the chart version actually being deployed, not an old blog post or command history.
• B. kubectl apply -f against a single static install.yaml, with flags hardcoded and unchangeable after install.
• C. Kustomize is the only supported installation method; Helm charts are deprecated.
• D. kyverno init, a bootstrap subcommand of the standalone CLI that installs the controllers directly.

Q15. A generate rule creates a NetworkPolicy in every new Namespace via the background controller, but nothing is ever created, and the policy's own status shows no error. What is the most likely root cause to check first?

• A. The background controller's ServiceAccount lacks RBAC permission to create NetworkPolicy objects — generate and mutate-existing rules act through the background controller, which needs its own grant for whatever kind it creates or modifies.
• B. The rule's preconditions are almost certainly malformed.
• C. generate rules never require any RBAC beyond what the admission controller already has, by design.
• D. Kubernetes silently caps generate rules at ten created resources per hour, cluster-wide.

Q16. Which of the following is a genuine, distinct Kyverno CRD a platform engineer should expect to see in kubectl api-resources after a Helm install?

• A. PolicyException (polex) — a real, separate CRD used to declaratively carve one named workload out of one policy's enforcement, reviewable through Git and code review rather than editing the policy itself.
• B. PolicyOverride — a CRD that globally disables one named policy for every namespace at once.
• C. Kyverno has exactly one CRD, ClusterPolicy; everything else — reports, exceptions, cleanup — is stored as ConfigMaps.
• D. KyvernoConfig — a required CRD that must be created manually before any ClusterPolicy will be accepted.

Q17. A team is two minor versions behind and wants to helm upgrade straight to the latest release in one step. What does the "Upgrading Kyverno" competency most directly warn them to check first?

• A. CRD handling on upgrade has varied across chart versions, and skipping minor versions risks missing an intermediate migration step — read the release notes for the specific target version, generally avoid skipping minor versions, and use helm search repo kyverno/kyverno --versions to see what's actually available rather than guessing.
• B. Nothing — Helm upgrades are always fully backward- and forward-compatible across any version gap, by the nature of Helm itself.
• C. Only the reports controller needs to be upgraded; the other three deployments are version-independent.
• D. Downgrade to v1.0 first, then upgrade forward one version at a time — Kyverno requires a full version reset before any multi-version jump.

Kyverno CLI — 3 questions

☺ Like you're 10: Three little helper commands you can run on your own laptop, no cluster required, before anything you write ever touches a real one.

Twelve percent, and the best value on the paper — the curriculum names exactly three subcommands (apply, test, jp) plus installing the CLI itself. An afternoon of hands-on practice locks this domain in.

Q18. A platform engineer wants to know exactly what a new ClusterPolicy would do to a directory of manifests, offline, before merging anything:

kyverno apply ./policies/ --resource ./manifests/ --policy-report

What does this specific command do, and how does it differ from adding --cluster?

• A. It evaluates the policies against local manifest files entirely offline and renders the result as a PolicyReport-shaped summary; --cluster is a separate flag that instead dry-runs the same policies against a live cluster's actual resources.
• B. It applies every discovered policy directly to the live current kubectl context.
• C. This is impossible without a live cluster — Kyverno policies can only be evaluated by the in-cluster admission webhook.
• D. It is equivalent to kyverno test, since both commands evaluate manifests against policies.

Q19. A repository keeps a kyverno-test.yaml beside each policy directory, several levels deep, each asserting expected pass/fail results per rule. What does kyverno test ., run from the repo root, actually do?

• A. It recursively discovers every kyverno-test.yaml under the working directory and runs each as a declarative unit test, comparing the policy's actual per-rule result against the declared expected result — the same discipline as a unit test suite, wired into CI to catch a regression before it reaches a cluster.
• B. It applies every discovered policy directly to the live current kubectl context.
• C. kyverno-test.yaml files must be named exactly that and placed only in the repository root — subdirectories are never scanned.
• D. It automatically generates a kyverno-test.yaml file for any policy that doesn't already have one.

Q20. A rule author is about to paste a JMESPath-style expression into a preconditions block and wants to confirm it returns what they expect first. Which subcommand is built exactly for this?

• A. kyverno jp — for example kyverno jp query -i pod.yaml 'spec.containers[*].image' evaluates the expression against a real manifest before it's live inside a rule, and kyverno jp function lists Kyverno's own custom functions beyond the standard JMESPath spec.
• B. kyverno test, which will flag any malformed expression syntax as part of its normal output.
• C. Expression syntax can only be validated by submitting the full policy to a live cluster and reading the resulting webhook error.
• D. kyverno lint, a subcommand that statically type-checks expressions against the Kubernetes OpenAPI schema.

Applying Policies — 3 questions

☺ Like you're 10: Not writing the rule — pointing it at the right things, in the right way, once it's already written.

Ten percent: how match/exclude actually select resources, and the common settings — like background and the two forms of enforcement — that apply once a rule is already live in a cluster.

Q21. A policy must apply to Pods in any of three specific namespaces, and separately, only when the requesting user is not in the platform-admins group. Which statement correctly describes how to combine these two conditions?

• A. A match.any[] list of namespace filters expresses "any of these three namespaces"; genuinely combining that with an unrelated condition on the requester's group needs preconditions, since match/exclude are structured around resource identity — kind, namespace, name, labels, subjects, operations — not arbitrary boolean logic over unrelated conditions.
• B. Use only exclude.all[] with the three namespaces listed — exclude never supports any as a keyword.
• C. match can only ever contain a single namespace per policy; three namespaces always requires three separate ClusterPolicy objects.
• D. Namespace filtering requires a separate NamespaceSelector CRD applied before the ClusterPolicy.

Q22. One rule in a policy file uses the newer, per-rule validate.failureAction: Enforce; another rule in the same file uses the older, policy-level spec.validationFailureAction: enforce. What should a platform engineer preparing for KCA understand about these two forms?

• A. Both are real, and the exam expects you to recognize both — the rule-level failureAction is the current, more granular form, while the policy-level validationFailureAction is the older, policy-wide form; a mixed-vintage policy repo needs both read correctly.
• B. The rule-level form is deprecated in favor of the policy-level form.
• C. Only one of the two forms can ever appear anywhere in a cluster; mixing them across different policies breaks Kyverno entirely.
• D. Enforce and enforce — capitalized versus lowercase — are functionally different settings with opposite behavior.

Q23. A require-team-label ClusterPolicy with background: true is installed into a cluster that already has 400 running Deployments, most missing the team label. What happens to those 400 versus a new Deployment created the next day?

• A. The 400 pre-existing Deployments are picked up by the background controller's periodic scan and show up as fail results in PolicyReports, even though they were never touched by admission; the new Deployment is evaluated live, at admission time, by the same rule — background: true extends coverage backward, it doesn't change how new resources are handled.
• B. Only the new Deployment is ever evaluated; background: true has no effect on resources created before the policy existed.
• C. All 400 pre-existing Deployments are immediately deleted, since they fail the policy.
• D. The 400 Deployments are automatically mutated in place to add a placeholder team label.

Policy Management — 2 questions

☺ Like you're 10: The report card after the rules run — and the paperwork-approved way to make one exception without weakening the rule for everybody.

The smallest domain, at 10%, but it's how a fleet is actually governed day to day: PolicyReports for measurement, PolicyExceptions for reviewable carve-outs, and Kyverno's own Prometheus metrics for dashboards. See the blueprint for the full three-line CLI summary of this domain.

Q24. A platform engineer runs kubectl get polr -A -o wide and sees a mix of pass, fail, warn, skip, and error results. What does a skip result specifically indicate, as distinct from pass?

• A. skip means the rule did not evaluate against that resource at all — typically because a match/exclude condition or a preconditions check excluded it — whereas pass means the rule did evaluate and the resource satisfied it. Conflating the two hides real coverage gaps.
• B. skip means the resource passed, but only because failureAction was set to Audit rather than Enforce.
• C. skip and pass are simply two different labels for the identical outcome, kept for historical reasons.
• D. skip only appears for verifyImages rules, never for validate or mutate rules.

Q25. A single payment-processing workload legitimately needs to run as root, but the disallow-privileged policy should stay strict for every other workload in the cluster. What is the reviewable, KCA-tested way to grant this one workload a carve-out?

• A. A PolicyException scoped to that specific workload and that specific policy/rule — a separate resource that lives in Git like anything else, so the exception is visible, auditable, and can later be time-bound or revoked, while the underlying policy stays strict for everyone else.
• B. Edit the disallow-privileged ClusterPolicy directly and add an exclude block for that one workload's name.
• C. There is no supported way to grant a single-workload exception in Kyverno; the policy must be disabled cluster-wide.
• D. Add spec.rules[].bypass: [payment-svc] directly inside the rule.

Scoring yourself, and what to do with a miss

☺ Like you're 10: Getting it wrong isn't the problem — not knowing why you got it wrong is. Every miss fits one of four boxes, and each box has its own fix.

Count your correct answers and divide by 25 for a rough percentage — this bank is too small to be a statistically precise rehearsal of the real paper, but it's plenty large enough to tell you whether a domain needs more reading before you attempt Mock Exam · Set 1.

When you miss one, resist the urge to just note the correct letter and move on — that teaches you almost nothing. File it instead:

Whichever domain produced the most misses, weigh that against its blueprint weight before deciding where to spend the next study session — a rough score in the 32%-weighted Writing Policies domain costs far more than the same rough score in the 10%-weighted Policy Management domain. The KCA study plan lays out exactly how to sequence reading, this bank, and the two mock exams across the days you have. If Kubernetes fundamentals themselves — CRDs, webhooks, RBAC — feel shaky underneath any of this, that's this course's own scope stopping short on purpose: see CKA in the sibling Kubernetes course first.