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

This is the second of this course's two full KCNA sittings, built to the exact same shape as Set 1 so the two scores are directly comparable: 50 multiple-choice questions, weighted 22 / 14 / 8 / 6 to 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. Every question below is new; none of the fifty repeats a stem, an option list, or an answer from Set 1, though a fair number circle back to the same underlying facts in different words — Kubernetes Fundamentals alone is 44% of the real exam, and there simply isn't two papers' worth of genuinely distinct propositions in "what does the control plane do." Work straight through without opening a second tab, then check every answer against the explanation folded behind each domain's answer key. If Set 1 already found your weak domains, this sitting is where you find out whether the fix actually took.

Where this sitting fits your prep

☺ Like you're 10: This isn't a fresh start — it's stage four of the same loop Set 1 set up: learn, sit, fix, sit again.

If you haven't sat Set 1 yet, sit that one first — this page assumes you have, and is calibrated as the confirmation rep, not the diagnostic one.

Exam conditions for this sitting

☺ Like you're 10: Same rules as last time — one clock, closed book, and no peeking at an answer before you've actually chosen one.

The conditions haven't moved since Set 1, because the real exam's conditions don't move either. One timer, started once, 90 minutes — the real KCNA's published duration, per the Linux Foundation's own Multiple Choice Exam FAQ. Closed-book — no reference material at all. Unlike this course's CKA and CKAD mocks, which open a documentation tab inside their exam environment, KCNA gives you nothing. Answer every question once, in order; multiple choice carries no time cost to revisiting a flagged question, but never leave one blank on a guess-penalty-free exam. No peeking at an answer key before you've committed — the entire diagnostic value of a second sitting depends on it measuring what you actually know today, not what you remember reading five minutes ago.

How the 50 questions are weighted

☺ Like you're 10: Same split as Set 1, because the real exam's domain weights don't change between sittings either.

The domain math is identical to Set 1's, because it's the CNCF's math, not this course's: the four official weights — 44, 28, 16, and 12 — sum to exactly 100% straight from the KCNA curriculum, and every one 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 anywhere, summing to exactly 50. Kubernetes Fundamentals and Container Orchestration together are still 72% of this paper, exactly as they were on Set 1 — if your first sitting's domain breakdown showed weakness in either one, this is the sitting that finds out whether it's actually fixed.

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

☺ Like you're 10: Same clubhouse as Set 1 — who's in charge of what, which rooms exist, and the rules for getting a chore actually done — asked from a different angle this time.

Fundamentals covers four official competencies: Kubernetes Core Concepts (Q1–9), Administration (Q10–14), Scheduling (Q15–19), and Containerization (Q20–22). A few of this domain's questions below cover ground Set 1 never touched at all — ResourceQuota, LimitRange, and the three distinct taint effects — so don't assume a strong Set 1 Domain 1 score means there's nothing left to check here. Background: the KCNA blueprint and Kubernetes architecture.

apiVersion: apps/v1
kind: DaemonSet                  # one Pod per matching node, not a fixed replica count
metadata: { name: node-exporter, namespace: monitoring }
spec:
  selector:
    matchLabels: { app: node-exporter }
  template:
    metadata:
      labels: { app: node-exporter }
    spec:
      tolerations:
        - operator: Exists        # tolerate every taint, so it still lands on every node
      containers:
        - name: node-exporter
          image: prom/node-exporter:v1.8.2
          resources:
            requests: { cpu: "50m", memory: "64Mi" }
            limits:   { cpu: "200m", memory: "128Mi" }
---
apiVersion: v1
kind: LimitRange                  # fills in a default request/limit for any container that omits one
metadata: { name: default-limits, namespace: monitoring }
spec:
  limits:
    - type: Container
      defaultRequest: { cpu: "50m", memory: "64Mi" }
      default:        { cpu: "200m", memory: "128Mi" }

1. How does the control plane actually learn that a node has stopped responding?

   1. An administrator has to mark it manually
   2. The kubelet on that node stops renewing its heartbeat (via a Node Lease object), and once enough of those are missed the node is marked NotReady
   3. etcd polls every node's IP directly every second
   4. It doesn't — nodes are assumed healthy until a Pod on them fails

2. Every object you create with kubectl ultimately becomes a record in etcd. Which single component is the only one ever allowed to read or write that record?

   1. kubelet
   2. kube-scheduler
   3. kube-apiserver
   4. Any control-plane component, as long as it has the right certificate

