Certifications · KCA · Mock Exam · Set 1

KCA Mock Exam · Set 1

Forty-five multiple-choice questions, sat in one 90-minute closed-book block, weighted to the six official KCA domains in the same proportion the CNCF weights them — 14 questions on Writing Policies (32%), 8 each on Fundamentals of Kyverno (18%) and Installation, Configuration & Upgrades (18%), and 5 each on Kyverno CLI (12%), Applying Policies (10%), and Policy Management (10%) — the exact split from the KCA blueprint page. Every question below has a full explanation folded underneath it, so you can grade honestly instead of guessing whether your reasoning was right for the right reason. This is Set 1 of two; Set 2 is a separate, unseen paper, held back on purpose so you have fresh material once this one stops surprising you. If you haven't worked through the blueprint, the study plan, and the untimed practice bank yet, start there — this paper measures whether that prep survives a clock, not whether you've read about the four rule types.

☺ Explain it like I'm 10

You've studied the door-robot's rulebook one chapter at a time — the check-and-reject chapter, the quietly-fix-it chapter, the hand-out-something-new chapter, the check-the-seal chapter, and the boring-but-important chapters about installing and updating the robot itself. This is the pop quiz that asks about every chapter, mixed together, in the order a real quiz would ask them, with a clock running and no going back to reread mid-question. Some questions are about the biggest chapter, because it's worth the most marks; some are about the smallest, because it still counts. Underneath every question is the full explanation — not just which answer was right, but why the other three doors were built to look almost right.

🐢🐰Your hosts for this topic: Timmy the Turtle & Remy the Rabbit — Timmy holds the stopwatch for the full 90 minutes and won't stop it for anything, because he owns every domain this paper draws from, and Remy is this course's quick-recall specialist, which makes him the right co-host for a paper built to reward fast, correct recall of field names over slow deliberation.

Where Set 1 sits in your KCA prep

☺ Like you're 10: First you learn the whole rulebook, then you drill loose questions about it, and only then do you sit the whole timed quiz — in that order, not skipped ahead.

The natural sequence on this course is: read the KCA blueprint for the six domains and their real weights, follow the study plan's week-by-week build, work the untimed practice bank until nothing there surprises you, and only then sit this paper as your first honest measurement of all six domains at once, under a clock. This paper assigns questions to each domain in the same proportion the CNCF assigns them — 32% Writing Policies, 18% Fundamentals, 18% Installation, 12% CLI, 10% Applying Policies, 10% Policy Management — so a weak score in one domain here is unusually actionable: it tells you precisely which section of the blueprint to reread, not just that you "did badly" in some vague sense.

Stage	What you do	What it tells you
1 · Build the vocabulary	Read the blueprint and follow the study plan's write-the-policy-from-memory drills.	Whether you know the material at all — untimed, open-book.
2 · Drill loose questions	The practice bank, untimed, reading every explanation even for questions you got right.	Whether you can recognize the right answer among convincing distractors.
3 · Sit Set 1	This page. One 90-minute block, no pausing, all 45 questions.	Your pacing under a clock — can you bank a passing score, not just eventually get there.
4 · Fix gaps, then sit Set 2	Re-drill only the domains you missed, then sit Set 2 — a fresh, unseen paper — a day or two later.	Whether the gap is actually closed, on material you haven't already seen the answer to.

◆ Why 45 questions in 3 blocks

Neither official KCA page publishes the exam's real question count — the blueprint's logistics table already says so plainly, and this paper takes that seriously rather than inventing a precision the CNCF itself doesn't claim. 45 was chosen because it splits cleanly into three 15-question, 30-minute blocks across a realistic 90-minute sitting, and because 45 divides by the real domain weights into whole numbers of questions — 14 / 8 / 8 / 5 / 5 / 5 — without much rounding. Treat that shape as this course's own study scaffolding, not a leaked format.

Sit it like the real thing

☺ Like you're 10: No notes, no open tabs, one sitting, go — and if you're not sure, answer anyway, because a blank answer earns the same zero as a wrong one.

KCA is online, remote-proctored, and closed-book — no notes, no browser tab, no this course, no colleague, no AI assistant, once the clock starts. Sit this practice paper under the same restriction. Close every other tab, and treat the 45 questions below exactly as you would a locked-down sitting: read the stem once, commit to an answer, and only then open the explanation underneath it — peeking first turns a diagnostic into a comprehension exercise and tells you nothing about whether you'd have gotten there cold.

