Skip to content

20 Free KCA Sample Questions with Answers

By Ibrahim Yesilay · Published · Updated

Here are 20 free KCA sample questions with answers, taken from the GoldenKube question bank and grouped by exam domain. Every question has the correct answer marked and a written explanation, so you can check what you know and see why the wrong options fail. Kyverno Certified Associate is a multiple-choice exam; this set is independent practice and not affiliated with the Linux Foundation.

How to use these KCA practice questions

Work through the 20 KCA sample questions in one sitting without looking anything up. For each question, decide on an answer first, then open the answer and read the explanation, including when you were right, because a correct guess and a correct line of reasoning look identical until the exam rewords the question. Mark every question as right, wrong or guessed, and count a guess as wrong when you score yourself. Give the set about 30 minutes, which is the average time per question on the real exam multiplied by twenty. The aim is to find out which exam domains are already solid and which ones need study before you buy the exam.

The official exam format is 60 questions in 90 minutes, with a passing score of 75%, according to the Linux Foundation documentation checked on 2026-10-23.

With JavaScript enabled, each answer starts collapsed behind a Show answer button so you can test yourself. Without JavaScript, and for any crawler or screen reader that reads the raw page, every answer and explanation is already visible below its question.

These questions were written for GoldenKube practice. They are not copied from the real exam, and nothing on this page tells you what the real exam will ask.

  • Read the question twice and underline the constraint words: "most", "least", "first", "only", "not".
  • Eliminate options you can prove wrong before you pick between the rest.
  • Where a question says to select all that apply, every correct option must be chosen and none of the wrong ones.
  • Read the explanation even for questions you got right; it often names the nearby concept the exam likes to swap in.

Fundamentals of Kyverno (5 questions)

Question 1

Which Cosign signing mode is fully offline-capable, requiring no external service to be reachable at sign or verify time?
  1. A.Both modes require the same external services.
  2. B.Keyless signing via Fulcio and Rekor.
  3. C.Neither mode can function without a live internet connection.
  4. D.Keyed signing with a locally generated public/private keypair.

Correct answer: D

Keyed signing only needs the private key to sign and the public key to verify — both can be generated and distributed entirely offline.

Question 2

Your policy repository contains a rule that is *supposed* to reject Pods without a team label. You want a CI job that fails the build if that rule ever stops rejecting them — for example, after someone refactors the match block. Which CLI command expresses that requirement, and why is the other one unsuitable?
  1. A.kyverno apply, because it exits non-zero whenever a resource fails a policy.
  2. B.kyverno test, because a test suite can assert that a specific resource must *fail* a specific rule, and reports an error when that expected failure stops happening.
  3. C.kubectl apply --dry-run=server, because only a real admission webhook can confirm a rule still works.
  4. D.Either command works identically; test is just an alias for apply with prettier output.

Correct answer: B

A kyverno-test.yaml suite declares an expected result (pass, fail, skip, or warn) per resource per rule. Declaring result: fail for the unlabelled Pod asserts "this rule must reject this resource" — so if a refactor breaks the match block and the rule silently stops firing, the expectation is no longer met and the suite fails. That is exactly the regression signal described.

Question 3

You write a rule intending to require every Pod to carry a team label, using this pattern: 
validate:
  pattern:
    labels:
      team: "?*"
After applying it, Pods with no team label are still created successfully with no rejection. What is the most likely cause?
  1. A.Label-based rules require a context entry to function.
  2. B.validationFailureAction must be explicitly set to Audit for label checks to work.
  3. C.The pattern is missing the metadata: wrapper — no Pod has a top-level labels field, so the pattern matches nothing and the rule silently never fires.
  4. D.?* is invalid Kyverno pattern syntax and the whole policy failed to load.

Correct answer: C

A validate.pattern block must mirror the real resource's structure exactly, starting from its root. labels only exists nested under metadata on a Pod — a pattern missing that wrapper checks a field path that does not exist anywhere on any Pod, so it trivially "matches" everything and the rule never rejects anything. This does not error at apply time; the policy shows Ready: True and appears to work while doing nothing.

