CKA Troubleshooting Practice Test 2 — 15 Questions

Question 1

A pod is stuck in Pending state. 'kubectl describe pod' shows '0/2 nodes are available: 1 node(s) had taint that the pod didn't tolerate, 1 node(s) didn't match pod anti-affinity rules'. What should you check?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The node's taints and the pod's tolerations. The error message explicitly states that nodes are unavailable due to taints and anti-affinity rules. Taints and tolerations control which pods can be scheduled on which nodes; if a pod lacks the necessary toleration for a node's taint, it cannot be scheduled there. Therefore, checking the node's taints and the pod's tolerations is the direct and correct troubleshooting step.

Answer

The pod's resource requests

Answer

The pod's image pull policy

Answer

The pod's liveness probe configuration

Question 2

Which command shows all events in the cluster sorted by timestamp?

Accepted Answer

kubectl get events --sort-by=.metadata.creationTimestamp. To display all events in the cluster sorted by timestamp, the correct command would be `kubectl get events --all-namespaces --sort-by=.metadata.creationTimestamp` (or `kubectl get events -A --sort-by=.metadata.creationTimestamp`). The B option as written only shows events in the current namespace. The sorting itself by `.metadata.creationTimestamp` is valid and lists events in chronological order (oldest first), but the scope is incomplete for the question's wording.

Answer

kubectl get events --watch

Answer

kubectl logs --events

Answer

kubectl describe events

Question 3

You suspect that the kube-scheduler is not running. Which command checks the scheduler's health?

Accepted Answer

kubectl get componentstatuses. `kubectl get componentstatuses` (or `cs`) queries the Kubernetes API server for the health of core control plane components, including the scheduler. The API server periodically performs a health check against each component and reports its status as Healthy or Unhealthy. This command directly shows whether the scheduler is reachable and responding, making it the appropriate diagnostic tool when you suspect the scheduler is down.

Answer

systemctl status kube-scheduler

Answer

kubectl get pods -n kube-system | grep scheduler

Answer

kubectl describe node

Question 4

Which TWO of the following are valid reasons for a pod to be in the Pending state? (Choose two)

Accepted Answer

The pod's PersistentVolumeClaim is not bound. Option A is correct because the scheduler cannot place a pod whose PersistentVolumeClaim is not yet bound to a PersistentVolume; the pod remains Pending until the PVC is satisfied. Option B is correct because if no node has enough allocatable CPU or memory to satisfy the pod's resource requests, the scheduler leaves the pod in Pending with a FailedScheduling event. Option C is not a Pending cause: an incorrect image name leads to ImagePullBackOff/ErrImagePull after the pod is scheduled, so the pod is Running/Pending only briefly and shows a waiting container state. Option D is not a Pending cause: a failing liveness probe occurs after the container starts and triggers restarts, not scheduling failure. Option E is not a Pending cause: a container command that fails immediately produces CrashLoopBackOff after scheduling, not a Pending phase.

Answer

The pod's image name is incorrect

Answer

The pod's liveness probe is failing

Answer

The container command fails immediately

Question 5

You need to check the logs of a container that previously ran but has crashed. Which command would you use?

Accepted Answer

kubectl logs pod --previous. Both options A and B are correct because `--previous` and its shorthand `-p` are equivalent flags that retrieve logs from the previous instance of a crashed or restarted container. When a container terminates and is restarted by Kubernetes, the logs of the terminated container are preserved and can be accessed using either flag. This is essential for debugging why the container failed. Option C (`--all-containers`) retrieves logs from all containers in a pod but not specifically the previous instance. Option D (`kubectl describe pod`) provides pod status and events but does not retrieve container logs.

Answer

kubectl logs pod --all-containers

Answer

kubectl describe pod

Question 6

You run 'kubectl get pods' and see a pod in CrashLoopBackOff. The pod has a single container. You want to see the last termination message from the container. Which command will provide that information?

Accepted Answer

kubectl describe pod. `kubectl describe pod` includes a `Last State: Terminated` section that shows the exit code, reason, and the termination message from the container's last run. This message is stored in the container's `terminationMessagePath` (default `/dev/termination-log`) and is captured even if the container has already exited, unlike logs which may be lost after restart.

Answer

kubectl events pod

Answer

kubectl get pod -o yaml

Answer

kubectl logs pod --tail=50

Question 7

Which command shows all events in the cluster sorted by timestamp?

Accepted Answer

kubectl get events --sort-by=.metadata.creationTimestamp. According to the official Kubernetes Cheat Sheet, the standard and documented command to list events sorted by timestamp is `kubectl get events --sort-by='.metadata.creationTimestamp'`. While modern versions of kubectl apply some default sorting, using the explicit `--sort-by` flag is the precise, guaranteed, and exam-expected method.

Answer

kubectl describe events

Answer

kubectl get events

Answer

kubectl logs --all-namespaces

Question 8

Which TWO of the following are common causes for a pod to be stuck in Pending state?

Accepted Answer

Node taints that the pod does not tolerate. Option A is correct because if a node has a taint (e.g., node-role.kubernetes.io/master:NoSchedule) that the pod's tolerations do not match, the scheduler cannot bind the pod to any node, leaving it in Pending. Option B is correct because when no node has enough allocatable CPU or memory to satisfy the pod's resource requests, the kube-scheduler cannot find a feasible node and the pod remains Pending. Option C is not a cause of Pending; ImagePullBackOff occurs after the pod has been scheduled to a node, so the pod is in Running/Waiting state, not Pending. Option D is not a direct cause of Pending; a Pending PVC can block a pod from starting, but the pod itself typically stays in Pending only as a scheduling consequence, and the question asks for common causes of the pod's Pending state, not the PVC's. Option E is not a cause of Pending; OOMKilled is a container termination reason that occurs after the pod has been scheduled and started, resulting in CrashLoopBackOff or Error, not Pending.

