KCNA Container Orchestration Practice Question
A cluster administrator is configuring a NetworkPolicy for a set of pods labeled 'role=db' in the 'backend' namespace. The policy should allow ingress only from pods labeled 'role=api' in the 'frontend' namespace, and only on TCP port 6379. Which NetworkPolicy specification correctly enforces this?
⚠ Common exam trap
The trap here is using an arbitrary namespace label like 'name: frontend' instead of the automatically applied 'kubernetes.io/metadata.name: frontend', or forgetting to include the podSelector for the source pods.
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
✓
spec: { podSelector: { matchLabels: { role: db } }, ingress: [ { from: [ { namespaceSelector: { matchLabels: { kubernetes.io/metadata.name: frontend } }, podSelector: { matchLabels: { role: api } } } ], ports: [ { protocol: TCP, port: 6379 } ] } ] }
A NetworkPolicy ingress rule can combine namespaceSelector and podSelector to allow traffic from specific pods in specific namespaces. The namespaceSelector must match the namespace's labels; Kubernetes automatically labels namespaces with 'kubernetes.io/metadata.name=<namespace-name>'. The policy must also specify the allowed port. The correct specification uses the proper namespace label and includes both selectors.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
spec: { podSelector: { matchLabels: { role: db } }, ingress: [ { from: [ { podSelector: { matchLabels: { role: api } } } ], ports: [ { protocol: TCP, port: 6379 } ] } ] }
Why it's wrong here
This policy only uses a podSelector for the source, which matches pods with 'role=api' in the same namespace as the policy (backend). It does not restrict to the frontend namespace, so it would allow traffic from any pod with that label in the backend namespace, violating the requirement.
- ✗
spec: { podSelector: { matchLabels: { role: db } }, ingress: [ { from: [ { namespaceSelector: { matchLabels: { name: frontend } } } ], ports: [ { protocol: TCP, port: 6379 } ] } ] }
Why it's wrong here
This policy uses namespaceSelector with 'name: frontend' (incorrect label) and omits the podSelector for 'role=api'. It would allow all pods from the frontend namespace if the namespace label were correct, but it is not, so it fails to match. Additionally, it does not restrict to pods with 'role=api'.
- ✓
spec: { podSelector: { matchLabels: { role: db } }, ingress: [ { from: [ { namespaceSelector: { matchLabels: { kubernetes.io/metadata.name: frontend } }, podSelector: { matchLabels: { role: api } } } ], ports: [ { protocol: TCP, port: 6379 } ] } ] }
Why this is correct
This policy selects pods with 'role=db' in the backend namespace. The ingress rule allows traffic from pods with 'role=api' in namespaces labeled 'kubernetes.io/metadata.name=frontend', which is the standard label automatically applied to namespaces. It restricts to TCP port 6379, correctly enforcing the requirement.
- ✗
spec: { podSelector: { matchLabels: { role: db } }, ingress: [ { from: [ { namespaceSelector: { matchLabels: { name: frontend } }, podSelector: { matchLabels: { role: api } } } ], ports: [ { protocol: TCP, port: 6379 } ] } ] }
Why it's wrong here
This policy uses namespaceSelector with matchLabels 'name: frontend', but the default namespace label is 'kubernetes.io/metadata.name: frontend', not 'name: frontend'. Without the correct label, the namespaceSelector will not match the frontend namespace, so the policy will not allow traffic from it.
Go deeper
Related to this question
Learn chapter
Cluster Architecture and Lifecycle Management
Key term
Namespaces
A Namespace in Kubernetes is a virtual cluster within a physical cluster that allows you to organize and isolate resources, like an apartment building with separate units for different tenants.
Key term
ReplicaSet and Replication
A ReplicaSet ensures a specified number of identical pod instances are running at all times in Kubernetes, using replication to maintain availability and stability.
About these practice questions
This KCNA question is part of Courseiva's 930-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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This KCNA 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 KCNA exam.