3. A newly created Pod has no nodeName set yet and its status is Pending. What has to happen before it can move to Running?

   1. The kubelet on every node has to vote
   2. kube-scheduler has to find a node that satisfies its constraints and assign it there
   3. The Pod has to be manually bound with kubectl bind by a human
   4. Nothing — Pending Pods start automatically after 30 seconds

4. If kube-controller-manager stopped running entirely, what would you actually observe?

   1. Every currently running Pod would be killed immediately
   2. Existing Pods would keep running, but a ReplicaSet whose Pod count dropped below its target would stop self-healing — nothing would replace the missing Pods
   3. The API server would refuse all new requests
   4. Nothing — controller-manager has no observable effect on the cluster

5. What is a static Pod?

   1. A Pod with its replica count fixed and unable to autoscale
   2. A Pod defined by a manifest file that one node's kubelet reads directly from local disk, rather than one managed via the API server — the mechanism kubeadm uses for the control-plane components themselves
   3. A Pod that has finished all its readiness probes
   4. A synonym for a DaemonSet Pod

6. If you inspect a running Deployment's Pods, which intermediate controller object will you find sitting between the Deployment and the Pods themselves?

   1. A StatefulSet
   2. A ReplicaSet
   3. A Job
   4. Nothing — a Deployment owns its Pods directly

7. You need exactly one logging-agent Pod on every node, current and future, with no fixed replica count to manage. Which workload object is built for that?

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

8. Which workload object numbers its Pods predictably (db-0, db-1...) and gives each one its own PersistentVolumeClaim that follows it across a reschedule?

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

9. A one-off database migration script needs to run to completion exactly once and then stop — not on a schedule, not repeatedly. Which object is correct?

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

10. You want a command that's safe to run twice in a row on the same file — creating the object if it's missing, updating it in place if it already exists. Which is it?

    1. kubectl create -f
    2. kubectl apply -f
    3. kubectl replace -f
    4. kubectl edit

11. A platform team wants permissions that work identically no matter which Namespace they're eventually granted in — fully reusable, defined once. Which RBAC object should they define?

    1. A Role, copy-pasted into every Namespace
    2. A ClusterRole, which can then be bound per-namespace with a RoleBinding, or cluster-wide with a ClusterRoleBinding
    3. A ServiceAccount
    4. A NetworkPolicy

12. You create a Role granting get on Pods and confirm it exists with kubectl get roles. A user still receives Forbidden when they try. What's missing?

    1. Nothing should be missing — the Role alone should be enough
    2. A RoleBinding (or ClusterRoleBinding) actually binding that Role to the user
    3. The Role needs a matching NetworkPolicy
    4. The user needs a new kubeconfig context

13. What does a ResourceQuota object do?

    1. Sets a default CPU/memory request and limit for any container that omits one
    2. Caps the total resource consumption allowed across every object in one Namespace — for example, a hard ceiling on total memory requested
    3. Restricts which container images a Pod is allowed to use
    4. Limits how many nodes a cluster can have

14. What does a LimitRange do that a ResourceQuota does not?

    1. It caps the Namespace's aggregate resource usage
    2. It sets a default (and optionally a min/max) request and limit applied per individual object, so a container that specifies neither still gets a sane value
    3. It replaces the need for RBAC entirely
    4. It's simply a deprecated alias for ResourceQuota

15. Which of these does kube-scheduler actually consult when choosing a node for a new Pod?

    1. The container's image size
    2. The Pod's resources.requests for CPU and memory
    3. The Pod's log verbosity level
    4. The container's limits.memory value only

16. What is the one thing a Pod's toleration for a node's taint can never do by itself?

    1. Allow the Pod to be scheduled there despite the taint
    2. Attract the Pod toward that specific node over any other untainted, eligible node
    3. Be combined with node affinity for a stronger pinning effect
    4. Match a taint's key, value, and effect exactly

17. A container hits its CPU limit versus its memory limit. What's the actual difference in what Kubernetes does in each case?

    1. Both result in the container being killed immediately
    2. Exceeding the CPU limit throttles the container, which keeps running more slowly; exceeding the memory limit gets it OOMKilled by the kernel
    3. Both are purely advisory and enforce nothing
    4. Exceeding either limit reschedules the Pod onto a bigger node automatically

