CKA Troubleshooting Practice Question
You are troubleshooting a DNS issue. From within a pod, you run 'nslookup kubernetes.default.svc.cluster.local' and get 'connection timed out; no servers could be reached'. What is the most likely cause?
⚠ Common exam trap
Many exam-takers confuse DNS resolution failures with network plugin issues, but the specific 'connection timed out' error points to the DNS service itself being unreachable, not to a general network misconfiguration.
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 kube-dns service is not running or is misconfigured
The error 'connection timed out; no servers could be reached' from nslookup indicates that the DNS resolver (typically the kube-dns or CoreDNS service) is unreachable. Since the query targets the standard Kubernetes service name 'kubernetes.default.svc.cluster.local', the most likely cause is that the kube-dns service (or its backend pods) is not running or is misconfigured, preventing the pod from resolving cluster-internal DNS names.
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 pod's /etc/resolv.conf has incorrect nameservers
Why it's wrong here
If a pod's /etc/resolv.conf contained incorrect nameservers, resolution attempts would likely result in immediate connection errors like 'connection refused' or 'host unreachable' if the specified IP address does not host a DNS server or is entirely invalid. A DNS timeout, however, implies that the query successfully reached a server that was expected to respond but failed to do so within the configured timeframe. This points to the DNS service itself being unresponsive rather than the initial target IP being fundamentally wrong.
- ✗
The node's network plugin is misconfigured
Why it's wrong here
A misconfigured node network plugin (e.g., CNI) would typically manifest as broader network connectivity issues, affecting all pod-to-pod or pod-to-service communication on that node or across the cluster. While DNS relies on network connectivity, a specific DNS timeout suggests the network path to the DNS service IP is functional, but the service at that IP is not responding to DNS queries. If the network plugin were truly broken, the pod would likely be unable to establish any network connections, including reaching the DNS service IP.
- ✗
The pod's DNS policy is set to 'None'
Why it's wrong here
When a pod's `dnsPolicy` is set to 'None', Kubernetes configures the pod's `/etc/resolv.conf` using the `dnsConfig` specified in the pod definition, completely bypassing the cluster's default DNS. If the `dnsConfig` points to an invalid or non-existent external nameserver, resolution attempts would typically fail immediately with 'Host not found' or 'NXDOMAIN' if the server responds negatively, or 'connection refused' if the server is unreachable. A timeout implies the query was sent to a server that did not respond, which is less common for 'None' unless the explicitly configured external server is unresponsive.
- ✓
The kube-dns service is not running or is misconfigured
Why this is correct
The `kube-dns` (or `CoreDNS`) service is the designated DNS resolver for pods within a Kubernetes cluster, with pods' `/etc/resolv.conf` typically pointing to its ClusterIP. If the underlying `kube-dns` or `CoreDNS` pods are not running, are crashing, or are misconfigured (e.g., resource starvation, incorrect upstream servers), the DNS service IP will be unresponsive to queries. This directly causes DNS resolution attempts from client pods to time out, as queries are sent to the correct IP but receive no response from the non-functional or overloaded DNS server.
Visual reference
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
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.