A KubernetesService without selectorsrequires you to manage its backend endpoints manually, soBis correct. Normally, a Service uses aselectorto match a set of Pods (by labels). Kubernetes then automatically maintains the backend list (historically Endpoints, now commonly EndpointSlice) by tracking which Pods match the selector and are Ready. This automation is one of the key reasons Services provide stable connectivity to dynamic Pods.

When you create a Servicewithout a selector, Kubernetes has no way to know which Pods (or external IPs) should receive traffic. In that pattern, you explicitly create anEndpointsobject (or EndpointSlices, depending on your approach and controller support) that maps the Service name to one or more IP:port tuples. This is commonly used to representexternal services(e.g., a database running outside the cluster) while still providing a stable Kubernetes Service DNS name for in-cluster clients. Another use case is advanced migration scenarios where endpoints are controlled by custom controllers rather than label selection.

Why the other options are wrong: ServicetypeslikeClusterIP,NodePort, andLoadBalancerdescribe how a Service is exposed, but they do not inherently require manual endpoint management. A ClusterIP Servicewith selectors(D) is the standard case where endpoints are automatically created and updated. NodePort and LoadBalancer Services also typically use selectors and therefore inherit automatic endpoint management; the difference is in how traffic enters the cluster, not how backends are discovered.

Operationally, when using Services without selectors, you must ensure endpoint IPs remain correct, health is accounted for (often via external tooling), and you update endpoints when backends change. The key concept is:no selector → Kubernetes can’t auto-populate endpoints → you must provide them.

=========