CKA Troubleshooting Practice Questions

Free CKA Troubleshooting practice test questions

8 questions from this domain with answers and explanations - different from the samples on the main CKA page. A free account includes a fixed set of 20 questions for this exam; paid access unlocks the full bank.

1. Question 1Troubleshooting

   A Pod is in 'CrashLoopBackOff' status. What does this indicate?

   • AThe container keeps crashing and Kubernetes is waiting before restarting itCorrect
   • BThe Pod's container image cannot be pulled
   • CThe Pod's volume cannot be mounted
   • DThe Pod cannot be scheduled due to insufficient resources
   ✓ Correct answer: A

   CrashLoopBackOff means a container has repeatedly started and then exited or crashed, and the kubelet is applying an exponential back-off delay (capped at five minutes) before each subsequent restart attempt. It indicates the container process is failing after launch, commonly due to an application error, a missing dependency, a bad configuration, or a failing liveness probe. The back-off prevents the kubelet from hammering the node with rapid restart attempts. You typically diagnose it with kubectl logs (including --previous) and kubectl describe pod to inspect exit codes and events.

   Why the other options are wrong

   • BThe Pod's container image cannot be pulled is incorrect because that condition produces an ImagePullBackOff or ErrImagePull status, not CrashLoopBackOff, since the container never starts.
   • CThe Pod's volume cannot be mounted is incorrect because volume mount failures surface as FailedMount events and leave the pod in a ContainerCreating or Pending state rather than crash-looping.
   • DThe Pod cannot be scheduled due to insufficient resources is incorrect because unschedulable pods remain in Pending state and never reach the running-then-crashing cycle that CrashLoopBackOff describes.
2. Question 2Troubleshooting

   A cluster administrator notices that CoreDNS pods are crashing. Applications in the cluster cannot resolve service names. Which of the following is the immediate impact?

   • AThe kube-apiserver will become unavailable
   • BAll pods in the cluster will be terminated
   • CAll existing network connections between pods will be immediately severed
   • DPods can still use Service ClusterIPs, but DNS-based service discovery failsCorrect
   ✓ Correct answer: D

   CoreDNS provides in-cluster DNS that resolves names such as my-svc.my-namespace.svc.cluster.local into Service ClusterIPs; the actual packet forwarding to backends is handled by kube-proxy's iptables/IPVS rules, which are independent of DNS. Therefore when CoreDNS is down, any workload that already knows the target ClusterIP (or connects by IP) keeps working, but any pod that must look up a name first will get resolution failures and be unable to discover services. This is why the immediate impact is broken DNS-based discovery rather than a total loss of pod-to-pod connectivity.

   Why the other options are wrong

   • AThe kube-apiserver will become unavailable is incorrect because the API server runs independently on the control plane and does not depend on CoreDNS for its operation.
   • BAll pods in the cluster will be terminated is incorrect because a CoreDNS outage does not trigger eviction or deletion of workload pods; they continue running.
   • CAll existing network connections between pods will be immediately severed is incorrect because established connections and IP-based routing through kube-proxy are unaffected by DNS availability; only new name lookups fail.
3. Question 3Troubleshooting

   'kubectl top nodes' returns an error about metrics. What is the usual cause?

   • AThe nodes are cordoned already
   • BCoreDNS has not started yet
   • CThe kubelet port is firewalled
   • DMetrics Server is not deployedCorrect
   ✓ Correct answer: D

   Like top pods, kubectl top nodes depends on the metrics.k8s.io API provided by the Metrics Server. If that component is not installed or not healthy, the command cannot retrieve node CPU and memory usage. Installing Metrics Server resolves the error.

   Why the other options are wrong

   • ACordoning blocks scheduling, not metrics collection.
   • BWhether CoreDNS has started yet is unrelated to the metrics API that kubectl top reads; name resolution plays no part in collecting node CPU and memory samples.
   • CA firewalled kubelet port can break metrics collection as well, but the usual cause of this error is simply that no Metrics Server is deployed.
4. Question 4Troubleshooting

   A pod repeatedly crashes with exit code 126. What does this exit code typically mean?

   • AOut of memory
   • BThe command was not found
   • CThe command was found but is not executableCorrect
   • DThe process was killed by SIGKILL
   ✓ Correct answer: C

   Exit code 126 is a standard shell/runtime convention meaning the target command or file was located but could not be invoked because it is not executable, most often due to a missing execute permission bit or attempting to run a non-executable file. In containers this commonly happens when a script is copied without chmod +x or is mounted with restrictive permissions. The container fails at startup, so the pod repeatedly crashes. The remedy is to set the executable bit (chmod +x) in the image or correct the file mode.

   Why the other options are wrong

   • AOut of memory is incorrect because an OOM kill is reported as exit code 137 (128+9) with the OOMKilled reason, not 126.
   • BThe command was not found is incorrect because a missing command yields exit code 127, whereas 126 specifically means the command exists but cannot be executed.
   • DThe process was killed by SIGKILL is incorrect because SIGKILL termination maps to exit code 137 (128+9), not 126.
