KCA Mock Exam · Set 2

This is the companion paper to Set 1: fifty more multiple-choice questions, weighted question-for-question to the same six domains of the official KCA curriculum — sixteen on Writing Policies, nine on Fundamentals of Kyverno, nine on Installation, Configuration & Upgrades, six on the Kyverno CLI, five on Applying Policies, five on Policy Management. Every question and scenario below is original to this course, built around a fictional orbital-habitat cluster rather than anything lifted from CNCF material or reused from elsewhere on this shelf. KCA is a pure knowledge exam — no live cluster, no terminal — so there is nothing to install here: read the stem, pick an answer, then read the explanation underneath whether you got it right or not. Sit it as one uninterrupted block, answer every question even when guessing, and treat each miss as a pointer to exactly which part of the blueprint page to re-read.

How to sit this paper

☺ Like you're 10: Set a timer, close every other tab, and go straight through without stopping to look anything up.

A mock paper only tells you the truth if you sit it under the conditions it's imitating. Looking things up mid-paper measures your search skills, not your recall — so treat this like the real 90-minute sitting: one block, no documentation open, no other tabs, and a committed answer on every question, even a guessed one. Nothing published states that Linux Foundation multiple-choice exams deduct marks for a wrong answer, so there is no reason to ever leave one blank.

The protocol

1. Set a clock for 90 minutes. That's the duration the Linux Foundation publishes for KCA — see the logistics table on the blueprint page for the full picture and why it's worth re-verifying before you book.
2. Answer, then open the explanation. If it just confirms what you thought, move on. If it surprises you, write down the concept — that list becomes your revision plan for the next two days.
3. Don't re-sit immediately. Go and re-read your two weakest domains first. A second attempt an hour later measures short-term memory, not knowledge.
4. Sit Set 1 and this paper on separate days if you haven't already — same weighting, different scenarios, and together they're a much more honest signal than either alone.

What this paper deliberately is not

It isn't a leaked or reconstructed exam — the wording, the fictional cluster, and every resource name below are original to this course, not the CNCF's. A multiple-choice paper is the right shape of practice specifically because KCA is knowledge-based: you pick answers, you never touch a live cluster, unlike the fully performance-based LFCS or the hybrid ICA elsewhere on this shelf. And it isn't a general Kubernetes security exam — this course assumes the five core Kubernetes certifications, including CKS, are already cleared over in the sibling Kubernetes course. Nothing here re-teaches kubectl, RBAC fundamentals, or admission-control theory in general — only Kyverno's own idioms on top of them.

How the fifty questions are weighted

☺ Like you're 10: The questions are shared out the same way the real test shares out its marks — the biggest topic gets almost a third, the smallest two get a tenth each.

The six published weights — 32%, 18%, 18%, 12%, 10%, 10% — are applied to fifty questions the same way the blueprint page applies them to the real exam. The arithmetic lands exactly, with no remainder to argue about: 32% of 50 is 16, 18% of 50 is 9 (twice), 12% of 50 is 6, and 10% of 50 is 5 (twice). Add them up — 16 + 9 + 9 + 6 + 5 + 5 — and you get exactly 50, so unlike some forty-question papers on this shelf, no domain here needs a rounding tie-break at all.

The fifty questions run across three blocks, each mixing all six domains rather than grouping them — exactly like the real exam, where you never know which domain the next question belongs to. Budget your 90 minutes roughly in proportion to each domain's share, with a few minutes held back at the end for anything you flagged:

The paper — 50 questions across six domains

☺ Like you're 10: Read the recipe card if there is one, pick your best answer, then check yourself before moving to the next one.

Each question names its domain in parentheses. On the real exam you won't get that label, so if you sit this paper a second time, try covering the domain tags and see how many you can still place by content alone. Every resource, namespace and policy name below belongs to one running fiction — an orbital habitat cluster called orbit — used only to make the scenarios concrete.

Block 1 — Q1–17

Q1 (Writing Policies). A validate rule is installed using the current per-rule schema, with no failureAction field set anywhere inside its validate block. A resource is created that violates the rule's pattern. What happens?

