A transit platform team debates whether enabling a CNI plugin is the same as enforcing NetworkPolicies. What distinction should they apply?
Select an answer to reveal the explanation.
Short Explanation
CNI is the plumbing that lets Pods talk; NetworkPolicy is the optional lock on which conversations are allowed. You need connectivity first—policy is not a substitute for a CNI.
Full Explanation
A transit platform team debating whether enabling a CNI plugin is the same as enforcing NetworkPolicies should apply this distinction: CNI provides Pod network connectivity; NetworkPolicy optionally restricts that traffic. Installing a CNI gives Pods IPs and cross-node routes. NetworkPolicy objects only take effect when a policy-capable CNI or network engine enforces them. Connectivity and policy are layered concerns for municipal clusters.
NetworkPolicy does not replace CNI and is not required before any Pod receives an IP. CNI does not only configure CoreDNS while NetworkPolicy assigns all Pod CIDRs. NetworkPolicy does not provision Nodes while CNI only creates Service ClusterIPs.
Exam caveat: without a policy-aware dataplane, NetworkPolicy objects may exist in the API yet do nothing. Operational check: verify CNI health for basic Pod connectivity first, then deploy NetworkPolicies and confirm enforcement with allow and deny tests between transit namespaces. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.