Linux Foundation multiple-choice exams don't publish a separate penalty for a wrong guess beyond simply not earning the point, so the correct strategy is unambiguous: never leave a question blank. Eliminate what you can, then commit to your best remaining option. Three questions below are marked (Select TWO), matching the real exam's multiple-response format — full credit requires both correct letters.

⚠ Format specifics can change — verify before you book

The 90-minute duration and the 75% pass mark reflect the Linux Foundation's own KCA page and its general Multiple Choice Exam FAQ at the time of writing, per the blueprint's logistics table — but the exact question count is not published for KCA at all, and this paper's 45-question, 3-block shape is this course's own construction, not a leaked format. This is an independent, unofficial study resource, not affiliated with the CNCF or the Linux Foundation. Confirm current duration, pricing, and pass mark on the official Linux Foundation KCA page before you register.

Your 90-minute budget

☺ Like you're 10: Forty-five questions, ninety minutes — three even blocks of thirty minutes each, so you can check your pace roughly every half hour.

Forty-five questions in 90 minutes averages exactly two minutes each, and the paper is split into three 15-question, 30-minute blocks so you have a clean checkpoint to compare against, rather than discovering with ten minutes left that you're only on question 20. Every block mixes all six domains, the same way a real exam does — you won't see all fourteen Writing Policies questions bunched together at the start.

If a question runs past about two minutes without you being confident, eliminate what you can, commit to your best remaining guess, and move on — there's no folded worked solution to peek at mid-paper the way a hands-on lab bank might tempt you with, since each explanation sits directly underneath its own question.

The paper — 45 questions in exam order

☺ Like you're 10: Forty-five questions, three blocks of fifteen, every chapter mixed into every block — read the stem, pick one answer (or two, when it says so), then check yourself before moving on.

Read each stem once, pick your answer, and only then open the explanation underneath it. Each question is tagged with its domain in parentheses so you can total your score by domain afterward — on the real exam you won't get that label, so once you've sat this paper, consider a second pass with the tags covered to see how many you can still place on content alone. Three questions below are marked (Select TWO), matching the real exam's multiple-response format — full credit requires both correct letters.

Block 1 — Q1–15 (minutes 0–30)

Q1 (🐢 Writing Policies). Every rule's match and exclude fields accept lists of resource filters. Which two combinators do those lists use to say "match if any of these filter sets matches" versus "match only if every one of these filter sets matches"?

A. allOf and anyOf
B. any and all
C. oneOf and noneOf
D. include and exclude

Check the answer

B. any matches if at least one listed filter set matches; all matches only if every listed filter set matches. A is Kubernetes node-affinity terminology, not Kyverno's match/exclude combinators.

Q2 (🦉 Fundamentals of Kyverno). Which field is mandatory on every rule inside a policy's spec.rules[], regardless of whether the rule uses validate, mutate, generate, or verifyImages?

A. background
B. match
C. preconditions
D. a context entry

Check the answer

B. Every rule needs a match block to find resources to act on; background, preconditions, and context are all optional refinements on top of it.

Q3 (🐢 Writing Policies). A rule's preconditions block evaluates to false for a given request. What happens?

A. The rule denies the request with the validate message anyway
B. The rule is skipped entirely for that request, as if it had never matched
C. The mutate, generate, or verifyImages logic still runs; only failureAction is ignored
D. Kyverno throws an admission error and blocks the entire policy

Check the answer

B. preconditions is a cheap gate — when it evaluates false, the whole rule is skipped for that request, none of its validate/mutate/generate/verifyImages logic runs.

Q4 (🦫 Installation, Configuration & Upgrades). Which Helm value scales the one Kyverno controller that sits directly in the live admission request path, and should be the first thing you scale for high availability?

A. backgroundController.replicas
B. reportsController.replicas
C. admissionController.replicas
D. cleanupController.replicas

Check the answer

C. The admission controller is the only one actually in the request path — every create and update waits on it — so it's the priority scale target for HA.

Q5 (🐿️ Kyverno CLI). Which kyverno CLI subcommand evaluates a set of policies against a set of local manifest files, with no cluster required, so you can rehearse a policy change before ever applying it?

A. kyverno test
B. kyverno apply
C. kyverno jp
D. kubectl apply --dry-run

Check the answer

B. kyverno apply ./policies/ --resource ./manifests/ runs entirely locally against files on disk. test runs declarative test files rather than raw manifests, and jp debugs an expression, not a full policy.