• A. The resource is rejected immediately — Enforce is the default
• B. The violation is recorded in a policy report, but the resource is still admitted — the default failureAction is Audit, not Enforce
• C. The resource is rejected only if background: true is also set
• D. The rule is skipped entirely, since failureAction is required for the rule to evaluate at all

Q2 (Fundamentals of Kyverno). Within a single ClusterPolicy, can one entry inside spec.rules[] declare both validate and mutate at the same time?

• A. Yes, freely — both actions execute together as one rule
• B. No — each rule declares exactly one of validate, mutate, generate, or verifyImages; combining two actions means writing two separate rules, not merging them into one
• C. Only if background: true is also set
• D. Only inside a namespaced Policy, never a ClusterPolicy

Q3 (Installation, Configuration, and Upgrades). What is the standard Helm-based method to install Kyverno for the first time onto a cluster?

• A. kubectl apply -f https://kyverno.io/install.yaml — Helm is never the named method
• B. Add the kyverno Helm repo, then helm install kyverno kyverno/kyverno -n kyverno --create-namespace, which installs the CRDs and the controllers together
• C. A mandatory three-chart split — a base chart, a control-plane chart, and a gateway chart — with no single-chart option
• D. istioctl install --set profile=kyverno

Q4 (Writing Policies). A precondition on a rule reads: key: "{{ request.operation }}", operator: AnyIn, value: [CREATE, UPDATE]. A DELETE request arrives that otherwise satisfies the rule's match block. What happens?

• A. The rule still evaluates its validate pattern against the DELETE
• B. The precondition evaluates false, so the rule is skipped entirely for that request — a cheaper filter than trying to encode the same logic inside the pattern itself
• C. DELETE requests are always evaluated regardless of any precondition
• D. Preconditions can only reference request.object, never request.operation

Q5 (Kyverno CLI). What is the key advantage of kyverno apply ./policies/ --resource ./manifests/ over applying a policy straight to a live cluster to see what it does?

• A. It's simply faster, nothing else changes
• B. It evaluates the policies against the manifest files with no cluster required at all — safe to run against arbitrary local YAML before anything touches a real environment
• C. It automatically fixes any violations it finds
• D. It requires cluster-admin privileges, unlike a live apply

Q6 (Policy Management). What's the difference between kubectl get polr -A and kubectl get cpolr?

• A. They're aliases for exactly the same underlying resource
• B. polr (PolicyReport) holds results for namespaced resources, one report per namespace; cpolr (ClusterPolicyReport) holds the cluster-scoped equivalent, for resources like Namespace itself
• C. cpolr is deprecated and no longer produced by current Kyverno releases
• D. polr only ever shows failing results, never passing ones

Q7 (Writing Policies). Which two mechanisms can a mutate rule use to rewrite an incoming resource on its way in?

• A. patchStrategicMerge and patchesJson6902 (an RFC 6902 JSON patch)
• B. pattern and deny
• C. generate and clone
• D. webhookTimeoutSeconds and background

Q8 (Applying Policies). A ClusterPolicy is installed with background left unset, so it defaults to true. What does this mean for resources that already existed in the cluster before the policy was created?

• A. Nothing — policies never evaluate resources that predate them, under any setting
• B. They get evaluated too — the background controller periodically scans existing resources against the policy, in addition to the live admission path catching new and updated ones going forward
• C. background only ever affects generate rules, never validate
• D. Pre-existing violating resources are automatically deleted

Q9 (Fundamentals of Kyverno). Why can a platform engineer write and review Kyverno policies without learning a brand-new domain-specific language first?

• A. Kyverno rules are written in Rego, the same language used by several other admission-control tools
• B. A Kyverno policy is itself an ordinary Kubernetes YAML resource, and a rule's pattern is expressed by echoing the shape of the resource it's checking — the same YAML structure already read every day
• C. Policies must be compiled into a binary before they can be applied
• D. Kyverno only accepts JSON manifests, never YAML

Q10 (Installation, Configuration, and Upgrades). Which of the following is not a genuine, separate Kyverno CRD?

• A. ClusterPolicy
• B. PolicyException
• C. ClusterCleanupPolicy
• D. ValidatingAdmissionPolicy

Q11 (Writing Policies). A generate rule uses clone rather than data to create a companion resource, with synchronize: true set. What does synchronize: true actually do?

