CKAD Services and Networking Practice Question
You have a Deployment with 3 replicas. You create a Service with 'clusterIP: None'. What is the effect on pod DNS?
⚠ Common exam trap
Many exam-takers confuse headless Services with regular ClusterIP Services, assuming 'None' means no DNS resolution at all, when in fact it changes the DNS behavior to return pod IPs directly.
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
✓
DNS returns the IPs of all matching pods.
When a Service is created with `clusterIP: None`, it becomes a headless Service. For a headless Service, DNS is configured to return the IP addresses of all matching pods (the endpoints) rather than a single virtual IP. This allows client applications to discover and connect to individual pods directly, which is essential for stateful workloads like databases.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Each pod gets its own DNS record in the form <pod-ip>.<service>.<namespace>.svc.cluster.local
Why it's wrong here
For a headless Service backing a Deployment, each pod does not receive an individual DNS record in the form <pod-ip>.<service>.<namespace>.svc.cluster.local. That naming scheme is used by StatefulSets, which create stable per-pod hostnames like <pod-name>.<service>.<namespace>.svc.cluster.local. In contrast, the headless Service for a Deployment simply returns a set of A records corresponding to the current pod IPs, so the DNS name expands to multiple addresses without per-pod names.
- ✓
DNS returns the IPs of all matching pods.
Why this is correct
With a headless Service (clusterIP: None) that has a selector matching the Deployment’s pods, the DNS name resolves to all matching pod IPs as separate A records. A DNS query for the Service name returns the list of endpoint IPs, which corresponds to the three running replicas. This design lets clients directly connect to individual pods for client-side load balancing or service discovery.
- ✗
The Service name does not resolve to any IP; DNS fails.
Why it's wrong here
DNS resolution does not fail; the Service name still resolves successfully to the underlying pod IP addresses. In a headless Service, CoreDNS returns multiple A records for the Service’s DNS name, each pointing to a different Pod IP. A failure (NXDOMAIN) would only occur if the Service has no endpoints, which is not the case given the deployment has three replicas matching the selector.
- ✗
The Service name resolves to a single virtual IP that load balances across pods.
Why it's wrong here
This describes a normal ClusterIP Service, not a headless Service. For a regular Service, DNS resolves to a single virtual ClusterIP that load-balances across all endpoints; however, this question is about a headless Service (clusterIP: None), where no virtual IP exists. Instead, DNS returns the actual pod IPs, allowing clients to perform their own load balancing or choose a specific pod directly.
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.