Cloud Digital Leader Practice Question: Google Cloud products, services, and solutions

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