City application Pods reach api.permits.svc.cluster.local successfully. Which component primarily provides that in-cluster Service DNS resolution?
Select an answer to reveal the explanation.
Short Explanation
In-cluster phone book duty belongs to CoreDNS. Names like api.permits.svc.cluster.local resolve there so Pods can find Services without memorizing ClusterIPs.
Full Explanation
City application Pods resolve names such as api.permits.svc.cluster.local primarily through CoreDNS, the usual cluster DNS provider. CoreDNS answers Service and pod DNS names inside the cluster domain, and kubelet points Pod resolv.conf at the cluster DNS Service ClusterIP so workloads discover municipal APIs without hard-coding IPs. That in-cluster phone book is CoreDNS’s job—not an edge, scheduler, or cloud-LB concern.
GatewayClass controllers implement Gateway API entrypoints; they do not own *.svc.cluster.local resolution. kube-scheduler binds Pods to nodes and does not inject static Service host entries on every Node as the primary discovery mechanism. Cloud LoadBalancer webhooks do not register ClusterIP names globally on the internet for in-cluster DNS lookups.
Exam caveat: DNS success is necessary but not sufficient for connectivity—empty Endpoints, NetworkPolicy, and listening ports still matter. Short names work only because search domains expand them toward FQDNs CoreDNS knows. If CoreDNS is down, name-based discovery fails even when Services exist.
Operational check: locate CoreDNS Pods and the kube-dns Service in kube-system, dig the permits Service FQDN from a client Pod, confirm the answer matches the Service ClusterIP, then test TCP/HTTP to separate resolution from application failures.