18. Which scheduling mechanism supports set-based expressions like In, NotIn, and Exists against node labels — something a plain nodeSelector cannot do?

    1. A taint
    2. Node affinity
    3. A ResourceQuota
    4. A toleration

19. Of the three taint effects — NoSchedule, PreferNoSchedule, and NoExecute — which one actively evicts Pods already running on the node that don't tolerate it?

    1. NoSchedule
    2. PreferNoSchedule
    3. NoExecute
    4. None of the three — taints only ever block new Pods

20. An image built with one vendor's tooling runs correctly under a completely different vendor's container runtime. What makes that possible?

    1. Every runtime happens to be built by the same handful of companies
    2. Compliance with the OCI's open image-spec and runtime-spec, which standardize image format and runtime behavior across vendors
    3. Kubernetes translates every image at pull time
    4. It isn't actually possible — images are runtime-specific

21. Why can a single host typically run far more containers than virtual machines?

    1. Containers use less disk space on average
    2. Containers share the host's own kernel instead of each booting a full guest operating system, which removes most of a VM's per-instance overhead
    3. Containers are not actually isolated from each other
    4. VMs require more network bandwidth per instance

22. The kubelet needs to start a container, but it never speaks a vendor-specific API to do it. What standard interface does it use instead?

    1. CNI
    2. CSI
    3. CRI
    4. OCI, directly

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

☺ Like you're 10: The clubhouse's phone system, its front door, its locks, and what to do the moment something inside starts acting strange — same territory as Set 1, different specific questions about it.

Orchestration covers four competencies: Networking (Q23–26), Security (Q27–30), Troubleshooting (Q31–33), and Storage (Q34–36). A few facts here — the default ServiceAccount fallback, mutating vs. validating admission, reclaim policy, ReadWriteMany — go a layer deeper than Set 1 asked. Background: the KCNA blueprint, networking & the CNI, and storage & the CSI.

23. What must be true of every Pod's IP address in a conformant Kubernetes cluster, regardless of which CNI plugin is installed?

    1. It's only reachable from Pods on the same node
    2. It's routable and reachable from every other Pod in the cluster, with no NAT required
    3. It changes every time the Pod is scaled
    4. It's shared with every other Pod in the same Namespace

24. Which Service type requires integration with an external cloud provider to actually provision anything, and simply behaves like a plain NodePort without one?

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

25. What can an Ingress do that a Service's own built-in load balancing alone cannot?

    1. Encrypt traffic between Pods automatically
    2. Route by hostname and URL path — layer-7 rules that send external traffic to different backend Services from one shared entry point
    3. Provide storage for stateless applications
    4. Automatically scale the number of Pod replicas

26. What is the standard DNS name pattern a Pod can use to reach a Service named api in Namespace shop, without hardcoding an IP address?

    1. shop-api.internal
    2. api.shop.svc.cluster.local
    3. api.cluster.shop.local
    4. Services have no predictable DNS name

27. A request reaches the API server carrying an expired client certificate. At which stage of the request pipeline does it get rejected?

    1. Authorization, after the identity is already accepted
    2. Authentication — it never gets far enough to have an identity for authorization to evaluate
    3. Admission control, at the very end of the pipeline
    4. It's silently accepted and logged as anonymous

28. Given that Secrets are only base64-encoded by default, what's the standard way to actually get encryption at rest for their contents?

    1. Nothing can be done; Secrets can never be encrypted
    2. Configure an EncryptionConfiguration for etcd (or use an external secret store), since it isn't the default behavior
    3. Rename the Secret object to encrypted-secret
    4. Base64-encode the value a second time

29. If a Pod's spec doesn't name a ServiceAccount at all, which identity does it use to authenticate to the API server?

    1. None — it can't make any API calls
    2. The cluster-admin identity, by default
    3. The default ServiceAccount of whichever Namespace the Pod runs in
    4. The identity of whoever ran kubectl apply

30. What's the difference between a mutating and a validating admission webhook, and which runs first?

    1. They're the same thing under two names; order doesn't matter
    2. A mutating webhook can modify the incoming object and runs first; a validating webhook can only accept or reject it, and runs after
    3. Validating webhooks run first and can modify the object; mutating webhooks only reject
    4. Only one type is allowed to be configured per cluster

