Services and Networking →easyMultiple Choice

CKAD Services and Networking Practice Question

You want to deny all incoming traffic to a set of pods except from pods with label 'role: frontend'. Which NetworkPolicy spec should you use?

⚠ Common exam trap

A common mix-up: candidates confuse podSelector with namespaceSelector, or using an empty podSelector that applies the policy to all pods instead of a specific set, leading to unintended broad access or denial.

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: app: myapp ingress: - from: - podSelector: matchLabels: role: frontend

It selects pods with label 'app: myapp' and defines an ingress rule that only allows traffic from pods with label 'role: frontend'. By default, NetworkPolicy denies all traffic not explicitly allowed, so this configuration ensures only frontend pods can reach the selected 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.

✗
spec: podSelector: matchLabels: app: myapp ingress: - from: - namespaceSelector: matchLabels: role: frontend
Why it's wrong here
The podSelector in the spec correctly targets the protected pods, but the `from` clause uses a `namespaceSelector`, which matches namespaces by their labels rather than individual pods. This would permit incoming traffic from any pod running in any namespace labeled `role=frontend`, even if those pods themselves don't carry that label. The rule therefore does not enforce the required pod-level restriction to only allow traffic from pods labeled `role=frontend`.
✗
spec: podSelector: matchLabels: app: myapp egress: - to: - podSelector: matchLabels: role: frontend
Why it's wrong here
This rule is placed under the `egress` field instead of `ingress`, so it restricts outbound traffic from the selected pods rather than denying incoming traffic to them. In a NetworkPolicy, `egress` controls connections leaving the pod, while `ingress` controls connections arriving at the pod. Since the requirement is to deny all incoming traffic except from frontend pods, this configuration addresses the wrong direction and leaves incoming traffic unrestricted.
✗
spec: podSelector: {} ingress: - from: - podSelector: matchLabels: role: frontend
Why it's wrong here
An empty `podSelector` (`{}`) selects every pod in the namespace rather than the specific set of pods intended to be protected (e.g., those with `app=myapp`). This means the policy would apply to all pods, potentially allowing traffic from `role=frontend` pods to reach unrelated workloads and failing to isolate the intended pods. The selector must be scoped to the target pods by using labels that uniquely identify them, such as `app: myapp`.
✓
spec: podSelector: matchLabels: app: myapp ingress: - from: - podSelector: matchLabels: role: frontend
Why this is correct
This is the correct NetworkPolicy because `spec.podSelector` matches only the protected pods labeled `app=myapp`, and the single `ingress` rule uses a `from` clause with a `podSelector` that matches source pods labeled `role=frontend`. By defining only this rule and no default `ingress` rules, the policy defaults to denying all other incoming traffic to those pods while explicitly permitting traffic from the intended frontend pods. The use of `podSelector` for both the target and the source ensures precise, pod-level control over allowed ingress.

Go deeper

CKAD Services and Networking Practice Question

Why each option matters

Option-by-option breakdown

Related to this question