Cloud Digital Leader Practice Question: Google Cloud products, services, and solutions
A company migrated a microservices application to Google Kubernetes Engine (GKE). They set up an internal HTTP(S) load balancer to route traffic to the services. However, some pods are not receiving traffic. What is the most likely cause?
⚠ Common exam trap
GCDL often tests the distinction between liveness and readiness probes — candidates incorrectly assume a Running pod always receives traffic, forgetting that readiness gates endpoint membership.
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 pods have failing readiness probes that are preventing them from being added to the load balancer's backend endpoints.
GKE internal HTTP(S) load balancers use network endpoint groups (NEGs) that only include pod IPs whose readiness probes are passing. If a pod's readiness probe fails, the pod is removed from the backend endpoints and receives no traffic, even though it is Running. This is the most common cause of 'some pods not receiving traffic' in GKE.
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 type is NodePort instead of LoadBalancer.
Why it's wrong here
A Kubernetes Service of type NodePort is still a valid front-end; it can be combined with an Ingress or a custom load balancer to route traffic. Conversely, changing the Service to type LoadBalancer with the networking.gke.io/load-balancer-type: Internal annotation would create an internal load balancer, but that alone does not guarantee traffic reaches the pods. The real issue is whether the Service has any Ready endpoints, regardless of Service type, so using NodePort instead of LoadBalancer is not the underlying cause.
- ✓
The pods have failing readiness probes that are preventing them from being added to the load balancer's backend endpoints.
Why this is correct
Readiness probes are executed by the kubelet on a recurring basis; if the probe fails, the pod is marked NotReady and its IP is removed from the Service’s Endpoints object. With no ready pods, the EndpointSlices are empty, so the internal load balancer's backend set has zero healthy instances and will not forward any requests. This perfectly matches the symptom of a pod that is Running (it exists) but receives no traffic, making this the correct diagnosis.
- ✗
The cluster does not have enough nodes to schedule the pods.
Why it's wrong here
An insufficient number of nodes would cause unscheduled pods to remain in Pending state, because the scheduler cannot find a node that satisfies resource requests and constraints. The problem statement indicates the pods exist and are presumably Running, which means they have been successfully bound to nodes. Even if nodes are scarce, once a pod is scheduled, resource availability no longer affects traffic delivery; the failure is at the readiness layer, not the scheduling layer.
- ✗
The firewall rules are not allowing traffic from the load balancer to the nodes.
Why it's wrong here
GKE automatically creates and manages firewall rules for Kubernetes LoadBalancer services, including internal load balancers, using a proxy-only subnet and the cluster's node ports. If the firewall were misconfigured, you would typically see health check failures or timeouts from the load balancer, but the Service would still have backend endpoints. Here the primary symptom is no traffic to the pod itself, which points to the pod being absent from the endpoint list rather than to a network-level block between the load balancer and nodes.
Go deeper
Related to this question
Learn chapter
Cloud Maturity Model and Readiness Assessment
Key term
Anthos
Anthos is a Google Cloud platform that lets you run applications consistently across different computing environments, like on-premises data centers and multiple public clouds.
Key term
IPS
An Intrusion Prevention System (IPS) is a network security device that monitors traffic in real time and automatically blocks threats before they reach your systems.
About these practice questions
One of 848 original GCDL 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Google Cloud exam blueprint
This GCDL practice question is part of Courseiva's free Google Cloud 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 GCDL exam.