CKA Services and Networking Practice Question
You apply the following NetworkPolicy:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress
What effect does this policy have?
⚠ Common exam trap
Candidates often think a NetworkPolicy with no rules is ineffective or that `podSelector: {}` alone does nothing, but in Kubernetes, specifying `policyTypes` without corresponding rules triggers a default-deny for that traffic direction.
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 any pod in the namespace is denied.
This NetworkPolicy uses a `podSelector: {}` which selects all pods in the namespace, and specifies `policyTypes: [Ingress]` with no ingress rules. According to Kubernetes NetworkPolicy semantics, when no ingress rules are defined, all ingress traffic is denied. This effectively creates a default-deny ingress policy for all pods in the namespace, making option D correct.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Ingress traffic from pods with label 'app: allowed' is allowed.
Why it's wrong here
No ingress rule references any label, so 'app: allowed' pods receive no exemption; all inbound traffic is denied. The policy contains only policyTypes, with no from selectors. It tempts because label-based allow rules are the usual pattern, but here no such rule exists to permit that traffic.
- ✗
All ingress and egress traffic to/from pods in the namespace is denied.
Why it's wrong here
The policy lists only Ingress under policyTypes, so egress traffic remains unrestricted; it isolates pods for inbound connections alone. Adding Egress to policyTypes would deny outbound traffic too. This option describes a default-deny-all posture, which suits namespaces requiring complete isolation in both directions.
- ✗
The policy has no effect because no rules are specified.
Why it's wrong here
An empty podSelector with an Ingress policyType selects all pods and, with no ingress rules, denies all inbound traffic to them. The absence of rules enforces the deny, it does not nullify it. This option tempts those who assume rules are mandatory, but a rule-less policy is the standard default-deny construct.
- ✓
All ingress traffic to any pod in the namespace is denied.
Why this is correct
An empty podSelector selects every pod in the namespace, and the sole policyType is Ingress, so all inbound connections to those pods are blocked while egress stays unaffected. It satisfies the scenario's requirement to deny all incoming traffic namespace-wide.
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
One of 726 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.