KCNA Mock Exam · Set 1 — 50 questions, one clock, four domains

This is a full KCNA-format sitting: 50 multiple-choice questions, weighted 22 / 14 / 8 / 6 to match the real exam's four official domains — Kubernetes Fundamentals, Container Orchestration, Cloud Native Application Delivery, and Cloud Native Architecture — against one unbroken 90-minute block, closed-book, exactly like the real sitting. Unlike this course's CKA and CKAD mocks, there is no cluster here to build or break: KCNA is knowledge-based, so every question below tests whether you hold the right mental model, not whether you can type fast enough to fix one. Work straight through without opening a second tab, then check every answer against the explanation folded behind each domain's answer key — the explanation is the actual lesson, not the letter you happened to pick. If any domain still feels shaky going in, read the KCNA blueprint and the study plan & practice bank first; this paper measures recall under a clock, not first exposure to the material.

How this paper is built, and where it fits your prep

☺ Like you're 10: This isn't your only rep — it's stop two in a four-stop loop: learn, sit, fix, sit again.

KCNA has no performance-based tier to build toward, so the loop is shorter than the CKA's, but it's still a loop, not a single event. Sit this paper cold, mark yourself honestly by domain, go fix exactly the gaps it found, then confirm the fix with a second, fresh paper before you spend the exam fee.

Exam conditions for this sitting

☺ Like you're 10: One clock, closed book, and no peeking at what's behind the curtain until you've actually chosen an answer.

One timer, started once. 90 minutes. That is the real KCNA's published duration, confirmed on the Linux Foundation's own Multiple Choice Exam FAQ, and this paper uses the same clock even though its question count is a teaching choice rather than a leak. Closed-book — no reference material at all. This is the one place KCNA's conditions diverge sharply from this course's CKA and CKAD mocks: those performance-based exams open a documentation tab inside the exam environment; KCNA does not. Close every tab except this one. Answer every question once, in order; multiple choice carries no time cost to revisiting a question you've flagged, so mark uncertain ones and return if the clock allows, but never leave one blank on a guess-penalty-free exam. No peeking at an answer key before you've committed — reading the answer first turns a diagnostic paper into a comprehension exercise, and you will not get that data back.

How the 50 questions are weighted

☺ Like you're 10: The questions are shared out exactly the way the real exam shares out its marks — the biggest topic gets the most questions, down to the last one.

The four official weights — 44, 28, 16, and 12 — sum to exactly 100%, straight from the CNCF's own KCNA curriculum, and every one of them is a multiple of 4. That's why 50 questions works so cleanly: 44% of 50 is 22.0, 28% is 14.0, 16% is 8.0, and 12% is 6.0 — four whole numbers, no rounding decisions to make anywhere, summing to exactly 50. Kubernetes Fundamentals alone is 22 of the 50 questions — nearly half the paper — and adding Container Orchestration's 14 means 72% of this exam is "do you understand Kubernetes itself?" The two cloud-native-flavoured domains, worth 28% between them, are the ones candidates chronically under-read because they feel like general-knowledge reading rather than hands-on studying — which is exactly backwards, since Cloud Native Architecture's 12% includes some of the most memorizable, least-changing facts on the whole paper.

🦉 Domain 1 — Kubernetes Fundamentals (44% · Q1–22)

☺ Like you're 10: This domain is the clubhouse itself — who's in charge of what, which rooms exist, and the rules for getting a chore actually done.

Fundamentals covers four official competencies: Kubernetes Core Concepts (Q1–9), Administration (Q10–14), Scheduling (Q15–19), and Containerization (Q20–22). This is the domain where the control-plane/node split and the API-object-plus-controller pattern do almost all the work — understand those once and the rest of this domain, and a good chunk of the other three, gets easier together. If any of the objects below are unfamiliar, the KCNA blueprint and Kubernetes Architecture cover every one of them at teaching depth.

apiVersion: apps/v1
kind: Deployment                 # manages a ReplicaSet, which manages Pods
metadata: { name: checkout, namespace: shop }
spec:
  replicas: 3
  selector:
    matchLabels: { app: checkout }        # must match the Pod template's labels
  template:
    metadata:
      labels: { app: checkout }
    spec:
      containers:
        - name: app
          image: ghcr.io/acme/checkout:1.4.3   # immutable tag, never "latest"
          resources:
            requests: { cpu: "100m", memory: "128Mi" }   # the SCHEDULER reserves this
            limits:   { cpu: "500m", memory: "256Mi" }   # the KERNEL enforces this
