A company runs ECS services behind an internet-facing ALB that is the origin for CloudFront. An AWS WAF web ACL is associated with CloudFront, but clients can bypass it by accessing the ALB…

Question

Options

• AUse AWS PrivateLink with the ALB.
• BReplace the ALB with an internal ALB.
• CRestrict ALB listener rules to CloudFront IP ranges.
• DRequire a custom header from CloudFront and validate it at the ALB.

• A
  15% (4)
• B
  8% (2)
• C
  4% (1)
• D
  73% (19)

Explanation

Explanation

Option D is correct because CloudFront can be configured to inject a custom secret header (e.g., X-Custom-Header: mysecretvalue) into every request it forwards to the ALB origin, and the ALB listener rules can then be configured to only allow requests that contain this header - effectively blocking any client attempting to reach the ALB directly without going through CloudFront first.

Why the distractors are wrong:

• A (PrivateLink): PrivateLink is used for private connectivity between VPCs or AWS services and does not solve the problem of an internet-facing ALB being accessed directly from the public internet.
• B (Internal ALB): Switching to an internal ALB would make it unreachable from the internet entirely, including from CloudFront, breaking the intended architecture unless significant VPC networking changes are made.
• C (Restrict to CloudFront IP ranges): CloudFront's IP ranges are publicly known and change frequently, making IP-based restrictions unreliable, difficult to maintain, and potentially spoofable.

Memory Tip: Think of the custom header as a secret handshake - only CloudFront knows the password, so only CloudFront gets through the ALB's door. This is a well-documented AWS best practice pattern specifically designed to "lock the back door" when using CloudFront + WAF.

No community discussion yet for this question.