CKA Practice Question 6: NetworkPolicy Default Deny DNS
Certified Kubernetes Administrator (CKA) · Test 1 · question 6 of 10
In the prod namespace you apply a default-deny NetworkPolicy with an empty podSelector and policyTypes: [Ingress, Egress]. You then add a second NetworkPolicy that allows egress from the application pods to the database pods on TCP 5432.
The application still cannot reach the database. Its logs show that connections fail during hostname lookup for db.prod.svc.cluster.local. The CNI plugin supports NetworkPolicy and the database pods are Running and Ready.
What is the cause?
Show answer and explanation
Answer:
This is the classic trap when introducing default-deny egress. Once a pod is selected by any policy with Egress in its policyTypes, all of its outbound traffic is denied except what a policy explicitly allows, and that includes DNS queries to CoreDNS in kube-system. The application never gets as far as opening a TCP connection to port 5432, because it cannot resolve the name first, which matches the "fails during hostname lookup" symptom. The fix is an additional egress rule allowing port 53 on both UDP and TCP to the CoreDNS pods, typically selected by a namespaceSelector for kube-system plus a podSelector for the DNS pod labels.
Option A is simply untrue: NetworkPolicy has supported egress rules for many releases, and the policyTypes field in the stem names Egress explicitly.
Option B misstates the evaluation model. NetworkPolicies are purely additive allow-lists; there is no deny rule and no precedence ordering. A pod's permitted traffic is the union of every matching policy's rules; the "default-deny" policy is just a policy that allows nothing.
Option D is a real consideration in some CNI implementations but is not the cause here. Traffic to a ClusterIP is DNAT'd to a backing pod IP, and policy is evaluated against that pod IP, so a podSelector matching the database pods works correctly. It also would not produce a name resolution failure.
Reference: Network Policies