CKA Services and Networking Practice Question
Which TWO network plugins (CNI) are commonly used in Kubernetes clusters? (Select TWO)
⚠ Common exam trap
Many candidates confuse Kubernetes networking components (CoreDNS, kube-proxy) with actual CNI plugins, or mistaking Docker's deprecated networking model for a valid CNI plugin.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Calico
Calico (A) is correct because it is a widely deployed CNI plugin that provides pod networking and network policy enforcement using BGP or VXLAN for routing. Flannel (B) is also correct as a common, lightweight CNI plugin that creates an overlay network (typically VXLAN) to give each pod a cluster-wide unique IP. CoreDNS (C) is not a CNI plugin; it is the cluster DNS server that resolves service and pod names. kube-proxy (D) is not a CNI plugin; it implements Service load balancing via iptables/IPVS rules on each node. Docker (E) is a container runtime, not a Kubernetes CNI plugin.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Calico
Why this is correct
Calico is a widely deployed CNI plugin providing pod networking and NetworkPolicy enforcement in Kubernetes clusters. It operates as a CNI implementation, unlike service meshes or ingress controllers, which sit above the CNI layer rather than supplying pod IP address management and connectivity.
- ✓
Flannel
Why this is correct
Flannel is a widely deployed CNI plugin that provides overlay networking for pod-to-pod traffic, typically using VXLAN encapsulation to create a flat Layer 3 network across nodes. It satisfies the question's requirement for a commonly used Kubernetes CNI, alongside Calico, and is frequently chosen for its simplicity in basic cluster networking.
- ✗
CoreDNS
Why it's wrong here
CoreDNS is the cluster DNS server that resolves service names, not a CNI plugin; it runs alongside whichever plugin provides pod networking. It is tempting because it is a core add-on installed in nearly every cluster, but it would be the answer to a question about service discovery rather than pod network implementation.
- ✗
kube-proxy
Why it's wrong here
kube-proxy implements Service load balancing via iptables or IPVS rules; it is not a CNI plugin and does not assign pod IP addresses. It is tempting because it is a core networking component, but CNI plugins such as Calico, Flannel or Cilium provide pod networking.
- ✗
Docker
Why it's wrong here
Docker is a container runtime, not a CNI plugin; it creates and runs containers but delegates pod network setup to a separate plugin. It is tempting because Kubernetes historically shipped with Docker, but that is the container runtime interface, a different layer from the CNI specification.
Visual reference
Go deeper
Related to this question
Learn chapter
Troubleshooting Networking and Services
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
About these practice questions
One of 726 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.