5. Question 5Troubleshooting

   You need to check the kubelet logs on a node for the last hour. Which command is correct?

   • Akubectl logs kubelet --since=1h
   • Bsystemctl logs kubelet --time=1h
   • Ccat /var/log/kubelet/latest.log | tail -3600
   • Djournalctl -u kubelet --since "1 hour ago"Correct
   ✓ Correct answer: D

   The kubelet runs as a systemd service and writes its logs to the systemd journal, so journalctl is the correct tool to read them, with -u kubelet selecting the kubelet unit and --since "1 hour ago" limiting output to the last hour. This is the standard way to inspect kubelet behavior, startup errors, and node-readiness issues directly on a node. You can combine it with -f to follow live output or -p err to filter by priority. The quoted relative time expression is parsed by systemd's flexible time syntax.

   Why the other options are wrong

   • Akubectl logs kubelet --since=1h is incorrect because kubectl logs retrieves logs from pod containers via the API server, and the kubelet is a host systemd service, not a pod, so there is no such log object.
   • Bsystemctl logs kubelet --time=1h is incorrect because systemctl has no logs subcommand and no --time flag; viewing unit logs is the job of journalctl.
   • Ccat /var/log/kubelet/latest.log | tail -3600 is incorrect because the kubelet does not write to a /var/log/kubelet/latest.log file when using systemd journald, and tailing 3600 lines is not equivalent to one hour of logs.
6. Question 6Troubleshooting

   A pod is running but the readiness probe is failing. What is the effect on the service?

   • AThe pod enters CrashLoopBackOff and is repeatedly restarted by the kubelet
   • BThe pod is terminated and a replacement is scheduled by the controller
   • CThe node hosting the pod is marked NotReady until the probe passes
   • DThe pod remains running but is removed from the service endpoints, so it receives no trafficCorrect
   ✓ Correct answer: D

   The readiness probe controls only whether a pod is considered ready to serve requests, and a failing readiness probe sets the pod's Ready condition to false, which causes the endpoints controller (and EndpointSlice controller) to remove the pod's IP from the Service's endpoints. As a result the kube-proxy load-balancing rules stop directing traffic to that pod even though the container continues running normally and is never restarted. This mechanism gracefully takes a pod out of rotation while it is temporarily unable to serve, such as during warm-up or transient dependency outages. Once the probe succeeds again, the pod is re-added to the endpoints and resumes receiving traffic.

   Why the other options are wrong

   • AA failing readiness probe does not restart the container; only a failing liveness probe leads to restarts and CrashLoopBackOff.
   • BReadiness failures never terminate or reschedule the pod; they only gate whether it appears in service endpoints.
   • CA readiness probe affects only the individual pod's endpoint eligibility, not the node's Ready condition.
7. Question 7Troubleshooting

   A Job keeps creating pods but they all fail. The Job has backoffLimit: 4 and you see 5 failed pods. What will happen next?

   • AThe controller converts the failing Job into a Deployment to keep retrying
   • BThe Job resets its failure counter after backoffLimit and starts a fresh set
   • CThe Job will stop creating new pods and be marked as Failed since it exceeded the backoffLimitCorrect
   • DThe Job keeps retrying indefinitely until at least one pod succeeds
   ✓ Correct answer: C

   The Job's backoffLimit specifies the number of retries before the Job is considered failed; with backoffLimit: 4 the controller tolerates up to 4 retries and the 5th failure crosses the limit. Once the number of failed pods exceeds the backoffLimit, the Job controller stops creating new pods and sets the Job's status condition to Failed with reason BackoffLimitExceeded. Retries are also subject to an exponential back-off delay between attempts (capped at 6 minutes). At that point manual intervention is required to fix the workload and rerun the Job.

   Why the other options are wrong

   • AJobs and Deployments are separate controllers; a Job never transforms itself into a Deployment when it fails.
   • BThe backoffLimit is a hard cap, not a counter that resets; once exceeded the Job stops and is marked Failed.
   • DThe backoffLimit exists precisely to stop indefinite retries; after 4 retries plus the initial attempt the Job fails.
8. Question 8Troubleshooting

   What does an ImagePullBackOff pod status indicate?

   • AThe image could not be pulled, and retries are being delayedCorrect
   • BThe container started from the image, then crashed and is waiting
   • CThe container was killed after failing its liveness probe
   • DThe container exceeded its memory limit and was killed
   ✓ Correct answer: A

   The documentation describes ImagePullBackOff as a state in which a container could not start because Kubernetes could not pull its image, for reasons such as an invalid image name or a private registry without an imagePullSecret. The BackOff part means Kubernetes keeps trying with an increasing delay, up to a limit of 300 seconds. Because no container has started, the cause lies in the image reference, the registry or the credentials, not in the application.

   Why the other options are wrong

   • BA container that starts and then crashes repeatedly shows CrashLoopBackOff; with ImagePullBackOff the image was never pulled, so nothing has run.
   • CA liveness probe can only fail for a container that is already running; with ImagePullBackOff no container has started.
   • DA container that exceeds its memory limit is killed with reason OOMKilled, which needs a running container that an unpulled image cannot provide.

How Troubleshooting is tested

This domain holds 156 of the 793 questions in the CKA bank, about 20%. The mix is 197 single-answer multiple choice and 16 multiple-response, so it is worth practising the formats as well as the content.

Once you have a few attempts recorded, CertGrid scores every domain separately and points you at the weakest one, so you can drill Troubleshooting on its own rather than re-running full-length mocks.

Other CKA exam domains

• Cluster Architecture Installation and Configuration167 questions
• Workloads and Scheduling173 questions
• Services and Networking152 questions
• Storage145 questions
• All CKA practice questions793 total
• Troubleshooting study notesKey concepts
• Cloud Native practice examsAll Cloud Native

CKA Troubleshooting FAQ