CKA Troubleshooting Practice Test 19 — 15 Questions

Question 1

A node shows status NotReady. You SSH into the node and run 'systemctl status kubelet' which shows the kubelet is active (running). What is the next most likely step to diagnose the issue?

Accepted Answer

Check kubelet logs with journalctl -u kubelet. Even if the kubelet is running, it may be unhealthy. Checking the kubelet logs with 'journalctl -u kubelet' can reveal errors such as network plugin failures or node pressure.

Answer

Restart the kubelet with systemctl restart kubelet

Answer

Check the container runtime status

Answer

Reboot the node

Question 2

A pod is stuck in Pending with event '0/4 nodes are available: 1 node(s) had taint "node.kubernetes.io/disk-pressure", and 3 node(s) had taint "node.kubernetes.io/memory-pressure", that the pod didn't tolerate'. What is the best approach to schedule the pod?

Accepted Answer

Free up disk space and reduce memory usage on the affected nodes. The cluster has nodes with disk-pressure and memory-pressure taints. These are typically added by the node controller when resources are low. The pod does not tolerate these taints. The best approach is to free resources on the nodes or add tolerations; however, tolerating pressure taints is not recommended as it can cause further instability. Usually, you should resolve the underlying resource issues.

Answer

Use 'kubectl taint nodes --all node.kubernetes.io/disk-pressure- node.kubernetes.io/memory-pressure-' to remove the taints

Answer

Add tolerations for both taints to the pod spec

Answer

Delete the pod and recreate it with higher resource requests

Question 3

You want to see the last 50 lines of logs from a pod named 'api-pod' for the container 'api-container'. Which command accomplishes this?

Accepted Answer

kubectl logs api-pod -c api-container --tail=50. 'kubectl logs api-pod -c api-container --tail=50' shows the last 50 lines for the specified container.

Answer

kubectl logs -l app=api --tail=50

Answer

kubectl logs api-pod --tail=50

Answer

kubectl logs api-container -p api-pod --tail 50

Question 4

Which THREE of the following are valid steps to troubleshoot DNS issues in a Kubernetes cluster?

Accepted Answer

Run 'kubectl exec <pod> -- nslookup kubernetes.default'. To troubleshoot DNS, you can check the DNS pod logs, test resolution from a pod, and verify the DNS service endpoints.

Answer

Check the /etc/resolv.conf on the host

Answer

Restart all nodes in the cluster

Question 5

A node in your cluster is marked as NotReady. You SSH into the node and run 'systemctl status kubelet'. The output shows the kubelet is inactive (dead). What should you do FIRST to restore the node?

Accepted Answer

Run 'systemctl start kubelet'. The kubelet service is stopped. The first step is to start it with 'systemctl start kubelet'. If it fails to start, further investigation with journalctl is needed.

Answer

Reboot the node

Answer

Delete the node object from the cluster

Answer

Reinstall the kubelet package

Question 6

Which command can you use to view the logs of a container that has crashed and been restarted?

Accepted Answer

kubectl logs pod-name --previous. The --previous flag retrieves logs from the previous instance of the container.

Answer

kubectl describe pod pod-name

Answer

kubectl exec pod-name -- cat /var/log/crash.log

Answer

kubectl logs pod-name

Question 7

A Deployment named 'web' is failing to schedule pods. You run 'kubectl describe pod web-xyz' and see the event: '0/3 nodes are available: 3 Insufficient cpu.' What is the most likely cause?

Accepted Answer

The CPU request in the pod spec is too high. The error indicates that CPU requests are too high for the available node resources. Reducing CPU requests or adding more nodes can fix it.

Answer

The network plugin is misconfigured

Answer

The nodes have insufficient memory

Answer

The kubelet is not running on the nodes

Question 8

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 9

You deploy a pod with image 'nginx:1.21'. It stays in ImagePullBackOff. You run 'kubectl describe pod nginx-pod' and see the event: 'Failed to pull image "nginx:1.21": rpc error: code = Unknown desc = Error response from daemon: manifest for nginx:1.21 not found'. What is the most likely fix?

Accepted Answer

Change the image tag to a valid one, e.g., nginx:1.21.6. The tag '1.21' does not exist in the registry. Use a valid tag like '1.21.6' or 'latest'.

Answer

Use a different container runtime

Answer

Add imagePullSecrets to the pod

Answer

Restart the kubelet on the node

Question 10

Which command shows resource usage (CPU and memory) for nodes in a cluster?

Accepted Answer

kubectl top nodes. kubectl top nodes displays resource usage if metrics-server is installed.

Answer

kubectl describe nodes

Answer

kubectl logs nodes

Answer

kubectl get nodes -o wide

Question 11

The controller-manager logs show repeated errors: 'Failed to list *v1.Pod: connection refused'. What is the most likely cause?

Accepted Answer

The API server is down or not reachable. The controller-manager communicates with the API server. 'connection refused' indicates the API server is not reachable or not running.

Answer

The kube-controller-manager is not running

Answer

The kubelet on the controller node is down

Answer

The scheduler is overloading the API server

Question 12

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

Accepted Answer

The image is in a private registry and no imagePullSecrets are defined. Common causes: invalid image tag (typo) and authentication failure when the image is in a private registry.

Answer

The node has insufficient memory

Answer

The pod has a resource limit that is too low

Answer

The kubelet is not running

Question 13

Which THREE of the following are valid commands to troubleshoot network connectivity between pods? (Select 3)

Accepted Answer

kubectl exec pod-a -- nslookup service-name. kubectl exec can run networking tools inside a pod. curl is a common tool. nslookup tests DNS. ping tests basic connectivity.

Answer

kubectl describe node | grep Network

Answer

kubectl logs pod-a | grep network

Question 14

You run 'kubectl get pods' and see that a pod is in CrashLoopBackOff. Which THREE of the following are valid next steps? (Select 3)

Accepted Answer

Run 'kubectl describe pod pod-name' to check events. Option A is correct because 'kubectl describe pod pod-name' surfaces the pod's Events section, which shows why the kubelet restarted the container (e.g., OOMKilled, failed liveness probe, image pull issues) and the backoff timing. Option B is correct because 'kubectl logs pod-name' retrieves the container's stdout/stderr, which typically contains the application error that caused the process to exit and enter CrashLoopBackOff; adding --previous shows logs from the prior crashed instance. Option C is correct because the jsonpath query reads .status.containerStatuses[0].state.waiting.reason, which directly returns the waiting reason such as CrashLoopBackOff along with the last termination state, confirming the container's current status. Option D is not appropriate because 'kubectl top pod' only reports live CPU/memory usage from the metrics server and does not explain why the container is crash-looping. Option E is not a valid diagnostic step because deleting the pod merely recreates it (or removes it if managed by a controller) without revealing the root cause, so it does not help troubleshoot the failure.

Answer

Run 'kubectl top pod pod-name'

Answer

Run 'kubectl delete pod pod-name'

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