The Layer 4 versus Layer 7 distinction is one of the more abstract things on the Associate Cloud Engineer exam, but the way the exam tests it is concrete. This article covers what the OSI layer framing actually means, how it maps to GCP's load balancer types, and the scenario patterns that show up on the ACE exam.
It does not cover every variant of every GCP load balancer or the deep details of TCP, HTTP, or SSL. The goal is the practical version that shows up on the exam.
The OSI model is a way of organizing networking functionality into seven layers. Most of the layers do not matter for the ACE exam. Two of them do.
Layer 4 is the transport layer. This is where TCP and UDP live. Load balancers operating at Layer 4 see traffic as connections defined by IP addresses and port numbers. They do not inspect the contents of the traffic. They just decide which backend to send the connection to based on network-level info.
Layer 7 is the application layer. This is where HTTP, HTTPS, FTP, and SMTP live. Load balancers at Layer 7 can inspect the actual application traffic. They can read HTTP headers, look at the URL path, look at cookies, and route accordingly.
For the Associate Cloud Engineer exam, canonical examples are you a clean mapping. If you need a Layer 4 load balancer, you use a TCP/UDP Load Balancer (in the newer naming, this is the Network Load Balancer). If you need a Layer 7 load balancer, you use an HTTP(S) Load Balancer (in the newer naming, the Application Load Balancer).
That is the whole mapping for the exam. Network LB equals Layer 4. Application LB equals Layer 7.
Layer 4 (TCP/UDP) load balancing is what you use for non-HTTP protocols, for very high-throughput TCP workloads where you need raw connection forwarding, or when you do not care about routing based on URL paths. Examples. A custom TCP service. A game server. A database proxy. Anything that is not HTTP.
Layer 7 (HTTP/HTTPS) load balancing is what you use for web applications. The big benefit is that you can route by URL path or host. /api goes to one backend, /static goes to another, api.example.com goes to a different one entirely. You can also do SSL termination at the load balancer, which offloads decryption from your backends and centralizes certificate management.
SSL termination is a Layer 7 thing because it requires understanding the HTTPS protocol. Layer 4 cannot do that.
The Associate Cloud Engineer exam pattern is consistent. A scenario describes a workload and asks which load balancer to use.
If the workload is HTTP or HTTPS, especially a web application with multiple paths or hosts, the answer is the HTTP(S) Load Balancer (Application Load Balancer, Layer 7). If the workload is TCP or UDP traffic that is not HTTP, the answer is the TCP/UDP Load Balancer (Network Load Balancer, Layer 4).
The clearest signals. If you see "HTTP", "HTTPS", "URL path", "host header", or "SSL termination", that is Layer 7. If you see "TCP", "UDP", "non-HTTP protocol", or "high-throughput connections", that is Layer 4.
One additional axis the exam touches. GCP load balancers come in external (for traffic coming from the internet) and internal (for traffic that stays within the VPC) variants. This is independent of the Layer 4 vs Layer 7 question. You can have an external Application LB, an internal Application LB, an external Network LB, or an internal Network LB.
If a question describes load balancing internal-only traffic between microservices, that is an internal load balancer (which variant depends on whether it is HTTP or not). External traffic from internet users goes through an external load balancer.
One specific signal worth memorizing. If a question describes a need to route different URL paths to different backends, that is unambiguously Layer 7. Path-based routing requires inspecting the HTTP request, which Layer 4 cannot do. The HTTP(S) Load Balancer is the answer.
If you see "route /api to one backend and /static to another", that is the HTTP(S) Load Balancer.
The other clear Layer 7 signal. SSL termination, where the load balancer handles HTTPS decryption and forwards plain HTTP to backends, requires understanding HTTPS at the application level. This is a Layer 7 capability. The HTTP(S) Load Balancer does this. The Network Load Balancer does not.
If you see "SSL termination" or "centralized certificate management", think HTTP(S) Load Balancer.
For reference, creating a basic external HTTP(S) load balancer involves a backend service, a URL map, a target HTTP proxy, and a forwarding rule. It is more components than a simple Network LB, which mostly just needs a forwarding rule and a backend.
gcloud compute forwarding-rules create my-network-lb \
--region=us-central1 \
--ports=80 \
--backend-service=my-backend-serviceThe exam usually does not ask you to write the gcloud commands. It asks you to pick the right type of load balancer for the scenario.
Layer 4 load balancers operate at the transport layer (TCP and UDP) and route based on IP and port. In GCP, that is the Network Load Balancer (also called the TCP/UDP Load Balancer). Layer 7 load balancers operate at the application layer (HTTP and HTTPS) and route based on URL paths, hostnames, and other application-level data. In GCP, that is the Application Load Balancer (HTTP(S) Load Balancer).
For the Associate Cloud Engineer exam, the rule is simple. HTTP and HTTPS workloads, especially anything involving URL routing or SSL termination, use the HTTP(S) Load Balancer. Non-HTTP TCP or UDP workloads use the TCP/UDP Load Balancer. The exam tests this distinction directly, so once you have the rule, the questions become quick.
My Associate Cloud Engineer course covers Layer 4 and Layer 7 load balancers in the networking section alongside the rest of Cloud Load Balancing, so you can match each scenario to the right load balancer type without having to puzzle over the OSI framing.