Answer

Image pull failure (ImagePullBackOff)

Answer

PersistentVolumeClaim is in Pending state

Answer

Container exited with OOMKilled

Question 9

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The 'OOMKilled' status indicates the container was terminated because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to use more memory without being killed by the Out-of-Memory (OOM) killer. This directly addresses the root cause of the CrashLoopBackOff state.

Answer

Delete the namespace and redeploy all workloads

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Question 10

You need to verify if the kube-apiserver is running on the control plane node. Which command should you use?

Accepted Answer

kubectl get pods -n kube-system. The kube-apiserver runs as a static pod in the kube-system namespace on the control plane node. Using `kubectl get pods -n kube-system` lists all control plane components, including the kube-apiserver, allowing you to verify its running status directly via the Kubernetes API.

Answer

kubectl describe node controlplane

Answer

kubectl get services -n default

Answer

systemctl status kube-apiserver

Question 11

A pod is in 'CrashLoopBackOff' state. You run 'kubectl logs my-pod' and see 'exec format error: exec: "/app": stat /app: no such file or directory'. What is the most likely cause?

Accepted Answer

The container image is missing the specified command or entrypoint. The error 'exec: "/app": stat /app: no such file or directory' indicates that the container's entrypoint or command (in this case, '/app') does not exist inside the container image at the specified path. This typically happens when the Pod spec's 'command' or the image's 'ENTRYPOINT'/'CMD' references a file that is missing or misspelled. Note that because the container failed to start entirely, this error is found in the pod's events or status via 'kubectl describe pod', rather than in the application logs via 'kubectl logs'.

Answer

The container has insufficient memory

Answer

The container runtime is not installed

Answer

The pod's service account lacks permissions

Question 12

Which THREE of the following are valid methods to troubleshoot a CrashLoopBackOff pod?

Accepted Answer

Run 'kubectl describe pod' to check events. Option B is correct because 'kubectl describe pod' surfaces the pod's Events section, which shows the kubelet's reasons for restarting the container (e.g., Back-off restarting failed container, OOMKilled, or image pull errors), making it a primary troubleshooting step. Option D is correct because 'kubectl logs pod --previous' retrieves the logs from the prior terminated container instance, which is essential since the current container may not have started or may have already crashed. Option A is not valid because a pod in CrashLoopBackOff has no running container to attach to, so 'kubectl exec' typically fails with a container-not-running error. Option C is not a troubleshooting method; deleting and recreating the pod does not diagnose the root cause and may simply reproduce the same crash. Option E is not valid because scaling the deployment to zero replicas only stops the workload and provides no diagnostic information about why the container is crashing.

Answer

Run 'kubectl exec -it pod -- bash' and inspect the container

Answer

Run 'kubectl delete pod' and recreate it

Answer

Run 'kubectl scale deployment --replicas=0'

Question 13

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The OOMKilled status indicates the container was terminated by the Linux Out-of-Memory (OOM) killer because it exceeded its memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause of the crash loop.

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Question 14

You have a multi-node cluster. One node is healthy but pods scheduled on another node are failing to resolve DNS names. You exec into a pod and run 'nslookup kubernetes.default.svc.cluster.local' and get 'server can't find kubernetes.default.svc.cluster.local: NXDOMAIN'. Running the same command on a pod on the healthy node works. What is the MOST likely cause?

Accepted Answer

The CoreDNS pod is not scheduled on that node, and network policy blocks cross-node DNS traffic. The CoreDNS pod runs as a Deployment and may not be scheduled on every node. If a network policy (or a misconfigured CNI plugin) blocks DNS traffic from the failing node to the node hosting the CoreDNS pod, the DNS resolution fails. The fact that `nslookup` works from a pod on the healthy node confirms that the CoreDNS service itself is functional, isolating the issue to cross-node connectivity.

Answer

The container runtime on the failing node is misconfigured

Answer

The kube-dns service is not running in the cluster

Answer

The node's /etc/resolv.conf is pointing to an external DNS server

Question 15

Which TWO of the following are possible reasons for a node being in 'NotReady' state?

Accepted Answer

The kubelet service has stopped on the node. Option B is correct because the kubelet is the node agent that registers the node with the API server and continuously posts node status via heartbeats; if the kubelet service stops, the node's status updates cease and the node controller marks it NotReady. Option D is correct because the node's Ready condition depends on the Container Network Interface (CNI) plugin (e.g., Calico, Flannel) being functional; if the network plugin fails, the kubelet reports NetworkUnavailable and the node transitions to NotReady. Option A is incorrect because an outdated kernel version alone does not cause NotReady; the kernel must be incompatible with required features (e.g., missing cgroups or overlayfs support) to affect node readiness. Option C is incorrect because a full disk typically triggers DiskPressure and eviction of pods, but does not by itself set the node to NotReady unless it prevents the kubelet from functioning. Option E is incorrect because insufficient CPU resources cause scheduling failures or pod evictions, not a NotReady node condition.

Answer

The node is running an outdated kernel version

Answer

The node's disk is full

Answer

The node has insufficient CPU resources