CKA: Certified Kubernetes Administrator Practice Exam

What the CKA exam covers

• Cluster Architecture Installation and Configuration182 questions
• Workloads and Scheduling174 questions
• Services and Networking162 questions
• Storage158 questions
• Troubleshooting164 questions

Free CKA sample questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 840.

1. Question 1Storage

   Which field in a PVC requests a minimum storage size?

   • Aspec.resources.requests.storageCorrect
   • Bspec.capacity.storage
   • Cspec.minimumStorage
   • Dspec.storage.size
   ✓ Correct answer: A

   The spec.resources.requests.storage field in a PersistentVolumeClaim specifies the minimum amount of storage the claim requires.

   Why the other options are wrong

   • BWhen the PVC is processed, Kubernetes either binds it to an existing PersistentVolume whose capacity is at least this value, or triggers dynamic provisioning through the StorageClass to create one. The PVC uses the same ResourceRequirements structure as a Pod's resource requests, so storage is expressed under resources.requests just like cpu or memory.
   • Cspec.minimumStorage is incorrect because no such field exists in the PVC schema; the request is always expressed through resources.requests.storage. spec.storage.size is incorrect because there is no spec.storage object on a PVC; storage size is nested under resources.requests, not a storage.size path.
   • DThe bound PV will report at least the requested capacity in its spec.capacity.storage. spec.capacity.storage is incorrect because that field belongs to the PersistentVolume object and describes the actual capacity of the volume, not what a claim requests.
2. Question 2Storage

   You need to expand a PVC from 10Gi to 20Gi. kubectl edit pvc shows the change is saved, but the actual volume size doesn't change. What is likely missing?

   • AThe StorageClass must have allowVolumeExpansion: true, and for filesystem volumes, the pod may need to be restartedCorrect
   • BThe node needs more disk space
   • CThe PV needs to be deleted first
   • DPVCs cannot be expanded
   ✓ Correct answer: A

   Editing a PVC's requested size only takes effect when the governing StorageClass has allowVolumeExpansion: true; otherwise the API blocks the change and the backing volume never grows. Even after the external-resizer enlarges the underlying volume, a filesystem-mode volume must also have its filesystem expanded, and for many drivers this file-system resize occurs when the volume is (re)mounted, so restarting the pod completes the expansion. Until both the block device and the filesystem are grown, the pod continues to see the old size. The PVC's status.conditions will show FileSystemResizePending in this state.

   Why the other options are wrong

   • BThe node needs more disk space is incorrect because the volume is backed by the storage provider, and the limiting factor is the StorageClass expansion setting plus filesystem resize, not node disk.
   • CThe PV needs to be deleted first is incorrect because expansion grows the existing volume in place; deleting the PV would destroy data and is never required.
   • DPVCs cannot be expanded is incorrect because PVCs can be expanded (grown) whenever allowVolumeExpansion is enabled and the driver supports resizing.
3. Question 3TroubleshootingSelect all that apply

   Which of the following could cause a Pod to remain in 'Pending' state? (Select THREE)

   • AAn unbound PersistentVolumeClaim referenced by the PodCorrect
   • BNo node matches the Pod's nodeSelectorCorrect
   • CInsufficient CPU or memory on all nodesCorrect
   • DThe container image does not exist
   • EA readiness probe failure
   ✓ Correct answer: A, B, C

   No node matches the Pod's nodeSelector Insufficient CPU or memory on all nodes A pod stays Pending whenever the scheduler cannot bind it to a node. An unbound PVC blocks scheduling because the pod cannot be placed until its storage is provisioned and bound, a nodeSelector with no matching node leaves the scheduler with zero eligible candidates, and insufficient CPU or memory on every node fails the resource fit predicate. All three are pre-binding conditions evaluated by the scheduler, so each keeps the pod in Pending until the constraint is resolved.

   Why the other options are wrong

   • DThe container image does not exist is incorrect because image problems arise only after the pod is scheduled to a node, producing ImagePullBackOff rather than keeping the pod Pending.
   • EA readiness probe failure is incorrect because readiness probes execute after the container is already running on a node, so they affect Service endpoint membership rather than scheduling.
