Application Load Balancer (ALB) in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

How does an Application Load Balancer route traffic?

Imagine you have a web app behind an Application Load Balancer (ALB). How does the ALB decide which server to send a user's request to?

A It always sends all requests to the first server in the list.

B It sends requests randomly to any server without checking health.

C It routes requests based on the content of the request, like URL path or host header.

D It sends requests only to servers that are offline to balance load.

💡 Hint

Think about how ALB can inspect the request details before forwarding.

ALB can look at request details such as URL path or host header to route traffic to different target groups. This allows smart routing based on content.

❓ Architecture

intermediate

Which component is NOT part of an ALB architecture?

In the architecture of an Application Load Balancer, which of these components is NOT involved?

A Listeners that check incoming requests on specific ports.

B Target groups that contain registered servers or containers.

C Auto Scaling groups that automatically add or remove servers.

D DNS servers that resolve domain names to IP addresses.

💡 Hint

Consider which components ALB directly manages versus external services.

DNS servers are external to ALB. ALB uses listeners, target groups, and often works with Auto Scaling groups but does not manage DNS resolution itself.

❓ scaling

advanced

How does ALB handle sudden traffic spikes to maintain performance?

Your web app behind an ALB suddenly gets a huge spike in traffic. How does ALB help maintain performance?

A ALB distributes requests evenly across healthy targets and supports auto scaling integration.

B ALB automatically adds more servers to the target group to handle load.

C ALB queues incoming requests indefinitely until servers are free.

D ALB rejects all new requests until traffic decreases.

💡 Hint

Think about how ALB works with other AWS services to handle load.

ALB balances requests across healthy targets and integrates with Auto Scaling to add or remove servers based on demand, helping maintain performance during spikes.

❓ tradeoff

advanced

What is a tradeoff when using ALB with sticky sessions enabled?

Sticky sessions (session affinity) keep a user's requests on the same server. What is a downside of enabling sticky sessions on ALB?

A It prevents the ALB from checking server health.

B It can cause uneven load because some servers get more requests than others.

C It disables SSL encryption on the ALB.

D It improves load distribution evenly across all servers.

💡 Hint

Consider how sticking users to one server affects load balance.

Sticky sessions can cause some servers to receive more requests than others, leading to uneven load and potential performance issues.

❓ estimation

expert

Estimate the number of concurrent connections ALB can handle for a high-traffic app.

You plan to deploy an ALB for a high-traffic app expecting 100,000 concurrent users. What is a reasonable estimate of ALB's concurrent connection capacity per load balancer?

A About 100,000 concurrent connections per ALB.

B About 1,000,000 concurrent connections per ALB.

C About 10,000 concurrent connections per ALB.

D ALB has no limit on concurrent connections.

💡 Hint

Think about AWS ALB documented limits and typical usage.

AWS ALB supports around 100,000 concurrent connections per load balancer by default, which can be increased by request but is a practical baseline.

Practice

1. What is the primary purpose of an Application Load Balancer (ALB) in AWS?

easy

A. To create virtual private clouds (VPCs)

B. To distribute incoming web traffic across multiple targets for better availability

C. To monitor network traffic for security threats

D. To store large amounts of data securely

Solution

1. Step 1: Understand ALB's role in traffic management

   ALB distributes incoming HTTP/HTTPS requests to multiple backend servers to balance load and improve availability.

2. Step 2: Compare options with ALB's function

   Options A, B, and C describe other AWS services, not ALB's main function.

3. Final Answer:

   To distribute incoming web traffic across multiple targets for better availability -> Option B

4. Quick Check:

   ALB = traffic distribution [OK]

Hint: ALB balances web traffic to keep apps available [OK]

Common Mistakes:

• Confusing ALB with storage services
• Thinking ALB handles security monitoring
• Mixing ALB with network setup services

2. Which of the following is the correct way to specify a listener protocol for an ALB in AWS?

easy

A. ListenerProtocol: HTTP

B. ListenerProtocol: FTP

