CertGrid
Cloud Native Certification

CKA: Certified Kubernetes Administrator Practice Exam

Validates skills in Kubernetes cluster architecture, installation, configuration, workloads, networking, storage, and troubleshooting.

Start with a free CKA practice test, then work through 793 exam-style questions with full answer explanations, and use MCQ readiness practice to check concepts and command decisions before hands-on lab work.

Free account: a fixed set of 20 practice questions for this exam, retryable anytime. Paid access unlocks the full bank and timed mock exams. No credit card required to start.

793
Practice pool
Hands-on lab
Real exam
120 min
Real exam time
Intermediate
Level
66%
Passing score

CertGrid MCQ practice: 50 questions. The real CKA exam is hands-on and performance-based. CertGrid provides a fixed 50-question MCQ practice session to test concepts, command decisions, and troubleshooting readiness. Practice in a real Kubernetes cluster before booking.

Objective-mapped practice, aligned to current exam objectives · Reviewed Oct 2026 · Independent practice platform.

What the CKA exam covers

Free CKA practice test questions

A sample of 10 questions with answers and explanations. A free account includes a fixed set of 20 practice questions for this exam, retryable anytime. Paid access unlocks the full 793-question bank.

  1. Question 1Cluster Architecture Installation and Configuration

    Which component in a Kubernetes control plane is responsible for persisting all cluster data?

    • Akube-controller-manager
    • Bkube-apiserver
    • Ckube-scheduler
    • DetcdCorrect
    ✓ Correct answer: D

    etcd is the consistent and highly available key-value store that serves as the sole backing store for all Kubernetes cluster state and configuration data. Every object created in the cluster - nodes, pods, services, config maps, secrets - is persisted in etcd. All other control plane components access cluster data by reading from and writing to etcd exclusively through the kube-apiserver, which acts as the only direct client of etcd.

    Why the other options are wrong
    • Akube-controller-manager runs reconciliation loops that watch cluster state and drive actual state toward desired state, but it does not persist data - it reads and writes through the kube-apiserver.
    • Bkube-apiserver is the front-end gateway for the Kubernetes control plane and is the only component that communicates directly with etcd, but the apiserver itself does not store data - it delegates persistence entirely to etcd.
    • Ckube-scheduler watches for unscheduled pods and assigns them to suitable nodes, but it holds no persistent state of its own and does not interact with the storage layer directly.
  2. Question 2Cluster Architecture Installation and Configuration

    You need to mark a node as unschedulable without evicting existing pods. Which command should you use?

    • Akubectl taint nodes node01 NoSchedule
    • Bkubectl disable-scheduling node01
    • Ckubectl drain node01
    • Dkubectl cordon node01Correct
    ✓ Correct answer: D

    kubectl cordon sets the node's schedulable flag to false by patching the node's spec.unschedulable field to true, which results in the node status showing SchedulingDisabled. The scheduler will not place any new pods on the node after this point, but all currently running pods remain undisturbed. This is typically done as the first step before draining a node for maintenance.

    Why the other options are wrong
    • AA taint argument must be written as key[=value]:effect, so a bare NoSchedule is rejected. Even a valid NoSchedule taint is a different mechanism from cordoning: Pods that tolerate it can still be scheduled, and it does not set spec.unschedulable.
    • Bkubectl disable-scheduling node01 is not a valid kubectl command; there is no 'disable-scheduling' action in kubectl - the correct command for marking a node unschedulable is 'kubectl cordon'.
    • Ckubectl drain node01 both marks the node as unschedulable and evicts all eligible running pods from it, which is more disruptive than required when the goal is only to prevent new scheduling without affecting existing workloads.
  3. Question 3Workloads and Scheduling

    AutoScale Inc wants their application to automatically scale based on CPU utilization. Which Kubernetes resource manages automatic horizontal scaling of pods?

    • AReplicaSet
    • BVerticalPodAutoscaler
    • CHorizontalPodAutoscalerCorrect
    • DResourceQuota
    ✓ Correct answer: C

    The HorizontalPodAutoscaler (HPA) continuously monitors metrics - most commonly average CPU utilization - for the pods of a target workload (Deployment, StatefulSet, or ReplicaSet) and automatically adjusts the replica count to keep the metric at a desired target value. When CPU utilization rises above the threshold, the HPA increases the replica count; when it falls, the HPA scales down. This allows applications to handle variable load without manual intervention, staying within configured minimum and maximum replica bounds.

    Why the other options are wrong
    • AReplicaSet maintains a fixed, manually specified number of pod replicas. It does not monitor metrics or automatically adjust the replica count in response to load; the desired replica count must be changed manually or by a higher-level controller like HPA.
    • BVerticalPodAutoscaler (VPA) automatically adjusts the CPU and memory resource requests and limits of individual containers based on historical usage. It scales resources vertically (per pod), not horizontally (replica count), and may need to restart pods to apply new resource values.
    • DResourceQuota limits the aggregate resource consumption within a namespace to prevent any single team or workload from monopolizing cluster resources. It is a hard cap that causes pod creation to fail when exceeded - it does not dynamically scale workloads.
  4. Question 4Workloads and Scheduling

    Which probe mechanism executes a command inside the container and considers the check successful if the command exits with status code 0?

    • AhttpGet
    • BexecCorrect
    • CtcpSocket
    • Dgrpc
    ✓ Correct answer: B

    The exec probe mechanism runs a specified command inside the container using the container's runtime environment. If the command exits with status code 0, the probe is considered successful; any non-zero exit code is treated as a failure. This is useful for health checks that cannot be expressed as HTTP endpoints or TCP connections, such as checking database connectivity or file system state via a custom script.

    Why the other options are wrong
    • AhttpGet performs an HTTP GET request to a specified path and port on the container; success is determined by the HTTP response status code, not by a command exit code.
    • CtcpSocket checks whether a TCP connection can be established to a specified port on the container; it does not execute a command inside the container.
    • Dgrpc uses the gRPC Health Checking Protocol to send a health check request to a gRPC server running in the container; it does not execute a command inside the container.
  5. Question 5Services and Networking

    Which kube-proxy mode uses Linux kernel virtual servers for load balancing?

    • Anftables
    • Buserspace
    • CIPVSCorrect
    • Diptables
    ✓ Correct answer: C

    IPVS (IP Virtual Server) mode makes kube-proxy use the Linux kernel IPVS module, part of the Linux Virtual Server project, to load-balance Service traffic. Instead of long iptables rule chains it uses hash tables and supports several scheduling algorithms, such as round robin and least connections. Note that ipvs mode has been deprecated since Kubernetes v1.35, and the docs plan to disable it by default from v1.40, so new clusters should use iptables or nftables.

    Why the other options are wrong
    • Anftables is an alternative to iptables that uses the netfilter framework with a different rule syntax. While nftables mode has been introduced as an option in newer Kubernetes versions, it does not use kernel virtual servers for load balancing.
    • Buserspace mode was the original kube-proxy mode where the proxy process itself handled packet forwarding in user space. It is the slowest mode and does not use Linux kernel virtual servers.
    • Diptables mode uses netfilter/iptables rules in the Linux kernel to perform NAT-based service routing. While it operates in kernel space, it uses iptables chains rather than IPVS virtual server constructs.
  6. Question 6Storage

    What does the subPath field in a volumeMount let you do?

    • AMount a volume across two containers
    • BMount one subdirectory of a volumeCorrect
    • CMount a volume as strictly read-only
    • DMount a remote NFS export by itself
    ✓ Correct answer: B

    subPath lets a container mount just one directory or file from within a volume rather than the whole volume at the mount point. This is useful when several containers or paths share one volume but each needs a different subtree. The referenced subPath is created inside the volume if it does not exist.

    Why the other options are wrong
    • ASharing a volume between containers is normal mounting, not subPath's purpose.
    • CRead-only is set by the readOnly field, not by subPath.
    • DsubPath selects a path within an existing volume, not a new NFS source.
  7. Question 7Storage

    How do you handle shared storage for a Deployment with multiple replicas that all need read-write access?

    • AUse a PVC with ReadWriteOnce and pin all replicas to a single node with affinity
    • BUse an emptyDir volume so each replica mounts the shared scratch space
    • CUse a PVC with ReadWriteMany access mode backed by a shared filesystem like NFSCorrect
    • DGive each replica its own PVC provisioned from a shared StorageClass
    ✓ Correct answer: C

    When many Deployment replicas, possibly spread across nodes, must all write to the same volume, the volume must support read-write mounting from several nodes at once. The ReadWriteMany (RWX) access mode allows the same PersistentVolume to be mounted read-write by pods on multiple nodes simultaneously. RWX support depends on the volume type: shared file systems such as NFS or CephFS provide it, and for CSI volumes it depends on the driver. A single RWX PVC can then be referenced by every replica in the Deployment.

    Why the other options are wrong
    • AReadWriteOnce allows one node to mount read-write; pinning replicas defeats the purpose of scaling out.
    • BemptyDir is per-pod and node-local, so replicas cannot share the same data through it.
    • DSeparate per-replica PVCs give each pod isolated storage, not shared read-write access.
  8. Question 8Troubleshooting

    A pod status shows "Init:CrashLoopBackOff". What does this mean?

    • AThe pod is being initialized by the scheduler
    • BThe pod is waiting for a network plugin
    • CAn init container is repeatedly failing and restartingCorrect
    • DThe main application container is crashing
    ✓ Correct answer: C

    The Init: prefix in a pod status indicates the pod is still in its initialization phase running init containers, which must each complete successfully before the application containers start. The CrashLoopBackOff suffix means an init container has exited with a non-zero status and the kubelet is repeatedly restarting it with an increasing back-off delay. You diagnose this with kubectl logs <pod> -c <init-container-name> and kubectl describe pod to see which init container is failing and why.

    Why the other options are wrong
    • AThe pod is being initialized by the scheduler is incorrect because the scheduler only binds the pod to a node; it does not run init containers, and CrashLoopBackOff is a kubelet runtime state, not a scheduler state.
    • BThe pod is waiting for a network plugin is incorrect because a missing CNI surfaces as ContainerCreating with NetworkPluginNotReady events, not Init:CrashLoopBackOff.
    • DThe main application container is crashing is incorrect because a crashing app container shows plain CrashLoopBackOff without the Init: prefix, which specifically denotes the init phase; until the init container succeeds the main application containers never start.
  9. Question 9Storage

    A workload must consume a high-performance NVMe device as a raw block device (no filesystem) for its own database engine. The CSI driver supports block volumes. Which combination of fields correctly delivers a raw block device into the container?

    • ASet volumeMode: Block on the PVC (and PV/StorageClass), and reference the volume in the container under volumeDevices with a devicePathCorrect
    • BSet volumeMode: Filesystem on the PVC and mount it under volumeMounts with mountPath, then disable formatting via mountOptions
    • CUse a hostPath volume of type BlockDevice pointing at /dev/nvme0n1 and mount it with volumeMounts
    • DSet accessMode: ReadWriteOncePod on the PVC; this automatically presents the volume as a raw block device
    ✓ Correct answer: A

    Kubernetes supports two volume modes: Filesystem (the default, where the volume is formatted and mounted at a path) and Block, where an unformatted device is exposed to the container. To get a raw device you set spec.volumeMode: Block consistently on the PV/PVC, and in the pod the container references it under volumeDevices with name and devicePath (e.g., /dev/xvda), not volumeMounts. The application is then responsible for any formatting. This is the correct pattern for databases that manage their own block layout.

    Why the other options are wrong
    • BFilesystem mode formats and mounts the volume; volumeMounts cannot deliver a raw device, and mountOptions do not turn a filesystem volume into a block device.
    • ChostPath type BlockDevice only validates an existing host device and bypasses CSI dynamic provisioning and scheduling guarantees; it is not the portable way to consume a provisioned block volume.
    • DAccess modes control concurrency (which/how many consumers), not volumeMode; ReadWriteOncePod does not change a volume into block mode.
  10. Question 10Services and Networking

    A Service exposes two ports, 80 and 443, in spec.ports. What does the API require of the two port entries?

    • ANothing extra; the entries are told apart by their port numbers alone
    • BEach entry must set a targetPort that no other entry in the Service uses
    • CEach entry must set protocol explicitly, since TCP is assumed for one port only
    • DEach entry must have a name, and the names must be unique within the ServiceCorrect
    ✓ Correct answer: D

    When a Service defines more than one port, every entry in spec.ports must have a name, and all names within the Service must be unique so that the ports are unambiguous; the name is optional only when the Service has a single port. Other fields keep their defaults: protocol defaults to TCP, and if targetPort is not given it takes the value of port.

    Why the other options are wrong
    • APort numbers alone are not enough; the API requires every entry of a multi-port Service to carry a name.
    • BThe API reference requires unique names, not unique targetPort values, and targetPort defaults to the value of port when it is left out.
    • Cprotocol defaults to TCP on every entry, so it does not have to be set explicitly.