4. Question 4TroubleshootingSelect all that apply

   RapidScale Inc notices that a node is in 'NotReady' state. Which of the following could be causes of this condition? (Select THREE)

   • AThe node cannot communicate with the API serverCorrect
   • BThe container runtime on the node is not respondingCorrect
   • CThe node has run out of disk space
   • DA pod on the node has crashed
   • EThe kubelet service on the node has stoppedCorrect
   ✓ Correct answer: A, B, E

   The container runtime on the node is not responding The kubelet service on the node has stopped A node's Ready status depends on the kubelet posting periodic heartbeats (node status/Lease) to the API server and on the kubelet reporting that its core components are healthy. If the kubelet is stopped it sends no heartbeats, if the node cannot reach the API server the heartbeats never arrive, and if the container runtime (containerd/CRI) is unresponsive the kubelet marks the node NotReady because it cannot manage containers. After the heartbeat grace period the node-controller flips the node to NotReady, which is why these three conditions all produce that state.

   Why the other options are wrong

   • CThe node has run out of disk space is incorrect because exhausted disk sets the DiskPressure condition and triggers eviction, but the node generally remains Ready unless the kubelet or runtime itself fails; low disk by itself does not make a node NotReady.
   • DA pod on the node has crashed is incorrect because an individual pod crash (e.g., CrashLoopBackOff) is a workload-level problem isolated to that pod and does not affect the node's Ready status reported by the kubelet.
5. Question 5Troubleshooting

   Which kubectl command shows the resource usage (CPU and memory) of all Pods in a namespace?

   • Akubectl get pods -n <namespace>
   • Bkubectl status pods -n <namespace>
   • Ckubectl describe pods -n <namespace>
   • Dkubectl top pods -n <namespace>Correct
   ✓ Correct answer: D

   The kubectl top pods command displays live CPU and memory consumption for pods, and adding -n <namespace> scopes the output to a specific namespace. It queries the Metrics API (metrics.k8s.io) served by the Metrics Server, which aggregates real usage data sampled from each node's kubelet. This gives an at-a-glance view of actual resource utilization, distinct from the requests and limits declared in the pod spec.

   Why the other options are wrong

   • Akubectl get pods -n <namespace> is incorrect because it lists pods with their phase, readiness, and restart counts but does not report CPU or memory usage.
   • Bkubectl status pods -n <namespace> is incorrect because there is no kubectl status subcommand; it is not a valid kubectl verb.
   • Ckubectl describe pods -n <namespace> is incorrect because describe shows configuration, events, and resource requests/limits but not the live measured CPU and memory utilization.
6. Question 6Troubleshooting

   A container keeps crashing. kubectl logs shows "Error: database connection refused at 10.96.0.15:5432". What should you check first?

   • AWhether the pod has a resource limit
   • BWhether the node has network hardware issues
   • CWhether the container image is correct
   • DWhether the database service exists and has endpointsCorrect
   ✓ Correct answer: D

   The error "database connection refused at 10.96.0.15:5432" shows the application reached a ClusterIP in the service network (10.96.0.0 range) but no backend accepted the connection, which is the classic symptom of a Service that has no ready endpoints. You should verify that the database Service exists and that its selector matches running, ready database pods by checking kubectl get endpoints (or endpointslices); an empty endpoints list means kube-proxy has nowhere to forward traffic, producing connection refused. The crash is therefore a downstream dependency problem, not a fault in the crashing pod itself. Fixing the Service selector or starting the database pods resolves it.

   Why the other options are wrong

   • AWhether the pod has a resource limit is incorrect because resource limits affect throttling and OOM behavior, not whether a TCP connection to a database IP is refused.
   • BWhether the node has network hardware issues is incorrect because the connection reached a cluster ClusterIP and was actively refused, indicating reachable networking but no listening backend rather than hardware failure.
   • CWhether the container image is correct is incorrect because the application clearly started and attempted the connection, so the image runs; the problem is the unavailable database endpoint.
7. Question 7Troubleshooting

   kubectl get nodes shows a node in "NotReady" status. What is the first thing you should check on the node?

   • AWhether the kube-proxy DaemonSet is healthy
   • BWhether the container images are cached
   • CWhether the kubectl binary is installed
   • DWhether the kubelet service is running: systemctl status kubeletCorrect
   ✓ Correct answer: D

   The kubelet is the per-node agent that registers the node with the API server and continuously posts heartbeats (node lease updates and status). When the kubelet stops or cannot communicate, the node controller stops receiving heartbeats and marks the node NotReady after the grace period. Therefore the first diagnostic step is to confirm the kubelet is actually running on the node with systemctl status kubelet, and to inspect its logs with journalctl -u kubelet if it has failed. A dead or crash-looping kubelet is the most common direct cause of a NotReady node.

   Why the other options are wrong

   • AWhether the kube-proxy DaemonSet is healthy is incorrect because kube-proxy programs service networking rules and its failure does not change a node's Ready condition, which is reported by the kubelet.
   • BWhether the container images are cached is incorrect because image caching affects pod startup speed, not node readiness reported via kubelet heartbeats.
   • CWhether the kubectl binary is installed is incorrect because kubectl is a client tool not required on worker nodes; its absence has no effect on whether the kubelet reports the node Ready.
