CKA Troubleshooting Practice Test 14 — 15 Questions

Question 1

A node in your cluster is in the 'NotReady' state. You SSH into the node and run 'systemctl status kubelet' which shows the kubelet is active but not functioning correctly. Which command should you use to get detailed logs to troubleshoot the kubelet?

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

Accepted Answer

journalctl -u kubelet. `journalctl -u kubelet` retrieves the systemd journal logs specifically for the kubelet service, which is the standard way to access detailed, timestamped logs when the kubelet is running but malfunctioning. Since the kubelet is active (not stopped), its logs are captured by systemd and can be inspected without restarting the service, preserving the current state for troubleshooting.

Answer

kubectl describe node <node-name>

Answer

kubectl logs kubelet -n kube-system

Answer

systemctl restart kubelet

Question 2

You have a pod named 'web-pod' that is in a CrashLoopBackOff state. To examine the logs from the previous instance of the container, which command should you use?

Accepted Answer

kubectl logs web-pod --previous. The correct command is kubectl logs web-pod --previous (Option A). This retrieves the logs from the previous instance of the container, which is essential when a pod is in CrashLoopBackOff because the container has restarted and the current logs may be empty or not show the error from the previous run. Option B uses kubectl exec to read a log file, but it does not access previous logs and requires the container to be running. Option C shows pod details but not logs. Option D shows current logs only, which may not capture the crash reason.

Answer

kubectl exec web-pod -- cat /var/log/app.log

Answer

kubectl describe pod web-pod

Answer

kubectl logs web-pod

Question 3

A pod is in the 'Pending' state for a long time. You run 'kubectl describe pod pending-pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, 3 node(s) had taint {node-role.kubernetes.io/control-plane: } that the pod didn't tolerate.' What is the MOST likely solution?

Accepted Answer

Add tolerations to the pod for the control-plane taint. The pod is stuck in 'Pending' because it cannot be scheduled. The event shows that 3 control-plane nodes have the 'node-role.kubernetes.io/control-plane' taint, which by default prevents non-tolerant pods from scheduling on them. Adding the corresponding toleration to the pod's spec allows it to be scheduled on those nodes, resolving the pending state.

Answer

Remove the taint from the control-plane nodes

Answer

Delete the pod and recreate it

Answer

Increase the pod's resource requests

Question 4

You run 'kubectl get pods' and see a pod with status 'ImagePullBackOff'. Which of the following is a possible cause?

Accepted Answer

The container image name is misspelled. The correct answer is C: the container image name is misspelled. ImagePullBackOff means the kubelet failed to pull the container image and is backing off before retrying, which commonly happens when the image reference is invalid, such as a typo in the image name or tag, or when the image does not exist in the registry. Option A is incorrect because disk pressure on a node typically causes Evicted pods or a DiskPressure node condition, not ImagePullBackOff. Option B is incorrect because insufficient resource limits usually lead to Pending scheduling or OOMKilled states, not image pull failures. Option D is incorrect because a failing liveness probe causes container restarts and a CrashLoopBackOff-like state, not an image pull error.

Answer

The node has a disk pressure condition

Answer

The pod's resource limits are too low

Answer

The pod's liveness probe is failing

Question 5

You need to check the resource usage of nodes in your cluster. Which command should you run?

Accepted Answer

kubectl top nodes. `kubectl top nodes` retrieves and displays real-time CPU and memory usage metrics for all nodes in the cluster. This command relies on the metrics server being deployed and functioning, which aggregates resource usage data from kubelet’s cAdvisor endpoint. It is the standard Kubernetes command for checking node-level resource consumption.

Answer

kubectl get nodes -o wide

Answer

kubectl logs --all-containers

Answer

kubectl describe nodes

Question 6

A pod named 'app' is not starting. You run 'kubectl describe pod app' and see the event: 'MountVolume.SetUp failed for volume "pvc-volume" : rpc error: code = NotFound desc = volume not found'. What is the most likely issue?

Accepted Answer

The PersistentVolumeClaim (PVC) referenced by the pod does not exist or is not bound. The error 'volume not found' indicates that the PersistentVolumeClaim (PVC) named 'pvc-volume' does not exist or is not bound to a PersistentVolume (PV). Kubernetes requires a PVC to be in 'Bound' state before a pod can mount it; if the PVC is missing or unbound, the volume mount fails at pod startup.

Answer

The container image is not found in the registry

Answer

The node running the pod is out of disk space

Answer

The pod has insufficient CPU resources

Question 7

You suspect a DNS issue inside a pod. Which command can you run to test DNS resolution from within a pod?

Accepted Answer

kubectl exec -- nslookup kubernetes.default. The correct command is `kubectl exec -- nslookup kubernetes.default`, which runs the DNS lookup from inside the existing pod's network namespace, using the pod's own /etc/resolv.conf and DNS policy. This directly tests whether the pod can resolve cluster DNS names through kube-dns/CoreDNS, which is exactly what a DNS issue inside a pod requires. Running nslookup from within the affected pod isolates the problem to that pod's DNS configuration rather than the cluster DNS service as a whole.

Answer

kubectl logs coredns -n kube-system

Answer

kubectl describe svc kubernetes

Answer

kubectl run test --image=busybox -- nslookup kubernetes.default

Question 8

You are troubleshooting a network connectivity issue between two pods in different namespaces. The pods have the following labels: pod-a in namespace 'foo' with labels {app: web}, pod-b in namespace 'bar' with labels {app: db}. You verify that both pods have IP addresses and can ping the Kubernetes service IP. However, pod-a cannot connect to pod-b on port 5432. What should you check first?

