20+ practice questions focused on Troubleshooting — one of the most tested topics on the Certified Kubernetes Administrator CKA exam. Each question includes a detailed explanation so you learn why the right answer is correct.
Start Troubleshooting PracticeA pod named 'web-frontend' is in CrashLoopBackOff. You run 'kubectl logs web-frontend' and see: 'Error: listen tcp :8080: bind: address already in use'. What is the most likely cause and how should you fix it?
Explanation: The error 'address already in use' indicates the container process is trying to bind to port 8080, but that port is still held by a previous instance of the process that did not release it. This typically happens when the container process does not handle SIGTERM gracefully (e.g., it ignores the signal or takes too long to shut down), so Kubernetes kills it with SIGKILL, leaving the socket in a TIME_WAIT or lingering state. Adding a preStop hook or using a proper init system (like tini or a signal-aware wrapper) ensures the process releases the port before the container stops, preventing the crash loop.
A user reports that their application cannot resolve DNS names for services in the cluster. The application runs in a pod with dnsPolicy: ClusterFirst. What is the most likely cause?
Explanation: When dnsPolicy is ClusterFirst, the pod's DNS queries are forwarded to the cluster's DNS service (CoreDNS by default). If the CoreDNS deployment has 0 ready replicas, the DNS service has no backend endpoints to handle queries, causing all DNS resolutions to fail. This is the most direct and common cause of complete DNS failure in a cluster.
Which TWO of the following are valid methods to troubleshoot a pod that is stuck in 'Pending' state?
Explanation: A is correct because 'kubectl describe pod <pod-name>' displays the Events section, which includes detailed reasons for a pod being stuck in Pending state, such as insufficient CPU/memory, persistent volume claims not binding, or node selector mismatches. This is the primary diagnostic command for understanding scheduling failures.
A developer reports that a newly deployed Deployment named 'web-app' is not serving traffic. The Deployment has 3 replicas, a Service of type ClusterIP, and an Ingress. Which TWO commands should you run first to diagnose the issue?
Explanation: `kubectl describe svc web-app` shows the Service's ClusterIP, port mapping, and endpoint list. If the endpoints are empty, the Service has no healthy Pods to route traffic to, which is a common cause of traffic failure. This command directly checks whether the Service is correctly wired to the Pods.
You are tasked with troubleshooting a production Kubernetes cluster. A user reports that they cannot access a web application running in the cluster. The application is deployed as a Deployment named 'frontend' with 2 replicas, exposed via a Service of type LoadBalancer. You have kubectl access to the cluster. You run 'kubectl get pods -l app=frontend' and see both pods are Running and Ready. You run 'kubectl get svc frontend' and see the Service has an external IP of 192.168.1.100. However, when you curl http://192.168.1.100 from a machine outside the cluster, you get a connection timeout. You are able to curl the pod IPs directly from within the cluster and get a response. Which of the following is the most likely cause of the issue?
Explanation: The pods are running and ready, and the service has an external IP, but external access fails with a connection timeout while internal access to pod IPs works. This indicates the cloud provider's load balancer is not properly routing traffic to the node ports, or a security group/firewall is blocking inbound traffic on the node port range (30000-32767). The load balancer must forward traffic to the node ports, and the nodes must allow that traffic.
+15 more Troubleshooting questions available
Practice all Troubleshooting questions1. Baseline your knowledge
Start with 10 questions to gauge your current understanding of Troubleshooting. This tells you whether you need a concept refresher or just practice.
2. Review every explanation
For each question — right or wrong — read the full explanation. Understanding why an answer is correct is more valuable than knowing the answer itself.
3. Focus on exam traps
Troubleshooting questions on the CKA frequently use trap wording. Look for subtle differences in answers that test your precision, not just general knowledge.
4. Reach 80% consistently
Do repeated sessions until you score 80%+ three times in a row. Then move to mixed-mode practice to test cross-topic recall under realistic conditions.
The exact number varies per candidate. Troubleshooting is tested as part of the Certified Kubernetes Administrator CKA blueprint. Practicing with targeted Troubleshooting questions ensures you can handle any format or difficulty that appears.
Yes. Courseiva provides free CKA practice questions across all exam topics and domains. The platform includes topic-based practice, mock exams, missed-question review, bookmarked questions, and readiness tracking — no account required.
Difficulty is subjective, but Troubleshooting is a high-priority exam concept tested in multiple ways — direct recall, scenario analysis, and command-output interpretation. Consistent practice is the best way to build confidence.
Launch a full Troubleshooting practice session with instant scoring and detailed explanations.
Start Troubleshooting Practice →