C. ListenerProtocol: TCP

D. ListenerProtocol: SMTP

Solution

1. Step 1: Identify supported ALB listener protocols

   ALB supports HTTP and HTTPS protocols for listeners, not TCP, FTP, or SMTP.

2. Step 2: Match correct protocol syntax

   ListenerProtocol: HTTP uses HTTP, which is valid for ALB listeners.

3. Final Answer:

   <code>ListenerProtocol: HTTP</code> -> Option A

4. Quick Check:

   ALB listener protocol = HTTP or HTTPS [OK]

Hint: ALB listeners use HTTP/HTTPS, not TCP or FTP [OK]

Common Mistakes:

• Using unsupported protocols like FTP or SMTP
• Confusing ALB with Network Load Balancer protocols
• Incorrect syntax for listener protocol

3. Given an ALB with two target groups: tg1 and tg2. The ALB uses a rule to route requests with path /api/* to tg1 and all other requests to tg2. What happens when a user requests /api/users?

medium

A. The request is routed to target group tg1

B. The request is routed to target group tg2

C. The request is rejected with an error

D. The request is routed to both tg1 and tg2 simultaneously

Solution

1. Step 1: Analyze the ALB routing rule

   The rule states requests with path starting /api/ go to tg1.

2. Step 2: Match the request path

   The request path /api/users matches the /api/* pattern, so it routes to tg1.

3. Final Answer:

   The request is routed to target group <code>tg1</code> -> Option A

4. Quick Check:

   Path /api/* routes to tg1 [OK]

Hint: Path rules route matching requests to correct target group [OK]

Common Mistakes:

• Assuming default target group handles all requests
• Thinking requests route to multiple target groups
• Ignoring path-based routing rules

4. You configured an ALB with HTTPS listener but forgot to attach an SSL certificate. What issue will occur?

medium

A. The ALB will route requests without encryption

B. The ALB will automatically generate a certificate and accept requests

C. The ALB will downgrade HTTPS requests to HTTP

D. The ALB will reject all HTTPS requests with a TLS handshake failure

Solution

1. Step 1: Understand HTTPS listener requirements

   HTTPS listeners require a valid SSL certificate to establish secure connections.

2. Step 2: Consequence of missing certificate

   Without a certificate, TLS handshake fails, causing ALB to reject HTTPS requests.

3. Final Answer:

   The ALB will reject all HTTPS requests with a TLS handshake failure -> Option D

4. Quick Check:

   HTTPS needs SSL cert; missing cert = handshake failure [OK]

Hint: HTTPS listeners must have SSL certificates attached [OK]

Common Mistakes:

• Assuming ALB auto-generates SSL certificates
• Thinking ALB downgrades HTTPS to HTTP automatically
• Believing ALB routes unencrypted traffic on HTTPS listener

5. You want to design a scalable web app using ALB that routes traffic based on user device type: mobile users to tg-mobile and desktop users to tg-desktop. Which ALB feature should you use to implement this?

hard

A. Use ALB path-based routing with /mobile and /desktop paths

B. Use ALB health checks to detect device type

C. Use ALB listener rules with HTTP header-based routing on the User-Agent header

D. Use ALB sticky sessions to route users based on device

Solution

1. Step 1: Identify how to detect device type in requests

   User device type is typically indicated in the HTTP User-Agent header.

2. Step 2: Choose ALB feature for routing based on headers

   ALB supports listener rules that route traffic based on HTTP headers like User-Agent.

3. Step 3: Evaluate other options

   Health checks do not detect device type; path-based routing requires URL changes; sticky sessions maintain session but don't route by device.

4. Final Answer:

   Use ALB listener rules with HTTP header-based routing on the User-Agent header -> Option C

5. Quick Check:

   Header-based routing = device type routing [OK]

Hint: Use header-based routing on User-Agent for device detection [OK]

Common Mistakes:

• Using health checks to detect device type
• Relying on path-based routing without URL changes
• Confusing sticky sessions with routing logic