Who this CKA practice exam is for

This practice set is for anyone preparing for the CKA: Certified Kubernetes Administrator exam at the intermediate level - from first-time candidates building a foundation to experienced Cloud Native practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this CKA practice exam

  1. Start with the free sample questions above to gauge your current baseline.
  2. Read the full explanation on every question, including why each wrong option is wrong.
  3. Track your weak domains and focus your study where you are losing the most marks.
  4. Once you are scoring consistently well, take a timed, full-length mock exam.
  5. Treat your readiness score as knowledge readiness, then validate it with hands-on practice in a real environment before booking the CKA exam.

Related Cloud Native resources

CKA practice exam FAQ

How many questions are in the CKA practice exam on CertGrid?

CertGrid has 793 practice questions for CKA: Certified Kubernetes Administrator, covering 5 exam domains. The real CKA exam is a hands-on, performance-based lab exam (120 min). The real CKA exam is hands-on and performance-based. CertGrid provides a fixed 50-question MCQ practice session to test concepts, command decisions, and troubleshooting readiness. Practice in a real Kubernetes cluster before booking. CertGrid's MCQ readiness practice covers 50 questions.

Is CertGrid a hands-on Cloud Native lab simulator?

No. The real CKA exam is a hands-on, performance-based lab exam. CertGrid provides MCQ-style readiness practice to help you check concepts, commands, troubleshooting choices, and weak domains before doing hands-on labs - it is not a live lab simulator.

What is the passing score for CKA?

The CKA exam passing score is 66%, and you have about 120 min to complete it. CertGrid tracks your readiness across every objective so you know where to focus your hands-on lab practice.

Are these official CKA exam questions?

No. CertGrid is an independent practice platform. We do not provide real or leaked exam questions. Our questions are original and designed to help you practice the concepts, scenarios, and difficulty style of the CKA: Certified Kubernetes Administrator exam.

Is there a free CKA practice test?

Yes. You can take a free CKA: Certified Kubernetes Administrator practice test straight away: a fixed set of 20 practice questions for this exam, retryable as often as you like, with no credit card required. You get readiness scoring and a weak-domain breakdown on those questions. Paid plans unlock the full 793-question bank, timed mock exams and full-bank domain analytics.

What CertGrid is (and is not)

CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.

Independent & original. CertGrid is an independent practice platform and is not affiliated with or endorsed by the Cloud Native Computing Foundation. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.