---
apiVersion: v1
kind: Service                    # a stable virtual IP + DNS name for those Pods
metadata: { name: checkout, namespace: shop }
spec:
  selector: { app: checkout }    # finds Pods by LABEL, never by name
  ports: [ { port: 80, targetPort: 8080 } ]

1. Which control-plane component is the only one that communicates directly with etcd?

   1. kubelet
   2. kube-scheduler
   3. kube-apiserver
   4. kube-controller-manager

2. What does etcd actually store?

   1. Container image layers
   2. The cluster's entire desired and observed state
   3. Pod stdout/stderr logs
   4. Node kernel modules

3. Which component decides which node a newly created Pod should run on?

   1. kubelet
   2. kube-scheduler
   3. kube-proxy
   4. kube-controller-manager

4. What is the primary job of kube-controller-manager?

   1. Enforce NetworkPolicy rules on the wire
   2. Run the built-in reconciliation control loops that drive observed state toward desired state
   3. Store the cluster's Secrets
   4. Route Service traffic between Pods

5. Which node-level agent watches the API server for Pods assigned to its own node and makes sure their containers are actually running?

   1. kube-proxy
   2. kubelet
   3. A container runtime acting alone, with no Kubernetes agent involved
   4. kube-scheduler

6. A Deployment creates and manages which intermediate object to actually maintain the requested number of running Pods?

   1. A StatefulSet
   2. A DaemonSet
   3. A ReplicaSet
   4. A Job

7. Which workload object guarantees exactly one Pod replica runs on every matching node in the cluster — the typical shape for a log collector or node-level agent?

   1. Deployment
   2. StatefulSet
   3. DaemonSet
   4. Job

8. Which workload object is the right choice for a Pod that needs a stable, unique network identity and persistent storage that follows it across rescheduling — for example, one replica of a database?

   1. Deployment
   2. StatefulSet
   3. DaemonSet
   4. ReplicaSet

9. What distinguishes a CronJob from a plain Job?

   1. A CronJob can only ever run once
   2. A CronJob creates new Jobs on a repeating schedule expressed in cron syntax
   3. A CronJob never creates any Pods
   4. A CronJob cannot be namespaced

10. What is the key practical difference between kubectl apply -f and kubectl create -f?

    1. apply only works on Deployments
    2. apply is declarative and updates an existing object to match the file; create is imperative and fails if the object already exists
    3. create supports YAML while apply only supports JSON
    4. There is no practical difference

11. In RBAC, what is the difference between a Role and a ClusterRole?

    1. A Role can only grant read access; a ClusterRole can grant write access
    2. A Role's permissions are scoped to a single Namespace; a ClusterRole's permissions are cluster-wide
    3. ClusterRole is a deprecated alias for Role
    4. There is no difference — they're interchangeable names for the same object

12. A Role exists in a namespace but has no RoleBinding pointing at it. What access does it grant?

    1. Full access to that namespace
    2. Read-only access to everything in that namespace
    3. Nothing at all — a Role only takes effect once bound to a subject
    4. Access to every namespace in the cluster

13. Which kubeconfig concept lets you store and switch between multiple clusters, users, and default namespaces from a single config file?

    1. Profiles
    2. Contexts
    3. Sessions
    4. Realms

14. Which of these four is namespace-scoped, unlike the other three?

    1. Node
    2. PersistentVolume
    3. ConfigMap
    4. ClusterRole

15. What is the practical difference between a Pod container's resources.requests and its resources.limits?

    1. They're identical fields; limits is a legacy alias
    2. requests is what the scheduler reserves when choosing a node; limits is the ceiling the kernel enforces at runtime
    3. requests applies only to memory; limits applies only to CPU
    4. requests is purely cosmetic and never enforced

16. A Pod defines a toleration matching a taint on Node X. What does that guarantee?

    1. The Pod will be scheduled onto Node X
    2. The Pod becomes eligible for Node X, but the scheduler could still place it anywhere untainted
    3. Node X is now untainted for every other Pod too
    4. The toleration permanently removes the taint

