What is the most appropriate use case for a headless service in Kubernetes?

• A. Exposes a stable virtual IP for load balancing
• B. Routes external traffic to the service via an external load balancer
• C. Returns the actual set of endpoints for the service, allowing direct connection to pods
• D. Provides DNS resolution to external services

Answer: (C)

Headless services in Kubernetes are used when you want clients to connect directly to the actual pods behind the service, rather than going through a single virtual IP. By not allocating a cluster IP (clusterIP: None), the service doesn't provide a stable VIP or perform kube-proxy–level load balancing. Instead, DNS for the service returns the list of pod endpoints, so clients can choose a specific pod or iterate through the endpoints themselves.

This is why returning the actual set of endpoints is the best fit: it enables direct pod addressing and is often used with StatefulSets or custom distribution logic where you need insight into or control over which pod you connect to.

The other ideas don’t fit because a headless service does not expose a stable virtual IP for load balancing, it isn’t about routing external traffic through an external load balancer, and it doesn’t provide DNS resolution to external services.