CKAD Services and Networking Practice Question
A developer creates a headless Service with 'clusterIP: None' for a StatefulSet. What is the primary purpose of using a headless Service?
⚠ Common exam trap
Test-takers frequently confuse 'headless' with 'no DNS' or 'no networking', when in fact headless Services provide DNS records for individual pods, which is essential for stateful workloads that need stable identities.
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 provide stable network identities and DNS records for each pod in the StatefulSet
A headless Service (with `clusterIP: None`) is used with StatefulSets to provide stable, unique network identities (DNS records) for each pod. Instead of a single virtual IP and round-robin load balancing, the headless Service returns A/AAAA records for each pod's individual IP address, enabling direct pod-to-pod communication based on stable hostnames like `pod-name.service-name.namespace.svc.cluster.local`.
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 prevent DNS resolution of the service
Why it's wrong here
Headless services still expose DNS records; setting ClusterIP: None simply omits a virtual IP. With a headless service, the DNS name resolves to the individual pod IPs (or, in a StatefulSet, to per-pod DNS names), so the service does not 'prevent' DNS resolution—it changes the shape of that resolution from a single VIP to a list of endpoint IPs.
- ✗
To enable TLS termination at the service level
Why it's wrong here
TLS termination is a Layer 7 concern and is handled by ingress controllers, Gateway API, or sidecar proxies (e.g., Istio) because it requires inspecting the encrypted request and often decrypting/encrypting on behalf of backends. A headless service inherently operates at Layer 4, exposing raw pod IPs and ports without any protocol-level awareness, so it cannot terminate TLS.
- ✗
To provide load balancing across the pods
Why it's wrong here
A regular ClusterIP service gives clients a virtual IP and uses kube-proxy to balance traffic across the backing pods. A headless service (ClusterIP: None) deliberately removes that virtual IP; its DNS query returns a set of pod IP addresses, leaving the client to perform any load distribution, so it does not provide load balancing itself.
- ✓
To provide stable network identities and DNS records for each pod in the StatefulSet
Why this is correct
When a headless service is paired with a StatefulSet, each pod receives a unique, stable DNS record of the form <pod-name>.<service-name>.<namespace>.svc.cluster.local. Because pods are created with deterministic ordinal names (e.g., web-0, web-1), the headless service creates these per-pod DNS entries, giving each pod a stable network identity that remains reachable directly by name even if pods are rescheduled.
Visual reference
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 160-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 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.