17. A container exceeds the limits.memory set on it. What happens?

    1. Nothing — limits are advisory only
    2. The container is throttled but keeps running indefinitely
    3. The container is terminated by the kernel with an OOMKilled reason
    4. The entire node is cordoned automatically

18. What is the simplest way to constrain a Pod to nodes carrying one specific label, with no set-based logic involved?

    1. A taint
    2. A nodeSelector
    3. A ResourceQuota
    4. A LimitRange

19. Which concept marks a node as generally unsuitable for scheduling unless a Pod explicitly tolerates it?

    1. cordon
    2. drain
    3. A taint
    4. A label

20. What does the OCI (Open Container Initiative) actually define?

    1. Kubernetes' own private packaging format
    2. Vendor-neutral specifications for container images, runtimes, and distribution, so tooling from different vendors interoperates
    3. A CNCF governance process for admitting new projects
    4. Kubernetes' API versioning scheme

21. What is the fundamental architectural reason containers are lighter-weight than virtual machines?

    1. Containers always use less disk space
    2. Containers share the host machine's kernel instead of each running a full guest operating system
    3. Containers cannot run on cloud infrastructure
    4. Containers don't use images at all

22. Which component on a node actually pulls images and starts/stops containers, on instruction from the kubelet, via the Container Runtime Interface?

    1. kube-proxy
    2. A CRI-compatible runtime such as containerd
    3. kube-scheduler
    4. etcd

📦 Domain 2 — Container Orchestration (28% · Q23–36)

☺ Like you're 10: This domain is the clubhouse's phone system, its front door, its locks, and what to do the moment something inside starts acting strange.

Orchestration covers four competencies: Networking (Q23–26), Security (Q27–30), Troubleshooting (Q31–33), and Storage (Q34–36). This is the domain where a status string like CrashLoopBackOff stops being scary vocabulary and starts being a specific, diagnosable claim about what the kubelet just observed.

23. In Kubernetes' flat networking model, how do Pods reach each other by default?

    1. Every cross-Pod connection requires NAT
    2. Every Pod gets its own IP and can reach every other Pod's IP directly, with no NAT
    3. Pods can only reach other Pods on the same node
    4. Pods communicate exclusively through the API server

24. Which Service type is correct for exposing an application only to other Pods inside the cluster, with no external access at all?

    1. NodePort
    2. LoadBalancer
    3. ClusterIP
    4. ExternalName

25. What is the main architectural difference between Ingress and the newer Gateway API?

    1. Gateway API only supports TCP; Ingress only supports HTTP
    2. Ingress is a single, fairly narrow HTTP/HTTPS routing resource; Gateway API is a more expressive, role-oriented, portable set of resources covering more protocols and routing patterns
    3. They are the exact same API under two names
    4. Ingress replaces Gateway API as of the newest Kubernetes releases

26. Which cluster add-on resolves a name like my-svc.my-namespace.svc.cluster.local to a ClusterIP?

    1. kube-proxy
    2. CoreDNS
    3. etcd
    4. kube-scheduler

27. What is the distinction between authentication and authorization on the Kubernetes API request path?

    1. They're the same check performed twice
    2. Authentication establishes who is making the request; authorization decides what that identity is allowed to do
    3. Authorization always runs before authentication
    4. Authentication only ever applies to human users, never workloads

28. By default, how are values inside a Kubernetes Secret protected?

    1. Encrypted automatically with AES-256
    2. Only base64-encoded — an encoding, not encryption — unless encryption at rest is separately configured
    3. Stored as plaintext, with no encoding at all
    4. One-way hashed and never retrievable

29. What does Pod Security Admission enforce, at the Namespace level, via its enforce/audit/warn labels?

    1. Network bandwidth limits
    2. One of the built-in Pod Security Standards profiles — Privileged, Baseline, or Restricted
    3. Container image digests
    4. RBAC RoleBindings

30. What is an admission controller's role in the API request lifecycle?

    1. It runs before authentication
    2. It intercepts a request after authentication and authorization but before the object is persisted, and can validate or mutate it
    3. It applies only to kubectl delete
    4. It fully replaces the need for RBAC

