CKA Services and Networking Practice Question
Which THREE of the following are true about NetworkPolicy in Kubernetes? (Select 3)
⚠ Common exam trap
The CKA exam often tests the misconception that NetworkPolicy is cluster-scoped, but it is actually namespaced, and candidates frequently forget that egress rules require explicit allowance for DNS traffic to avoid breaking name resolution.
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 supports both ingress and egress rules
Option B is correct because a NetworkPolicy spec can include both an ingress array and an egress array, allowing you to control inbound and outbound traffic for the selected pods (with policyTypes declaring which directions are enforced). Option C is correct because the podSelector within an ingress/egress rule can be combined with a namespaceSelector, and when both are used in the same peer element they match pods in the namespaces selected by namespaceSelector, enabling cross-namespace pod selection. Option E is correct because Kubernetes NetworkPolicy is additive and default-allow: if no NetworkPolicy selects a given pod, that pod is not isolated and all ingress and egress traffic is permitted. Option A is not correct because NetworkPolicy peers are defined by ipBlock CIDRs, podSelector, and namespaceSelector — not by DNS names. Option D is not correct because NetworkPolicy is a namespaced resource (it lives in a namespace and selects pods within that namespace, though rules can reference other namespaces).
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 can define rules based on DNS names
Why it's wrong here
NetworkPolicy rules operate at the IP layer and can only express matches using podSelector, namespaceSelector, or ipBlock. DNS names are not part of the NetworkPolicy API because controllers and CNI plugins enforce rules against pod IP addresses, and hostnames/DNS would be ambiguous across namespaces and dynamic IP changes. Any rule based on a DNS name must be resolved to IP CIDRs manually using ipBlock.
- ✓
NetworkPolicy supports both ingress and egress rules
Why this is correct
NetworkPolicy is designed to control both directions of traffic. The spec contains an ingress section that restricts inbound connections to selected pods, and an egress section that restricts outbound connections from those pods. Each section is independently evaluated: an empty list under ingress means no inbound traffic is allowed, while an empty egress list blocks all outbound traffic, effectively creating default-deny behavior.
- ✓
NetworkPolicy can select pods from other namespaces using namespaceSelector
Why this is correct
Using namespaceSelector among the from or to peers selects all pods in any namespace whose labels match the given expression, including pods in different namespaces from the policy. For example, a policy in namespace ns-a with a namespaceSelector matching label 'team=metrics' can admit traffic from pods running in namespace ns-b that carries that label. You can also nest a podSelector inside the same peer to further scope the selected pods within those namespaces.
- ✗
NetworkPolicy is a cluster-scoped resource
Why it's wrong here
NetworkPolicy is a namespaced Kubernetes resource, created within a specific namespace and affecting only the pods in that namespace. It is not cluster-scoped; there is no cluster-wide NetworkPolicy object that applies to every namespace at once. A common workaround is to create identical policies in each namespace, or use a Namespace-scoped policy with an empty podSelector, but that still does not change the resource scope.
- ✓
By default, if no NetworkPolicy applies to a pod, all traffic to that pod is allowed
Why this is correct
When no NetworkPolicy selects a pod, the cluster's default behavior is to allow all traffic to and from that pod — both ingress and egress. The moment any NetworkPolicy selects the pod, that policy becomes the only source of truth for the allowed traffic, and anything not explicitly permitted is denied. This default-allow behavior is why the common "default deny" pattern is implemented by creating a policy that selects all pods with no rules.
Visual reference
Go deeper
Related to this question
Learn chapter
Installing Kubernetes with kubeadm
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
About these practice questions
Courseiva writes every CKA question from scratch — 726 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 CKA 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 CKA exam.