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. Sign up free to practice the full set.

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 2TroubleshootingSelect all that apply

   A Service is not routing traffic to its backend pods. Which of the following should you check to diagnose the issue? (Select THREE)

   • AEnsure the target pods are in Running state and passing readiness probesCorrect
   • BVerify the Service selector matches the labels on the target podsCorrect
   • CCheck if the PersistentVolumes are properly mounted
   • DCheck that the Endpoints object associated with the Service has pod IPs listedCorrect
   • EVerify the node's hostname resolves correctly
   ✓ Correct answer: A, B, D

   Verify the Service selector matches the labels on the target pods check that the Endpoints object associated with the Service has pod IPs listed A Service routes traffic by selecting pods whose labels match its spec.selector, and only Running pods that pass their readiness probe are added to the Service's Endpoints (or EndpointSlice). kube-proxy programs the dataplane rules from the Endpoints list, so if a pod is not Ready, its label does not match the selector, or the Endpoints object is empty, traffic will not reach the backends. Therefore confirming pod readiness, validating selector-to-label matching, and inspecting the Endpoints/EndpointSlice for populated pod IPs are the three core diagnostic steps for a Service that is not delivering traffic.

   Why the other options are wrong

   • Ccheck if the PersistentVolumes are properly mounted is incorrect because storage mounting affects whether a pod's application starts correctly but has no role in how a Service selects endpoints or routes layer-4 traffic.
   • EVerify the node's hostname resolves correctly is incorrect because Service routing relies on pod IPs in Endpoints and kube-proxy rules, not node hostname DNS resolution; node hostnames are irrelevant to ClusterIP traffic delivery.
3. Question 3Troubleshooting

   NodeDrain Corp needs to perform maintenance on a worker node. Which kubectl command safely evicts all pods from a node before maintenance?

   • Akubectl cordon <node-name>
   • Bkubectl drain <node-name>Correct
   • Ckubectl taint node <node-name>
   • Dkubectl delete node <node-name>
   ✓ Correct answer: B

   The kubectl drain command safely evicts all manageable pods from a node and simultaneously marks it unschedulable, making it the correct one-step command for preparing a node for maintenance. It respects PodDisruptionBudgets and gracefully terminates pods so they can be rescheduled onto other nodes, and it typically requires flags like --ignore-daemonsets and --delete-emptydir-data to complete. Once drained, the node holds no workload pods and is cordoned, so maintenance such as kernel patching or reboots can proceed without disrupting running applications.

   Why the other options are wrong

   • Akubectl cordon <node-name> is incorrect because it only marks the node unschedulable to prevent new pods, but it leaves all existing pods running on the node.
   • Ckubectl taint node <node-name> is incorrect because adding a taint repels future pods that lack a toleration but does not evict the pods already scheduled there.
   • Dkubectl delete node <node-name> is incorrect because it removes the node object from the API server abruptly without gracefully evicting its pods, which is destructive rather than a safe maintenance procedure.
4. Question 4Troubleshooting

   You want to see all cluster events sorted by the time they occurred. Which command is correct?

   • Akubectl get events --order-by=time
   • Bkubectl get events --chronological
   • Ckubectl get events --sort=timestamp
   • Dkubectl get events --sort-by=".lastTimestamp"Correct
   ✓ Correct answer: D

   The kubectl get events command does not chronologically order output by default, so you use the generic --sort-by flag with a JSONPath expression pointing at a field on the Event object. The .lastTimestamp field records the most recent occurrence of each event, making it the standard field to sort by when you want events ordered by when they last happened. The --sort-by flag is a built-in kubectl output option available on get for any resource, and it accepts a quoted JSONPath such as ".lastTimestamp" or ".metadata.creationTimestamp". This produces a list ascending by time so the newest events appear at the bottom.

   Why the other options are wrong

   • Akubectl get events --order-by=time is incorrect because kubectl has no --order-by flag; sorting is done exclusively through the --sort-by JSONPath flag.
   • Bkubectl get events --chronological is incorrect because no --chronological flag exists in kubectl; the option is unrecognized and the command would error.
   • Ckubectl get events --sort=timestamp is incorrect because the flag is named --sort-by (not --sort) and its value must be a JSONPath field expression, not a bare word like timestamp.
