Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For AWS DVA-C02 candidates, the confusion often lies in how to reliably capture the original client IP in load-balanced environments. In production, this is about knowing exactly which load balancer type supports which mechanisms for client IP forwarding, and how your application must handle it. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
TechCraft Solutions, a fast-growing startup, plans to launch a new customer-facing web application on AWS. The app will serve traffic over HTTP and HTTPS and will sit behind a load balancer to handle scaling and availability. However, the development team must ensure that the backend services can log and act upon the original client IP addresses for security auditing and geolocation features.
The Requirement: #
Determine which AWS load balancing solution allows the application to receive the real client IP addresses while providing HTTP/HTTPS listener support.
The Options #
- A) Use an Application Load Balancer (ALB) and rely on the X-Forwarded-For headers.
- B) Use a Network Load Balancer (NLB) with proxy protocol enabled on both NLB and target application.
- C) Use an Application Load Balancer and register targets by instance ID.
- D) Use a Network Load Balancer with X-Forwarded-For headers.
Google adsense #
leave a comment:
Correct Answer #
A
Quick Insight: The Developer Imperative #
To capture client IP addresses behind HTTP/HTTPS load balancing, understanding the forwarding mechanism is key. ALBs use standard HTTP headers (X-Forwarded-For) to propagate client IPs, whereas NLBs relay client IP via proxy protocol or preserve the source IP at the TCP level but do not populate HTTP headers themselves. This affects how you configure and code your backend services.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option A
The Winning Logic #
The Application Load Balancer (ALB) is designed for HTTP and HTTPS traffic and injects the X-Forwarded-For header that includes the original client IP address. This is the standard and AWS-recommended way to preserve client IP in web-layer load balancing scenarios. Your backend application just needs to parse this header to get the true client IP.
- ALBs operate at Layer 7 (HTTP/HTTPS), so they have full visibility into HTTP headers and can modify or add them.
X-Forwarded-Foris the conventional standard header all HTTP clients and proxies use to relay the originating IP address.- Backend targets can be registered by IP or instance ID, but this choice doesn’t impact the client IP forwarding behavior itself.
The Trap (Distractor Analysis): #
-
Why not B? (NLB with proxy protocol)
Proxy protocol is TCP-level and requires enabling proxy protocol support in your backend application to decode headers; also, NLBs operate at Layer 4 and do not add HTTP headers likeX-Forwarded-For. This is a valid option only if clients connect via TCP and your app supports proxy protocol parsing, which is more complex and less common for HTTP/HTTPS workloads. -
Why not C? (ALB targets registered by instance ID)
While registering by instance ID is allowed, it is unrelated to client IP preservation. This option doesn’t address the key requirement. -
Why not D? (NLB with X-Forwarded-For headers)
NLBs do not addX-Forwarded-Forheaders as they do not interpret HTTP; this is invalid.
The Technical Blueprint #
# How to enable proxy protocol on NLB targets (if you ever choose Option B)
aws elbv2 modify-target-group-attributes \
--target-group-arn <your-target-group-arn> \
--attributes Key=proxy_protocol_v2.enabled,Value=true
# How to read X-Forwarded-For header in backend application (Node.js example)
const clientIp = req.headers['x-forwarded-for'] || req.connection.remoteAddress;
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Low | Medium | Native HTTP(S) load balancing; client IP via header |
| B | High | High | TCP load balancing with proxy protocol parsing |
| C | Low | Medium | Target registration method; no impact on IP forwarding |
| D | Invalid | N/A | NLBs do not inject HTTP headers, so incorrect |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick Application Load Balancer for HTTP/HTTPS traffic when the question mentions client IP visibility via headers like X-Forwarded-For.
Real World #
In real systems, if you need extreme performance or TCP-level proxying (such as very low latency or non-HTTP protocols), NLB with proxy protocol support might be preferred — but your backend must handle proxy protocol decoding explicitly.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.