CKA Troubleshooting Practice Test 19 — 15 Questions

Question 1

You want to check the status of the kube-apiserver on a control plane node. Which commands should you use? (Select the best option)

Accepted Answer

systemctl status kube-apiserver or crictl ps | grep kube-apiserver. On a control plane node, the kube-apiserver runs either as a systemd service or as a static pod managed by the kubelet. If it runs as a systemd service, you check its status using 'systemctl status kube-apiserver'. If it runs as a static pod (as in kubeadm-based clusters), you must inspect the container runtime directly using 'crictl ps | grep kube-apiserver' (or 'docker ps' on older clusters) because 'kubectl' commands will fail if the API server is unresponsive.

Answer

journalctl -u kubelet

Answer

ps aux | grep kube-apiserver

Answer

docker ps | grep kube-apiserver

Question 2

You are troubleshooting a node that is 'NotReady'. Which THREE of the following are possible causes? (Choose three.)

Accepted Answer

The kubelet cannot contact the API server. The kubelet is the primary node agent that communicates with the API server to report node status, heartbeats, and pod lifecycle events. If the kubelet cannot reach the API server (e.g., due to network partition, TLS certificate issues, or API server downtime), it cannot send the periodic NodeStatus updates, and the control plane marks the node as 'NotReady' after the `node-monitor-grace-period` (default 40 seconds) expires.

Answer

The node has disk pressure

Answer

A pod on the node is consuming excessive memory

Question 3

A pod is in 'Pending' state. 'kubectl describe pod' shows: '0/3 nodes are available: 1 Insufficient memory, 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' Which THREE actions would resolve the issue? (Choose three)

Accepted Answer

Remove the taint from the control-plane nodes.. The pod cannot be scheduled because one node lacks memory and two nodes have a control-plane taint. Any single action that resolves either the memory issue (decreasing memory request) or the taint issue (removing taint or adding toleration) will make a node available. Since the question asks for three actions, A, B, and D are the correct choices as each independently resolves the scheduling block. Options C and E do not address the reported problems.

Answer

Increase the CPU request of the pod.

Answer

Add a node selector to the pod that matches the control-plane nodes.

Question 4

A pod has been restarted multiple times. You want to see the logs from the previous (terminated) container instance. Which command should you use?

Accepted Answer

kubectl logs my-pod -p. The `kubectl logs` command retrieves logs for a container in a pod. To view the logs of a previously terminated container instance, you must use either the `--previous` or `-p` flag. To ensure there is only one correct option, we will change Option D to use an invalid flag (`--past`), leaving Option C (`-p`) as the sole correct answer.

Answer

kubectl logs my-pod -c --previous

Answer

kubectl logs my-pod --tail=100

Answer

kubectl logs my-pod --past

Question 5

A pod is in Pending state. You see the event: '0/2 nodes are available: 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate'. What should you do to schedule the pod on one of the control-plane nodes?

Accepted Answer

Add a toleration to the pod spec matching the taint. The pod is in Pending state because the control-plane nodes have a taint (node-role.kubernetes.io/control-plane) that the pod does not tolerate. By default, pods are not scheduled on control-plane nodes unless they explicitly tolerate that taint. Adding a toleration to the pod spec that matches the taint's key, effect, and optionally value allows the scheduler to place the pod on a control-plane node.

Answer

Increase the pod's resource requests

Answer

Remove the taint from the control-plane node

Answer

Use a different namespace

Question 6

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. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification. Option A would delete the namespace and all workloads, which is too drastic and would affect other pods. Option B increases CPU request, which does not address the memory issue. Option D deletes and recreates the pod without fixing the resource limits, so the crash loop would continue.

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 7

You attempt to schedule a pod but it remains 'Pending'. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) didn't match node selector.' What is the MOST likely cause?

Accepted Answer

The pod's nodeSelector does not match any node labels. The error '0/3 nodes are available: 3 node(s) didn't match node selector' directly indicates that the pod has a nodeSelector that does not match any node's labels. Option A (PVC not bound) would show a different error like 'persistentvolumeclaim not found'. Option B (insufficient resources) would show 'Insufficient memory/cpu'. Option C (taints not tolerated) would show 'node(s) had taints'. Therefore, the most likely cause is that the pod's nodeSelector does not match any node labels, which is Option D.

Answer

A PersistentVolumeClaim is not bound

Answer

All nodes have insufficient memory or CPU

Answer

The nodes have taints that the pod does not tolerate

Question 8

A pod is in 'ImagePullBackOff' state. Which of the following is NOT a common cause?

Accepted Answer

The container requires more memory than the limit allows. Insufficient memory would cause OOMKilled, not ImagePullBackOff. ImagePullBackOff is caused by issues pulling the container image: wrong image name (C), nonexistent tag (B), authentication failure (A), or registry unreachable. Options A, B, and C are all common causes of ImagePullBackOff.

Answer

The image registry requires authentication and no imagePullSecrets are configured

Answer

The image tag does not exist

Answer

The image name is misspelled

Question 9

You need to check the logs of a kubelet on a node. Which command should you run on the node?

