Pods must call legacy.permits.example.com using an in-cluster DNS name legacy-permits. Which Service type creates a CNAME-style mapping for that external hostname?
Select an answer to reveal the explanation.
Short Explanation
ExternalName is a sticky note in cluster DNS that says “when you ask for this Service, go look up that outside name.” Perfect for easing Pods toward a legacy hostname without selecting Pod backends. It’s a CNAME-style alias, not a cloud LB.
Full Explanation
Pods that must call legacy.permits.example.com using an in-cluster DNS name legacy-permits should use Service type ExternalName with externalName set to legacy.permits.example.com. ExternalName is a sticky note in cluster DNS that says when you ask for this Service name, look up that outside hostname—implemented as a CNAME-style mapping. It eases municipal Pods toward a legacy system without Pod selectors or in-cluster Endpoints objects.
A ClusterIP Service with an empty selector and no Endpoints object does not create that external hostname CNAME mapping in the ExternalName sense. NodePort with externalIPs set to the external hostname string misuses fields—externalIPs expects addresses, not a hostname alias mechanism. LoadBalancer with loadBalancerIP set to the hostname is not the ExternalName alias pattern and is the wrong tool for DNS remapping to legacy.permits.example.com.
Exam caveat: ExternalName does not make kube-proxy reverse-proxy to Pods; it rewrites discovery. Network reachability, DNS recursion, and firewall rules to the legacy system must still work. Operational check: create the ExternalName Service, from an app Pod resolve legacy-permits.<ns>.svc.cluster.local and confirm it references the external hostname, then test application connectivity. Record the alias in the municipal permits migration plan as a bridge while the legacy dependency remains outside the cluster.