Q6 (🦉 Fundamentals of Kyverno). Kyverno registers itself with the Kubernetes API server as which kind of admission webhook(s)?

A. Only a validating webhook
B. Only a mutating webhook
C. Both a validating and a mutating webhook
D. Neither — it only reads via a controller informer, out of band

Check the answer

C. Kyverno registers as both, which is exactly why it can reject a request (validating) and rewrite one (mutating) — including the verifyImages rule type, which runs in the mutating phase.

Q7 (🐢 Writing Policies). A mutate rule needs to add a single new field to a container spec using an RFC 6902 patch. Which field carries that patch?

A. patchStrategicMerge
B. patchesJson6902
C. generate.data
D. verifyImages.attestors

Check the answer

B. patchesJson6902 carries an RFC 6902 JSON patch — a list of op/path/value operations. patchStrategicMerge is the other mutate option, a strategic merge patch instead.

Q8 (🤖 Applying Policies). A validate rule's match block correctly targets Pod, and failureAction: Enforce is already set, yet the policy never fires for pods created by a Deployment. What's the single most likely explanation?

A. Autogen for the pod-controller kinds has been disabled, so the generated Deployment-level rule never ran
B. preconditions are unsupported on validate rules
C. ClusterPolicy objects cannot match Pod resources at all
D. The rule needs a generate block instead of validate

Check the answer

A. A rule matching Pod is autogenerated into equivalent rules for Deployment, StatefulSet, DaemonSet, Job, and CronJob by default — unless the pod-policies.kyverno.io/autogen-controllers annotation has switched that off.

Q9 (🦫 Installation, Configuration & Upgrades). Which Kyverno controller must hold RBAC permissions for whatever object type a generate rule creates, since it's the controller that actually performs generation and mutate-existing work?

A. The admission controller
B. The reports controller
C. The background controller
D. The cleanup controller

Check the answer

C. The background controller drives background scans, generate, and mutate-existing work, so it's the one that needs RBAC for whatever it creates or modifies. A generate rule that silently does nothing is very often a missing permission here, not a broken rule.

Q10 (🐢 Writing Policies, Select TWO). A generate rule needs the resource it creates to keep tracking changes made later to its source object, rather than copy it once at creation time and never again. Which TWO fields, together, achieve that?

A. clone
B. data
C. synchronize: true
D. patchesJson6902
E. mutateDigest

Check the answer

A and C. clone points the generate rule at a source object to copy instead of an inline data block, and synchronize: true keeps the generated copy in step whenever the source changes later. patchesJson6902 and mutateDigest belong to mutate and verifyImages respectively.

Q11 (🦉 Fundamentals of Kyverno). A team writes a Kyverno policy that looks structurally like the Kubernetes resources it's policing, with no separate policy language to learn. Which contrast does this draw against a tool like OPA/Gatekeeper?

A. Kyverno has no real contrast here — it also requires learning a separate language
B. Kyverno policies are themselves native-shaped Kubernetes YAML resources, while Gatekeeper constraints are commonly authored in a separate policy language (Rego)
C. Gatekeeper is YAML-native and Kyverno requires a separate language
D. Neither tool is expressed in YAML at all

Check the answer

B. This is Kyverno's headline pitch: you don't learn a new DSL, you write YAML that looks like the YAML it's policing. That's a real, testable contrast against Rego-based engines.

Q12 (🐿️ Kyverno CLI). Which kyverno CLI subcommand runs declarative test files, automatically discovered as kyverno-test.yaml, that assert an expected pass/fail/skip result for each rule against given resources?

A. kyverno apply
B. kyverno test
C. kyverno jp
D. kyverno version

Check the answer

B. kyverno test ./policies/ discovers kyverno-test.yaml files recursively and asserts each rule's declared expected result — the unit-testing half of the CLI domain, distinct from apply's "what would this do" dry run.

Q13 (🐢 Writing Policies). Which expression language can be used as an alternative to a pattern-matching validate rule, and is the same language the Kubernetes API server itself uses natively for ValidatingAdmissionPolicy?

A. JMESPath
B. Rego
C. Common Expression Language (CEL)
D. Starlark

Check the answer

C. CEL is the named competency under Writing Policies, and the exam likes this fact specifically because it's the same language backing native ValidatingAdmissionPolicy — not a Kyverno-only invention.

Q14 (🦫 Installation, Configuration & Upgrades). A team is planning a Kyverno upgrade two minor versions ahead of their current install. What does the Upgrading Kyverno competency expect you to know about this?