Question 4

You want to know exactly what image bytes a running Pod actually pulled, independent of whatever tag was written in its spec. Which field do you check?
  1. A..spec.containers[0].image
  2. B..metadata.annotations.image
  3. C..status.containerStatuses[0].imageID
  4. D..status.containerStatuses[0].image

Correct answer: C

imageID is the only field that reports the digest the kubelet actually resolved and pulled. Both the spec and the status image fields simply echo whatever reference string (tag or digest) was written in the Pod spec.

Question 5

You have two Kyverno policies you want to ship together in one file for a GitOps pipeline to apply as a unit. What must separate the two ClusterPolicy documents inside that single YAML file?
  1. A.A blank line.
  2. B.A comment line starting with #---.
  3. C.A line containing only ---.
  4. D.Nothing; kubectl apply automatically detects document boundaries by kind.

Correct answer: C

A line containing only --- is the YAML multi-document separator. kubectl apply -f parses each document in the file separately and applies each in order.

Installation, Configuration, and Upgrades (5 questions)

Question 6

You're upgrading from an older Kyverno release straight to a much newer one, skipping several minor versions in between, including 1.10. What should you read before running the upgrade?
  1. A.The release notes for the target version AND every intermediate minor version you're skipping, since Kyverno 1.10 specifically introduced breaking changes that affect upgrades to it or beyond.
  2. B.Only the target version's release notes — intermediate versions don't matter once you're past them.
  3. C.Nothing — Helm upgrades are always backward-compatible by design.
  4. D.Only the Kyverno CLI changelog; Helm chart release notes are unrelated to controller behavior.

Correct answer: A

Kyverno's own docs flag 1.10 as introducing breaking changes that limit how upgrades to it, or past it, behave — a multi-version jump can silently walk through breaking changes you'd only catch by reading every intermediate version's notes, not just the final target's.

Question 7

You are upgrading Kyverno from an older to a newer chart version via helm upgrade --install kyverno kyverno/kyverno -n kyverno -f values.yaml. A colleague warns "Helm never upgrades CRDs, so you'll need to manually apply the new CRDs first." Is this accurate for Kyverno specifically?
  1. A.No — that folklore is about Helm's special crds/ directory convention specifically, which is install-only by design; Kyverno deliberately ships its CRDs as regular templated resources in a chart dependency gated by crds.install, so a normal helm upgrade does update them.
  2. B.Yes, but only when upgrading across a major version boundary; minor-version upgrades are exempt.
  3. C.Yes — this is universally true for every Helm chart including Kyverno's, with no exceptions.
  4. D.No, because Kyverno has no CRDs at all as of recent versions.

Correct answer: A

The "Helm never upgrades CRDs" rule of thumb refers specifically to Helm's dedicated crds/ directory feature, which by design is applied only on install, never on upgrade. Kyverno sidesteps this entirely by shipping its CRDs as ordinary templated Kubernetes manifests inside a chart dependency (controlled by crds.install), which Helm treats like any other template — rendered and applied on every helm upgrade, same as a Deployment or ConfigMap.

Question 8

You author a syntactically valid PolicyException on a fresh, default Kyverno install and apply it with kubectl apply -f. The exempted resource is still blocked exactly as before. What is the most likely cause?
  1. A.PolicyException is disabled by default; it must be turned on with --enablePolicyException=true on the admission controller, and the exception's namespace must also be listed in --exceptionNamespace.
  2. B.The object was applied to the wrong CRD version; PolicyException does not exist in Kyverno.
  3. C.PolicyException only works for mutate rules, never validate rules.
  4. D.PolicyException objects take up to 24 hours to propagate.

Correct answer: A