31. A container keeps starting and exiting in a repeating cycle, with Kubernetes waiting longer between each restart attempt. What's this status called, and is it one of the five true Pod phases?

    1. CrashLoopBackOff; yes, it's a phase
    2. CrashLoopBackOff; no — it's a container-level waiting-state reason, not a phase
    3. Failed; yes, it's a phase
    4. ImagePullBackOff; no, it isn't a real status at all

32. A Pod can't be scheduled because no node currently has enough free CPU. Where does Kubernetes actually record that reason, since it never shows up in kubectl logs?

    1. It doesn't record a reason anywhere
    2. In the Pod's Events, visible via kubectl describe pod
    3. Only in the scheduler's own container logs, on the control-plane node
    4. In a dedicated FailureReason field on the Node object

33. A container's state is reported as Waiting, distinct from Running or Terminated. What does Waiting mean?

    1. The container ran successfully and exited on its own
    2. The container hasn't started yet — commonly still pulling its image, or blocked behind an init container
    3. The container is running but paused by the kubelet
    4. The Pod has been deleted but the container hasn't noticed

34. A PVC is deleted. Its PersistentVolume was created with reclaimPolicy: Retain. What happens to the underlying storage?

    1. It's deleted immediately, along with the PVC
    2. The PV moves to a Released state and the storage is preserved — an administrator has to handle it manually
    3. It's automatically reused by the next PVC that asks for the same size
    4. Retain has no actual effect on deletion behavior

35. Which access mode allows the same volume to be mounted read-write by multiple nodes at once — something a typical cloud block disk cannot do, but a shared filesystem like NFS can?

    1. ReadWriteOnce (RWO)
    2. ReadOnlyMany (ROX)
    3. ReadWriteMany (RWX)
    4. None — no access mode allows this

36. What happens to an emptyDir volume's contents when its Pod is deleted?

    1. They persist and can be reattached to a future Pod
    2. They're deleted permanently along with the Pod — its lifetime is tied to the Pod, not the node
    3. They're automatically uploaded to the configured StorageClass
    4. They survive as long as the node itself stays up

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

☺ Like you're 10: How new stuff actually gets into the clubhouse, and exactly which command to reach for 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 still rewards knowing which command to reach for first over knowing every flag — but this set pushes a step past Set 1's plain command list into a couple of genuine nuances each command has. Background: GitOps on Kubernetes, Helm, and Kustomize.

# Not the current, running container — the one that already crashed
kubectl logs deploy/checkout -n shop -p

# Stream new lines as they're written, instead of one static snapshot
kubectl logs deploy/checkout -n shop -f

# rollout undo with no flag steps back exactly ONE revision — not necessarily the good one
kubectl rollout history deploy/checkout -n shop
kubectl rollout undo    deploy/checkout -n shop --to-revision=2

# Sorted oldest-first, Events explain what logs never will: Pending, scheduling failures, evictions
kubectl get events -n shop --sort-by=.metadata.creationTimestamp

37. What security advantage does a pull-based GitOps model have over a traditional push-based CI/CD pipeline?

    1. Pull-based deployments happen faster, with no other real difference
    2. An agent running inside the cluster pulls from Git and applies changes itself, so cluster credentials never have to be handed to an external CI system
    3. Pull-based means no audit trail is kept
    4. There's no meaningful security difference between the two models

38. What does helm upgrade do differently from simply re-running helm install against a changed chart?

    1. Nothing — the two commands are interchangeable
    2. upgrade tracks the change as a new revision of an existing release and can be rolled back with helm rollback; a fresh install has no continuity with anything before it
    3. upgrade only works on StatefulSets
    4. install supports rollback, but upgrade does not

39. A team wants identical base manifests for staging and production, differing only in replica count and one environment variable, with no templating language involved anywhere. Which tool is purpose-built for that?

    1. Helm, using its templating engine
    2. Kustomize, using template-free overlays and patches
    3. A raw shell script that finds-and-replaces text in the YAML
    4. etcd, directly

40. What is the default update strategy for a Kubernetes Deployment, and which two fields govern how aggressively it replaces old Pods?

    1. Recreate; it has no configurable fields
    2. RollingUpdate; governed by maxSurge and maxUnavailable
    3. Canary; governed by trafficWeight and stepDuration
    4. Blue/green; governed by activeColor and standbyColor

41. A Pod is Running and passing every probe, but the application inside is returning wrong data to real users. Which command actually helps diagnose this, and which one mostly won't?

    1. kubectl describe helps; kubectl logs doesn't
    2. kubectl logs helps, since it shows application output; kubectl describe mostly won't, since it would just show a healthy object with nothing wrong to report
    3. Neither command can help with application-level bugs
    4. kubectl top is the only useful command here

