A library frontend in namespace web cannot resolve a backend Service named catalog in namespace data using only the short name catalog. What DNS name should it use instead?
Select an answer to reveal the explanation.
Short Explanation
Short Service names only work inside the same namespace—cross-namespace needs the fuller name, like catalog.data.svc.cluster.local. Think city, street, then house number.
Full Explanation
A library frontend in namespace web that cannot resolve a backend Service named catalog in namespace data using only the short name catalog should use a cross-namespace DNS name such as catalog.data.svc.cluster.local. Short Service names resolve within the same namespace search path; cross-namespace calls need the Service name plus namespace and usually svc.cluster.local. That FQDN pattern is essential for multi-namespace municipal library architectures.
catalog.svc.default.cluster.local only is wrong because it points at the default namespace, not data. Node-local DNS on 127.0.0.1 does not rewrite all Service names to NodePorts as described. Using the backend Pod IP from /etc/hosts on the worker is brittle and bypasses Service DNS entirely.
Exam caveat: DNS search domains in resolv.conf explain why short names work in-namespace. Operational check: from a web Pod, nslookup or curl catalog.data.svc.cluster.local and confirm CoreDNS answers with the Service 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.