• A. Nothing — it only ever affects data-based generation, not clone
• B. Keeps the generated copy in step with the source object going forward — if the source changes later, the generated copy updates to match, and a direct edit to the generated copy is reverted
• C. Deletes the generated resource automatically if the trigger resource is later deleted
• D. Forces the generated resource into the same namespace as the source, regardless of what namespace says

Q12 (Kyverno CLI). What does adding --cluster to kyverno apply ./policies/ --policy-report change?

• A. Nothing; the flag doesn't exist in the CLI
• B. It evaluates the named policies against the resources actually present in your currently-configured live cluster, rather than local manifest files — still a dry run, just against real cluster state instead of files on disk
• C. It installs the named policies onto the cluster permanently
• D. It switches evaluation to CEL-only mode

Q13 (Fundamentals of Kyverno). What kind of Kubernetes object does Kyverno register itself as, in order to intercept every create and update before persistence?

• A. A CustomResourceDefinition only
• B. A ValidatingWebhookConfiguration and a MutatingWebhookConfiguration — both — so it can act in either capacity depending on the rule type in play
• C. Only a MutatingWebhookConfiguration; validation happens out-of-band, after the fact
• D. A CronJob that polls the API server on an interval

Q14 (Writing Policies). Which phase of the Kyverno admission webhook does a verifyImages rule execute in, and why does that matter?

• A. The validating phase — it can only ever reject, never modify the object
• B. The mutating phase — because a successful verification can rewrite the image tag to the verified digest via mutateDigest, closing the tag-mutation race
• C. A separate, third phase that runs after both validate and mutate have finished
• D. Entirely inside the background controller, never on the live admission path

Q15 (Applying Policies). A rule's match.any block lists two separate resources filters: one for kinds: [Pod] and one for namespaces: [orbit]. How does any combine these two filters?

• A. Both must be true simultaneously for a resource to match — effectively an AND
• B. Either filter alone is sufficient to match — this actually matches any Pod anywhere in the cluster, or anything at all in the orbit namespace, which is likely broader than intended
• C. Neither filter applies unless both are written inside the same single resources: block
• D. any is only valid syntax under exclude, never under match

Q16 (Installation, Configuration, and Upgrades). Chart values for controller flags — such as admissionController.container.extraArgs — can differ between Kyverno chart releases. What's the reliable way to check which flags a specific chart version actually supports, rather than trusting an old blog post?

• A. kubectl explain kyverno
• B. helm show values kyverno/kyverno, run against the specific chart version you're installing, since values.yaml is the authoritative, versioned source
• C. Reading through the Kyverno GitHub issues tracker
• D. There's no reliable way to check this ahead of time

Q17 (Policy Management). A team wants exactly one workload exempt from one specific rule, without weakening that rule for every other workload in the cluster. What's the idiomatic Kyverno mechanism for this?

• A. Add an exclude block directly to the shared policy, naming that one workload
• B. Create a PolicyException — a separate, reviewable resource naming the exempted policy, rule, and resource, so the exemption goes through Git and code review without editing the policy itself
• C. Set failureAction: Audit for the whole policy
• D. Delete the rule entirely and rely on a different rule to cover the gap

Block 2 — Q18–34

Q18 (Writing Policies). A rule needs to read a value from a ConfigMap that isn't part of the incoming request at all, then use it inside a validate.pattern. Which mechanism supplies that value?

• A. preconditions alone, with no other construct needed
• B. A context entry (for example a configMap entry) that fetches the value, referenced afterward as a {{ }} variable inside the rule
• C. background: true
• D. The pod-policies.kyverno.io/autogen-controllers annotation

Q19 (Fundamentals of Kyverno). Which of these is a digest-pinned image reference, as opposed to a tag-pinned one?

• A. ghcr.io/orbit/telemetry-uplink:v2
• B. ghcr.io/orbit/telemetry-uplink@sha256:9f86d0...
• C. ghcr.io/orbit/telemetry-uplink:latest
• D. ghcr.io/orbit/telemetry-uplink with no suffix at all

