CKAD Services and Networking Practice Question
A Pod named `my-pod` in namespace `ns1` tries to resolve `svc-a.ns2.svc.cluster.local`. The DNS query fails. The Service `svc-a` exists in namespace `ns2`. What is the most likely cause?
⚠ Common exam trap
Watch out — candidates often assume cross-namespace DNS queries are blocked by default, but Kubernetes DNS actually resolves FQDNs across namespaces, so the failure must be due to a cluster-wide DNS issue like CoreDNS being unavailable.
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 DNS add-on (e.g., CoreDNS) is not deployed or is misconfigured
The DNS query for `svc-a.ns2.svc.cluster.local` fails despite the Service existing, which points to a cluster-wide DNS resolution issue. CoreDNS is the default DNS add-on in Kubernetes that translates service names to IP addresses; if it is not deployed or misconfigured, all DNS queries (including cross-namespace ones) will fail. The fact that the Service exists and the Pod is in a different namespace does not inherently prevent resolution—CoreDNS handles cross-namespace lookups by default.
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 Service `svc-a` does not have any endpoints
Why it's wrong here
DNS lookup for a Service is based on the Service object itself, not on the backing EndpointSlice objects. Even if a Service has no matching pods (no endpoints), CoreDNS still returns a DNS record for the Service because the Service definition exists and carries a ClusterIP (for non-headless Services). Missing endpoints only cause connection failures after DNS resolution, since the name resolves to an IP that drops or rejects traffic. Thus the absence of endpoints does not prevent the name from resolving.
- ✗
The Pod cannot resolve names from other namespaces
Why it's wrong here
Kubernetes DNS uses the fully qualified domain name schema <service>.<namespace>.svc.<cluster-domain>, so a pod in any namespace can resolve a Service in another namespace simply by including that namespace in the query. There is no built-in namespace isolation for DNS lookups; network policies may block traffic between namespaces, but they do not affect the DNS resolution itself. The statement that the pod cannot resolve names from other namespaces is therefore incorrect, because cross-namespace resolution is a standard and expected capability.
- ✗
The Service type is NodePort
Why it's wrong here
The Service type (ClusterIP, NodePort, LoadBalancer) determines how the Service is exposed externally, not how it is discovered internally. For every type except headless, an A record is created for the Service in the cluster DNS, and that record points to the Service's ClusterIP (or to pod IPs for headless Services). Changing the type to NodePort does not remove or alter the DNS entry; the name still resolves normally. Consequently, the Service type being NodePort is an irrelevant detail for a DNS resolution failure.
- ✓
The DNS add-on (e.g., CoreDNS) is not deployed or is misconfigured
Why this is correct
In-cluster DNS resolution depends entirely on a working cluster DNS add-on, most commonly CoreDNS, which runs as a daemon and provides a service named kube-dns. If CoreDNS is not deployed, is crashing, or has a misconfigured Corefile (e.g., missing Kubernetes plugin or incorrect zone), no Service names can be resolved for any pod. This matches the described symptom exactly, because the failure would affect all Services, not just svc-a. Therefore this is the only option that correctly identifies a root cause that would cause DNS resolution to fail.
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.