Building-permits administrators apply several NetworkPolicy objects, but traffic is never filtered. Pods and Services look correct. What dependency is most likely missing?
Select an answer to reveal the explanation.
Short Explanation
Writing NetworkPolicy YAML without an enforcing CNI is like posting speed-limit signs with no police — the paper exists, the traffic doesn't change.
Full Explanation
Building-permits administrators who apply several NetworkPolicy objects but see traffic never filtered—while Pods and Services look correct—are most likely missing a CNI or network-policy engine that implements and enforces NetworkPolicy; without it, policy objects have no effect on packets. The API will happily store NetworkPolicy resources, but enforcement depends on the dataplane. A cluster without a policy-capable plugin will leave permits east-west traffic open despite YAML that looks strict.
A PriorityClass named network-policy needing to exist or the apiserver drops NetworkPolicy resources is false. Every namespace needing a default ServiceAccount token Secret named networkpolicy-enforcer is fictional. Ingress controllers scaled to zero are unrelated to NetworkPolicy activation.
Exam caveat: confirm your exam environment's CNI documents NetworkPolicy support before relying on deny tests. Operational check: verify the CNI/policy controller is running, apply a deny-all and an allow test between permits Pods, and confirm packets are actually dropped. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.