CKA Services and Networking Practice Question
Which of the following is a valid use case for a Headless Service?
⚠ Common exam trap
Many exam-takers confuse the purpose of a Headless Service with a regular ClusterIP Service, assuming it still provides load balancing or a stable virtual IP, when in fact it is designed for direct pod DNS resolution without proxying.
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 DNS-based service discovery for stateful applications like StatefulSets
A Headless Service (with clusterIP: None) is used to enable DNS-based service discovery, returning the IP addresses of all backing pods rather than a single virtual IP. This is essential for stateful applications like StatefulSets, where each pod requires a stable network identity and direct pod-to-pod communication without load balancing.
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 provide a stable IP address for a deployment
Why it's wrong here
Headless Services explicitly set the clusterIP field to None, meaning Kubernetes does not allocate a single, stable virtual IP address for the service. Instead of routing traffic through a single service IP to a Deployment's pods, DNS queries for a headless service return the direct IP addresses of the underlying pods.
- ✓
To enable DNS-based service discovery for stateful applications like StatefulSets
Why this is correct
By setting clusterIP to None, a headless service allows CoreDNS to generate direct A or AAAA records for each individual pod associated with a StatefulSet. This enables peer-to-peer discovery and direct communication between specific replicas, which is essential for clustering databases like PostgreSQL, Cassandra, or Kafka.
- ✗
To load balance traffic across pods using iptables
Why it's wrong here
Standard services use kube-proxy to configure iptables or IPVS rules that load balance traffic across backend pods. Because headless services lack a ClusterIP, kube-proxy ignores them, bypassing iptables-based load balancing entirely and leaving client applications to manage connection distribution themselves.
- ✗
To allow external traffic to reach pods without a load balancer
Why it's wrong here
Headless services are strictly an internal cluster discovery mechanism and do not expose pods to external networks. To route external traffic directly to pods without a cloud load balancer, administrators must use alternative configurations such as NodePort services, HostNetwork, or HostPort settings.
Go deeper
Related to this question
Learn chapter
Network Policies and Secure Connectivity
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.
Key term
ClusterIP NodePort LoadBalancer
ClusterIP, NodePort, and LoadBalancer are three types of Kubernetes Services that control how traffic reaches your application pods inside the cluster or from outside.
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.