Google Cloud's documentation lists more types of load balancers than the platform actually has distinct products. Some of the names on the list refer to the same load balancer through different lenses, and the terminology drifts depending on which page of the docs you land on. For the Professional Cloud Architect exam, you do not need to memorize every label, but you do need to recognize them when they appear in a question and not get thrown off by inconsistent wording.
I want to walk through how I think about the load balancer catalog, and then move into the more important distinction the Professional Cloud Architect exam keeps coming back to, which is regional versus global scope.
Google Cloud's official taxonomy enumerates a handful of load balancers. You will see Application Load Balancers, which operate at Layer 7 of the OSI model and handle HTTP and HTTPS traffic. You will also see references to HTTP(S) Load Balancers and to Global Load Balancers. In practical terms, the first two of those are the same thing under different names, both Layer 7 products that terminate HTTP and HTTPS at the edge and route based on URL paths, headers, and host rules. Google's own documentation has not been particularly disciplined about picking one name and sticking to it.
Beyond the Layer 7 products, the catalog includes Network Load Balancers, which operate at Layer 4 and route TCP and UDP traffic without inspecting the payload. There are also Internal Load Balancers, which sit inside your VPC and distribute traffic among internal backends rather than exposing a public endpoint. Some of these are regional, some are global, some can be either depending on how you configure them.
On the exam, you should expect to see questions written in mixed terminology. A question might call something an HTTP(S) Load Balancer in one sentence and a Global Load Balancer in the next, and both phrases can refer to the same Layer 7 product. If you see Application Load Balancer, treat it as a synonym for the Layer 7 HTTP(S) product. The exam writers care whether you understand what the load balancer does, not whether you can recite the canonical name.
This is the distinction worth spending real time on. The words regional and global, when applied to a load balancer in Google Cloud, refer to the scope of where the load balancer can route traffic, not to where the load balancer itself physically lives. That phrasing trips people up, so I want to be precise about it.
A regional load balancer routes incoming traffic to backends in a single region. If your backend lives in us-east1, the regional load balancer in front of it can distribute requests across the zones inside us-east1, which gives you availability if a zone fails. What it cannot do is forward traffic to a backend in a different region. A user request from London hits the regional load balancer and gets sent to us-east1, even though there might be no backend closer to the user. The transatlantic round trip happens whether you want it to or not.
This architecture is the right call when your backend is genuinely regional. If you serve a domestic user base out of a single region, a regional load balancer is simpler, cheaper, and entirely sufficient. The trouble starts when you have global users or backends in multiple regions, because the regional load balancer cannot stitch them together.
A global load balancer is built for that case. It presents a single anycast IP address that users anywhere in the world connect to, and it routes each request to the nearest healthy backend. If your backend is deployed in us-west1, europe-west1, and asia-south1, traffic from a user in Tokyo lands in asia-south1, traffic from Berlin lands in europe-west1, and traffic from Seattle lands in us-west1. The routing happens automatically based on user location and backend health, so you also get failover for free if one region goes offline.
Two consequences of this design matter for the Professional Cloud Architect exam. First, latency drops because users always reach the closest backend rather than crossing oceans to a fixed region. Second, you get cross-region redundancy without writing your own failover logic, because the global load balancer simply stops sending traffic to a region that fails health checks and redistributes to the others.
Professional Cloud Architect questions about load balancing almost always come down to matching scope to the workload. If a scenario describes a global user base, multi-region backends, or a requirement to keep serving traffic when a region goes down, the answer needs a global load balancer. If a scenario describes a backend confined to one region with regional users, a regional load balancer is the right answer and the cheaper one.
The other thing to watch for is questions that mix the OSI layer with the scope. A scenario might require Layer 7 routing rules, like sending /api requests to one backend service and /static requests to another, while also requiring global distribution. The product that satisfies both is the global Application Load Balancer. The exam will not always state this directly. You have to recognize that you need both Layer 7 features and global scope and pick the load balancer that offers them.
My Professional Cloud Architect course covers Cloud Load Balancing types and regional versus global scope alongside the rest of the networking material.
