KCNA Study Plan & Practice Bank

Correct: A. kube-apiserver is the only component with direct etcd access — it validates and persists every object, and it is the front door everything else goes through. (B) and (C) both invent direct etcd access for components that in fact only read and write objects via the API server, never touching etcd itself. (D) is doubly wrong: kubelet runs on nodes and talks to the API server, and it has no relationship with etcd at all, local copy or otherwise.

Correct: D. kube-scheduler watches for Pods with no assigned node, evaluates requests, taints and affinity rules, and binds the Pod to a node. (A) runs reconciliation loops for objects like Deployments and Nodes, but binding a Pod to a node is not one of them. (B) only takes over once a node has already been chosen — kubelet runs the Pod, it doesn't pick where. (C) programs Service routing rules on nodes, entirely unrelated to scheduling decisions.

Correct: A. A Job creates Pods and tracks successful completions, retrying a failed Pod until it succeeds, and does not keep the workload alive once that completion count is reached. (B) maintains a steady desired replica count indefinitely — the opposite of "run once and stop." (C) runs one Pod per matching node continuously; it has no notion of a finite task at all. (D) manages Pods with stable identity and storage for long-running stateful applications, not a single finite script.

Correct: C. A DaemonSet's controller automatically schedules one copy onto every node that matches (or all nodes, by default) — including any node added afterward, with no manual recount needed. (A) is a fixed number that doesn't grow when nodes are added and has no built-in guarantee of one-per-node placement. (B) might approximate the spread with enough tuning, but has no built-in guarantee of matching the node count exactly, and doesn't auto-adjust as nodes join. (D) runs a task to completion on a schedule — it's not a continuously running one-per-node agent at all.

Correct: D. Kernel sharing is the actual mechanism — no guest OS to boot, no hypervisor layer to cross for most operations. (A) is a downstream effect at best, not the reason, and isn't even reliably true. (B) overreaches with "always" — containers commonly run inside VMs too, that's not a defining trait. (C) is simply false: containers absolutely use a filesystem, typically a layered, union-style one built from image layers.

Correct: A. The OCI Image Spec and Runtime Spec define how images are packaged and layered, and how a compliant runtime must run them — the reason an image built with one tool runs correctly under containerd, CRI-O, or any other compliant runtime. (B) describes the Kubernetes API's own schema, a completely separate standard the OCI has nothing to do with. (C) names a concern the OCI specs never address. (D) is an adjacent-tool distractor — Helm and Kustomize's YAML conventions aren't OCI's concern, even though OCI registries can happen to store Helm charts.

Correct: C. Requests drive scheduling decisions; limits are enforced at runtime by the kernel, and a container that exceeds its memory limit is killed with an OOM reason. (B) is the same two facts with the roles swapped — a classic "right idea, wrong direction" trap worth watching for on any requests-vs-limits question. (A) denies there's any real difference, which contradicts the entire point of setting both. (D) is false — limits absolutely are enforced; a Pod exceeding its memory limit does not keep running.

Correct: B. A failing liveness probe gets the container killed and restarted by the kubelet, subject to the Pod's restart policy. (C) correctly describes what happens on a failing readiness probe instead — the right mechanism, attached to the wrong probe, which is exactly the distinction this question is testing. (A) is false; liveness failures clearly do trigger an action. (D) is unrelated — cordoning is a manual, node-level admin action, not something a per-Pod probe result ever triggers.

Correct: A. A toleration only cancels out one specific taint's repelling effect for that Pod — it doesn't attract or pin the Pod there. Without an explicit affinity or nodeSelector naming gpu-1, the scheduler is free to place the tolerating Pod on gpu-1 or on any ordinary untainted node. (B) overclaims exclusivity that nothing in the setup creates. (C) is false — tolerating a taint is exactly what makes scheduling onto that node possible; nothing here blocks scheduling elsewhere either. (D) overreaches — a toleration addresses one specific taint, not "all other scheduling constraints."