Q20 (Writing Policies). Which RFC 6902 JSON Patch operation would you use inside patchesJson6902 to add a new field to a Pod's first container that doesn't yet exist there, without disturbing the rest of the container spec?

• A. replace, since add requires the target field to already exist
• B. add, targeting the specific path — add works whether or not the target key already exists at that location, unlike replace
• C. remove, followed by a second operation that re-adds it
• D. copy

Q21 (Installation, Configuration, and Upgrades). Take the rule fragment below:

- name: generate-default-deny
  match:
    any:
      - resources: { kinds: [Namespace] }
  generate:
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    name: default-deny
    namespace: "{{ request.object.metadata.name }}"
    data:
      spec:
        podSelector: {}
        policyTypes: [Ingress, Egress]

This rule is installed cluster-wide, kyverno test passes locally, but on the live cluster no NetworkPolicy ever actually appears in newly-created namespaces. What's the most likely operational cause?

• A. The rule's YAML is malformed, despite kyverno test reporting success
• B. The background controller's ClusterRole doesn't grant permission to create NetworkPolicy objects — generate rules need RBAC for whatever kind they create, and a silently-missing permission is a very common cause of a generate rule that appears to do nothing
• C. generate rules can never target NetworkPolicy, only ConfigMaps
• D. The rule needs background: true explicitly set to create anything

Q22 (Kyverno CLI). Running kyverno test ./policies/ with no other arguments, how does the CLI know which test cases to actually run?

• A. It requires an explicit --file flag naming every individual test case
• B. It recursively discovers kyverno-test.yaml files under the given path and runs the declarative test cases they define
• C. It only runs tests embedded as comments inside the policy YAML itself
• D. It re-runs whatever was most recently applied with kyverno apply

Q23 (Writing Policies). A validate rule matches only kind: Pod in its match block. A developer creates a Deployment whose Pods would violate that rule if they were created directly. Assuming autogen is left at its default behavior, what actually happens?

• A. Nothing — a Pod-only rule never applies to a Deployment
• B. Kyverno's autogen mechanism automatically generates an equivalent rule for the pod controllers, including Deployment, so the Deployment is checked and rejected with the message at the layer the developer actually applied
• C. The rule silently applies to the Deployment's ReplicaSet only, never to the Deployment resource itself
• D. Autogen only works for mutate rules, never for validate

Q24 (Policy Management). Kyverno exposes its own operational metrics via the kyverno-svc-metrics Service. What format are they in, and what do they integrate with?

• A. A proprietary JSON format, readable only through the Kyverno CLI
• B. Ordinary Prometheus-format metrics — admission counts, rule-result totals, latencies — so guardrail behavior lands on the same dashboards as everything else already being monitored
• C. StatsD format, requiring a separate exporter to translate it
• D. Kyverno exposes no metrics at all; only PolicyReport objects carry that information

Q25 (Fundamentals of Kyverno). A Policy (not a ClusterPolicy) is created in namespace orbit. Can its rules match a Namespace resource?

• A. Yes — any policy kind can match any resource kind
• B. No — a namespaced Policy can only ever match resources inside its own namespace, and Namespace itself is cluster-scoped, so only a ClusterPolicy can match it
• C. Only if background: true is also set on the Policy
• D. Only if the target Namespace carries a matching label

Q26 (Installation, Configuration, and Upgrades). A team wants to make their Kyverno install highly available and, due to a resource budget, can only prioritize scaling one controller's replica count first. Which controller should that be, and why?

• A. The cleanup controller — it runs on the most frequent schedule
• B. The admission controller — it's the only one of the four directly in the live request path, so its unavailability blocks new resource creation cluster-wide in a way the other three controllers don't
• C. The reports controller — PolicyReport objects are the most operationally important artifact
• D. It doesn't matter; all four controllers sit directly in the live request path equally

Q27 (Writing Policies). A ClusterCleanupPolicy is created with schedule: "0 2 * * *" and a match selecting completed Jobs older than 48 hours. Which statement about this resource is correct?

• A. It's a fifth Kyverno rule type, nested inside spec.rules like validate or mutate
• B. It's a separate CRD served by its own cleanup controller, unrelated to spec.rules on a ClusterPolicy, and it deletes matching resources on the stated cron schedule
• C. It only ever runs once, at the moment it's created
• D. It requires background: true to take effect

