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.

Practice

1. What is the primary function of an HTTP(S) Load Balancer in Google Cloud Platform?

easy

A. Distribute incoming web traffic across multiple backend services

B. Store user data securely in the cloud

C. Create virtual machines automatically

D. Monitor network latency between regions

Solution

1. Step 1: Understand the role of HTTP(S) Load Balancer

   It is designed to spread incoming web traffic to multiple backend services to improve performance and reliability.

2. Step 2: Eliminate unrelated functions

   Storing data, creating VMs, and monitoring latency are not functions of the load balancer.

3. Final Answer:

   Distribute incoming web traffic across multiple backend services -> Option A

4. Quick Check:

   Load balancer = traffic distribution [OK]

Hint: Load balancer = spreading traffic to backends [OK]

Common Mistakes:

• Confusing load balancer with storage or VM services
• Thinking it monitors network latency
• Assuming it creates resources automatically

2. Which component is NOT part of the HTTP(S) Load Balancer setup in GCP?

easy

A. Cloud Storage bucket

B. Forwarding rule

C. Target proxy

D. URL map

Solution

1. Step 1: Identify components of HTTP(S) Load Balancer

   It includes URL maps, forwarding rules, and target proxies to route traffic.

2. Step 2: Recognize unrelated components

   Cloud Storage bucket is for storing files, not part of load balancing setup.

3. Final Answer:

   Cloud Storage bucket -> Option A

4. Quick Check:

   Storage bucket ≠ load balancer component [OK]

Hint: Storage buckets store files, not route traffic [OK]

Common Mistakes:

• Confusing storage services with load balancer parts
• Mixing forwarding rules with storage buckets
• Assuming all GCP services are load balancer components

3. Given this URL map configuration snippet, which backend service will handle requests to /images/*?

{
  "hostRules": [{"hosts": ["*"], "pathMatcher": "allpaths"}],
  "pathMatchers": [{
    "name": "allpaths",
    "defaultService": "backend-service-default",
    "pathRules": [{"paths": ["/images/*"], "service": "backend-service-images"}]
  }]
}

medium

A. backend-service-default

B. backend-service-images

C. backend-service-static

D. backend-service-api

Solution

1. Step 1: Analyze path rules in URL map

   The path rule for /images/* points to backend-service-images.

2. Step 2: Understand default service role

   Requests not matching specific paths use backend-service-default, but /images/* matches a specific path rule.

3. Final Answer:

   backend-service-images -> Option B

4. Quick Check:

   Specific path rule overrides default service [OK]

Hint: Specific path rules override default backend [OK]

Common Mistakes:

• Choosing default service instead of specific path service
• Ignoring path pattern matching
• Confusing backend service names

4. A user configures an HTTP(S) Load Balancer but finds that requests to /api/* are not routed to the intended backend service. Which is the most likely cause?

medium

A. The backend service is not in the same region

B. The forwarding rule is missing

C. The target proxy is not HTTPS

D. The URL map lacks a path rule for /api/*

Solution

1. Step 1: Check URL map path rules

   If /api/* is missing in path rules, requests won't route correctly.

2. Step 2: Verify other components

   Forwarding rule and target proxy affect traffic flow but missing path rule directly causes routing failure. Backend region mismatch usually causes latency, not routing failure.

3. Final Answer:

   The URL map lacks a path rule for /api/* -> Option D

4. Quick Check:

   Missing path rule = routing failure [OK]

Hint: Check URL map paths if routing fails [OK]

Common Mistakes:

• Assuming forwarding rule absence causes routing error
• Confusing HTTPS proxy with routing logic
• Ignoring URL map path rules

5. You want to design a scalable web application using GCP's HTTP(S) Load Balancer that routes traffic based on URL paths to different backend services. Which design approach ensures high availability and efficient routing?

hard

A. Use a single backend service for all traffic and scale it vertically

B. Deploy multiple forwarding rules each pointing to different backend services without URL maps

C. Configure URL map with path matchers directing to multiple regional backend services behind managed instance groups

D. Use TCP Load Balancer instead of HTTP(S) Load Balancer for path-based routing

Solution

1. Step 1: Understand path-based routing needs

   HTTP(S) Load Balancer uses URL maps with path matchers to route requests to different backends efficiently.

2. Step 2: Ensure scalability and availability

   Using multiple regional backend services behind managed instance groups provides scalability and high availability.

3. Step 3: Evaluate other options

   Single backend limits scalability; multiple forwarding rules without URL maps cannot do path-based routing; TCP Load Balancer does not support Layer 7 routing.

4. Final Answer:

   Configure URL map with path matchers directing to multiple regional backend services behind managed instance groups -> Option C

5. Quick Check:

   URL map + regional backends = scalable routing [OK]

Hint: Use URL maps with regional backends for scalable routing [OK]

Common Mistakes:

• Using single backend limits scalability
• Misusing forwarding rules for path routing
• Choosing TCP Load Balancer for HTTP path routing