31. kubectl get pods shows a Pod's status as ImagePullBackOff. Which of the five true Pod phases does this belong to?

    1. It is itself a sixth Pod phase
    2. It's a container waiting-state reason displayed alongside the Pending phase — not a phase in its own right
    3. It always means the phase is Failed
    4. It means the phase is Unknown

32. A Pod's status reads Evicted. What does that most directly indicate?

    1. A failed liveness probe
    2. The node came under resource pressure (commonly disk or memory) and the kubelet removed the Pod to protect the node
    3. The image tag referenced doesn't exist
    4. A NetworkPolicy blocked the Pod's traffic

33. A Pod is crash-looping. Which command most directly explains why the kubelet keeps restarting it, via its recent Events?

    1. kubectl get pods
    2. kubectl describe pod
    3. kubectl top pod
    4. kubectl config view

34. What is the relationship between a PersistentVolume (PV), a PersistentVolumeClaim (PVC), and a StorageClass?

    1. A PVC is a request for storage; a PV is the actual storage resource; a StorageClass lets a PV be dynamically provisioned to satisfy a PVC automatically
    2. A PV requests storage from a PVC
    3. A StorageClass replaces the need for a PVC entirely
    4. PVs and PVCs are just two names for the same object

35. A PVC requests access mode ReadWriteOnce (RWO). What does that guarantee?

    1. Many nodes can mount it read-write at the same time
    2. The volume can be mounted read-write by a single node at a time
    3. The volume is permanently read-only
    4. The volume can only ever be read, never written

36. A StorageClass sets volumeBindingMode: WaitForFirstConsumer. What does this achieve?

    1. The PVC binds immediately on creation, before any Pod exists
    2. Binding and dynamic provisioning are delayed until a Pod that uses the PVC is actually scheduled, so the volume can be provisioned in the right topology zone
    3. It disables dynamic provisioning entirely
    4. It forces the PVC to stay Pending forever

🚀 Domain 3 — Cloud Native Application Delivery (16% · Q37–44)

☺ Like you're 10: This domain is how new stuff actually gets into the clubhouse, and what you do the moment something you just moved in stops working right.

Delivery covers two competencies: Application Delivery (Q37–40) and Debugging (Q41–44). The debugging half rewards knowing which command to reach for first far more than knowing every flag — the same four commands do almost all the work.

# The single most useful first move: full object state + recent Events
kubectl describe pod checkout-7d9f5b6c4-abcde -n shop

# Logs — add -p / --previous to read the CRASHED container, not the current one
kubectl logs deploy/checkout -n shop --tail=100
kubectl logs checkout-7d9f5b6c4-abcde -n shop -p

# Cluster Events, oldest first — explains Pending and Evicted better than logs ever will
kubectl get events -n shop --sort-by=.metadata.creationTimestamp

# Rollouts: check the state, then undo a bad one
kubectl rollout status deploy/checkout -n shop
kubectl rollout undo   deploy/checkout -n shop

37. What is the defining characteristic of the GitOps delivery model?

    1. Developers SSH into production servers to deploy changes directly
    2. A controller running against the cluster continuously pulls desired state from a Git repository and reconciles live state to match it
    3. Deployments are always triggered by a webhook that pushes changes straight into the cluster
    4. GitOps just means storing YAML files in Git, with no reconciliation involved

38. What problem does Helm primarily solve for Kubernetes application delivery?

    1. It replaces etcd as a cluster state store
    2. It packages a set of manifests as a templated, versioned, parameterizable "chart" that installs, upgrades, and rolls back as one unit
    3. It is itself a container runtime
    4. It is a CNI plugin

39. How does Kustomize's approach to configuration differ from Helm's?

    1. Kustomize uses a templating language, exactly like Helm
    2. Kustomize applies template-free, layered overlays and patches on top of plain YAML bases, rather than templating with variables
    3. Kustomize can only be used from inside a Helm chart
    4. Kustomize requires a server-side component to run

40. In a canary deployment strategy, what actually happens?

    1. All traffic switches to the new version instantly
    2. A small subset of traffic or replicas shifts to the new version first, validating risk before a full rollout
    3. Two full environments run forever, permanently splitting traffic in half
    4. The old version is deleted before the new one is even created