A. CRD handling has varied between chart versions, so you should read the release notes for the target version and avoid skipping minor versions rather than jumping straight there
B. Minor version upgrades never touch CRDs, so any jump is always safe
C. Upgrades must always go through a full uninstall and reinstall
D. Kyverno's CRDs are versionless and never change

Check the answer

A. CRD handling has genuinely varied between Kyverno chart versions, so the safe pattern is reading the release notes for your target version rather than assuming any jump — especially a multi-minor-version jump — behaves the same as the last one.

Q15 (🐘 Policy Management). Which resource holds Kyverno's policy results specifically for cluster-scoped resources like Namespace, as opposed to the namespaced PolicyReport?

A. ClusterPolicyReport (cpolr)
B. PolicyException (polex)
C. ClusterCleanupPolicy
D. a Kubernetes ClusterRole

Check the answer

A. ClusterPolicyReport is the cluster-scoped counterpart to the namespaced PolicyReport, mirroring the same namespaced-vs-cluster split as Policy/ClusterPolicy.

Block 2 — Q16–30 (minutes 30–60)

Q16 (🦉 Fundamentals of Kyverno). Which statement correctly distinguishes Policy from ClusterPolicy?

A. Policy is namespaced and can match Namespace objects; ClusterPolicy cannot
B. ClusterPolicy is namespaced; Policy can match Namespace objects
C. Policy has an identical schema but is confined to its own namespace; only ClusterPolicy can match cluster-scoped resources like Namespace
D. Both are cluster-scoped and functionally identical

Check the answer

C. Same schema, different scope: Policy lives and acts inside one namespace; only ClusterPolicy can reach cluster-scoped resources such as Namespace.

Q17 (🐢 Writing Policies). A rule includes both a preconditions block and a pattern under validate. In what order does Kyverno evaluate them for a matching request?

A. pattern first, then preconditions
B. preconditions first — if false, the rule (including its validate pattern) is skipped entirely
C. They evaluate in parallel, and either one failing blocks the request
D. preconditions only applies to mutate rules, never validate

Check the answer

B. preconditions is the cheap gate that runs first; a false precondition means the rest of the rule, including validate.pattern, is never evaluated for that request.

Q18 (🦫 Installation, Configuration & Upgrades). Which Kyverno controller aggregates every rule's results into PolicyReport and ClusterPolicyReport objects?

A. The admission controller
B. The reports controller
C. The background controller
D. The cleanup controller

Check the answer

B. The reports controller is the fourth of Kyverno's four controllers, dedicated to rolling every rule evaluation up into PolicyReport/ClusterPolicyReport objects.

Q19 (🐢 Writing Policies). A validate rule's pattern includes team: "?*" under metadata.labels. What does the ?* wildcard require?

A. Exactly one character, no more and no less
B. At least one character present in the value
C. The literal two-character string "?*"
D. Zero or more characters, including an empty string

Check the answer

B. ?* means "at least one character" — it fails an empty or missing label, and passes any non-empty value, without pinning the value to anything specific.

Q20 (🤖 Applying Policies, Select TWO). Which TWO fields sit at the policy or rule level, outside any single rule type, as part of the "Common Policy Settings for Kyverno Rules" competency — one controlling whether background scanning applies, the other bounding how long a rule waits on a slow external call?

A. background
B. webhookTimeoutSeconds
C. mutateDigest
D. clone
E. imageReferences

Check the answer

A and B. background controls whether the background controller also scans pre-existing resources against this policy; webhookTimeoutSeconds bounds how long the admission webhook waits on a rule's context calls before timing out. C, D and E are specific to verifyImages and generate, not common settings.

Q21 (🦉 Fundamentals of Kyverno). Kyverno dynamically registers its admission webhook configuration to cover only the resource kinds referenced by currently installed policies. What's the practical effect of installing a single policy that only matches Pod?

A. Kyverno starts intercepting every resource kind cluster-wide, regardless of what's installed
B. The API server only calls Kyverno's webhook for Pod admission requests — nothing else pays the latency cost
C. Kyverno stops functioning until a second policy is installed
D. The webhook configuration is static and must be edited by hand for every new policy

Check the answer

B. Kyverno keeps its own webhook configuration in sync with what's actually installed, so a narrow policy set means a narrow, low-latency webhook footprint — not a blanket interception of every kind.

Q22 (🐢 Writing Policies). Which annotation controls which pod-controller kinds (Deployment, StatefulSet, DaemonSet, Job, CronJob) autogen creates equivalent rules for, when a rule's match targets Pod?