PolicyException evaluation is off by default. Two admission-controller flags gate it: --enablePolicyException=true turns the feature on at all, and --exceptionNamespace=<ns> restricts which namespace(s) are trusted to author an exception Kyverno will actually honor. An exception outside that allow-list is as inert as if the feature were off.

Question 9

Kyverno's default config.excludeGroups is ["system:serviceaccounts:kube-system", "system:nodes"]. You run helm upgrade --reuse-values -n kyverno kyverno kyverno/kyverno --set config.excludeGroups[0]=system:serviceaccounts:ci. What is the resulting effective value of config.excludeGroups?
  1. A.["system:serviceaccounts:kube-system", "system:nodes", "system:serviceaccounts:ci"] — Helm appends new list entries.
  2. B.["system:serviceaccounts:ci"] — the whole list was replaced with just the new single entry, silently dropping both defaults.
  3. C.The command fails outright, since Kyverno protects its default exclude groups from being overridden.
  4. D.["system:serviceaccounts:ci", "system:nodes"] — only index 0 is replaced, the rest of the list is preserved.

Correct answer: B

Helm treats a list-valued override as a full replacement of that list, not a merge or a per-index patch. Setting excludeGroups[0] to a single new value replaces the entire excludeGroups array with ["system:serviceaccounts:ci"], silently dropping the built-in defaults.

Question 10

Your cluster runs a ClusterPolicy named require-owner-label that blocks any Deployment missing an owner label. You need to admit exactly one specific, already-approved Deployment named legacy-app without loosening the policy for anyone else, and without touching the policy itself. Which Kyverno CRD is designed for this?
  1. A.CleanupPolicy, since it can exclude resources from other policies.
  2. B.PolicyException (kyverno.io/v2) — a namespaced resource that exempts a specific match from a named policy's named rule(s), and which must be explicitly enabled on the admission controller before it has any effect.
  3. C.A second ClusterPolicy with validationFailureAction: Audit that overrides the first.
  4. D.GlobalContextEntry, since it can override policy evaluation results.

Correct answer: B

PolicyException is purpose-built for exactly this — a narrow, auditable carve-out for a specific resource from a specific policy's specific rule(s), leaving the policy itself, and its effect on everything else, untouched. It is disabled by default and only takes effect once the admission controller is started with --enablePolicyException=true and an --exceptionNamespace covering where the exception lives.

Kyverno CLI (4 questions)

Question 11

You run kyverno completion bash > /etc/bash_completion.d/kyverno after installing the CLI. What does this accomplish?
  1. A.It generates a shell completion script so <TAB> will suggest subcommands and flags for the kyverno command.
  2. B.It upgrades the CLI to the latest version automatically.
  3. C.It installs the kubectl kyverno plugin form in addition to the standalone binary.
  4. D.It verifies the CLI's checksum against the official release.

Correct answer: A

completion is a standard Cobra-CLI subcommand that emits a shell script teaching your shell's completion system about kyverno's subcommands and flags — a pure quality-of-life feature with no effect on the binary itself.

Question 12

A CI pipeline runs kyverno apply policy.yaml --resource ./manifests/ ; echo "step finished" and always reports success, even when a manifest clearly violates the policy. What is the most likely cause?
  1. A.The pipeline step's shell is discarding kyverno apply's exit status (for example, by unconditionally running a following command with ; instead of checking $?), so a real fail/error result never breaks the build.
  2. B.--resource pointed at a directory instead of individual files, which silently disables failure reporting.
  3. C.kyverno apply never returns a non-zero exit code, regardless of results.
  4. D.The policy needs --warn-exit-code set before failures can affect the exit code at all.

Correct answer: A

kyverno apply does exit non-zero when any resource fails or errors — that's what makes it usable as a CI gate. But cmd1 ; cmd2 always runs cmd2 regardless of cmd1's exit status, and if nothing downstream inspects $?, the pipeline step's own final exit code reflects echo, not kyverno apply. The fix is to let the failing command's exit code propagate (e.g. run it as its own step, or use && and check $? explicitly).

