CKA Troubleshooting Practice Question
A user reports that their application cannot resolve DNS names for services in the cluster. The application runs in a pod with dnsPolicy: ClusterFirst. What is the most likely cause?
⚠ Common exam trap
The trap here is that candidates may overthink network-level issues (like UDP port blocking) or misread the dnsPolicy, when the simplest and most common cause is that the DNS service itself (CoreDNS) is not running.
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 CoreDNS deployment has 0 ready replicas.
When dnsPolicy is ClusterFirst, the pod's DNS queries are forwarded to the cluster's DNS service (CoreDNS by default). If the CoreDNS deployment has 0 ready replicas, the DNS service has no backend endpoints to handle queries, causing all DNS resolutions to fail. This is the most direct and common cause of complete DNS failure in a cluster.
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 CoreDNS deployment has 0 ready replicas.
Why this is correct
CoreDNS is the default cluster DNS provider in Kubernetes, responsible for resolving internal service names and external domains. If the CoreDNS deployment has zero ready replicas, there are no active pods to handle DNS queries sent to the kube-dns service IP. Consequently, any pod attempting to resolve a DNS name will experience a timeout or resolution failure.
- ✗
The pod's dnsPolicy is set to Default instead of ClusterFirst.
Why it's wrong here
The scenario establishes that the pod's dnsPolicy is already correctly configured to ClusterFirst, which instructs the kubelet to configure the pod to use the in-cluster DNS service. If it were set to Default, the pod would inherit the node's name resolution configuration instead. Therefore, this option is incorrect because the policy is already set to the desired ClusterFirst value.
- ✗
The node's network plugin is misconfigured, blocking UDP port 53.
Why it's wrong here
While a misconfigured Container Network Interface (CNI) plugin blocking UDP port 53 would indeed disrupt DNS traffic, such a fundamental network plugin failure would typically cause broader node-to-node or pod-to-pod communication failures across the entire cluster. Because the issue is isolated specifically to DNS name resolution rather than general network connectivity, a complete CNI misconfiguration is less likely than a localized CoreDNS service outage.
- ✗
The pod's /etc/resolv.conf contains incorrect nameserver entries.
Why it's wrong here
When a pod is created with the ClusterFirst DNS policy, the local kubelet automatically and reliably populates the pod's /etc/resolv.conf file with the correct ClusterIP of the kube-dns service and the appropriate search domains. Manual misconfiguration of this file is rare because it is managed dynamically by the control plane. Thus, incorrect entries in this file are highly unlikely to be the root cause under standard Kubernetes operations.
Visual reference
Go deeper
Related to this question
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.