A. kyverno.io/background-scan
B. pod-policies.kyverno.io/autogen-controllers
C. admission.kyverno.io/webhook-timeout
D. policy.kyverno.io/exclude-controllers

Check the answer

B. That annotation names exactly which pod-controller kinds autogen should target, or disables autogen entirely for that rule.

Q23 (🦫 Installation, Configuration & Upgrades). Which command is the authoritative source for a Kyverno Helm chart's available extraArgs and other controller configuration flags, rather than a blog post that may reference an older chart version?

A. kubectl explain clusterpolicy
B. helm show values kyverno/kyverno
C. kyverno jp function
D. kubectl get clusterrole kyverno:background-controller -o yaml

Check the answer

B. Chart values move between releases, so helm show values against the chart you're actually installing is the ground truth — not a cached blog post or an old README.

Q24 (🐿️ Kyverno CLI). Which kyverno CLI subcommand lets you evaluate a JMESPath expression against a manifest directly, so you can debug the expression before pasting it into a rule's {{ }} syntax?

A. kyverno apply
B. kyverno test
C. kyverno jp
D. kyverno version

Check the answer

C. kyverno jp query runs a JMESPath expression against a manifest and prints the result, and kyverno jp function lists Kyverno's custom JMESPath functions — both purpose-built for debugging expressions in isolation.

Q25 (🐢 Writing Policies). Which field lets a rule read a ConfigMap value or call the Kubernetes API mid-evaluation, making that data available to the rest of the rule via a variable?

A. preconditions
B. a context entry
C. exclude
D. background

Check the answer

B. A context entry is how a rule pulls in outside data — a ConfigMap, an API call, a global context — and exposes it as a variable the rest of the rule can reference.

Q26 (🦉 Fundamentals of Kyverno). Which of the following correctly names Kyverno's admission-time evaluation order for a single request that a policy governs with all three of mutate, validate, and verifyImages?

A. validate → verifyImages → mutate
B. mutate → validate → verifyImages
C. verifyImages → mutate → validate
D. All three run simultaneously with no defined order

Check the answer

B. Mutation happens first so the object is in its final shape before validation checks it, and verifyImages — itself a mutating-phase rule that can rewrite a tag to a digest — runs after that.

Q27 (🦫 Installation, Configuration & Upgrades). Which command inspects exactly what Kyverno's background controller is actually permitted to touch in the cluster, rather than assuming from documentation alone?

A. helm repo update
B. kubectl get clusterrole kyverno:background-controller -o yaml
C. kyverno test ./policies/
D. kubectl get polr -A -o wide

Check the answer

B. Reading the actual ClusterRole is the only reliable way to know what a controller can touch — RBAC is ordinary Kubernetes RBAC here, worth inspecting directly rather than guessing.

Q28 (🐢 Writing Policies). CleanupPolicy and ClusterCleanupPolicy delete matching resources on a schedule. How do they relate to the four rule types (validate/mutate/generate/verifyImages)?

A. CleanupPolicy is a fifth rule type, nested inside spec.rules like the other four
B. They are separate CRDs served by their own controller, defining a cron schedule and a match — not a rule type inside a ClusterPolicy/Policy at all
C. They can only be attached as a precondition on a validate rule
D. They replace generate rules entirely in newer Kyverno versions

Check the answer

B. Cleanup policies are their own CRDs, evaluated by the dedicated cleanup controller on a cron schedule — the exam-worthy trap is assuming they're a fifth rule type bolted onto an ordinary policy.

Q29 (🤖 Applying Policies). A rule's match block selects Deployment, and its exclude block selects that same Deployment by name. When Kyverno evaluates a request for that specific Deployment, what happens?

A. The rule still applies, because match always takes precedence over exclude
B. The rule does not apply — a resource caught by exclude is skipped even if match also selects it
C. Kyverno raises a configuration error at policy-install time and refuses to install the policy
D. Only the generate portion of the rule is skipped; validate still runs

Check the answer

B. exclude wins: a resource matched by both match and exclude is treated as excluded, and the rule skips it entirely.

Q30 (🐘 Policy Management). PolicyExceptions (polex) let one named workload skip one named rule. What's the primary advantage of this over editing the ClusterPolicy directly to add an exclusion?

A. It removes the need for RBAC on the background controller
B. It is a separate, reviewable resource — the carve-out goes through Git and code review while the policy itself stays strict for every other workload
C. It disables background scanning cluster-wide
D. It automatically expires after exactly 24 hours with no configuration

