CKA Services and Networking Practice Question
After creating a NetworkPolicy that selects pods with label 'role: db' and allows ingress on TCP port 3306 from pods with label 'role: api', you notice that pods with label 'role: db' are still reachable on port 3306 from pods without 'role: api' label. What is the most likely cause?
⚠ Common exam trap
A common mix-up: candidates assume NetworkPolicies are cluster-scoped or automatically apply across namespaces, but they are namespaced resources and only affect pods in the same namespace unless explicitly using namespaceSelectors.
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
✓
The NetworkPolicy is not in the same namespace as the pods.
NetworkPolicies are namespaced resources. If the NetworkPolicy is created in a different namespace than the pods with label 'role: db', it will not apply to those pods. The policy must reside in the same namespace as the pods it targets; otherwise, the default behavior (allow all ingress) remains in effect for those pods.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The NetworkPolicy is not in the same namespace as the pods.
Why this is correct
Kubernetes NetworkPolicy resources are strictly namespace-scoped. The podSelector defined within a policy only matches pods residing in the exact same namespace as the policy itself. If the policy is deployed in a different namespace than the target pods, it will fail to select them and have no effect on their traffic.
- ✗
The NetworkPolicy uses the wrong protocol.
Why it's wrong here
While specifying an incorrect protocol (such as UDP instead of TCP for a database like MySQL) would block traffic, it does not explain why a policy fails to apply or select the target pods. NetworkPolicies default to TCP if no protocol is explicitly defined, which is the correct transport protocol for standard database connections.
- ✗
The NetworkPolicy has an egress rule that overrides ingress.
Why it's wrong here
In Kubernetes, ingress and egress rules are evaluated independently based on the policyTypes array. An egress rule controls outbound traffic from the selected pods and cannot override, negate, or conflict with ingress rules designed to manage incoming traffic. They operate on separate traffic directions and do not interfere with each other's evaluation.
- ✗
The NetworkPolicy requires an explicit 'deny all' rule.
Why it's wrong here
Kubernetes operates on a default-allow model until a NetworkPolicy selects a pod, at which point an implicit default-deny behavior is activated for unallowed traffic. There is no requirement to write an explicit 'deny all' rule to enforce isolation. Once a pod is selected by any policy, all traffic not explicitly whitelisted is automatically blocked.
About these practice questions
This CKA question is part of Courseiva's 726-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 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.