Q28 (Applying Policies). Which match.any.resources field would you use to make a rule apply only to requests made by a specific ServiceAccount, rather than filtering by the resource's own kind or namespace?

• A. kinds
• B. subjects, listing the ServiceAccount (or user, or group) making the request
• C. selector
• D. operations

Q29 (Writing Policies). Kyverno's validate rules can express their check using CEL instead of the pattern-matching style. What's true about the CEL option?

• A. It's a Kyverno-invented language unrelated to anything else in Kubernetes
• B. It's the same Common Expression Language the API server itself uses natively for ValidatingAdmissionPolicy, so CEL knowledge transfers directly between the two
• C. CEL rules can only ever audit, never enforce
• D. CEL is only usable inside generate rules, never inside validate

Q30 (Kyverno CLI). A kyverno-test.yaml file declares, for one resource and one rule, an expected result of fail. Applying that policy to that resource actually results in a pass. What does kyverno test report?

• A. Nothing — kyverno test has no way to detect this kind of mismatch
• B. A test failure — the actual result didn't match the declared expected result, exactly the way a unit-testing framework flags a mismatched assertion
• C. It silently updates the expected result in the file to pass
• D. It only ever compares failureAction, never the pass/fail outcome itself

Q31 (Fundamentals of Kyverno). A validate pattern block is written as nested YAML mirroring the shape of the resource it's checking, rather than as a separate expression language, in its non-CEL form. What does this design choice buy a reviewer?

• A. Nothing meaningful — it's purely a stylistic preference
• B. A rule's pattern reads almost like the manifest it's meant to constrain, so a reviewer already fluent in Kubernetes YAML can audit a policy's intent without learning new syntax first
• C. It means a pattern can only ever check metadata, never spec
• D. It means every pattern must itself be valid as an applyable Kubernetes resource

Q32 (Installation, Configuration, and Upgrades). Before running helm upgrade kyverno kyverno/kyverno --version X, what does the curriculum's "Upgrading Kyverno" competency specifically expect a candidate to check first?

• A. Nothing — Helm upgrades are always safe to run blind, regardless of version gap
• B. The target version's release notes, because CRD handling has varied between chart versions and skipping minor versions can leave CRDs in an inconsistent state
• C. Only the cluster's own Kubernetes version, never Kyverno's own release notes
• D. Whether background: true is set on any installed policy

Q33 (Writing Policies). A validate rule's pattern checks request.userInfo.username to restrict who may create a resource, and the same policy sets background: true. What happens when the background controller scans a pre-existing resource against this rule?

• A. The background scan reports a violation normally, using the original creator's recorded username
• B. The background scan cannot evaluate this rule meaningfully — admission-only context like request.userInfo isn't available outside a live admission request, so identity-dependent rules can only ever run at admission time
• C. background: true is simply ignored whenever userInfo is referenced anywhere in the rule
• D. The rule is automatically rewritten to skip the userInfo check during background scans

Q34 (Policy Management). A PolicyReport entry shows a result of error for one resource against one rule, distinct from fail. What does error typically indicate?

• A. The resource violated the rule's pattern, exactly the same meaning as fail
• B. The rule itself could not be evaluated correctly for that resource — for example a context API call failed, or a JMESPath expression errored — a different problem from the resource simply failing the check
• C. The rule was skipped because the resource was caught by exclude
• D. The resource passed, but with a non-blocking warning attached

Block 3 — Q35–50

Q35 (Writing Policies). A validate rule needs to allow a resource if it matches any one of several acceptable label patterns, not all of them simultaneously. Which field expresses that?

• A. pattern alone, since it supports OR conditions natively
• B. anyPattern — a list of patterns where satisfying at least one single entry passes the rule
• C. preconditions.any
• D. exclude.any

Q36 (Fundamentals of Kyverno). Besides CREATE and UPDATE, which other admission operation can a Kyverno rule's match legitimately filter on?

• A. Only CREATE and UPDATE are ever visible to Kyverno at all
• B. DELETE (and CONNECT, for certain resource types) are also visible admission operations a rule can match against, not just CREATE and UPDATE
• C. Kyverno cannot see DELETE requests under any circumstances
• D. PATCH is a distinct operation type, separate from UPDATE, that Kyverno also sees