Question 13

A colleague writes a Kyverno ClusterPolicy preconditions block using label_match(requiredSelector, request.object.metadata.labels), but the rule isn't behaving as expected once deployed to the cluster. What is the fastest way to isolate whether the problem is the JMESPath expression itself, versus something else in the policy (webhook config, match scoping, and so on)?
  1. A.Add background: true to the rule and wait for the next scheduled scan.
  2. B.Delete and recreate the ClusterPolicy repeatedly until it happens to work.
  3. C.Increase the Kyverno controller's log verbosity and hope the JMESPath evaluation is logged verbatim. </details>
  4. D.Extract the real requiredSelector and metadata.labels values into a small JSON file and run the same label_match(...) expression offline with kyverno jp query, entirely outside the cluster and the admission path.

Correct answer: D

kyverno jp query lets you evaluate the exact same expression and Kyverno custom function against representative data completely offline, isolating whether the *expression itself* is wrong before you ever involve the cluster, the webhook pipeline, or match/exclude scoping — a much faster and more precise debugging loop than iterating against a live admission request.

Question 14

You need to pin an exact Kyverno CLI version in a CI pipeline's setup step, on a Linux x86_64 runner, without relying on a package manager being preinstalled. Which approach is most appropriate?
  1. A.kubectl krew install kyverno, since Krew is guaranteed to be preinstalled on CI runners.
  2. B.brew install kyverno, since Homebrew ships with every Linux distribution by default.
  3. C.Download the exact kyverno-cli_v{VERSION}_linux_x86_64.tar.gz release asset with curl, extract it, and place the binary on PATH.
  4. D.go install github.com/kyverno/kyverno/cmd/cli/kubectl-kyverno@latest, since @latest always resolves to a reproducible, pinned version.

Correct answer: C

Downloading the exact versioned release tarball via curl has no external dependency beyond curl and tar (both near-universal on CI runners), and pins an exact, reproducible version — exactly what a CI setup step needs.

Applying Policies (3 questions)

Question 15

You want a validate rule to run when a Pod is first created, but explicitly NOT re-run when that same Pod is later updated (for example, by a status patch). What should you set?
  1. A.validationFailureAction: Audit instead of Enforce.
  2. B.operations: [CREATE] in the rule's match block.
  3. C.background: false on the rule.
  4. D.exclude.any.resources.operations: [UPDATE, DELETE].

Correct answer: B

operations in the match block restricts which admission verbs a rule evaluates. Setting it to [CREATE] means only brand-new Pods are checked at admission time; subsequent UPDATE requests to the same object never re-trigger the rule.

Question 16

A rule sets both namespaceSelector: {matchLabels: {env: prod}} and objectSelector: {matchLabels: {tier: frontend}} inside the same resources block, matching kinds: [Pod]. A Pod is labeled tier: frontend and created in a namespace labeled env: dev. Does the rule evaluate this Pod?
  1. A.Yes, because objectSelector always takes priority over namespaceSelector when both are present.
  2. B.Yes — objectSelector matching is sufficient on its own regardless of namespaceSelector.
  3. C.No — both selectors sit inside the same resources block and are ANDed together; the namespace's env: dev label fails the namespaceSelector condition, so the rule does not evaluate this Pod even though its own labels match objectSelector.
  4. D.No, because namespaceSelector and objectSelector cannot legally coexist in the same resources block.

Correct answer: C

Fields inside one resources block are implicitly ANDed. objectSelector checks the Pod's own labels (satisfied here), while namespaceSelector checks the Namespace object's labels (not satisfied — the namespace is env: dev, not env: prod). Since both must hold, the rule does not evaluate this Pod.

Question 17

A newly-applied ClusterPolicy has validationFailureAction: Audit. A Pod violating its rule is created. What happens immediately?
  1. A.The Pod is automatically mutated into compliance.
  2. B.The Pod is rejected outright.
  3. C.The Pod is admitted normally, and the violation is recorded in a PolicyReport/ClusterPolicyReport — nothing is blocked.
  4. D.The Pod is admitted, then deleted seconds later by the background controller.

