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.

• ✗

  Place the web servers in public subnets and assign each instance an Elastic IP address.

  Why it's wrong here

  Placing the web servers in public subnets with Elastic IPs would expose the instances directly to the internet, bypassing the security boundary provided by private subnets. While Elastic IPs provide static addresses, they allow unsolicited inbound traffic, increasing the attack surface and violating the requirement to keep instances private. The Application Load Balancer already serves as the public-facing front end, so instances should remain private and only initiate outbound traffic through a NAT gateway. Additionally, assigning a unique Elastic IP to every web server does not scale and does not address outbound-only connectivity.

• ✓

  Deploy a NAT gateway in a public subnet with an Elastic IP and route outbound traffic from the private subnets through the NAT gateway.

  Why this is correct

  Deploying a NAT gateway in a public subnet and adding a route (0.0.0.0/0) to the private subnets' route tables enables outbound internet access while preserving the private nature of the instances. The NAT gateway's Elastic IP provides a consistent, static public source IP for all outbound traffic, meeting the requirement to whitelist a single address for the external API. No inbound connections are permitted, as the NAT gateway is one-way, and this managed service is highly available within each Availability Zone. This is the standard AWS architecture for outbound-only internet access from private subnets.

• ✗

  Create a VPC endpoint for the external API service.

  Why it's wrong here

  A VPC endpoint is only available for AWS services and specific third-party services enabled through AWS PrivateLink; it cannot be created for an arbitrary external API. Since the external API is not a PrivateLink partner, a VPC endpoint is not a viable option for this scenario. Even if an endpoint existed, endpoints provide private connectivity without traversing the internet and do not inherently assign a static public IP for outbound traffic. The correct mechanism for controlling the outbound public IP is a NAT gateway (or NAT instance) with an Elastic IP.

• ✗

  Use AWS Global Accelerator to provide static IP addresses for outbound traffic.

  Why it's wrong here

  AWS Global Accelerator provides static anycast IP addresses for inbound client traffic to your application—typically fronting a load balancer or EC2 instances—but it does not influence outbound traffic from your instances. The direction of traffic is opposite: Global Accelerator directs traffic into your VPC, whereas the requirement here is about traffic leaving your VPC to reach an external API. Therefore, Global Accelerator cannot supply a static public IP for outbound calls and would not satisfy the requirement. For outbound traffic, a NAT gateway with an Elastic IP is the appropriate and accepted solution.

Go deeper

Related to this question