CKS Monitoring, Logging and Runtime Security Practice Question

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 spec: podSelector: matchLabels: app: busybox egress: - to: - podSelector: {}

  Why it's wrong here

  This policy cannot isolate the pod because it defines an egress rule that explicitly allows all outbound connections: `podSelector: {}` in the `to` field matches every pod, so the compromised busybox pod may freely send traffic anywhere. Additionally, since only an egress rule is present and `policyTypes` is omitted, Kubernetes infers `policyTypes` as `Egress` alone, leaving ingress traffic completely unisolated. The result is a permissive allow rule for egress and no restriction on ingress, so the pod remains compromised and fully networked.

• ✗

  apiVersion: v1 kind: NetworkPolicy metadata: name: isolate spec: podSelector: {} policyTypes: - Ingress

  Why it's wrong here

  This manifest is invalid because `NetworkPolicy` is a networking.k8s.io/v1 resource, not a core v1 resource, so the API server will reject it. Even if it were accepted, an empty `podSelector: {}` selects every pod in the namespace, meaning the policy would apply a default-deny on ingress to the entire namespace while leaving egress unrestricted. That is far too broad and does not target the compromised `busybox` pod specifically, so it cannot be used for isolated containment.

• ✗

  apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate spec: podSelector: matchLabels: app: busybox ingress: - from: - podSelector: {}

  Why it's wrong here

  This policy is the opposite of isolation because its ingress rule uses `podSelector: {}` in the `from` field, which matches every pod and therefore explicitly permits all inbound traffic to the busybox pod. Since no egress rule is included, `policyTypes` defaults to `Ingress` only, so the compromised pod's outbound traffic is not restricted at all. The policy effectively allows even more traffic than the default behavior and fails to block either direction of communication with the compromised pod.

• ✓

  apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate spec: podSelector: matchLabels: app: busybox policyTypes: - Ingress - Egress

  Why this is correct

  This is the correct isolation policy because it selects only the compromised pod using its `app: busybox` label and declares both `Ingress` and `Egress` in `policyTypes` while omitting any allow rules. According to NetworkPolicy semantics, when a policy isolates a traffic direction and contains no rules for that direction, all traffic of that type is denied. Therefore this policy enforces a complete default-deny on both inbound and outbound traffic for the busybox pod, cutting off all network communication with it.

Go deeper

Related to this question