CKAD Services and Networking Practice Question
A NetworkPolicy named 'default-deny-ingress' is applied to a namespace but contains no rules. What is the effect on pods in that namespace?
⚠ Common exam trap
Test-takers frequently assume an empty NetworkPolicy has no effect or allows all traffic by default, but Kubernetes isolates pods as soon as they are selected by any NetworkPolicy, and an empty rules list means deny all.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
All ingress traffic is denied.
A NetworkPolicy with no rules defaults to denying all ingress traffic because Kubernetes NetworkPolicies are additive: any pod selected by a NetworkPolicy is isolated, and only traffic explicitly allowed by rules is permitted. Since this policy has no rules, no ingress traffic is allowed, effectively creating a deny-all ingress policy for pods in the namespace.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
All ingress traffic is denied.
Why this is correct
A NetworkPolicy with an empty ingress rules list applies an implicit default-deny behavior: the pod selected by the podSelector is isolated, and because no source is listed as allowed, the Kubernetes network plugin blocks all incoming traffic to that pod. There is no separate 'deny all' rule needed; the absence of any ingress rule is itself the deny-all condition. This is why the policy is called a default-deny ingress policy.
- ✗
Only traffic from pods with label 'allow: true' is allowed.
Why it's wrong here
This option would require an ingress rule with a `from` section containing a `podSelector` matching pods labeled `allow: true`. Here, the policy's `ingress` array is completely empty, so there is no selector at all, and the policy never evaluates pod labels to decide admission. Consequently, allowing labeled pods would require adding an explicit rule; without one, even those labeled pods are denied.
- ✗
All ingress traffic is allowed.
Why it's wrong here
The NetworkPolicy semantics are the opposite: an empty `ingress` list means zero allow rules, and any traffic that does not match a rule is implicitly denied. In Kubernetes, a pod is initially allow-all until a policy selects it, but once this policy applies, the default switches to deny; it does not switch to allow-all. Thus, claiming all ingress is allowed confuses the pre-policy default with the post-policy isolation.
- ✗
Only traffic from pods in the same namespace is allowed.
Why it's wrong here
There is no implicit rule that grants access to pods in the same namespace; NetworkPolicy has no built-in same-namespace exemption. To allow same-namespace traffic, you would need an ingress rule with a `from` selector that matches all pods in the namespace (e.g., a `podSelector` with no matchLabels, or a `namespaceSelector` with the current namespace). Since this policy has no such rule, all ingress is denied—the policy does not distinguish between same-namespace and cross-namespace sources.
Visual reference
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKAD exam.