CKAD Services and Networking Practice Question
A pod is unable to resolve the DNS name of a Service in the same namespace. The pod's /etc/resolv.conf shows 'nameserver 10.96.0.10'. What is the most likely cause?
⚠ Common exam trap
A common mix-up: candidates confuse dnsPolicy: Default with the default pod DNS policy (ClusterFirst), or assume that an ExternalName Service bypasses DNS entirely, when in fact all DNS queries go through the same kube-dns resolver.
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
The pod's /etc/resolv.conf shows nameserver 10.96.0.10, which is the default ClusterIP of the kube-dns Service. If the kube-dns Service is not running, the DNS resolver will fail to respond to queries, causing the pod to be unable to resolve the DNS name of any Service, including one in the same namespace. This is the most direct cause because the pod relies entirely on that nameserver for DNS resolution.
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 kube-dns Service is not running
Why this is correct
The kube-dns Service (typically implemented by CoreDNS) is the cluster-wide DNS server that responds to queries for Service or Pod names. If the Service object or its backing pods are absent or in a failed state, cluster DNS resolution completely fails, causing pods to be unable to resolve any Service name. This is the most direct and common cause of such a symptom.
- ✗
The pod is using dnsPolicy: Default
Why it's wrong here
The pod's dnsPolicy: Default means it uses the node's /etc/resolv.conf settings, not the cluster's DNS configuration. However, in standard Kubernetes clusters the kubelet configures the node to point to the cluster DNS as the upstream resolver, so Service names would still be resolvable. Unless the node's DNS is intentionally modified, this policy alone does not break Service name resolution.
- ✗
The Service is of type ExternalName
Why it's wrong here
A Service of type ExternalName does not expose a ClusterIP; instead it creates a CNAME record in the cluster DNS that points to an external hostname. The pod's DNS resolver follows that CNAME and queries the external address, but the Service name itself still resolves via the cluster DNS. Therefore, the ExternalName type does not impede DNS resolution of the Service name.
- ✗
The pod's /etc/hosts file is misconfigured
Why it's wrong here
The /etc/hosts file is a static, local mapping of IP addresses to hostnames and is consulted by the system resolver before it queries DNS. Kubernetes Service names are not injected into /etc/hosts; they are resolved exclusively via the cluster DNS server. Even a misconfigured /etc/hosts would not affect Service name resolution, because that lookup path never touches the file.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 CKAD 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 CKAD exam.