A load balancer is only as reliable as its picture of which backends are actually healthy. Cloud Load Balancing builds that picture using health checks, and on the Professional Cloud Architect exam you are expected to know both how those probes work and what has to be true at the firewall layer for them to succeed.
A health check is a probe the load balancer sends to each backend instance to confirm it is ready to receive traffic. The backend can be a VM, a managed instance group member, or another supported service. The probe runs on a configuration you define: protocol (HTTP, HTTPS, TCP, and others), port, optional request path like /health or /status, frequency, and timeout.
The load balancer evaluates each backend continuously against that configuration. A backend that responds correctly within the timeout stays in the pool of instances receiving traffic. A backend that stops responding, returns an unexpected status, or exceeds the timeout is marked unhealthy and the load balancer stops sending it traffic. When the same backend starts passing health checks again, the load balancer reintegrates it automatically. Clients never get routed to a backend that is currently failing its probes.
This is what gives Cloud Load Balancing its self-healing behavior. You do not have to manually pull a broken instance out of rotation. The probe configuration decides what "healthy" means for your application, and the load balancer enforces it.
The probe only works if the load balancer can actually reach the backend. That sounds obvious, but it is the most common reason a correctly configured health check still marks every instance as unhealthy.
Backends that have public IPs are usually reachable by default through your existing ingress rules. Backends without public IPs, which is the common pattern for private deployments, depend entirely on VPC firewall rules to let health check traffic in. If those rules do not exist, the probe never lands, the backend never responds, and the load balancer treats every instance as failing.
Google Cloud sends health check traffic from two specific IP ranges:
35.191.0.0/16130.211.0.0/22To make health checks work against private backends, you need an ingress firewall rule that allows traffic from those two ranges on the port the health check is configured to use. The protocol and port in the firewall rule have to line up with the protocol and port in the health check configuration. If the health check probes TCP 8080, the firewall rule has to allow TCP 8080 from those ranges. A rule that allows the right ranges on the wrong port produces the same broken result as having no rule at all.
Professional Cloud Architect questions in this area tend to give you a load balancing scenario where backends are being marked unhealthy and ask you to identify the cause. The answer is almost always at one of two layers. Either the health check itself is misconfigured (wrong port, wrong path, wrong protocol for what the application actually exposes), or the VPC firewall is not allowing the two health check IP ranges through to the backend. Backends without public IPs amplify the second problem because there is no other path for the probe to take.
Knowing the two IP ranges by sight is worth doing. 35.191.0.0/16 and 130.211.0.0/22 show up explicitly in answer choices, and recognizing them lets you quickly narrow down which option correctly describes a working firewall rule for health checks.
My Professional Cloud Architect course covers health checks and firewall rules for Cloud Load Balancing alongside the rest of the networking material.