Q37 (Installation, Configuration, and Upgrades). What does the --create-namespace flag do in helm install kyverno kyverno/kyverno -n kyverno --create-namespace?

• A. Creates a NetworkPolicy restricting traffic into the kyverno namespace
• B. Creates the target namespace (kyverno) automatically if it doesn't already exist, rather than requiring it as a separate step beforehand
• C. Enables background: true cluster-wide, for every installed policy
• D. Registers the admission webhook a second time

- name: default-pull-policy-all
  match:
    any:
      - resources: { kinds: [Pod] }
  mutate:
    patchesJson6902: |-
      - op: add
        path: "/spec/containers/0/imagePullPolicy"
        value: IfNotPresent

Q38 (Writing Policies). The rule above only ever patches container index 0. A Pod defines three containers, and the requirement is to add the same imagePullPolicy field to all three, not just the first. Which construct fixes this without hand-writing three separate patch operations?

• A. A second patchesJson6902 entry, one hardcoded per index, up to some assumed maximum
• B. foreach inside the mutate rule, iterating over request.object.spec.containers and applying the patch to each entry it visits
• C. preconditions.all
• D. Setting background: true on the rule

Q39 (Kyverno CLI). Why would you run kyverno jp query -i pod.yaml 'spec.containers[*].image' before pasting that same expression into a rule's {{ }} variable?

• A. jp and {{ }} use entirely unrelated expression syntaxes, so there's no real benefit
• B. jp lets you evaluate a JMESPath expression against a real manifest and see the exact result it produces, so you can debug the expression in isolation before trusting it inside a live policy rule
• C. jp only works inside generate rules, never inside validate
• D. jp requires a live cluster connection to run at all

Q40 (Applying Policies). A rule's context entry calls an external API mid-evaluation, and that call is occasionally slow. Which common policy setting controls how long Kyverno waits before the webhook call itself times out?

• A. background
• B. webhookTimeoutSeconds
• C. failureAction
• D. synchronize

Q41 (Writing Policies). Which fields must a generate rule specify to know what resource to actually create, at minimum?

• A. Only a data block, nothing else
• B. apiVersion, kind, and name, along with a target namespace for a namespaced kind, plus either data or clone to supply the content
• C. Only a context entry naming the source
• D. mutate.foreach

Q42 (Fundamentals of Kyverno). Why does the KCA curriculum name "OCI Images" as its own fundamentals competency, distinct from Kubernetes generally?

• A. Because Kyverno defines and requires its own private, non-standard image format
• B. Because verifyImages operates directly on OCI (Open Container Initiative) image references and their registry-published signatures and attestations — reasoning correctly about that rule type requires understanding how an OCI reference and its signature are structured
• C. Because OCI images are unrelated to ordinary container images entirely
• D. Because Kyverno cannot run in a cluster that uses OCI-format images at all

Q43 (Installation, Configuration, and Upgrades). Structurally, what kind of Kubernetes object is a PolicyException?

• A. A field written directly inside the ClusterPolicy it exempts
• B. Its own separate CRD, referencing the policy and rule names it exempts and the resources it applies to — a standalone, reviewable object rather than an edit buried inside the policy itself
• C. An annotation attached to the exempted resource
• D. A Helm chart value

Q44 (Writing Policies). A verifyImages rule's attestors block uses keyless, naming a subject and an issuer, rather than a static public key. What does keyless verification actually check?

• A. Nothing at all — keyless means verification is effectively skipped
• B. A Sigstore/Fulcio-issued short-lived certificate binding the signature to an OIDC identity (the subject/issuer pair), rather than a long-lived static key pair
• C. Only that the image was pulled from a specific registry, unrelated to who actually signed it
• D. Whether the image carries a latest tag

Q45 (Kyverno CLI). Beyond standard JMESPath, Kyverno's expression evaluation supports extra custom functions for things standard JMESPath can't express on its own. Which command lists them?

• A. kyverno apply --list-functions
• B. kyverno jp function
• C. kyverno test --functions
• D. helm show values kyverno/kyverno --functions

