CKS Minimize Microservice Vulnerabilities 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.

• ✓

  Create the NetworkPolicy YAML manifest, then apply it using kubectl apply, then deploy test pods with appropriate labels, then verify connectivity using kubectl exec.

  Why this is correct

  This is the correct order. Creating the NetworkPolicy YAML first lets you declaratively define the intended ingress/egress rules with exact podSelector, namespaceSelector, and port/protocol fields. Applying it with `kubectl apply` before deploying test pods ensures the policy is active when the pods first start, so any traffic from the client pods is subject to the policy from the very beginning and there is no window of unrestricted communication. Finally, using `kubectl exec` from a labeled client pod provides a direct, runtime verification that allowed paths work and denied paths are blocked, giving a true reflection of the enforced policy.

• ✗

  Apply the NetworkPolicy using kubectl apply, then create the YAML manifest, then deploy test pods, then verify connectivity.

  Why it's wrong here

  This sequence is impossible because `kubectl apply` requires a manifest to already exist — you cannot apply a NetworkPolicy that has not yet been written. Even if the two steps were logically swapped, this ordering creates a nonsensical workflow where a policy is applied from a nonexistent file, and any attempt would fail with a 'file not found' error. Additionally, it leaves no record of what policy was actually applied, since the YAML was never created; so the subsequent verification steps are meaningless. A valid workflow must start with authoring the YAML manifest, then applying it.

• ✗

  Create the NetworkPolicy YAML, then deploy test pods, then apply the policy, then verify connectivity.

  Why it's wrong here

  This order introduces an unprotected time window: test pods are deployed before the policy exists, so they can communicate freely under the default allow-all behavior. When the NetworkPolicy is applied later, it only governs new connections — already-established sessions may remain unaffected depending on the CNI, and the verification step, which runs after policy application, does not test the traffic that occurred in that initial unblocked period. Furthermore, if a problem is detected, it is difficult to tell whether it was caused by the policy being absent initially or by a flaw in the policy itself, because the pods were never observed under enforcement from the start.

• ✗

  Deploy test pods, then create and apply the NetworkPolicy, then verify connectivity.

  Why it's wrong here

  Starting with test pods means the cluster runs in a default-permissive state before the NetworkPolicy exists, so any inter-pod communication that occurs during that period is completely unrestricted and goes unverified. After the policy is created and applied, existing connections may not be re-evaluated (depending on the CNI implementation), so some connections between the test pods could remain allowed even though the policy should deny them, producing misleading results when you verify connectivity. This order also delays the enforcement point, meaning a security-sensitive workload would be exposed in the interim, which defeats the purpose of applying a NetworkPolicy in the first place.

Go deeper

Related to this question