CKAD Services and Networking Practice Question
A NetworkPolicy with the following spec is applied: spec: podSelector: {} policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: frontend What does this policy do?
⚠ Common exam trap
Candidates often think an empty `podSelector: {}` has no effect, but in Kubernetes, it selects all pods in the namespace, and combined with the ingress rule, it creates a default-deny for all other traffic.
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
✓
Allows incoming traffic from pods labeled 'role: frontend' to all pods
This NetworkPolicy selects all pods (empty podSelector `{}`) and defines an ingress rule that only allows incoming traffic from pods with the label `role: frontend`. By default, Kubernetes NetworkPolicies are additive and deny all traffic that is not explicitly allowed, so this policy permits ingress from frontend pods to all pods while blocking all other inbound traffic.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Allows all outgoing traffic from pods labeled 'role: frontend'
Why it's wrong here
This interpretation reverses the direction of the policy. The policy defines an ingress rule, meaning it evaluates incoming connections to the selected destination pods; it contains no egress specification, so outbound traffic from any pod is unaffected. Even for ingress, the selected destination is all pods in the namespace (empty podSelector), not only pods with the 'role: frontend' label. Thus the policy neither describes outgoing traffic nor targets that specific pod set.
- ✗
Blocks all incoming traffic to pods labeled 'role: frontend'
Why it's wrong here
NetworkPolicy rules are allow-list entries, not deny rules. The ingress 'from' selector 'role: frontend' identifies permitted sources, so matching pods are allowed to connect, not blocked. Furthermore, the empty podSelector in the policy spec applies the rule to every pod in the namespace as the destination, not just to pods carrying 'role: frontend'. This option is incorrect because it mistakes permission for restriction and misidentifies the affected destination set.
- ✓
Allows incoming traffic from pods labeled 'role: frontend' to all pods
Why this is correct
The policy spec uses an empty podSelector, which selects all pods in the namespace as the destination of traffic. Its ingress rule contains a from podSelector matching any pod labeled 'role: frontend', so those sources are explicitly allowed to initiate connections to every pod selected by the policy. Since no egress rules or policyTypes are set, only inbound traffic is controlled and only from that source label.
- ✗
Has no effect because policyTypes is missing Egress
Why it's wrong here
Omission of the policyTypes field does not nullify the policy. Per the NetworkPolicy spec, if policyTypes is absent it defaults to whatever types of rules appear in the spec: here an ingress rule is present, so it defaults to 'Ingress' and the rule is enforced. A missing Egress entry simply means no egress restrictions are added, which is a valid single-direction policy. The policy therefore remains fully effective for the ingress rule it declares.
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.