Q46 (Policy Management). A PolicyException names policies: [require-team-label] and a match block selecting one specific Deployment by name. What does this exemption actually cover?

• A. Every rule in every policy, for every resource in the entire cluster
• B. Only the named policy's named rule(s), and only for resources matching the exception's own match block — the same match/exclude filtering vocabulary an ordinary policy uses, scoped down to one narrow carve-out
• C. The entire namespace the named Deployment happens to live in, regardless of resource name
• D. All future policies created after this exception, automatically

Q47 (Writing Policies). Inside a validate pattern, what's the difference between the wildcard ?* and * when checking a field like metadata.labels.team?

• A. They're functionally identical
• B. ?* requires at least one character to be present — the field must exist and be non-empty; * matches any value including an empty string, but the field still has to exist
• C. * requires the field to be entirely absent
• D. ?* only matches numeric values

Q48 (Fundamentals of Kyverno). Why does installing a single policy that only matches kind: Pod not add any latency at all to, say, ConfigMap creation elsewhere in the cluster?

• A. ConfigMaps are always exempt from admission control by default
• B. Kyverno dynamically configures its own webhook rules to cover only the kinds referenced by currently installed policies — so the API server never calls Kyverno at all for kinds nothing has policies against
• C. Kyverno processes every request regardless of kind, then silently discards non-Pod ones after the fact
• D. ConfigMaps are routed through a separate, lower-priority webhook entirely

Q49 (Installation, Configuration, and Upgrades). Unlike Istio's revision-tag canary upgrade pattern — installing a second, parallel control plane under a new revision label, then moving namespaces across one at a time — how does a standard Kyverno upgrade typically proceed?

• A. Identically — Kyverno also supports revision-tagged, side-by-side control planes selected per namespace
• B. In place, via helm upgrade against the existing release — Kyverno has no equivalent namespace-revision-label mechanism, which is exactly why release notes and CRD compatibility matter even more before upgrading
• C. By deleting and recreating the entire cluster on every upgrade
• D. Kyverno cannot be upgraded once installed; it must be reinstalled from scratch each time

Q50 (Applying Policies). A very old ClusterPolicy manifest sets spec.validationFailureAction: enforce at the top level, rather than failureAction: Enforce inside each rule's validate block. What should a candidate recognize about this?

• A. It's invalid YAML and will be rejected outright by the API server
• B. It's the older, deprecated form of the same setting — expect to recognize both the legacy spec.validationFailureAction and the current per-rule validate.failureAction on the exam
• C. It only ever affects mutate rules, never validate rules
• D. It silently disables the entire rule

Score yourself

☺ Like you're 10: Your score is a thermometer, not a verdict — the list of questions you got wrong is the actually useful part.

Count your correct answers out of 50 and convert to a percentage. The number to beat is 75%: per the blueprint page's logistics table, the Linux Foundation's Multiple Choice Exam FAQ states that a score of 75% or above must be earned to pass a multiple-choice exam, and KCA is one — though that figure lives on the Foundation's general FAQ, not a KCA-specific page, so it's worth re-confirming before you book. This paper isn't calibrated to the real exam's difficulty and every scenario is entirely original to this course, so don't read a score here as a literal prediction of your real result — but the pattern of where you lost points travels reliably:

Whatever you scored, do one more thing before closing the tab: for every question you missed, write in your own words why the option you picked was wrong — not just why the correct one was right. That sentence is what actually stops the same mistake happening again in the real sitting.

Where each domain is taught

☺ Like you're 10: Every question above traces back to one of a handful of pages — go back to the page, not to a search engine.

Nothing in this paper examines anything outside this course's own material. The KCA blueprint page is the primary source for all six domains; where a competency needs the wider admission-control or supply-chain picture, it lives in this course's own tool and deep-dive pages.

Round it out with the KCA study plan for a pacing schedule funded by domain weight, the practice question bank for drilling between full papers, the glossary for terminology, flashcards for the vocabulary, and the certifications overview for where KCA sits against the other eight badges on this ladder. Because Kyverno enforces admission control, the sibling CKS blueprint over in the Kubernetes course is worth a skim if the surrounding cluster-security picture ever feels shakier than the Kyverno-specific facts themselves.