CKA Troubleshooting Practice Test 8 — 15 Questions

Question 1

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. Correct answer is B. DNS resolution relies on CoreDNS pods. If the CoreDNS pod is not running on that node, or the pod cannot reach it due to network policy, DNS will fail. Option A would affect both nodes. Option C would affect all pods. Option D is not typical; nodes usually use the same DNS config.

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 2

You run 'kubectl get pods' and see a pod in 'CrashLoopBackOff'. You want to see the logs of the last crashed instance. Which command should you run?

Accepted Answer

kubectl logs pod-name --previous. Correct answer is A. 'kubectl logs pod-name --previous' shows logs of the previous container instance. Option B shows current logs. Option C is incorrect flag. Option D shows logs of all containers, not previous.

Answer

kubectl logs pod-name --all-containers

Answer

kubectl logs pod-name -p

Answer

kubectl logs pod-name

Question 3

Which command can you run to see the events related to a specific pod?

Accepted Answer

kubectl describe pod pod-name. Correct answer is A. 'kubectl describe pod pod-name' includes events at the bottom. Option B shows all events cluster-wide. Option C is for logs. Option D shows pod status briefly.

Answer

kubectl logs pod-name

Answer

kubectl get pod pod-name

Answer

kubectl get events

Question 4

You have a pod that is stuck in 'Pending' state. Running 'kubectl describe pod' shows the event: '0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 node(s) didn't match pod anti-affinity rules.' What is the MOST likely solution?

Accepted Answer

Remove or modify the pod anti-affinity rules. Correct answer is C. The pod has anti-affinity rules that prevent it from being scheduled on the two nodes, and the third node has a taint. The solution is to remove the anti-affinity rules or adjust them. Option A is not correct because tolerating the master taint would still leave the anti-affinity issue. Option B is not specific enough. Option D is incorrect because the node is not unschedulable.

Answer

Cordon the master node to remove it from scheduling

Answer

Add a toleration for the master taint to the pod spec

Answer

Delete and recreate the pod

Question 5

Which TWO of the following are valid steps to troubleshoot a pod that is in 'CrashLoopBackOff'?

Accepted Answer

Run 'kubectl logs pod-name --previous' to view logs from the previous crash. Correct answers are A and C. Checking logs and describing the pod are standard troubleshooting steps. B is not directly helpful. D is not a troubleshooting step. E is not a command.

Answer

Run 'kubectl exec -it pod-name -- /bin/bash' to inspect the container

Answer

Run 'kubectl rollout restart deployment/pod-name'

Answer

Run 'kubectl delete pod pod-name' to force restart

Question 6

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. Correct answers are B and C. Kubelet stopped or network plugin issues are common causes. A would cause scheduling issues but node would still be Ready. D is not a direct cause. E is not a direct cause.

Answer

The node is running an outdated kernel version

Answer

The node's disk is full

Answer

The node has insufficient CPU resources

Question 7

Which THREE of the following are possible causes for a pod to remain in 'Pending' state?

Accepted Answer

A PersistentVolumeClaim used by the pod is not bound. Correct answers are A, B, and D. Resource constraints, taint/toleration issues, and PVC not bound are common causes. C would cause CrashLoopBackOff, not Pending. E would cause the pod to run.

Answer

The container image is not found and the pod is in ImagePullBackOff

Answer

The container's startup command is misconfigured

Question 8

A node in your cluster is reporting 'NotReady' status. You log into the node and run 'systemctl status kubelet'. The kubelet service is not running. Which command should you use to start the kubelet and enable it to start on boot?

Accepted Answer

systemctl enable --now kubelet. The correct command is 'systemctl enable --now kubelet' which enables the service to start on boot and starts it immediately. Option A does not start it immediately. Option B is for restarting, not starting from stopped. Option D is incorrect syntax.

Answer

systemctl start --enable kubelet

Answer

systemctl enable kubelet

Answer

systemctl start kubelet

Question 9

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. Which command would help you determine the exact reason for the image pull failure?

Accepted Answer