Correct answer: C

Audit admits and records — that is the entire mechanism.

Policy Management (3 questions)

Question 18

A ClusterPolicy is applied with spec.background: false, and a Deployment that existed before it violates one of its rules. What appears in the reports?
  1. A.An error entry, because the rule cannot be evaluated outside admission.
  2. B.A fail entry once the next background scan runs.
  3. C.Nothing for that pre-existing Deployment, ever — spec.background: false means the policy is only evaluated at admission time.
  4. D.A skip entry, recording that background evaluation was disabled.

Correct answer: C

background is a policy-level field (spec.background, default true). Setting it to false opts the whole policy out of periodic re-scanning. The pre-existing resource generates no admission request, and the background scan will not look at it, so no result entry is ever produced for that pairing. This is by design and is the correct setting for a policy whose rules inspect request-specific context such as request.userInfo.

Question 19

A ClusterPolicy reports a violation on a PersistentVolume. Which report object holds it?
  1. A.A ClusterPolicyReport, because PersistentVolume is cluster-scoped.
  2. B.A PolicyReport in the namespace of the Pod using the volume.
  3. C.A PolicyReport in the kyverno namespace.
  4. D.Neither; cluster-scoped resources are not reported on.

Correct answer: A

The report kind follows the scope of the *reported resource*, never the policy. A cluster-scoped resource's findings go into ClusterPolicyReport (cpolr).

Question 20

Which Service and port do you scrape for Kyverno's admission controller metrics?
  1. A.kyverno-svc-metrics on 8000, path /metrics.
  2. B.kyverno-admission-controller-metrics on 8000.
  3. C.kyverno-svc on 443.
  4. D.kyverno-reports-controller-metrics on 8000.

Correct answer: A

All four controllers serve metrics on 8000 at /metrics, and the admission controller's metrics Service is named after its main Service (kyverno-svc), not after its Deployment.

Score yourself

The Linux Foundation lists a passing score of 75% for KCA. On a set of 20 questions that is 15 correct. Reaching 15 here is a useful signal and not a prediction: 20 questions is a small sample, and the real exam covers every domain in its published weights. Use the table below to decide what to do next. Count only the questions you answered correctly without help, and be strict about it: a question you got right for the wrong reason belongs in the missed pile. Then repeat the exercise a few days later with a different set from the full bank so that you are measuring understanding and not memory of these specific questions.

Count your misses per domain, using the headings above. One missed question in a domain is noise; three misses in one domain is a study plan. The practice mode on GoldenKube does this sorting for you by sending you back to the domains where you are weakest.

Correct out of 20What it suggestsWhat to do next
18 to 20The basics are solid in the domains sampled.Move to harder mixed practice and check the domains this set did not cover.
15 to 17Close to the benchmark, with some gaps.Review every missed explanation, then practise the domains where you missed questions.
11 to 14Several domains need real study.Read the official curriculum for those domains, then return to practice.
0 to 10You are early in your preparation.Start from the curriculum and the project documentation, then retry this set.

Fundamentals of Kyverno: what it tests

Fundamentals of Kyverno covers what Kyverno is and how its policies work. Expect Kyverno as a policy engine that runs as a Kubernetes admission controller, policies and cluster policies, the rule types for validating, mutating, generating and verifying images, how a policy matches resources, background scanning of existing resources, and policy reports. Questions ask which rule type or scope fits a goal. A typical trap is confusing validation with mutation: a validate rule allows or denies a request, while a mutate rule changes it, and the exam may describe a requirement that sounds like one but needs the other. Questions here are mostly about choosing correctly among a small number of concepts.

Write one example requirement for each rule type, such as block, default, create and sign check. Matching a stated need to a rule type is the core skill here.

Installation, Configuration, and Upgrades: what it tests

