CKA Services and Networking Practice Question
A pod is unable to resolve DNS names of services in other namespaces. Which DNS configuration is most likely missing?
⚠ Common exam trap
A common mix-up: candidates assume DNS issues are always due to CoreDNS not running or a service misconfiguration, but the CKA exam tests the subtle behavior of `dnsPolicy` and how `Default` inherits the node's DNS, breaking cluster service resolution.
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 pod's dnsPolicy is set to 'Default'.
When a pod's `dnsPolicy` is set to `Default`, the pod inherits the node's DNS resolution configuration, which typically points to the host's `/etc/resolv.conf` and does not include the cluster's DNS service (CoreDNS). This prevents the pod from resolving service DNS names like `<service>.<namespace>.svc.cluster.local`, which are only resolvable via the cluster's DNS. Setting `dnsPolicy` to `ClusterFirst` (the default if not specified) ensures the pod uses CoreDNS for DNS queries, enabling cross-namespace service discovery.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
CoreDNS is not deployed in the cluster.
Why it's wrong here
If CoreDNS were completely absent from the cluster, all internal Kubernetes DNS resolution would fail, including local namespace lookups. Because the issue is specifically isolated to resolving services in other namespaces, CoreDNS must be running but is bypassed or unreachable by this specific pod.
- ✓
The pod's dnsPolicy is set to 'Default'.
Why this is correct
When a pod's dnsPolicy is configured as 'Default', it inherits the name resolution configuration of the hosting node rather than using the cluster's DNS service (CoreDNS). Consequently, the pod can resolve external internet domains but lacks the search paths and nameservers required to resolve internal Kubernetes service FQDNs across namespaces.
- ✗
The pod is in a different namespace than the service.
Why it's wrong here
Kubernetes natively supports cross-namespace service discovery using Fully Qualified Domain Names (FQDNs) formatted as '<service-name>.<namespace>.svc.cluster.local'. Simply residing in a different namespace does not block DNS resolution, provided the pod is querying the correct FQDN and using the cluster's DNS resolver.
- ✗
The service does not have a ClusterIP assigned.
Why it's wrong here
Headless services defined with 'clusterIP: None' still have valid DNS records created for them by CoreDNS. Instead of resolving to a single virtual IP, a query for a headless service returns the IP addresses of the underlying ready pods, meaning DNS resolution itself still succeeds.
Visual reference
Go deeper
Related to this question
Learn chapter
Troubleshooting Networking and Services
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
Kubernetes Services
A Kubernetes Service is a stable network endpoint that connects a set of pods to internal or external traffic, providing consistent access even as pods change.
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.