Accepted Answer

Check if a NetworkPolicy exists that denies ingress traffic to pod-b from namespace 'foo'. When pods can reach each other's IPs and services but a specific port connection fails, the most likely cause in a multi-namespace Kubernetes cluster is a NetworkPolicy restricting ingress to pod-b. NetworkPolicies are namespace-scoped and can deny cross-namespace traffic on specific ports, which perfectly matches the symptom of ICMP/service reachability succeeding while TCP/5432 fails.

Answer

Check if the kube-proxy is running on the node hosting pod-b

Answer

Check if the container runtime is Docker

Answer

Check if the DNS resolution for pod-b's service is correct

Question 9

You run 'kubectl get pods' and see a pod with status 'CrashLoopBackOff'. You check the logs with 'kubectl logs <pod> --previous' and see: 'Error: unable to connect to database at db-svc:5432 (connection refused)'. What is the most likely cause?

Accepted Answer

The database service is not running or is unreachable. The error message 'connection refused' indicates that the pod is attempting to connect to the database at 'db-svc:5432' but the target service is not accepting TCP connections on port 5432. This typically means the database pod or service is not running, or a network policy is blocking the connection. The 'CrashLoopBackOff' status confirms the application container repeatedly fails due to this startup dependency.

Answer

The pod's liveness probe is misconfigured

Answer

The pod's container image is missing

Answer

The pod has a memory limit that is too low

Question 10

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

Accepted Answer

Insufficient cluster resources (CPU/memory) to schedule the pod. Option B is correct because the Kubernetes scheduler places a pod into the Pending state when no node has enough allocatable CPU or memory to satisfy the pod's resource requests, so the pod remains unscheduled until resources free up or the cluster scales. Option D is correct because if a pod references a PersistentVolumeClaim that is not yet Bound (for example, waiting on a dynamic provisioner or a matching PersistentVolume), the scheduler cannot satisfy the volume's node affinity/topology constraints and the pod stays Pending. Option A is not a cause of Pending; an image that cannot be pulled produces an ImagePullBackOff/ErrImagePull status while the pod is already scheduled and typically Running or Waiting on a node. Option C is not a cause of Pending; a failing liveness probe causes kubelet to restart the container, resulting in CrashLoopBackOff or repeated restarts, not a scheduling failure. Option E is not a cause of Pending; an unreachable node affects existing pods (marking them Unknown/NotReady) rather than preventing scheduling, since the scheduler simply avoids nodes it considers unhealthy.

Answer

The container image is not found

Answer

The pod's liveness probe is failing

Answer

The node is unreachable due to network issues

Question 11

Which THREE of the following are valid steps to troubleshoot a node that is in 'NotReady' state?

Accepted Answer

Check the kubelet status using 'systemctl status kubelet' on the node. Options A, B, and C are valid troubleshooting steps to investigate a NotReady node. Option A checks if kubelet is running, Option B examines kubelet logs for errors, and Option C shows node conditions. Option D (restarting kubelet) is a remediation action, not a troubleshooting step. Option E (deleting and rejoining) is a recovery step.

Answer

Restart the kubelet using 'systemctl restart kubelet'

Answer

Delete the node object and rejoin it to the cluster

Question 12

Which TWO of the following are valid commands to check resource usage of pods?

Accepted Answer

kubectl top pod . Option C, `kubectl top pod `, is correct because the `kubectl top` command retrieves live CPU and memory usage metrics for a specific pod from the Metrics Server, which is exactly what checking resource usage of a pod requires. Option E, `kubectl top pods`, is also correct because it lists current CPU and memory consumption for all pods in the namespace, directly satisfying the resource-usage check. Option A, `kubectl top nodes`, is not correct here because it reports resource usage of cluster nodes, not pods. Option B, `kubectl describe pods`, shows configuration, events, and status details but not live CPU/memory usage metrics. Option D, `kubectl get pods --watch`, only streams pod status changes and does not report resource consumption.

Answer

kubectl top nodes

Answer

kubectl describe pods

Answer

kubectl get pods --watch

Question 13

You suspect the kubelet on a worker node is not functioning correctly. Which command should you use to check the kubelet service status?

Accepted Answer

systemctl status kubelet. The kubelet is a systemd service on worker nodes, so `systemctl status kubelet` is the correct command to check its current state, whether it is active (running), inactive, or failed. This command directly queries the service manager for the kubelet's status, which is the first step in troubleshooting a suspected malfunction.

Answer

kubectl get nodes

Answer

kubectl describe node <node-name>

Answer

journalctl -u kubelet

Question 14

You run 'kubectl logs my-pod -c my-container' and get no output, but you know the container produces logs. What should you do next to see previous container logs?

Accepted Answer

kubectl logs my-pod -c my-container --previous. The --previous flag retrieves logs from the previous instance of a crashed container.

Answer

kubectl logs my-pod -c my-container -f

Answer

kubectl logs my-pod -c my-container --tail=50

Answer

kubectl logs my-pod -c my-container --all-containers

Question 15

A pod is in ImagePullBackOff state. Which command would give you the most information about why the image pull failed?

Accepted Answer

kubectl describe pod . `kubectl describe pod ` provides detailed event logs, including the exact error message from the kubelet when it failed to pull the container image. This output includes the reason for the ImagePullBackOff state, such as authentication failures, image not found, or network issues, which is the most comprehensive information for troubleshooting.

Answer

kubectl get pod

Answer

kubectl logs <pod-name>

Answer

kubectl edit pod <pod-name>