Installation, Configuration, and Upgrades covers running Kyverno in a cluster. Expect installation with Helm or manifests, the separate controllers and why a high availability setup runs several replicas, the webhooks that connect Kyverno to the API server and their failure behaviour, resource filters, permissions that Kyverno needs, and upgrade considerations. Questions ask how to install, which setting changes a behaviour, or what happens when Kyverno is unavailable. The trap is failure policy: whether requests are admitted or blocked when the webhook cannot be reached is a deliberate setting with real consequences for cluster availability. Questions often describe an outage or a blocked deployment and ask which configuration decision explains it, so know the safe default and the trade-off for each setting.

Read through the installation options and list the three settings that most change safety or availability. Those are the ones scenario questions revolve around.

Kyverno CLI: what it tests

Kyverno CLI covers using Kyverno outside the cluster. Expect applying policies to resource files to see the result, running a test suite of expected outcomes, evaluating JMESPath expressions, and using the CLI in a CI pipeline so that bad configuration is caught before it reaches the cluster. Questions ask which command achieves a task or what a test file declares. A common trap is thinking the CLI needs a running cluster: it can evaluate policies against files, which is the reason it is useful in pre-merge checks. Remember which command applies, which tests and which evaluates an expression. Questions usually give a goal, such as checking a policy in a pipeline, and ask which subcommand fits it.

Practise the three CLI jobs on one policy and one resource: apply it, write a test for it, and evaluate a small expression. The commands then stay distinct.

Applying Policies: what it tests

Applying Policies covers how a written policy takes effect. Expect the choice between audit and enforce behaviour, match and exclude blocks to select resources, preconditions that skip rules, policy exceptions for justified cases, and how results appear in policy reports. Questions describe an outcome, such as a resource that was admitted although a policy exists, and ask why. The trap is a policy that is in audit mode, which records violations without blocking anything, so a violation in a report does not mean the request was denied. Reading match and exclude together is also a frequent source of errors. Check the mode, the match and any exclusions in that order, because the cause is almost always one of the three.

Take one policy and change only the mode, then only the match, and predict the effect on three example resources each time. The predictions are the questions.

Writing Policies: what it tests

Writing Policies is the largest KCA domain. Expect the structure of a policy and its rules, patterns and anchors for validation, strategic merge and JSON patches for mutation, generate rules that create resources, variables and the context that brings in external data, JMESPath expressions, loops over lists, and verifying image signatures. Questions show a policy and ask what it does or ask which fragment completes it. Traps include the exact meaning of anchors, how a variable is referenced, and the difference between a pattern that must match and a deny condition that must not. Precise syntax matters here more than in any other domain.

Write one validate, one mutate and one generate policy from a blank file and test each against a sample resource. Syntax sticks only when you type it.

Important for this page: none of the 20 sample questions comes from Writing Policies, even though it is 32% of the published weights. The GoldenKube KCA bank does not have any questions labelled for this domain yet, so the set cannot cover it. Do not read a good score here as evidence that you are ready for the largest domain.

Policy Management: what it tests

Policy Management covers living with policies over time. Expect policy reports and how to read them, handling exceptions, rolling out new policies safely by starting in audit mode, keeping policies in Git, testing before release, and monitoring the engine itself. Questions describe a rollout or an incident and ask for the safest next step. The trap is the order of actions: introducing a strict policy directly in enforce mode can block deployments, so the safer path is audit first, review the reports, fix or except the findings and only then enforce. The domain is small, with questions that are mostly judgement.

Write a four-step rollout plan for a new policy and note what you check between steps. The exam asks for exactly that kind of ordering.

What a 20-question KCA sample can and cannot tell you

A set of 20 questions is a screening test, not a measurement. With only a few questions per domain, one lucky guess or one unlucky wording moves your result by five percentage points, and a domain with only two questions behind it says almost nothing about that domain's true strength. The set is also fixed, so after one read-through it measures your memory of these items and not your command of KCA. Use it to choose where to start studying, not to decide whether you are ready, and then rely on the larger bank, where questions repeat only after a gap and the app tracks which domains stay weak.

