CKA Troubleshooting Practice Question
You are troubleshooting DNS resolution from within a pod. You exec into the pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command fails with 'connection timed out; no servers could be reached'. However, 'kubectl get svc -n kube-system' shows the kube-dns service with a ClusterIP. What is the MOST likely cause?
⚠ Common exam trap
The trap here is that candidates see the kube-dns service exists and assume DNS is working, but they forget that a service without healthy backend pods (CoreDNS) cannot serve requests, leading to timeouts rather than immediate failures.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The CoreDNS pods are not running or are crashing
The error 'connection timed out; no servers could be reached' from nslookup indicates that the pod cannot reach any DNS server at all. Since the kube-dns service exists (as shown by kubectl), the most likely cause is that the backend CoreDNS pods are not running or are crashing, so there are no endpoints to forward traffic to. Without running CoreDNS pods, the service's ClusterIP has no backing pods, causing all DNS queries to time out.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The CoreDNS pods are not running or are crashing
Why this is correct
This is the correct answer because if the CoreDNS pods are not running or are crashing, the Kubernetes `kube-dns` service will have no healthy endpoints. The `kube-proxy` component, responsible for managing service IPs, will be unable to forward DNS queries from pods to any functional CoreDNS instance. Consequently, any DNS lookup attempt from a pod will result in a connection timeout as the query never reaches an active DNS server to be processed.
- ✗
The pod's /etc/resolv.conf has incorrect search domains
Why it's wrong here
Incorrect search domains in a pod's `/etc/resolv.conf` would lead to DNS queries failing to resolve specific names, resulting in an `NXDOMAIN` response or a lookup failure after exhausting search paths. However, the initial attempt to connect to the `nameserver` IP specified in `resolv.conf` would still succeed if the CoreDNS service is operational. A timeout specifically indicates that the DNS server itself is unreachable or unresponsive, not merely that the name could not be found.
- ✗
A network policy is blocking traffic to the kube-dns service
Why it's wrong here
While a network policy could indeed block traffic to the `kube-dns` service, causing DNS queries to time out due to dropped packets, this is generally a less common root cause than CoreDNS pods being unhealthy. If a network policy were the culprit, it would explicitly deny egress from the requesting pod to the `kube-dns` service IP or ingress to the CoreDNS pods. However, the fundamental unavailability of the DNS server (CoreDNS pods not running) is a more direct and frequent cause of connection timeouts.
- ✗
The DNS name does not exist
Why it's wrong here
If the DNS name being queried does not exist, a functional DNS server, such as CoreDNS, would process the request and explicitly respond with an `NXDOMAIN` (Non-Existent Domain) status. This response confirms that the DNS server is reachable and operational, having authoritatively determined the name is not registered. A connection timeout, conversely, signifies that the DNS server could not be reached at all, preventing any response, including an `NXDOMAIN`.
Visual reference
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
Key term
CoreDNS
CoreDNS is a fast, flexible, and pluggable Domain Name System (DNS) server that is often used as the cluster DNS for Kubernetes, translating service names into IP addresses so containers can find each other.
About these practice questions
This CKA question is part of Courseiva's 302-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.