A library namespace applies a strict egress NetworkPolicy that blocks nearly all outbound traffic. Name resolution for Services immediately fails. What egress allowance is typically still required?
Select an answer to reveal the explanation.
Short Explanation
Lock the exits too hard and nobody can even look up phone numbers — leave a DNS path to CoreDNS on port 53.
Full Explanation
A library namespace that applies a strict egress NetworkPolicy blocking nearly all outbound traffic and then loses Service name resolution typically still requires allowing egress to the kube-system CoreDNS or kube-dns Pods or Service on UDP/TCP port 53 so DNS queries can succeed. Strict egress without DNS exceptions breaks short-name and FQDN Service discovery even when the backend Pods themselves would otherwise be reachable by raw IP.
Allowing egress only to etcd peer ports on control-plane nodes does not restore application DNS. Allowing egress to the metrics-server HTTPS port does not substitute for DNS. Allowing egress solely to NodePort ranges does not make DNS ride on kube-proxy hairpin NAT automatically.
Exam caveat: identify CoreDNS Pod labels/namespace for namespaceSelector and podSelector peers carefully. Operational check: add egress allow to DNS on port 53, retry nslookup from a library Pod, then layer additional egress allows for required app destinations. 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.