A cluster's CNI does not implement NetworkPolicy. What should an application developer expect after creating NetworkPolicy objects?
Select an answer to reveal the explanation.
Short Explanation
NetworkPolicies without a supporting CNI are like posted rules with no security guard—objects can exist, but packets won't be filtered. CKAD awareness: enforcement needs the network plugin, not the API object alone.
Full Explanation
NetworkPolicy objects are persisted API resources, but enforcement is performed by a CNI plugin (or equivalent data-plane implementation) that understands them. If the cluster’s CNI does not implement NetworkPolicy, creating NetworkPolicy objects may succeed while traffic rules are not enforced. Application developers should expect posted rules with no security guard: the objects can exist in etcd/API, yet packets may still flow unrestricted. That awareness matters for municipal teams who might otherwise assume YAML alone equals isolation.
kube-apiserver will not typically reject all NetworkPolicy creates until a developer installs a supporting CNI. Kubernetes does not enforce NetworkPolicies purely in the control plane regardless of CNI. NetworkPolicies also do not automatically install Calico (or another plugin) when missing and begin enforcing within seconds.
Exam caveat: CKAD-level questions often test whether you know enforcement depends on cluster networking support—not merely on object validity. Operational check: consult platform documentation for NetworkPolicy support; apply a default-deny and test with curl between Pods; if traffic still passes, treat policies as non-enforcing and escalate to the platform team before claiming compliance isolation for city workloads. Do not silence the gap by widening RBAC or setting hostNetwork on apps.