41. Which command should almost always be reached for first when a Pod is misbehaving, because it surfaces full object state and recent Events together?

    1. kubectl logs
    2. kubectl describe
    3. kubectl exec
    4. kubectl top

42. A container has already crashed and restarted. Which flag reads the logs from that crashed instance rather than the current, running one?

    1. kubectl logs --before
    2. kubectl logs -p (--previous)
    3. kubectl logs --restart
    4. kubectl logs --old

43. Which command reverts a Deployment to its previous working revision after a bad rollout?

    1. kubectl delete deployment
    2. kubectl rollout undo
    3. kubectl scale --replicas=0
    4. kubectl apply --force

44. Sorted cluster Events are especially useful for diagnosing which two Pod situations, since neither is fully explained by kubectl logs alone?

    1. Successful rollouts and ConfigMap updates
    2. Pods stuck Pending and Pods that were Evicted
    3. Completed Jobs and CronJob schedules
    4. Node labels and taints

🗺️ Domain 4 — Cloud Native Architecture (12% · Q45–50)

☺ Like you're 10: This domain is the widest reading and the smallest slice of the test — the ecosystem the clubhouse sits inside, not the clubhouse itself.

Architecture covers three competencies: Observability (Q45–46), Cloud Native Ecosystem and Principles (Q47–48), and Cloud Native Community and Collaboration (Q49–50). At 12% it's the smallest domain on the paper, but it's also the one candidates most reliably under-read, and the CNCF's own project maturity ladder shows up in more interviews than its exam weight would suggest.

45. What are the three commonly cited pillars of observability?

    1. CPU, memory, disk
    2. Metrics, logs, and traces
    3. Uptime, latency, throughput
    4. Dashboards, alerts, runbooks

46. Prometheus's default model for collecting metrics is:

    1. Push-based — every application must push metrics to Prometheus itself
    2. Pull-based — Prometheus scrapes HTTP endpoints on a schedule
    3. Log-file based only
    4. Dependent on a message-queue intermediary

47. What does "immutable infrastructure" mean in a cloud native context?

    1. Servers are patched in place and never replaced
    2. Running instances — images, containers, nodes — are never modified after deployment; a change means building and rolling out a new instance instead
    3. Infrastructure that can't be defined as code
    4. Storage volumes that can never be deleted

48. CNI, CSI, and CRI are all examples of:

    1. CNCF governance bodies
    2. Kubernetes' pluggable interface specifications — for networking, storage, and container runtimes respectively — letting third-party implementations plug into the same core
    3. Certification exam codes
    4. Deprecated Kubernetes APIs

49. What are the three stages of the CNCF's project maturity ladder, in order?

    1. Alpha → Beta → Stable
    2. Sandbox → Incubating → Graduated
    3. Draft → Review → Released
    4. Experimental → Core → Deprecated

50. What is a CNCF Special Interest Group (SIG), roughly speaking?

    1. A paid support contract
    2. A community-organized group focused on a particular technical area — networking, storage, security, and similar — that provides ongoing oversight and shepherds contributions in that area
    3. A certification exam track
    4. A CNCF-run compliance audit

Marking yourself, and what to do next

☺ Like you're 10: Your score is a thermometer, not a verdict — the list of what you got wrong is the actual point.

Count your correct answers out of 50. The number to beat is 75%, which on this paper is 38 of 50 — the Linux Foundation's own Multiple Choice Exam FAQ states plainly that a score of 75% or above must be earned to pass a multiple-choice exam, and KCNA is one. Don't read a pass here as a guaranteed pass there — this paper isn't calibrated to the real exam's difficulty or wording — but score yourself by domain, not just by total, because the pattern is what actually travels.

Where each domain is taught, if you need more than this paper

☺ Like you're 10: Every question above came from somewhere specific on this course — go back to that page, not to a search engine.

Nothing in this paper tests material this course doesn't teach. The KCNA blueprint is the direct answer key at exam depth for all four domains; the sibling Platform Engineering course's KCNA page covers the identical curriculum from a platform-engineer's angle if a second explanation of the same material helps something click.

Beyond the blueprint: the study plan & practice bank for a week-by-week plan, the flashcards for pure vocabulary drilling, the glossary for anything a question here assumed you already knew, and the how to study for a CNCF exam page for technique that applies across every exam on this course's ladder.