An open-data portal needs DNS that returns Pod IPs for a discovery pattern similar to StatefulSet peers, not a single load-balanced ClusterIP. Which Service configuration produces that DNS behavior?
Select an answer to reveal the explanation.
Short Explanation
A normal ClusterIP Service is like a single front desk number that hides who is in the back. A headless Service (clusterIP: None) throws away that shared number and lets DNS hand out the actual desk phone numbers—the Pod IPs. That’s what you want for peer discovery patterns, including many StatefulSet-style setups.
Full Explanation
An open-data portal that needs DNS returning Pod IPs for a discovery pattern similar to StatefulSet peers—not a single load-balanced ClusterIP—should create a headless Service with clusterIP: None. Without a virtual ClusterIP, CoreDNS returns A/AAAA records for the Pods selected by the Service, and StatefulSets gain stable per-pod DNS names under the governing Service. A normal ClusterIP Service is one front-desk number; headless mode hands out the actual desk lines for peer discovery.
Creating a LoadBalancer Service so CoreDNS publishes only an external cloud VIP does not provide headless Pod-IP discovery semantics. Creating an ExternalName Service that CNAME-aliases to example.com does not enumerate Pod IPs. Annotating a ClusterIP Service with dnsPolicy: Default misuses a Pod DNS setting and does not skip kube-dns to invent headless behavior.
Exam caveat: headless Services still use selectors or explicit endpoints; not-ready Pods may be omitted unless publishNotReadyAddresses is set. Clients must handle multiple A records correctly.
Operational check: apply a headless Service selecting the portal Pods, dig the Service DNS name from another Pod, and confirm answers are Pod IPs rather than a single ClusterIP before wiring peer discovery logic. Document the headless Service name next to the StatefulSet governing service field.