Correct: D. Namespaces are primarily a naming and scoping mechanism — the same object name can exist in two namespaces without colliding, and a Role/RoleBinding scopes its grant to one namespace. (A) is a common misconception: by default, without a NetworkPolicy, Pod-to-Pod traffic crosses namespace boundaries freely. (B) requires a separate ResourceQuota object you must create yourself — a namespace carries no quota on its own. (C) invents a scheduling guarantee that doesn't exist; namespace has nothing to do with which node a Pod lands on.

Correct: C. The Kubernetes networking model requires flat, NAT-less Pod-to-Pod connectivity — every Pod gets a real IP, and Pods see each other's actual address regardless of which node they're on. (A) and (D) both invent a required detour through objects (a NodePort Service, an Ingress controller) that exist for external-facing traffic, not baseline Pod-to-Pod reachability. (B) describes a restriction that only exists once you deliberately add a NetworkPolicy — it isn't the default.

Correct: B. ClusterIP, the default Service type, is cluster-internal only and gets a stable virtual IP plus a DNS name — exactly the requirement, with nothing extra to configure. (A) and (C) both open an external access path (a cloud load balancer, or a port opened on every node) — over-provisioning for something that should stay internal. (D) solves a different problem entirely: pointing a Service at an external DNS name, not exposing an internal backend.

Correct: D. NetworkPolicy is additive and directional — a policy only restricts the directions actually listed in its policyTypes. With no Egress entry and no egress rule, egress for those Pods stays exactly as it was before: the cluster-wide default, unless something else already restricts it. (A) is the single most common misconception about NetworkPolicy — one policy touching a Pod does not silently lock down every unlisted direction, only the directions it names. (B) is false; nothing restricted egress before this policy existed. (C) invents an egress restriction that was never configured in the stem.

Correct: A. Only a ClusterRole bound with a ClusterRoleBinding grants a permission that applies across the whole cluster. (B) is namespaced end to end — a Role can never reach outside the namespace it lives in, no matter what binds it. (C) is a real, valid combination — but it scopes the ClusterRole's permissions down to the RoleBinding's own single namespace, which is exactly what makes it a strong "true, but not what was asked" distractor here, not a cluster-wide grant. (D) isn't a valid combination at all — a ClusterRoleBinding may only reference a ClusterRole, never a namespaced Role.

Correct: C. Base64 is an encoding, not encryption — anyone with read access to etcd or the API can trivially decode it. Real protection at rest requires enabling an encryption provider at the API server, or reaching for an external secrets manager. (A) is a fabrication; no such automatic key rotation happens by default. (B) would make the value unreadable even to Kubernetes itself, which is not how Secrets behave — hashing is one-way and Secrets need to be recoverable. (D) is false; Secrets are stored in etcd exactly like any other object, not held only in node memory.

Correct: D. ReadWriteOnce restricts the volume to a single node mounting it read-write at a time — a second Pod on a different node cannot also mount it. (A) misstates the entire restriction the access mode exists to express. (B) invents a silent read-only fallback that RWO does not provide. (C) invents automatic cloning behavior Kubernetes does not perform on its own.

Correct: B. ImagePullBackOff is specifically an image-retrieval failure — the image name, tag, or registry credentials are the usual culprits. (A) describes CrashLoopBackOff instead, a distinct and easily confused status covering a container that starts and exits repeatedly. (C) describes OOMKilled, a container-terminated reason, unrelated to pulling an image. (D) describes an unschedulable Pod stuck in the Pending phase — a Pod that can't even get a node assigned wouldn't be showing a container-level status like ImagePullBackOff at all.

Correct: C. Storing manifests in Git is necessary but not sufficient — the defining mechanism is a pull-based, continuously reconciling in-cluster controller, which is exactly what catches a hand-made change days after it happens. (A) and (B) both fall for the same oversimplification: "manifests live in Git" is not the same claim as "GitOps." Team A's push-based, once-per-merge apply is common CI/CD, but a manual change would silently survive until the next merge. (D) invents a manual-review requirement that isn't part of the definition; some teams choose that as policy, but it isn't what makes something GitOps.

