CKA Services and Networking Practice Question
What is the purpose of a headless Service (clusterIP: None)?
⚠ Common exam trap
A common mix-up: candidates confuse a headless Service with a regular ClusterIP Service, assuming it still provides load balancing or external access, when in fact it is designed for direct pod-to-pod DNS resolution without a virtual IP.
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 allow direct DNS resolution to pod IPs
A headless Service (clusterIP: None) disables the virtual IP and load balancing, causing DNS queries to return the IP addresses of the backing pods directly. This allows clients to perform DNS-based service discovery and connect to specific pod IPs, which is essential for stateful applications like databases that require direct pod-to-pod communication.
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 expose the Service externally via a cloud load balancer
Why it's wrong here
This option describes the LoadBalancer Service type, which provisions an external load balancer in supported cloud environments to route external traffic into the cluster. In contrast, a headless Service with clusterIP: None is an internal mechanism that does not allocate a virtual IP or interface with external cloud providers.
- ✗
To provide load balancing across pods
Why it's wrong here
A headless Service (clusterIP: None) does not provide load balancing because it returns the IP addresses of all matching pods directly via DNS, rather than distributing traffic through a virtual IP. This option is tempting because standard Services with a clusterIP do perform load balancing across pods, making it a natural assumption that a headless Service would do the same, but its actual purpose is to enable direct pod-to-pod communication for stateful workloads.
- ✗
To map the Service to an external DNS name
Why it's wrong here
This behavior is characteristic of the ExternalName Service type, which maps a Kubernetes Service to an arbitrary external DNS name using a CNAME record. Headless Services, however, are designed to discover and resolve internal Pod IPs within the cluster using CoreDNS, rather than redirecting traffic to external third-party domains.
- ✓
To allow direct DNS resolution to pod IPs
Why this is correct
By setting clusterIP: None, Kubernetes bypasses the allocation of a single virtual IP for the Service. Instead, the internal DNS server directly returns a list of A or AAAA records containing the individual IP addresses of all matching, healthy Pods, allowing clients to establish direct, peer-to-peer connections with specific Pods.
Go deeper
Related to this question
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
Courseiva writes every CKA question from scratch — 726 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 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.