5. Question 5Troubleshooting

   A pod is stuck in ContainerCreating. Events show "MountVolume.SetUp failed: configmap "app-config" not found." What should you do?

   • ARestart the kubelet
   • BCreate the ConfigMap "app-config" in the pod's namespaceCorrect
   • CChange the volume type from configMap to emptyDir
   • DDelete and recreate the pod
   ✓ Correct answer: B

   The event "MountVolume.SetUp failed: configmap \"app-config\" not found" means the pod references a ConfigMap volume whose object does not exist in the pod's namespace, so the kubelet cannot populate the volume and the pod remains in ContainerCreating. ConfigMaps are namespaced, so the referenced app-config ConfigMap must be created in the same namespace as the pod for the mount to succeed. Once you kubectl create configmap app-config (with the expected keys) in that namespace, the kubelet retries the mount and the pod proceeds to start. The pod will recover automatically without recreation once the ConfigMap appears.

   Why the other options are wrong

   • ARestart the kubelet is incorrect because the mount fails due to a missing API object, not a kubelet malfunction; restarting it changes nothing while the ConfigMap is absent.
   • CChange the volume type from configMap to emptyDir is incorrect because emptyDir provides empty scratch storage and would lose the intended configuration data, masking rather than fixing the missing ConfigMap.
   • DDelete and recreate the pod is incorrect because the kubelet already retries the mount automatically; recreating the pod still fails as long as the ConfigMap does not exist in the namespace.
6. Question 6Troubleshooting

   A service has the correct selector and matching pods, but connecting to the service from another pod times out. What should you check next?

   • AWhether the pod's init containers completed before the app container started
   • BWhether the namespace ResourceQuota is rejecting new connections to the pods
   • CWhether the pods pass their readiness probes and targetPort matches the app portCorrect
   • DWhether the backing container images are the latest available versions
   ✓ Correct answer: C

   Even with a correct selector and matching pods, a Service only forwards traffic to pods that are Ready, because failing readiness probes remove a pod's IP from the Service's Endpoints/EndpointSlices. Additionally, if the Service's targetPort does not match the port the application actually listens on, kube-proxy forwards connections to a closed port and they time out. You diagnose by checking kubectl get endpoints to see if any addresses are listed, kubectl describe pod for readiness status, and comparing targetPort to the container's listening port. Fixing readiness and aligning targetPort restores connectivity.

   Why the other options are wrong

   • ACompleted init containers would let the pod run and be selected; a connection timeout points to readiness or port mismatch, not init order.
   • BA ResourceQuota limits object creation, not live network connections, so it would not cause connection timeouts to a healthy service.
   • DImage freshness does not affect whether traffic reaches the app; the timeout points to readiness state or a targetPort mismatch.
7. Question 7Troubleshooting

   You need to check the restart count of all containers in a pod. Which command provides this information?

   • Akubectl get pod my-pod -o jsonpath="{.status.containerStatuses[*].restartCount}"Correct
   • Bkubectl get pod my-pod -o jsonpath="{.status.phase.restartCount}"
   • Ckubectl logs my-pod -o jsonpath="{.restartCount}" --all-containers
   • Dkubectl describe pod my-pod -o jsonpath="{.spec.restartCount}"
   ✓ Correct answer: A

   The per-container restart count is stored in the pod's status under status.containerStatuses[].restartCount, and a JSONPath query with the [*] wildcard extracts the restartCount value for every container in the pod. This reads the field directly from the API object, giving precise, scriptable output without relying on parsed human-readable text. It is the reliable way to programmatically retrieve restart counts, for example in monitoring or automation. You could also append initContainerStatuses for init container restarts.

   Why the other options are wrong

   • Bstatus.phase is a single string like Running and has no restartCount field; restart counts live under containerStatuses.
   • Ckubectl logs streams container output and does not accept jsonpath or expose a restartCount field.
   • DrestartCount is a status field, not a spec field, and kubectl describe does not take a jsonpath output flag.
8. Question 8Troubleshooting

   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.

How Troubleshooting is tested

This domain holds 183 of the 903 questions in the CKA bank, about 20%. The mix is 170 single-answer multiple choice and 13 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 Configuration197 questions
• Workloads and Scheduling187 questions
• Services and Networking168 questions
• Storage168 questions
• All CKA practice questions903 total
• Troubleshooting study notesKey concepts
• Cloud Native practice examsAll Cloud Native

CKA Troubleshooting FAQ