CKAD Services and Networking Practice Question
A Service of type LoadBalancer is created but the external IP remains <pending>. What is the most likely reason?
⚠ Common exam trap
It's easy for candidates to confuse a LoadBalancer's external IP assignment with Pod readiness or port availability, but the core requirement is a functioning cloud provider integration to allocate the external IP.
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
✓
The cluster does not have a cloud provider configured
A LoadBalancer Service in Kubernetes relies on an external cloud provider (e.g., AWS, GCP, Azure) to provision a real load balancer and assign its external IP. If no cloud provider is configured (e.g., in a bare-metal or Minikube cluster), the external IP will remain <pending> indefinitely because there is no controller to allocate the 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 Service port is already in use
Why it's wrong here
This is not the cause of a pending external IP. Service ports are logical and can be reused across different Services because each Service has its own ClusterIP and kube-proxy rules; the API server does not enforce global port uniqueness for Service objects. A genuine port conflict would surface as a validation or binding error, not as a status field remaining '<pending>' after a successful creation.
- ✗
The Service selector does not match any Pods
Why it's wrong here
Even if the Service's selector matches no Pods, the cloud controller will still provision the load balancer and assign an external IP, because endpoint discovery is a separate kube-controller-manager function. The lack of endpoints only means the cloud LB's backend pool will be empty, so traffic forwarded to the LB will fail, but the IP is still allocated. Thus, a pending external IP points to the LB provisioning step, not to endpoint health.
- ✓
The cluster does not have a cloud provider configured
Why this is correct
A pending external IP on a LoadBalancer Service almost always indicates that no cloud provider integration is active in the cluster. The component responsible for creating and managing the cloud load balancer is the cloud-controller-manager (or an in-tree cloud provider in older versions); if it is not running or the cluster is on bare metal, the Service will never transition out of the '<pending>' state. This is a common scenario in minikube, kind, or on-premises deployments, where you need a solution like MetalLB to provide LB functionality.
- ✗
The Pods are not listening on the container port
Why it's wrong here
The container port defined on the Pod spec is only a declaration used by the Service's targetPort to route traffic; it does not affect control-plane operations. Even if no Pod is listening on that port, the cloud provider will still create the load balancer and set the external IP, because health checks and endpoint readiness are determined after the IP is provisioned. The external IP pending issue is unrelated to the actual liveness of the backend Pods.
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD 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 CKAD 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 CKAD exam.