CKS NetworkPolicy Practice Question
You need to isolate a compromised pod named 'malicious-pod' in the 'default' namespace so that it cannot communicate with any other pod, but can still receive traffic from a specific monitoring pod. Which NetworkPolicy should you apply?
⚠ Common exam trap
A common mistake is thinking that an empty `ingress` or `egress` array denies all traffic, but in NetworkPolicy, if the policy type is specified and no rules are provided, all traffic of that direction is denied. However, if the policy type is not specified, traffic is allowed.
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
✓
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod ingress: - from: - podSelector: matchLabels: app: monitoring-pod policyTypes: - Ingress - Egress
It selects the compromised pod, allows ingress only from the monitoring pod (using podSelector), and specifies policyTypes as both Ingress and Egress. Since no egress rules are defined, egress traffic is denied by default, isolating the pod from initiating communication. Option B incorrectly allows all egress via an empty egress rule. Option C denies all ingress (no ingress rules) and thus blocks the monitoring pod. Option D allows all ingress and does not restrict egress, failing to isolate the pod.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod ingress: - from: - podSelector: matchLabels: app: monitoring-pod policyTypes: - Ingress - Egress
Why this is correct
This policy correctly isolates the compromised pod by selecting it with podSelector and defining an ingress rule that only allows traffic from pods labeled app: monitoring-pod. Because policyTypes explicitly includes both Ingress and Egress, and no egress rules are present, the pod gets a default egress deny. Thus, the pod cannot reach outbound destinations and only accepts incoming traffic from the monitoring pod, achieving effective quarantine while preserving observability.
- ✗
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod egress: - {} policyTypes: - Egress
Why it's wrong here
This policy fails to isolate because it uses an empty egress rule (`{}`), which matches all destinations and explicitly permits all outbound traffic. Furthermore, policyTypes only lists Egress, meaning ingress traffic is entirely unrestricted: the pod can still receive connections from any source. An empty rule is an allow-all for that direction, so this configuration does nothing to contain the compromised pod and actually leaves it fully exposed.
- ✗
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod policyTypes: - Ingress - Egress
Why it's wrong here
Although this policy lists both Ingress and Egress in policyTypes and thus triggers default deny for both directions, it provides no ingress rule to allow the monitoring pod. This over-isolates by blocking all inbound and outbound traffic, including the legitimate monitoring traffic needed to inspect the compromised pod. True isolation should block unauthorized traffic while explicitly permitting a known monitoring source, so this blunt denial is operationally counterproductive.
- ✗
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod ingress: - {} policyTypes: - Ingress
Why it's wrong here
This policy is incorrect because the empty ingress rule (`{}`) allows all incoming connections from any source, not just the monitoring pod. Since policyTypes includes only Ingress, egress traffic is left completely unrestricted, enabling the compromised pod to communicate outward without limitation. The empty rule acts as a wildcard allow, effectively expanding the pod's network access instead of isolating it.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS 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 CKS 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 CKS exam.