A school district app resolves short name api inside its own namespace but fails when the same short name is used to reach a Service in another namespace. Why?
Select an answer to reveal the explanation.
Short Explanation
Short name api is like saying “front desk” on your own floor—search paths fill in your namespace. Another floor needs a clearer address, such as api.otherns or the full svc.cluster.local name.
Full Explanation
A school district application resolves short name api inside its own namespace because DNS search paths expand unqualified names within the local namespace context (toward api.<namespace>.svc.cluster.local). The same short name fails when aiming at a Service in another namespace because search paths do not make api cluster-unique—cross-namespace access needs a qualified name such as api.otherns or the full svc.cluster.local FQDN. Short names are nicknames on your floor, not megaphones across buildings.
CoreDNS does not allow short names only for headless Services. Cross-namespace short names do not start working merely because both namespaces share a NetworkPolicy allow-all. kube-proxy does not block short-name resolution unless the Service type is LoadBalancer—the limitation is DNS search scope, not kube-proxy or Service type.
Exam caveat: identical Service names across namespaces are common in multi-tenant municipal clusters; baking FQDNs into app config prevents ambiguous search expansion. The resolv.conf ndots option influences how many suffixes are tried before the resolver treats a name as absolute.
Operational check: from the client Pod, dig api, api.otherns, and api.otherns.svc.cluster.local; update application configuration to use explicitly qualified names for cross-namespace calls; retest after DNS answers correctly. Prefer FQDNs in deployment manifests reviewed by the platform team.