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 VPC Gateway Endpoint for S3.

  Why this is correct

  A VPC Gateway Endpoint for S3 is the correct solution because it creates a horizontally scaled, redundant entry point that lets you route S3 traffic from your private subnet directly through the AWS backbone, not over the internet. You add a route to the subnet's route table using the S3 prefix list (e.g., pl-63a5400a for us-east-1), and no internet gateway, NAT, or public IP is required. This keeps traffic entirely within the AWS network, reducing egress costs and minimizing exposure to internet-based threats. Note that gateway endpoints are free and only support connectivity to S3 and DynamoDB within the same region.

• ✗

  Deploy a NAT Gateway in the public subnet and add a route to the private subnet's route table.

  Why it's wrong here

  Deploying a NAT Gateway is the wrong approach because a NAT gateway provides outbound-only internet connectivity by translating private IPv4 addresses to a public IP and sending traffic through the internet gateway. While instances in a private subnet could reach S3 via the NAT and the public internet, the request would traverse the public internet, incurring data transfer costs and exposing logs or data to risk. Additionally, the NAT gateway itself requires an Elastic IP, an Internet Gateway, and a route in the public subnet, making it unnecessarily complex compared to a free gateway endpoint. This still violates the requirement for private S3 access.

• ✗

  Attach an Internet Gateway to the VPC and add a default route in the private subnet's route table.

  Why it's wrong here

  Attaching an Internet Gateway and adding a default route to the private subnet route table is incorrect because an Internet Gateway alone does not allow instances without public IPs to initiate outbound traffic; it only enables communication for instances that have public IPv4 addresses or Elastic IPs. A private subnet instance has no public IP, so traffic routed to the IGW would be discarded—you would need a NAT gateway or instance to provide outbound access, and even then the path to S3 would traverse the internet. Moreover, this does not provide private connectivity to S3 and introduces additional egress data charges. The correct way to reach S3 privately is via a gateway endpoint, which uses the VPC as the network boundary without any IGW involvement.

• ✗

  Set up an AWS Direct Connect connection to the S3 bucket.

  Why it's wrong here

  Setting up an AWS Direct Connect connection is incorrect because Direct Connect is an on-premises network connectivity service that links your data center or office to AWS over a dedicated private line, not something you use for EC2-to-S3 communication inside a VPC. An EC2 instance already lives inside the AWS network, so Direct Connect would introduce a needless dependency on physical cabling, VPN termination, or partnering with a DX provider—while still not ensuring private S3 access without an additional public virtual interface or endpoint. For same-region S3 access from a private subnet, AWS recommends a VPC Gateway Endpoint, which is free and keeps all packets within Amazon's internal network. Direct Connect is only relevant if on-premises resources need access to your VPC and S3 without going over the public internet.

Go deeper

Related to this question