42. What does the --follow (-f) flag add to kubectl logs?

    1. It shows logs from the previous, crashed container instead of the current one
    2. It streams new log lines continuously as they're written, instead of printing the current buffer once and exiting
    3. It follows the Pod if it gets rescheduled to a different node mid-command
    4. It filters logs down to error-level lines only

43. kubectl rollout undo deploy/app with no flags reverts to which specific revision?

    1. The very first revision the Deployment ever had
    2. The immediately preceding revision — not necessarily the last genuinely working one, if more than one bad revision has already rolled out since then
    3. Whichever revision has the most replicas currently
    4. It always asks interactively which revision to use

44. Why is sorting cluster Events by timestamp specifically useful when troubleshooting a Pod that failed hours ago?

    1. Events are always already sorted by default, so it changes nothing
    2. Events have a limited retention window and no guaranteed default order, so sorting is what actually surfaces the real sequence leading to the failure
    3. Sorting is required before kubectl get events will return any results at all
    4. Only sorted Events are visible to a non-admin user

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

☺ Like you're 10: The widest reading and the smallest slice of the test — the ecosystem the clubhouse sits inside, not the clubhouse itself — and the domain candidates most reliably under-read.

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, but nothing here overlaps Set 1's six questions in this domain — this set covers SLIs/SLOs, declarative reconciliation, service meshes, and the SIG-versus-TAG distinction Set 1 never asked about at all. Background: observability on Kubernetes, the CNCF project landscape, and service-mesh fundamentals.

45. What's the relationship between an SLI, an SLO, and an error budget?

    1. They're three unrelated monitoring tools with no connection to each other
    2. An SLI is a measured indicator (like request latency); an SLO is a target for that indicator over time; the error budget is how much the SLI is allowed to miss the SLO before it counts as a breach
    3. An SLO is simply a stricter version of an SLI
    4. Error budgets replace the need for SLOs entirely

46. What does Prometheus scrape from each of its targets to collect metrics?

    1. A binary protocol pushed to it over gRPC
    2. An HTTP /metrics endpoint exposing plain-text, labeled time-series data, polled on a schedule
    3. Structured log lines, parsed after the fact
    4. SNMP traps from network hardware

47. What does "declarative," as the term is used in cloud native systems, actually mean?

    1. Writing step-by-step commands that must run in a specific order
    2. Stating the desired end state and letting a controller figure out — and continuously reconcile — how to get there and stay there
    3. Configuration that can never be stored in version control
    4. A synonym for "imperative" in Kubernetes' own documentation

48. What does a service mesh (such as Istio or Linkerd) typically add to a set of microservices via sidecar proxies, with no application code changes required?

    1. A replacement for the Kubernetes API server
    2. Consistent mutual TLS, traffic management, and observability between services
    3. Persistent storage for stateless applications
    4. A built-in CI/CD pipeline

49. What generally distinguishes a Graduated CNCF project from one still Incubating?

    1. Graduated projects are simply older by calendar date
    2. Graduated status requires a materially higher bar of demonstrated adoption, security auditing, and diversity of committers — a much stronger maturity and governance signal
    3. There's no real difference; the two terms are interchangeable
    4. Incubating projects are always more widely adopted than Graduated ones

50. What's the difference between a Kubernetes SIG (like sig-network) and a CNCF TAG (like TAG Security)?

    1. They're identical structures, just named differently
    2. A SIG organizes work within a single project — Kubernetes; a TAG provides cross-cutting technical oversight across many CNCF projects at once
    3. TAGs only exist to handle security incidents
    4. SIGs are CNCF's governing board; TAGs are individual contributors

Marking yourself, and what to do next

☺ Like you're 10: Your score is a thermometer, not a verdict — the real question is whether the same domain cost you marks on both papers.

Count your correct answers out of 50. The number to beat is 75%, which on this paper is 38 of 50 — identical to Set 1's bar, so the two scores really are directly comparable. Don't just compare totals, though: pull up your Set 1 domain breakdown next to this one. A domain that cost you marks on both sittings is a genuine gap; a domain that was weak on Set 1 and solid here means the fix actually worked.

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 either KCNA 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 and DevOps course's KCNA page cover the identical curriculum from different angles, 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.