A second limit is style. Written practice questions share one author voice, while a real exam draws on many writers and reads differently. Treat any practice score, here or elsewhere, as one input next to the official curriculum, hands-on experience with the technology, and the documentation of the project itself.

A one-week plan after the KCA sample set

After the sample set, spend a week turning the result into a plan. Start with the domains where you missed questions and read the matching part of the official curriculum before you try more questions, because practice is far more useful once you can explain the topic. Return to practice in short daily sessions, review every missed question the next day, and leave the last day for a fresh mixed set. Keep a simple note of which concepts caused misses; the same three or four ideas usually explain most of them, and naming them is what turns practice into progress.

The largest KCA domain is Writing Policies, at 32% of the published weights. If two domains tie for weakest in your tally, start with the heavier one, and keep the other 5 domains ticking over with short reviews.

Adjust the pace to your calendar. If you have more time, spread the same steps over two or three weeks and add a second mixed session at the end of each week. If you have less, keep days 1 to 3 and day 6 and accept a rougher picture. What matters is that every study session starts from a specific weak domain and ends with a check, not that the plan is followed to the letter.

DayTask
1Tally misses per domain and rank the domains from weakest to strongest.
2Read the official curriculum and documentation for the weakest domain.
3Practise that domain in the app and read every explanation.
4Repeat the exercise for the second weakest domain.
5Review the questions you missed on days 3 and 4 without looking at notes.
6Do a mixed session across all domains and compare the result with this page.
7Rest, then retake the 20 questions on this page and note which misses persist.

Practice the full KCA bank

These 20 questions are a small slice of the GoldenKube KCA bank, which holds more than 300 questions. In practice mode the app serves the questions you are due to review first, then the domain where you are weakest, and it brings missed questions back after a gap until you answer them correctly. You can answer 10 questions as a guest without an account; after that a free account keeps your progress, and no credit card is asked for at any point. Each answer comes with the same kind of written explanation you saw on this page, so a wrong answer is always followed by the reasoning that fixes it.

Practice mode shows one question at a time and gives the verdict and explanation as soon as you answer. A focus option lets you stay inside a single domain until it feels solid, which is the natural next step after finding your weakest domain on this page. There is no timer and no exam simulation in practice mode; the goal is learning, not performance under pressure.

Practice KCA

Frequently asked questions

Are these the real KCA exam questions?

No. They are practice questions written for GoldenKube to cover the published KCA domains. GoldenKube does not have the real exam, does not claim any overlap with it, and does not sell or share exam content. Use them to find gaps in your understanding, not to predict what you will be asked.

How many KCA questions does GoldenKube have?

The KCA bank holds more than 300 questions as of 2026-10-23. This page shows 20 of them. The full bank is available in practice mode, where the app chooses what to show you next based on what you have already answered and what you got wrong.

Do the answers come with explanations?

Yes. Every question on this page has the correct answer marked and a written explanation of why it is correct and, where useful, why the other options are not. Only questions that have an explanation are published on public pages, and where a question carries references they are listed under the explanation.

Is this free?

Yes. Reading this page needs no account. In the practice app you can answer 10 questions as a guest, and then you create a free account to continue. No credit card is requested at any point.

How were these 20 questions chosen?

A script picks them with a fixed seed, so the set does not change between visits. It considers only questions that have a written explanation and tries to follow the published domain weights. The domain labels in the bank do not always match the official wording, so a domain can be thinly represented in a single set of 20; the full bank is the better measure of coverage. The KCA bank currently has no questions for the Writing Policies domain, so this set contains none from it.

How often is this page updated?

The exam facts and the domain list were last checked against the Linux Foundation pages on 2026-10-23, and the page shows its update date at the top. When the curriculum changes or questions are added, corrected or removed in the bank, the page is reviewed again.

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