8. Question 8Troubleshooting

   After editing /etc/kubernetes/manifests/kube-apiserver.yaml, the API server does not come back up. How do you check what went wrong?

   • ARun docker ps to find the container
   • Bcheck the kubelet logs with journalctl -u kubelet since the kubelet manages static podsCorrect
   • Ccheck /var/log/kube-apiserver.log
   • Dkubectl describe pod kube-apiserver
   ✓ Correct answer: B

   check the kubelet logs with journalctl -u kubelet since the kubelet manages static pods.

   Why the other options are wrong

   • ARun docker ps to find the container is incorrect because modern kubeadm clusters use containerd with crictl rather than Docker, so docker ps will not list the containers on most current nodes. check /var/log/kube-apiserver.log is incorrect because the API server runs in a container and does not write to a fixed host log file at that path by default.
   • CThe kube-apiserver runs as a static pod whose lifecycle is owned entirely by the kubelet, so when the manifest is malformed or the container fails to start, the API server itself is unavailable and cannot surface its own logs. The kubelet logs the parsing and startup attempts for static pods, including syntax errors in the manifest and crash details, which you retrieve with journalctl -u kubelet on the control plane node. Because the API server is down, kubectl is also unavailable, leaving the kubelet logs and container runtime as the only diagnostic sources. Reviewing these logs reveals whether the manifest failed validation or the container is crash-looping.
   • Dkubectl describe pod kube-apiserver is incorrect because kubectl depends on a working API server, which is exactly the component that is down, so the command cannot connect.
9. Question 9Troubleshooting

   You run kubectl get events -n production and see "FailedMount: secret "db-password" not found." How do you fix this?

   • AChange the volume type to configMap
   • BCreate the secret "db-password" in the production namespaceCorrect
   • CRemove the volume mount from the pod spec
   • DCreate the secret in the kube-system namespace
   ✓ Correct answer: B

   The FailedMount event "secret \"db-password\" not found" means a pod in the production namespace references a Secret volume (or secretRef) named db-password that does not exist in that namespace, so the kubelet cannot mount it and the pod stays stuck. Secrets are namespace-scoped, so the pod can only consume a Secret that lives in its own namespace; creating db-password in production with the required data resolves the mount. Once the Secret exists, the kubelet retries the mount and the pod proceeds to start. You can create it with kubectl create secret generic db-password -n production with the appropriate key/value data.

   Why the other options are wrong

   • AChange the volume type to configMap is incorrect because the pod legitimately needs the secret data, and switching to a ConfigMap neither supplies that data nor is appropriate for sensitive credentials.
   • CRemove the volume mount from the pod spec is incorrect because the application depends on the password, so removing the mount would break the workload rather than fix the missing Secret.
   • DCreate the secret in the kube-system namespace is incorrect because Secrets are not shared across namespaces; a Secret in kube-system is invisible to a pod running in production.
10. Question 10Cluster Architecture Installation and Configuration

    When implementing Installation practices in Cluster Architecture Installation and Configuration, which approach is recommended?

    • ASkip planning and configure based on assumptions
    • BFollow documented best practices and vendor guidelinesCorrect
    • CUse default settings without any review or modification
    • DImplement untested solutions found in online forums
    ✓ Correct answer: B

    Following documented best practices and vendor guidelines for installation ensures the cluster is built on validated, repeatable configurations that account for version compatibility, supported topologies, and security baselines. Official Kubernetes and distribution documentation captures hard-won operational knowledge such as proper kubeadm initialization, certificate management, and component versioning, reducing the risk of misconfiguration. Adhering to these guidelines also keeps the environment supportable and aligned with upgrade paths. This produces a predictable, maintainable cluster rather than a fragile one.

    Why the other options are wrong

    • ASkip planning and configure based on assumptions is incorrect because unplanned configuration commonly produces version mismatches, missing prerequisites, and security gaps that cause failed or unstable installations.
    • CUse default settings without any review or modification is incorrect because defaults are not tailored to a specific environment's scale, networking, or security needs and can leave the cluster misconfigured or insecure.
    • DImplement untested solutions found in online forums is incorrect because unverified forum advice may target different versions or contexts and can introduce subtle, hard-to-diagnose failures.

CKA practice exam FAQ