kubectl describe pod . 'kubectl describe pod ' shows events and status details including image pull errors. Option A shows logs of a container, but the container hasn't started yet. Option C shows resource usage. Option D lists events cluster-wide, but the pod description includes relevant events.

Answer

kubectl top pod <pod-name>

Answer

kubectl logs <pod-name>

Answer

kubectl get events

Question 10

A Pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient cpu.' Which of the following is the most likely combination of issues?

Accepted Answer

Three nodes have insufficient CPU for the pod's request, and one node has a taint not tolerated by the pod. The event shows two distinct issues: one node has a taint that the pod doesn't tolerate, and three nodes have insufficient CPU. Option D correctly identifies both. Options A, B, C each miss one or both issues.

Answer

The pod has a resource request that exceeds available CPU on all nodes

Answer

The pod does not tolerate any taints, and all nodes have taints

Answer

The cluster has only one node with sufficient CPU, but it is cordoned

Question 11

A developer reports that a Pod named 'web-pod' in namespace 'frontend' is crashing repeatedly. You run 'kubectl logs web-pod -n frontend' but see no output. Which command should you run next to see the logs from the previous, crashed container instance?

Accepted Answer

kubectl logs web-pod -n frontend --previous. 'kubectl logs --previous' retrieves logs from the previous container instance, which is useful for debugging crash loops. Option A shows current logs (empty). Option C shows events. Option D attempts to exec into a crashed container.

Answer

kubectl get events -n frontend --sort-by=.metadata.creationTimestamp

Answer

kubectl logs web-pod -n frontend -c web-pod

Answer

kubectl exec -it web-pod -n frontend -- sh

Question 12

You have a Deployment with one replica. The Pod enters CrashLoopBackOff. 'kubectl describe pod' shows the container exits with code 137. What is the most likely cause?

Accepted Answer

The container is exceeding its memory limit and is OOMKilled. Exit code 137 (SIGKILL) typically indicates the container was killed by the OOM killer due to exceeding memory limits. Option B is correct. Option A (liveness probe) would exit with code other than 137. Option C (invalid command) would exit with non-zero code but not specifically 137. Option D (node restart) would result in pod being rescheduled rather than crash loop.

Answer

The node is being drained and the pod is being terminated

Answer

The container's startup command is invalid

Answer

The liveness probe is failing and Kubernetes is restarting the container

Question 13

You need to check the CPU and memory usage of all pods in the 'production' namespace. Which command should you use?

Accepted Answer

kubectl top pods -n production. 'kubectl top pods -n production' shows CPU and memory usage. Option A is for nodes. Option C is a made-up command. Option D shows pod status, not resource usage.

Answer

kubectl get pods -n production --show-labels

Answer

kubectl get resourceusage pods -n production

Answer

kubectl top nodes -n production

Question 14

A pod is in 'Pending' state. After running 'kubectl describe pod', you see the event: '0/3 nodes are available: 3 PersistentVolumeClaim is not bound'. What is the most likely cause?

Accepted Answer

The PersistentVolumeClaim referenced by the pod does not exist or is not bound. The PVC referenced by the pod is not bound to a PV. Option A correctly identifies this. Option B (different storage class) is a possible reason but not directly indicated. Option C (scheduler conflict) is irrelevant. Option D (node resources) would produce a different event.

Answer

The storage class used by the PVC does not match any PV

Answer

The scheduler is not configured to handle persistent volumes

Answer

The nodes do not have enough CPU or memory

Question 15

You have a Service named 'my-svc' in namespace 'app'. A Pod in the same namespace cannot resolve the hostname 'my-svc' to an IP address. Which command should you run inside the Pod to test DNS name resolution?

Accepted Answer

nslookup my-svc.app.svc.cluster.local. Option C uses nslookup with the service name and namespace in the format required by Kubernetes DNS (service.namespace). Option A is incorrect format. Option B uses curl, which tests HTTP, not DNS. Option D uses ping, which may be blocked.

Answer

ping my-svc

Answer

nslookup my-svc

Answer

curl http://my-svc