CKA LoadBalancer IP pending on-premises Practice Question
A Service of type LoadBalancer is created but the EXTERNAL-IP remains <pending>. The cluster is running on-premises without a cloud load balancer integration. Which of the following is the most likely reason?
⚠ Common exam trap
A common mix-up: candidates confuse the EXTERNAL-IP <pending> state with networking issues (Option B) or pod connectivity (Option D), when the root cause is the absence of a load balancer controller, a concept specific to on-premises Kubernetes deployments.
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
✓
No load balancer controller (e.g., MetalLB) is installed.
A Service of type LoadBalancer in Kubernetes requires an external load balancer controller to provision an external IP address. In on-premises clusters without cloud integration, no such controller exists by default, so the EXTERNAL-IP remains <pending> until a bare-metal load balancer like MetalLB is installed and configured. Option C is correct because without a load balancer controller, Kubernetes cannot assign an external IP.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The cluster has no default storage class.
Why it's wrong here
A default StorageClass is only relevant to dynamic provisioning of PersistentVolumes for workloads that need persistent storage. Services, including type LoadBalancer, do not consume storage, and the Kubernetes control plane does not block Service external IP assignment based on storage configuration. Even in a cluster with no StorageClass at all, a functioning load balancer controller still assigns an external IP.
- ✗
The nodes are not reachable from the internet.
Why it's wrong here
The external IP for a LoadBalancer Service is selected from a pool managed by the load balancer controller (e.g., MetalLB), not by verifying internet reachability of your nodes. Even if nodes are completely isolated from the internet, a controller can assign a routable or non-routable IP from its configured range and mark the Service ready. Conversely, if no controller is present, the IP remains pending regardless of node network connectivity.
- ✓
No load balancer controller (e.g., MetalLB) is installed.
Why this is correct
In on-premises clusters without a cloud provider integration, the Service controller has no built-in mechanism to allocate an external IP. A load balancer controller such as MetalLB is required to watch for Services of type LoadBalancer and update their status with an IP from its address pool. Until that controller runs, the external IP is stuck in <pending>, which is exactly the symptom shown.
- ✗
The Service selector does not match any pods.
Why it's wrong here
A Service whose selector matches no Pods still exists and has a ClusterIP; the load balancer controller would still create an external load balancer IP because the LB is provisioned based on the Service definition, not on endpoint availability. The only consequence is that the load balancer receives no backend endpoints, but the ExternalIP status is still updated. Thus, empty endpoints do not cause the external IP to remain pending.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The CKA exam frequently reuses these exact scenarios with slightly different constraints.
✓No load balancer controller (e.g., MetalLB) is installed.Correct answer▾
Why this is correct
In on-premises clusters without a cloud provider integration, the Service controller has no built-in mechanism to allocate an external IP. A load balancer controller such as MetalLB is required to watch for Services of type LoadBalancer and update their status with an IP from its address pool. Until that controller runs, the external IP is stuck in <pending>, which is exactly the symptom shown.
✗The cluster has no default storage class.Wrong answer — click to see why▾
Why this is wrong here
Storage class is unrelated to LoadBalancer IP assignment.
✗The nodes are not reachable from the internet.Wrong answer — click to see why▾
Why this is wrong here
Even if nodes are unreachable, a cloud LB would still assign an IP; on-premises, the LB controller would assign an IP from a pool.
✗The Service selector does not match any pods.Wrong answer — click to see why▾
Why this is wrong here
A mismatched selector would result in no endpoints, but the external IP could still be assigned (pending also occurs if there's no controller).
Analysis generated from the official CKAblueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Installing Kubernetes with kubeadm
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.