HTTP(S) Load Balancer (Layer 7) in GCP - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is an HTTP(S) Load Balancer in GCP?

An HTTP(S) Load Balancer in GCP is a Layer 7 load balancer that distributes incoming web traffic across multiple backend instances based on HTTP(S) request attributes like URL path, headers, or cookies. It helps improve availability and scalability.

beginner

What does Layer 7 mean in the context of load balancing?

Layer 7 refers to the application layer in the OSI model. Load balancing at Layer 7 means decisions are made based on application data such as HTTP headers, URLs, or cookies, allowing smarter routing than just IP or TCP level.

intermediate

Name two key features of GCP HTTP(S) Load Balancer.

1. Global load balancing with a single anycast IP address.
2. Content-based routing using URL maps to direct traffic to different backends.

intermediate

How does HTTP(S) Load Balancer improve scalability?

It distributes traffic across multiple backend instances automatically, scales backend capacity up or down, and uses health checks to route traffic only to healthy instances, ensuring efficient resource use.

intermediate

What is the role of URL maps in HTTP(S) Load Balancer?

URL maps define rules to route incoming requests to different backend services based on URL paths or hostnames. This allows serving different content or applications from the same IP address.

What layer does HTTP(S) Load Balancer operate on?

A Layer 2 - Data Link Layer

B Layer 3 - Network Layer

C Layer 4 - Transport Layer

D Layer 7 - Application Layer

HTTP(S) Load Balancer operates at Layer 7, the application layer, allowing it to route traffic based on HTTP attributes.

Which feature allows HTTP(S) Load Balancer to route traffic based on URL paths?

A URL Maps

B Health Checks

C Firewall Rules

D Backend Buckets

URL Maps define routing rules based on URL paths or hostnames.

What is the benefit of using a single anycast IP address in GCP HTTP(S) Load Balancer?

A Improves DNS resolution speed

B Reduces backend server count

C Enables global load balancing

D Encrypts traffic automatically

A single anycast IP allows global load balancing by routing user requests to the nearest backend.

How does HTTP(S) Load Balancer ensure traffic is sent only to healthy backends?

A Using firewall rules

B Using health checks

C Using SSL certificates

D Using DNS failover

Health checks monitor backend health and route traffic only to healthy instances.

Which protocol(s) does HTTP(S) Load Balancer support?

A Both HTTP and HTTPS

B Only HTTPS

C Only HTTP

D TCP and UDP

HTTP(S) Load Balancer supports both HTTP and HTTPS protocols.

Explain how GCP HTTP(S) Load Balancer routes traffic and improves application availability.

Think about how it uses HTTP details and global network to distribute traffic smartly.

Describe the difference between Layer 4 and Layer 7 load balancing and why Layer 7 is useful for web applications.

Consider what extra information Layer 7 has compared to Layer 4.

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