Building-permits developers need DNS that returns the Pod IPs themselves for direct discovery, not a single ClusterIP. Which Service configuration fits?
Select an answer to reveal the explanation.
Short Explanation
Need the roster of Pod addresses, not one VIP? Create a headless Service — clusterIP: None.
Full Explanation
Building-permits developers who need DNS that returns the Pod IPs themselves for direct discovery, not a single ClusterIP, should create a headless Service with clusterIP set to None, which returns Pod addresses via DNS for direct discovery use cases. Headless Services skip the virtual IP and answer with Pod A records (for ready Pods by default), which fits stateful or peer-discovery patterns in permits platforms.
A LoadBalancer Service with externalTrafficPolicy Cluster does not always resolve to Pod A records only. A NodePort Service with sessionAffinity ClientIP does not disable ClusterIP allocation permanently as the headless mechanism. Any ordinary ClusterIP Service with publishNotReadyAddresses unset does not publish raw Pod IPs by default—it uses the ClusterIP.
Exam caveat: headless still uses selectors and readiness unless publishNotReadyAddresses is set. Operational check: create clusterIP: None Service, query DNS from a client Pod, and confirm answers are Pod IPs rather than a ClusterIP. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.