CKA Services and Networking Practice Question
A NetworkPolicy named 'deny-all' is applied to a namespace with podSelector: {}. The policy has no ingress rules. What is the effect?
⚠ Common exam trap
Watch out — candidates often assume `podSelector: {}` matches nothing or that a policy with no rules allows all traffic, but in Kubernetes, an empty podSelector matches all pods, and a NetworkPolicy with no ingress rules defaults to denying all ingress 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
✓
All ingress traffic to pods in the namespace is denied, but egress traffic is allowed.
A NetworkPolicy with `podSelector: {}` selects all pods in the namespace. With no ingress rules defined, the policy defaults to denying all ingress traffic to those pods, while egress traffic remains unrestricted unless explicitly denied by another policy. This is because Kubernetes NetworkPolicy is additive for ingress: if any policy selects a pod, the default allow for ingress is overridden, and only explicitly allowed ingress traffic is permitted.
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 traffic to and from pods in the namespace is denied.
Why it's wrong here
This statement is incorrect because a standard default-deny ingress policy only targets incoming traffic by specifying Ingress in its policyTypes. Since Egress is not explicitly declared in the policy types or restricted by egress rules, outbound traffic from the pods remains entirely unrestricted.
- ✗
Only traffic from pods in the same namespace is allowed.
Why it's wrong here
This option is false because the policy contains an empty ingress rules list, which acts as an absolute block on all incoming connections. No exceptions are made for intra-namespace traffic, meaning even pods residing within the same namespace are prevented from communicating with each other.
- ✓
All ingress traffic to pods in the namespace is denied, but egress traffic is allowed.
Why this is correct
This is the correct behavior because setting podSelector: {} applies the policy to all pods in the namespace, and omitting ingress rules creates an isolate-and-deny-all state for incoming traffic. Because the policy does not define Egress in its policyTypes, outbound connections from these pods are left unaffected and allowed by default.
- ✗
All traffic is allowed because podSelector: {} matches nothing.
Why it's wrong here
This assertion is technically inaccurate because an empty podSelector: {} is a wildcard that selects every single pod within the namespace rather than matching none. Consequently, the policy is actively enforced across all workloads in the namespace, resulting in a complete block of ingress traffic instead of allowing it.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
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.
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.
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.