CKA Kubernetes DNS Practice Question
A pod in namespace 'ns1' cannot resolve the DNS name 'svc.ns2.svc.cluster.local'. What is the most likely cause?
⚠ Common exam trap
Candidates often confuse cross-namespace resolution issues. While it is true that a pod in 'ns1' cannot resolve a service in 'ns2' using only the short name 'svc', the stem specifies that the FQDN 'svc.ns2.svc.cluster.local' itself is failing to resolve. If the FQDN fails, the issue is that the target Service does not exist, not that the pod is using a short name.
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 service 'svc' does not exist in namespace 'ns2'.
In Kubernetes, CoreDNS dynamically creates DNS records for Services using the format '<service-name>.<namespace>.svc.<cluster-domain>'. If a pod attempts to resolve the fully qualified domain name (FQDN) 'svc.ns2.svc.cluster.local' and fails, the most likely cause is that the Service named 'svc' does not exist in the namespace 'ns2', meaning no DNS record exists for it.
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 DNS policy is set to None.
Why it's wrong here
DNS policy None removes cluster DNS configuration entirely, so the pod would fail all cluster lookups, not just cross-namespace ones; the stem implies other resolution works. It is tempting because None genuinely breaks DNS, and it would be correct when a pod must use only externally supplied nameservers via dnsConfig.
- ✓
The service 'svc' does not exist in namespace 'ns2'.
Why this is correct
DNS resolution of svc.ns2.svc.cluster.local requires a Service named svc in namespace ns2; CoreDNS returns NXDOMAIN when that Service is absent. Since the pod's own namespace is irrelevant to a fully qualified cross-namespace lookup, a missing Service in ns2 is the most likely cause.
- ✗
The pod is trying to resolve using only the short service name 'svc' without the namespace.
Why it's wrong here
Short names like 'svc' resolve only within the pod's own namespace, so this describes expected behaviour rather than the failure of the fully qualified name 'svc.ns2.svc.cluster.local'. It is tempting because short-name resolution is a common real-world mistake, and it would be the answer if the stem asked about 'svc' alone.
- ✗
The pod's DNS policy is set to Default.
Why it's wrong here
Default DNS policy inherits the node's resolv.conf and still routes cluster lookups through CoreDNS, so cross-namespace resolution works. It is tempting because Default is the standard setting for most pods, and it would be correct when a pod needs custom upstream nameservers via dnsConfig rather than cluster DNS.
Visual reference
Go deeper
Related to this question
Learn chapter
Services and Networking Fundamentals
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.
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.
About these practice questions
This CKA question is part of Courseiva's 726-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.