SOA-C02 Networking and Content Delivery Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create a CloudFront distribution and point it to the ALB as an origin.

  Why it's wrong here

  CloudFront is a content delivery network optimised for caching static and dynamic web content at edge locations, not for accelerating TCP/UDP traffic through the global AWS network. In this scenario, users in Asia experience high latency because traffic must traverse the public internet to reach the ALB in us-east-1; CloudFront would cache responses but does not alter the underlying network path for non-cacheable traffic or provide static anycast IPs that bypass internet congestion. It is tempting because CloudFront also uses edge locations, but the correct integration requires Global Accelerator’s anycast IPs and the AWS global network to reduce latency for all traffic types, including API calls and WebSockets, which CloudFront cannot accelerate.

• ✓

  Configure the ALB as an endpoint group in a Global Accelerator accelerator.

  Why this is correct

  Global Accelerator is a networking service that provides two static anycast IP addresses at AWS edge locations and routes traffic over the AWS global network to the ALB endpoint. By adding the ALB as an endpoint in an endpoint group for the us-east-1 region, user traffic from Asia enters the AWS backbone at the nearest edge and traverses the private, low-latency AWS network instead of the congested public internet. This also brings health checking, automatic failover, and consistent performance even during internet disruptions.

• ✗

  Set up a Route 53 geoproximity routing policy for the ALB.

  Why it's wrong here

  Route 53 geoproximity routing chooses the nearest resource based on the client's geographic location, but it does nothing to optimize the network path once the client sends its request; traffic still travels over the public internet to reach the ALB in us-east-1. It can route to ALBs in other regions if you deploy a multi-region setup, but with a single ALB it simply points all US East traffic to that ALB and does not reduce latency for users in Asia. The service also relies on DNS resolution, which can be cached and slow to update, and it lacks the static anycast IPs and automatic edge-based routing that Global Accelerator provides.

• ✗

  Use AWS WAF to allow traffic from Global Accelerator edge locations.

  Why it's wrong here

  AWS WAF is a layer-7 web application firewall that inspects and filters HTTP(S) requests based on rules such as IP reputation, SQL injection, or cross-site scripting. It has no networking capability to accelerate traffic, reroute packets, or reduce round-trip time; it only allows or blocks requests after they have already arrived at the ALB. Allowing traffic from Global Accelerator edge locations in WAF would be a security policy, not a performance feature, and it would not change the fact that client traffic must still cross the public internet to reach the ALB.

Go deeper

Related to this question