Correct: B. Canary describes exactly this: a small, deliberately controlled percentage of traffic routed to the new version, observed, then gradually increased. (A) replaces old Pods with new ones incrementally, but without percentage-based traffic splitting or an observation window tied to a specific traffic share. (C) keeps two full parallel environments and switches all traffic at once — no gradual ramp at all. (D) simply terminates the old Pods before starting new ones, with a gap and zero traffic control.

Correct: D. Kustomize's entire model is templating-free — it patches real, valid YAML through overlays layered on a base, and ships natively inside kubectl. (A) is the first tool the stem describes — templated charts with a package and release model — offered here as the tempting "I recognized a packaging tool" pick for the wrong description. (B) is a GitOps delivery controller, not a manifest-packaging tool at all. (C) is a container runtime, unrelated to manifest packaging entirely.

Correct: A. describe surfaces the Events feed — image pull failures, scheduling failures, failed probes, volume mount errors — even when the container itself never manages to log anything. (B) is a fix for a bad rollout, not a diagnostic step, and it rolls back before you even know what's wrong. (C) only reports live resource usage of a running container, which is useless for one that never starts. (D) stops the symptom but destroys the very Pod you needed to inspect, and gives back no diagnostic information at all.

Correct: B. The four golden signals are latency, traffic, errors, and saturation — how "full" a resource or service is. (A) and (D) are both real, related observability ideas — throughput especially sounds like a rewording of traffic — but neither is the specific fourth signal in this named framework. (C) is a real FinOps concern with nothing to do with this particular list.

Correct: B. The CNCF's three maturity levels, in order, are Sandbox (the earliest, minimal bar to entry), Incubating (adoption and process requirements), and Graduated (the highest bar — broad adoption, strong governance, a security audit, and more). (A) and (C) both misorder the same three real levels. (D) invents level names — "Proposed" and "Stable" are not the CNCF's actual terminology.

Correct: C. Distributed tracing exists specifically to show one request's full path across services with per-hop timing — precisely the "which service, in what order" question in the stem. (A) is an aggregated number over a time window — good for spotting that latency rose, useless for isolating which single request or service caused it. (B) is a discrete per-service record; correlating logs across seven services into one request's path is possible but is not what logs are purpose-built for, unlike a trace's request-scoped model. (D) records cluster state changes like scheduling — an infrastructure-level concept, not an application-request observability signal at all.

1. Kubernetes Fundamentals 44%; Container Orchestration 28%; Cloud Native Application Delivery 16%; Cloud Native Architecture 12% — summing to exactly 100%.
2. Because it's nearly half the exam on its own — larger than the other three domains combined minus one point — and it's the domain candidates most often over-rate themselves in, since every sentence in it sounds familiar even when a specific distinction (Job vs. CronJob, request vs. limit) isn't actually solid.
3. A failing readiness probe removes the Pod from Service endpoints but leaves the container running, un-restarted; a failing liveness probe gets the container killed and restarted by the kubelet.
4. Because GitOps' defining trait is a pull-based, continuously reconciling in-cluster agent, not merely that manifests live in Git. A push-based CI job only reconciles once per merge, so a hand-made change made outside a merge (a manual kubectl scale, for example) would silently survive until the next one — exactly the drift a true GitOps controller catches continuously instead.
5. ClusterRole and ClusterRoleBinding. A Role is namespaced no matter what binds it, so Role plus RoleBinding can never reach outside its own namespace — and a ClusterRoleBinding can't even reference a Role at all, only a ClusterRole.
6. 75% — stated directly in the Linux Foundation's Multiple Choice Exam FAQ as the passing score for its multiple-choice exams generally, KCNA included.
7. Any two from the readiness checklist — e.g. explaining every control-plane component in one sentence each without checking a page first; scoring comfortably above target on a cold re-attempt of the 24-question bank above; having sat and reviewed at least one full mock exam.