CKA Services and Networking Practice Question
You create a Service of type LoadBalancer in a Kubernetes cluster that does not have an external load balancer provider (e.g., bare-metal). What will be the state of the EXTERNAL-IP field when you run 'kubectl get svc'?
⚠ Common exam trap
Watch out — candidates often confuse `<pending>` with `<none>`, assuming that without a cloud provider the field will simply be empty, but Kubernetes explicitly marks the LoadBalancer Service as pending to indicate it is waiting for an external IP assignment.
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
✓
<pending>
When a Service of type LoadBalancer is created in a Kubernetes cluster without an external load balancer provider (e.g., bare-metal or on-premises), the cloud-controller-manager component responsible for provisioning the external load balancer is absent or non-functional. As a result, the external IP address remains unassigned, and `kubectl get svc` displays `<pending>` for the EXTERNAL-IP field until a controller sets it. This state persists indefinitely unless an external tool like MetalLB is deployed to fulfill the LoadBalancer request.
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 ClusterIP
Why it's wrong here
When you create a LoadBalancer service, Kubernetes automatically allocates an internal ClusterIP for intra-cluster communication. However, this internal IP is distinct from the external IP field, which represents the public-facing entry point provisioned by the cloud provider. Thus, the ClusterIP will never populate the external IP status field of the service.
- ✗
The node's IP address
Why it's wrong here
Node IP addresses are associated with the physical or virtual machines hosting the Kubernetes cluster, not the service's external load balancer. While a LoadBalancer service implicitly configures a NodePort to route traffic from nodes to pods, the external IP field itself is reserved for the dedicated load balancer's IP, not the individual node IPs.
- ✓
<pending>
Why this is correct
Immediately after a LoadBalancer service is created, its external IP status is set to <pending>. This status persists until the cloud-controller-manager successfully communicates with the underlying cloud provider's API to provision the physical or virtual load balancer and assign it a public IP address.
- ✗
<none>
Why it's wrong here
The <none> status is typically displayed for ClusterIP or NodePort services that do not request or support an external IP address. Because a LoadBalancer service explicitly requests an external IP from a cloud provider, its initial state is marked as <pending> rather than <none> while it awaits provisioning.
Go deeper
Related to this question
Learn chapter
Installing Kubernetes with kubeadm
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.
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
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.