CKAD Pod isolation Practice Question
Which THREE statements about NetworkPolicy are correct? (Select 3)
⚠ Common exam trap
A common pitfall in the CKAD exam is thinking NetworkPolicy is cluster-scoped (like a ClusterRole) or that it can block arbitrary external IPs without a CNI plugin that supports egress. Also, remember that by default all traffic is allowed; only when a policy selects a pod does the default become deny for the directions specified.
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
✓
NetworkPolicy follows an allow-list model; if no policy matches, traffic is denied.
NetworkPolicy follows an allow-list model: by default, all traffic to and from pods is allowed. Once a NetworkPolicy selects a pod, that pod becomes isolated, and only traffic explicitly allowed by the policy's rules is permitted for the specified direction (ingress/egress). Any traffic not matching an allow rule is denied for that direction. Option A is correct because once a policy applies, the default behavior becomes deny for unmatched traffic. Option C is correct because namespaceSelector can select a namespace, allowing traffic from all pods in that namespace. Option E is correct because NetworkPolicy can restrict egress traffic via egress rules. Option B is incorrect because ipBlock can be used to allow or block IP ranges, but blocking specific external IPs is possible only if the CNI supports it (and it's not universally supported). Option D is incorrect because NetworkPolicy is namespaced, not cluster-scoped.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
NetworkPolicy follows an allow-list model; if no policy matches, traffic is denied.
Why this is correct
Correct. In the Kubernetes NetworkPolicy model, a pod that is selected by any policy is isolated: all traffic that does not match an explicit allow rule is denied. This is an allow-list (whitelist) approach, meaning policies never add 'block' rules—they only declare allowed traffic. The apparent contradiction with the default allow-all behavior for unselected pods actually confirms the rule: isolation, and therefore default deny, only starts when at least one policy matches the pod.
- ✗
NetworkPolicy can block traffic to specific external IP addresses using ipBlock.
Why it's wrong here
ipBlock can be used in egress rules to restrict traffic to external IPs, but it can block or allow; the statement is ambiguous. Typically, ipBlock is used to allow traffic to external IPs. But actually, you can block by not including the IP in an allow rule. However, the statement is 'block traffic to specific external IP addresses' which is possible by not including them in an allow egress rule. But the default is deny, so you need to allow specific IPs. The statement is misleading. In practice, NetworkPolicy controls traffic to/from pods; it doesn't directly block external IPs unless you have a deny-all egress and then allow only specific CIDRs. But the statement is too absolute. I consider it false because NetworkPolicy is not a firewall for arbitrary external IPs.
- ✓
NetworkPolicy can use namespaceSelector to allow traffic from all pods in a namespace.
Why this is correct
Correct. A namespaceSelector matches namespaces by their labels, and when it appears in an ingress or egress rule it selects all pods running in any of those namespaces. For example, a rule with a namespaceSelector that matches 'team: api' allows traffic to/from every pod in every namespace that carries that label, regardless of the pod's own labels. This is especially useful for cross-namespace allow-listing without listing individual pod selectors.
- ✗
NetworkPolicy is a cluster-scoped resource.
Why it's wrong here
Incorrect. NetworkPolicy is a namespaced resource, not a cluster-scoped one; the YAML typically omits a namespace and the policy is applied to the current namespace (or the one in metadata.namespace). It can only select pods within that same namespace, and its selectors cannot directly reference pods in other namespaces—except indirectly through namespaceSelector directives. Cluster-scoped resources, such as ClusterRole and PersistentVolume, are not tied to a single namespace, unlike NetworkPolicy.
- ✓
NetworkPolicy can restrict egress traffic from pods.
Why this is correct
Correct. Egress rules enforce outbound connectivity: they limit the destinations a pod may communicate with, using podSelector, namespaceSelector, or ipBlock on the 'to' side. When an egress rule exists and matches a pod, all egress traffic that does not fall within an allow rule is dropped, which can be used to block data exfiltration or restrict a pod to specific internal services. Egress rules can be combined with ingress rules to fully segment a workload.
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.