Cloud Load Balancing shows up across the Professional Cloud Architect exam in scenarios about availability, scaling, global traffic, and protocol-level routing. The exam expects you to recognize when a use case calls for a Layer 4 load balancer versus a Layer 7 load balancer, and to understand how front-end IP addresses and SSL termination fit into a load-balanced architecture. This article walks through what I want you to lock in before exam day.
Cloud Load Balancing is a fully managed service that distributes incoming traffic across multiple backend instances. Because it is fully managed, Google handles the infrastructure underneath, and you get three things in return: high availability when an instance fails, scalability as traffic grows, and optimized performance because requests are routed to backends that can handle them.
It integrates with the main compute services on Google Cloud, including Compute Engine, Google Kubernetes Engine, Cloud Run, and App Engine. It also integrates with Cloud Armor when you need advanced security controls layered on top of the load balancer.
The way it makes routing decisions is through a combination of routing rules and health checks. Routing rules determine where a request should go based on attributes you configure. Health checks continuously probe the backends, and if a backend becomes unhealthy, the load balancer stops sending traffic to it. That combination is what gives you automatic failover when something goes wrong on the backend side.
One detail that comes up on the Professional Cloud Architect exam is how Cloud Load Balancing handles IP addresses on the front end. The load balancer can be configured with a static IP address, which means clients always reach your application at the same IP even when backend instances are added, removed, or replaced. That stability is what makes the load balancer a clean entry point for external clients.
By default you would assign an IPv4 address, which is the traditional standard. Cloud Load Balancing also supports IPv6 addresses, and this matters for dual-stack traffic. If some of your clients reach you over IPv4 and others over IPv6, the load balancer can accept both. A common setup has the same load balancer fronting an IPv4 address like 203.0.113.1 and an IPv6 address like 2001:db8::1, with the same backend services behind each.
Different Cloud Load Balancing options operate at different layers of the OSI model. The OSI model is a framework that organizes the functions of a networking system into seven layers, and the two layers you need to be comfortable with for the Professional Cloud Architect exam are Layer 4 and Layer 7.
Layer 4 is the Transport Layer. It is responsible for end-to-end communication and error handling. A Layer 4 load balancer makes its decisions based on network-level information like IP addresses and port numbers. It does not look at the contents of the request. The protocols associated with this layer are TCP and UDP.
Layer 7 is the Application Layer. This is where user-facing applications operate, including web browsers and email clients. A Layer 7 load balancer can inspect application-level information like HTTP headers, URL paths, and request content, which lets it make more intelligent routing decisions. The protocols associated with this layer are HTTP, HTTPS, FTP, and SMTP.
The exam uses specific naming conventions you need to recognize. When a question describes a Layer 4 scenario, the answer choice will typically be phrased as a TCP/UDP Load Balancer or simply a Layer 4 Load Balancer. The signal in the question stem is usually a mention of TCP or UDP traffic without any application-layer requirements.
When a question describes a Layer 7 scenario, the answer choice will be phrased as an HTTP(S) Load Balancer, a Global Load Balancer, or a Layer 7 Load Balancer. All three names refer to the same family of load balancer in different contexts.
Layer 4 use cases are easy to spot because they boil down to TCP or UDP traffic. Layer 7 has more variety, and these are the patterns I want you to be able to recognize on sight.
The first is plain HTTP and HTTPS traffic. Anything that operates at the application layer and uses HTTP or HTTPS belongs on a Layer 7 load balancer because that is where content inspection and application-aware routing become possible.
The second is path-based and content-based routing. If a question describes routing requests to different backends based on the URL path, for example sending /api/v1 to one backend and /api/v2 to another, that is a Layer 7 scenario. The same applies to routing based on headers or query strings, which is common in microservices architectures and applications that maintain multiple API versions.
The third is REST APIs. REST traffic uses HTTP or HTTPS, so it belongs on a Layer 7 load balancer. The load balancer can also terminate SSL on behalf of the API, which I will cover in the next section.
The fourth is SSL termination. Layer 7 load balancers can decrypt incoming HTTPS traffic at the load balancer itself. Layer 4 load balancers cannot do this, which is why SSL termination is a strong signal for Layer 7 in exam questions.
The fifth is global traffic. Layer 7 load balancers leverage Google's global edge network to route requests to the closest healthy backend across regions. When a question describes minimizing latency for users distributed worldwide and uses the phrase global load balancer, that is Layer 7.
The sixth is web applications. Web apps run on HTTP and HTTPS, so they default to Layer 7. The advanced routing, SSL termination, and global traffic features all stack together in this scenario.
SSL termination is the process of decrypting incoming SSL traffic at the load balancer, rather than passing the encrypted traffic all the way through to the backend. The flow looks like this: a client opens an HTTPS connection to the load balancer, the load balancer performs the SSL handshake and decrypts the data, and then the load balancer forwards the unencrypted HTTP traffic on to the backend services like GKE Pods or an App Engine service.
This setup gives you two clear advantages. First, it offloads the computationally expensive decryption work from your backend servers, which lets them focus on serving application logic. Second, it simplifies certificate management because you only install and manage SSL certificates on the load balancer instead of on every backend instance.
For exam purposes, the key association is that SSL termination is a Layer 7 capability. If a question describes SSL termination as a requirement, you are looking at an HTTP(S) load balancer.
Cloud Load Balancing on the Professional Cloud Architect exam comes down to a few patterns. Recognize that static front-end IP addresses can be IPv4 or IPv6 to support dual-stack traffic. Know that Layer 4 means TCP/UDP and routing on IPs and ports, and Layer 7 means HTTP(S) and routing on application-layer attributes. Memorize the naming conventions so that TCP/UDP Load Balancer and Layer 4 Load Balancer map to one answer, and HTTP(S) Load Balancer, Global Load Balancer, and Layer 7 Load Balancer map to the other. And remember that SSL termination, path-based routing, content-based routing, and global traffic are all Layer 7 signals.
My Professional Cloud Architect course covers Cloud Load Balancing alongside the rest of the networking material.
