CKA Services and Networking 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.

• ✗

  CoreDNS

  Why it's wrong here

  CoreDNS is a DNS server that provides service discovery by resolving Kubernetes service names and pod hostnames to IP addresses. It runs as a regular pod but is not involved in the data path or in enforcing L3/L4 traffic rules. NetworkPolicy rules are implemented by the CNI plugin at the network dataplane, so CoreDNS has no role in filtering pod-to-pod traffic even though it might be selected by a policy.

• ✗

  kube-controller-manager

  Why it's wrong here

  kube-controller-manager runs control loops for built-in controllers such as the replication controller, endpoints controller, and namespace controller. These controllers reconcile desired cluster state, but they do not inspect or filter network traffic. NetworkPolicy enforcement is a dataplane operation handled by the CNI plugin after the API server stores the policy, so the controller manager is not responsible for applying those rules.

• ✗

  kube-proxy

  Why it's wrong here

  kube-proxy is responsible for implementing Kubernetes Service networking, including ClusterIP, NodePort, and LoadBalancer types, by programming iptables, IPVS, or similar forwarding rules. It only handles service-to-pod and external-to-service traffic, whereas NetworkPolicy governs direct pod-to-pod communication based on labels, ports, and IP blocks. Because kube-proxy's forwarding logic is separate from the CNI's policy enforcement (such as Calico's iptables or Cilium's eBPF), it does not enforce NetworkPolicy rules.

• ✓

  CNI plugin

  Why this is correct

  The correct answer is the CNI plugin. The Container Network Interface plugin manages pod networking and, depending on the implementation (e.g., Calico, Cilium, Weave, or Antrea), also enforces NetworkPolicy by programming dataplane rules. When a NetworkPolicy is created or updated, the CNI plugin receives the pod metadata and translates the allow/deny rules into iptables, eBPF, or other forwarding constructs. Without a CNI plugin that supports NetworkPolicy, the rules are stored by the API server but have no effect on traffic.