HTTP(S) Load Balancer (Layer 7) in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Identify the correct architecture for a global HTTP(S) Load Balancer on GCP

Which of the following diagrams correctly represents the architecture of a global HTTP(S) Load Balancer on Google Cloud Platform that distributes traffic across multiple regions with automatic failover?

A Client requests are sent directly to backend instances without any load balancer, relying on DNS round robin for distribution.

B Client requests are routed to a global anycast IP address, then distributed by the HTTP(S) Load Balancer to backend services in multiple regions with health checks and failover.

C Client requests go to a single regional load balancer which then forwards to backend instances only in that region.

D Client requests are routed through a TCP load balancer that forwards traffic to backend instances based on IP address only.

💡 Hint

Think about how global traffic distribution and failover are handled in GCP HTTP(S) Load Balancer.

Option B correctly describes the global HTTP(S) Load Balancer using a single anycast IP that routes traffic to healthy backends across multiple regions with automatic failover. Other options describe regional or non-load balancer approaches.

❓ scaling

intermediate

Estimating capacity for HTTP(S) Load Balancer under high traffic

You expect 1 million requests per second to your HTTP(S) Load Balancer on GCP. Which factor is NOT relevant when estimating the load balancer's capacity requirements?

A Number of backend instances and their capacity

B Size and complexity of HTTP headers in requests

C Geographical distribution of clients

D The color scheme of the load balancer's management console

💡 Hint

Consider what affects load balancer performance and what is irrelevant.

The color scheme of the management console does not affect the load balancer's capacity or performance. Other options impact capacity planning.

❓ tradeoff

advanced

Choosing between HTTP(S) Load Balancer and TCP Load Balancer for a web app

Your web application requires SSL termination, URL-based routing, and global load balancing. Which load balancer type on GCP best fits these needs and why?

A TCP Load Balancer, because it handles SSL termination and URL routing efficiently.

B Network Load Balancer, because it provides global load balancing and URL routing.

C HTTP(S) Load Balancer, because it supports SSL termination, URL-based routing, and global anycast IP for global load balancing.

D Internal Load Balancer, because it supports SSL termination and global routing.

💡 Hint

Match features needed with load balancer capabilities.

HTTP(S) Load Balancer supports SSL termination, URL-based routing, and global anycast IP, making it ideal for web apps needing these features. TCP and Network Load Balancers lack URL routing and global features. Internal Load Balancer is for private networks.

🧠 Conceptual

advanced

Understanding health checks in HTTP(S) Load Balancer

What is the primary purpose of health checks in a GCP HTTP(S) Load Balancer setup?

A To verify backend service availability and route traffic only to healthy instances.

B To encrypt traffic between the load balancer and backend instances.

C To monitor backend instance CPU usage and automatically scale instances.

D To cache HTTP responses at the load balancer for faster delivery.

💡 Hint

Think about how load balancers decide where to send traffic.

Health checks test backend availability and ensure traffic is sent only to healthy instances. They do not handle scaling, encryption, or caching.

❓ component

expert

Request flow through GCP HTTP(S) Load Balancer components

Arrange the components in the correct order that a client HTTP request passes through when using a GCP HTTP(S) Load Balancer with backend services.

A 1,2,3,4

B 1,3,2,4

C 2,1,3,4

D 1,2,4,3

💡 Hint

Think about the natural flow from client to backend through the load balancer.

The request first hits the global IP, then SSL is terminated at the frontend, routing rules are applied, and finally the request is sent to a healthy backend.