CKAD Services and Networking Practice Question
A developer creates a Deployment with 3 replicas and a Service with `clusterIP: None`. What is the primary use case for this headless Service?
⚠ Common exam trap
Many exam-takers confuse a headless Service with a regular ClusterIP Service, assuming it still provides load balancing or a stable virtual IP, when in fact it removes both to enable direct pod addressing.
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
✓
To enable direct pod-to-pod communication without load balancing
A headless Service (clusterIP: None) disables the kube-proxy load balancer and DNS round-robin, returning A/AAAA records for all ready pod IPs. This allows client applications to perform direct pod-to-pod communication for stateful workloads like databases or messaging systems that require custom load balancing or leader election.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
To assign a static IP address to the Service
Why it's wrong here
A headless Service is created with `clusterIP: None`, which explicitly prevents Kubernetes from allocating a ClusterIP address to it. Because there is no virtual IP, there is nothing to make static, and any attempt to use `loadBalancerIP` or `clusterIP` for such a Service would be invalid or ignored. Static IP assignment applies only to normal ClusterIP or LoadBalancer Services, so this is not the intended purpose.
- ✗
To automatically create an Ingress resource
Why it's wrong here
A headless Service is just a Service manifest with `clusterIP: None`; it has no relationship to Ingress and does not sync with the Ingress controller to auto-generate routing rules. Ingress resources must be explicitly created by the user and are separate objects that define HTTP/HTTPS routing to backend Services. Therefore, creating a headless Service cannot automatically create an Ingress resource.
- ✗
To expose the Service externally via a load balancer
Why it's wrong here
Headless Services disable the cluster's kube-proxy load-balancing machinery, so they do not distribute traffic among pods nor present a stable virtual endpoint. They also lack a NodePort or LoadBalancer assignment, so they do not expose the application outside the cluster. External exposure and load balancing require a Service type of NodePort or LoadBalancer, not `clusterIP: None`.
- ✓
To enable direct pod-to-pod communication without load balancing
Why this is correct
A headless Service, configured with `clusterIP: None`, tells Kubernetes to omit the virtual IP and instead make DNS return individual A records (or AAAA records) for every ready pod that matches the Service's label selector. This allows clients to connect directly to a pod's IP address, bypassing the kube-proxy VIP and enabling direct pod-to-pod communication without any load balancing. It is particularly useful for stateful applications like a database cluster that requires each pod to be discovered by its unique hostname and IP.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.