Check the answer

B. A PolicyException is its own reviewable object — one team's carve-out is visible, git-tracked, and doesn't quietly weaken the rule everyone else is still held to.

Block 3 — Q31–45 (minutes 60–90)

Q31 (🐢 Writing Policies, Select TWO). Which TWO fields belong to a verifyImages entry, letting it both scope which image references are checked and rewrite a verified tag to its digest?

A. imageReferences
B. mutateDigest
C. clone
D. synchronize
E. patchStrategicMerge

Check the answer

A and B. imageReferences scopes which images the rule checks (for example a glob like ghcr.io/acme/*), and mutateDigest rewrites the tag to the verified digest once a signature checks out. C and D belong to generate; E belongs to mutate.

Q32 (🐘 Policy Management). Beyond pass and fail, which additional results can a PolicyReport row carry for a given rule against a given resource?

A. warn, skip, and error
B. only pending and retrying
C. approved and denied
D. archived and expired

Check the answer

A. The full result set is pass/fail/warn/skip/error — knowing all five, not just pass/fail, is what lets you tell "a resource wasn't evaluated" apart from "a resource failed."

Q33 (🦫 Installation, Configuration & Upgrades). Which two CRDs would you expect for Kyverno's cleanup feature specifically, distinct from ClusterPolicy and Policy?

A. PolicyReport and ClusterPolicyReport
B. CleanupPolicy and ClusterCleanupPolicy
C. PolicyException and UpdateRequest
D. AdmissionReview and MutatingWebhookConfiguration

Check the answer

B. CleanupPolicy (namespaced) and ClusterCleanupPolicy (cluster-scoped) are the pair dedicated to scheduled deletion, served by their own cleanup controller.

Q34 (🦉 Fundamentals of Kyverno). A ClusterPolicy's spec.rules array must contain at least how many rules for the policy to be valid, and which single field is mandatory on each one?

A. Zero rules are allowed; match is optional
B. At least one rule; match is mandatory on each
C. Exactly four rules, one per rule type; none are mandatory
D. At least one rule; validate is the only mandatory rule type

Check the answer

B. A policy needs at least one rule, and every rule needs a match block — but which of the four rule types it carries is entirely up to the author.

Q35 (🐿️ Kyverno CLI). Which of the following is one of the four things the KCA curriculum's Kyverno CLI domain explicitly names as testable, alongside apply, test, and jp?

A. Installing the Kyverno CLI itself
B. Writing a Helm chart from scratch
C. Configuring the admission controller's replica count
D. Writing a PolicyException

Check the answer

A. The curriculum names exactly four CLI competencies — apply, test, jp, and Installing Kyverno CLI — the last of which covers how the standalone binary itself gets onto your machine, not just how you use it once it's there.

Q36 (🐢 Writing Policies). A validate rule uses the older, deprecated spec.validationFailureAction: Enforce field instead of the current per-rule validate.failureAction. On a modern Kyverno install, what should you expect?

A. The policy fails to install at all
B. It is still recognized — the curriculum expects you to recognize both the current per-rule form and the older, deprecated spec-level form
C. It silently does nothing, with no error and no effect
D. It only works for generate rules, never validate

Check the answer

B. Both forms exist in real clusters you might inherit, so the exam expects you to recognize the deprecated spec-level field on sight, not just the newer per-rule one.

Q37 (🤖 Applying Policies). Resource Selection is called out as its own KCA competency. Which set of filter types can a match or exclude block combine, under any or all?

A. kinds, namespaces, names, label selectors, subjects, and operations
B. Only kinds and namespaces
C. Only label selectors
D. CPU limits and memory limits

Check the answer

A. That's the full filter surface — getting one of those six wrong, especially namespaces or operations, is the single most common reason a policy "does nothing" in practice.

Q38 (🐘 Policy Management). Which command exposes Kyverno's own operational metrics — admission counts, rule-result totals, latencies — in the same Prometheus-compatible format the rest of a platform's dashboards already use?

A. kubectl -n kyverno port-forward svc/kyverno-svc-metrics 8000:8000
B. kyverno jp function
C. kubectl get polex -A
D. helm show values kyverno/kyverno

Check the answer

A. Port-forwarding to the metrics service exposes ordinary Prometheus-format metrics, so guardrails land on the same dashboards and alerting as everything else already watched.

Q39 (🦫 Installation, Configuration & Upgrades). A team scales the admission controller to 3 replicas for high availability but leaves the background controller at 1 replica. Is this a reasonable HA configuration?

A. No — every Kyverno controller must always run the same replica count
B. Yes — the admission controller is the one directly in the live request path, so it's the priority for HA; the background controller's work tolerates more latency
C. No — the background controller is the only one that matters for HA
D. It's irrelevant, because Kyverno has no meaningful high-availability story at all

Check the answer

B. Only the admission controller sits directly in the request path where an outage blocks every create and update; the background controller's scans and generate work can tolerate a brief gap far more easily.

Q40 (🐢 Writing Policies). Which field on a mutate rule lets it modify resources that already exist in the cluster, not only the resource that triggered admission?

A. targets
B. preconditions
C. background
D. exclude

Check the answer

A. targets under mutate names additional existing resources to patch, driven by the background controller — the "mutate-existing" capability distinct from patching only the incoming object.

Q41 (🦉 Fundamentals of Kyverno). Which statement correctly describes what Kyverno's OCI image verification (verifyImages) is checking?

A. That the image was pulled from a specific registry hostname only
B. That the image has a valid signature or attestation trusted by the configured attestors, before the pod is admitted
C. That the image's file size is under a configured limit
D. That the image was built within the last 30 days

Check the answer

B. verifyImages checks cryptographic trust — a signature or attestation from a configured attestor — not registry origin, size, or freshness.

Q42 (🐿️ Kyverno CLI). A team wants a dry run of their full policy set against a live cluster's actual objects — not local YAML files — without changing anything. Which command achieves this?

A. kyverno apply ./policies/ --resource ./manifests/
B. kyverno apply ./policies/ --cluster --policy-report
C. kyverno test ./policies/
D. helm upgrade kyverno kyverno/kyverno -n kyverno

Check the answer

B. The --cluster flag points apply at the live cluster's real objects instead of local manifests, and --policy-report renders the result as a report rather than applying anything.

Q43 (🤖 Applying Policies). A rule matches Deployment in every namespace, and its author expects it to also govern Namespace creation directly. Why won't it?

A. Because match filters cannot include multiple kinds
B. Because a validate rule is namespaced-only regardless of policy kind
C. Because Namespace is a cluster-scoped resource, and matching Deployment says nothing about matching Namespace — it needs its own match entry, in a policy that's a ClusterPolicy
D. Because Deployment and Namespace share the same API group, so one match entry always covers both

Check the answer

C. match entries name specific kinds — matching one kind never implies matching another — and reaching Namespace at all additionally requires the policy to be a ClusterPolicy, since Policy objects can't touch cluster-scoped resources.

Q44 (🐢 Writing Policies). Which of the following is NOT one of the four rule types a Kyverno rule can specify exactly one of?

A. validate
B. mutate
C. authorize
D. generate

Check the answer

C. The four rule types are validate, mutate, generate, and verifyImages — there is no authorize rule type in Kyverno.

Q45 (🐘 Policy Management). A security team wants to measure a candidate policy against the whole fleet before ever enforcing it, so they install it with failureAction left at its default (audit). Which command shows them the resulting fail count without anything having been blocked?

A. kubectl get polr -A -o wide
B. kubectl delete clusterpolicy <name>
C. kyverno jp query
D. helm uninstall kyverno

Check the answer

A. PolicyReports record what a rule would have done regardless of failureAction, which is exactly what makes audit mode useful as a fleet-wide measurement tool before anyone flips a rule to Enforce.

Score yourself

☺ Like you're 10: Count your correct answers out of 45, compare against the 75% target, then look at which chapter cost you the most points — that second part is the useful part.

The Linux Foundation's general Multiple Choice Exam FAQ requires "a score of 75% or above" on LF multiple-choice exams, and KCA is one — so treat 34 of 45 (75.6%) as a reasonable target to clear comfortably, not as a guaranteed pass/fail line on the real exam, which uses its own question bank and its own count. Verify current pass-mark guidance on the official Linux Foundation KCA page before you rely on any number here.

Domain	Questions in this paper	Your score	If under two-thirds, go here
🐢 Writing Policies (32%)	Q1, 3, 7, 10, 13, 17, 19, 22, 25, 28, 31, 36, 40, 44	/14	The Writing Policies section of the blueprint
🦉 Fundamentals of Kyverno (18%)	Q2, 6, 11, 16, 21, 26, 34, 41	/8	The Fundamentals section of the blueprint
🦫 Installation, Configuration & Upgrades (18%)	Q4, 9, 14, 18, 23, 27, 33, 39	/8	The Installation section of the blueprint
🐿️ Kyverno CLI (12%)	Q5, 12, 24, 35, 42	/5	The CLI section of the blueprint
🤖 Applying Policies (10%)	Q8, 20, 29, 37, 43	/5	The Applying Policies section of the blueprint
🐘 Policy Management (10%)	Q15, 30, 32, 38, 45	/5	The Policy Management section of the blueprint
Total	45 questions	/45	~75% (34/45) as a rough target

◆ Key idea

A 34/45 built from six solid domains and a 34/45 built from five near-perfect domains plus a near-zero on one are very different results — the second is one unlucky question draw away from failing the real exam, even though both score the same total here. Always do the per-domain arithmetic, not just the headline number.

Beyond the domain breakdown, sort your misses into two piles, because they mean different things. A question you got wrong because you genuinely didn't know the field or the resource is a real content gap — reread the linked blueprint section and redo the exact question cold in a couple of days. A question you got wrong despite roughly knowing the material — you second-guessed yourself, confused two similarly-named fields like clone and data, or ran out of time and guessed under pressure — is a speed or confidence problem, not a knowledge gap, and the fix is more untimed reps in the practice bank plus another timed paper, not rereading content you already have.

🎬 At Mission Control
🐰Remy: Forty out of forty-five! Rule types, resource selection, the CLI — done, done, next!
🐢Timmy: Which domain hid your misses, Remy? Forty sounds great until one domain swallowed most of them.
🐰Remy: ...Installation, Configuration and Upgrades. I kept mixing up which controller does what.
🦫Benny: Admission is the one in the request path — scale it first for HA. Background does the scans and the generate work, and it's the one that needs the extra RBAC. Reports totals it all up into PolicyReports. Cleanup runs on its own cron schedule. Say it in that order until it's automatic, not just recognizable in a list.
🦉Professor Owl: And remember the one architectural gap hiding in there too — background scans can't see admission-only context like request.userInfo. A rule that depends on who made the request can only ever run at admission time, never in the background.
🐢Timmy: Fix that one gap, then sit Set 2 once it's actually fixed — not before, or you'll just confirm the same gap twice.

✓ Checkpoint

1. Why does this paper assign questions to each domain in the same proportion as the real KCA weights, rather than spreading them evenly across six piles? 2. What's the safe assumption about guessing penalties on a Linux Foundation multiple-choice exam, and what strategy follows from it? 3. Why is the 45-question, 3-block shape of this paper this course's own construction rather than an official KCA format? 4. You score 34/45 overall but 1/8 on one specific domain — why is that more actionable than a flat 75% average would suggest? 5. Name the two piles a wrong answer can fall into during review, and why they call for different fixes.

Check your answers

Because that's how the CNCF actually weights the real KCA blueprint — 32% Writing Policies, 18% Fundamentals, 18% Installation, 12% CLI, 10% Applying Policies, 10% Policy Management — so practicing, and scoring, in that same proportion is the closest a study paper can get to the real thing.
Linux Foundation multiple-choice exams don't publish an extra penalty for a wrong guess beyond simply not earning the point, so the safe strategy is to never leave a question blank — eliminate what you can, then commit to your best remaining guess.
Because neither official KCA page publishes the real question count at all — this paper's 45 questions across three 30-minute blocks were chosen because they split cleanly into whole numbers of questions per domain and fit a realistic 90-minute sitting, not because that's a leaked or official format.
Because a flat 75% hides where the gap actually is. A domain score of 1/8 is a concentrated, specific content gap fixable by rereading one section, while an evenly-spread 75% wouldn't tell you where to focus at all — the per-domain breakdown converts an average into a diagnosis.
A genuine content gap — you didn't know the fact at all — calls for rereading the linked blueprint section and redoing the exact question cold later. A speed or confidence problem — you roughly knew it but second-guessed yourself or ran out of time — calls for more timed reps and untimed practice-bank drilling, not rereading content you already have.

That's the full sitting. Reset the timer, close every tab except this one, and let the 45 questions above show you exactly which of the six domains is still soft — then go fix precisely that, and nothing else, before you move on to Set 2.

📝 The two papers

Set 1 (you are here) · Set 2. Both are 45 questions weighted to the same official domain percentages and scored against the same 75% target; see the study plan for when to sit each one, and the KCA blueprint for the real thing's domains, competencies, and day-of logistics.