Accepted Answer

journalctl -u kubelet. The correct command to view kubelet logs on a systemd-based node is 'journalctl -u kubelet'. Option D is correct. Option A ('journalctl -u docker') shows Docker daemon logs, not kubelet. Option B ('dmesg') displays kernel ring buffer messages. Option C ('tail -f /var/log/apache2/access.log') shows Apache web server logs.

Answer

journalctl -u docker

Answer

dmesg

Answer

tail -f /var/log/apache2/access.log

Question 10

You are troubleshooting a DNS issue in the cluster. You exec into a pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command returns 'server can't find kubernetes.default.svc.cluster.local: NXDOMAIN'. What is the MOST likely cause?

Accepted Answer

The CoreDNS pod(s) are not running or are misconfigured. NXDOMAIN indicates that the DNS server does not have a record for that name. The most common cause is that the CoreDNS pod(s) are not running or are misconfigured. Option A would cause a timeout not NXDOMAIN. Option B would cause a different error (connection refused). Option D might cause partial resolution but not NXDOMAIN for the entire service name.

Answer

The kube-dns service does not exist

Answer

The pod's /etc/resolv.conf points to an external DNS server instead of the cluster DNS

Answer

The pod's network policy blocks DNS traffic

Question 11

A pod is in 'Pending' state. Which TWO of the following are possible causes? (Select 2)

Accepted Answer

Node has insufficient CPU or memory resources. Options A and C are correct. A pod remains in 'Pending' state when it cannot be scheduled or when required resources are not available. Insufficient CPU or memory resources (A) prevent the scheduler from placing the pod. An unbound PersistentVolumeClaim (C) causes the pod to wait until the claim is bound. Option B: container exited with non-zero exit code would result in a CrashLoopBackOff or error state, not Pending. Option D: container killed due to OOM would cause the container to restart and enter CrashLoopBackOff. Option E: misspelled image name leads to ImagePullBackOff, not Pending.

Answer

Container exited with non-zero exit code

Answer

Container was killed due to OOM

Answer

Image name is misspelled

Question 12

You are troubleshooting a scenario where a pod cannot communicate with another pod in the same namespace via service name. Which THREE steps would you take to diagnose the issue? (Select 3)

Accepted Answer

Run 'kubectl get endpoints' to verify the service has healthy endpoints. Options B, C, and E are correct. Checking endpoints (B) verifies the service has healthy pods. Exec into the pod and using curl (C) tests connectivity to the service's cluster IP. Exec into the pod and running nslookup (E) checks DNS resolution of the service name. Option A checks node status, which is not directly related to pod-to-pod communication via service name. Option D checks logs of the target pod, which may not reveal network issues.

Answer

Run 'kubectl get nodes' to check node status

Answer

Run 'kubectl logs' on the target pod to check application logs

Question 13

A node is in 'NotReady' state. Which TWO of the following are common causes? (Select 2)

Accepted Answer

The kubelet service has stopped on the node. Options C and E are correct. A node becomes 'NotReady' when the kubelet stops reporting its status (C) or when the network plugin (e.g., Calico, Flannel) fails, preventing pod networking (E). Option A (ImagePullBackOff) is a pod-level issue and does not affect node status. Option B (insufficient memory) leads to pod eviction but the node remains Ready if kubelet is healthy. Option D (API server down) affects the entire cluster, but nodes may still show Ready if kubelet is functioning.

Answer

A pod on the node is in ImagePullBackOff

Answer

The node has insufficient memory

Answer

The Kubernetes API server is down

Question 14

A pod remains in Pending state. You run 'kubectl describe pod mypod' and see the following event: '0/3 nodes are available: 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 1 node(s) didn't match pod anti-affinity rules.' What is the best action to schedule the pod?

Accepted Answer

Modify the pod's anti-affinity rules or remove the conflicting pod on the third node. The pod is unschedulable because one node has a pod anti-affinity rule conflict, and the other two nodes have a control-plane taint. The best action is to modify the pod's anti-affinity rules (e.g., relax the requiredDuringSchedulingIgnoredDuringExecution constraint) or remove the conflicting pod on the third node, as this directly resolves the scheduling conflict without affecting the control-plane taint or replicas.

Answer

Increase the number of replicas

Answer

Remove the node.kubernetes.io/control-plane taint from the control plane nodes

Answer

Add a toleration for the control-plane taint to the pod spec

Question 15

You are troubleshooting a node that shows 'NotReady' status. Which TWO commands can help you investigate the kubelet state?

Accepted Answer

journalctl -u kubelet. journalctl -u kubelet (C) retrieves kubelet logs from the systemd journal, showing errors and warnings. systemctl status kubelet (D) displays the current status of the kubelet service, including whether it is running, enabled, and recent log entries. The other options: 'kubectl get nodes' (A) shows node status but not kubelet details; 'journalctl -u docker' (B) shows container runtime logs, not kubelet; 'kubectl describe pod' (E) is for pod details, not node-level kubelet troubleshooting.

Answer

kubectl get nodes

Answer

journalctl -u docker

Answer

kubectl describe pod