Networking and Content Delivery practice questions

Use a Transit Gateway instead of VPC Peering for cross-region connectivity.

Why wrong: A Transit Gateway provides a scalable hub-and-spoke architecture for many VPCs, but it does not inherently reduce latency for a single cross-region VPC pair; traffic still traverses the same AWS global network backbone, and the Transit Gateway adds an extra network hop for traffic from one VPC to the other. Replacing VPC Peering with Transit Gateway would not change the DNS resolution behavior that is causing the latency; the problem lies in how instances resolve and route traffic, not in the interconnection type.

Increase the MTU on the instances' network interfaces to 9001.

Why wrong: Increasing the MTU to 9001 enables jumbo frames, which reduces the number of packets needed for large data transfers and lowers per-packet overhead; this can improve throughput for bulk workloads but does not reduce the per-packet propagation delay that dominates latency on cross-region links. The observed latency issue is likely caused by DNS misconfiguration sending traffic over the public internet, not by packet size, so jumbo frames will not address the root cause.

Configure ECMP (Equal-Cost Multi-Path) routing on the VPC peering connection.

Why wrong: ECMP (Equal-Cost Multi-Path) routing allows traffic to be spread across multiple equal-cost paths to increase bandwidth and redundancy, but a VPC Peering connection is a single, point-to-point relationship between exactly two VPCs and does not support multiple parallel paths. Since there is only one peering pathway, ECMP cannot be configured on it; even if it were possible, ECMP only affects load balancing and aggregated throughput, not the serial latency of a single TCP flow, so it would not improve the delay.

Use Amazon Route 53 with a simple routing policy pointing to the ALB DNS name

Why wrong: Amazon Route 53 with a simple routing policy only returns the ALB's DNS name as an A/AAAA alias record. The ALB's underlying IP addresses are ephemeral and can change when the load balancer scales or is recreated, so the third party cannot extract a static, allowlisted IP from this DNS response. Simple routing also provides no mechanism to guarantee a fixed IP for the caller's firewall rules, making it invalid for a static-IP allowlisting requirement.

Use an Amazon CloudFront distribution with the ALB as the origin and provide the CloudFront IP addresses

Why wrong: CloudFront uses a shared IP range that is not dedicated to a specific distribution. These IPs also change when CloudFront updates its edge locations, so they are not a stable, dedicated set of IPs for allowlisting.

AWS Transit Gateway

Why wrong: Transit Gateway introduces unnecessary complexity and cost for a two-VPC peering scenario, as it requires a central hub router and additional attachments, whereas VPC peering provides direct, low-cost connectivity using the AWS backbone without such overhead. It is tempting because Transit Gateway is designed for hub-and-spoke architectures with many VPCs, where it simplifies routing and centralised management—making it the correct choice for large-scale multi-VPC topologies, but not for a simple two-VPC requirement.

AWS Direct Connect

Why wrong: AWS Direct Connect is a dedicated physical network connection that links an on-premises data center or colocation facility to AWS via a private circuit, typically delivered through a Direct Connect partner or location. It is designed exclusively for hybrid-cloud workloads where you need reliable, high-bandwidth, low-latency connectivity from your own infrastructure to AWS resources. Using Direct Connect for VPC-to-VPC traffic would force you to hairpin data through an external router on-premises, which is not only architecturally nonsensical but also introduces unnecessary physical infrastructure, carrier costs, and latency. Direct Connect does not provide a mechanism to connect two VPCs directly; instead, it attaches to a virtual private gateway for one VPC at a time, and inter-VPC communication would require complex routing that defeats the purpose of private AWS backbone connectivity.

AWS Site-to-Site VPN

Why wrong: AWS Site-to-Site VPN creates an encrypted IPsec tunnel between a VPN device on an on-premises network and a virtual private gateway attached to an AWS VPC, with traffic traversing the public internet. For VPC-to-VPC communication, you would need to establish two separate VPN connections—one from each VPC to some external VPN endpoint—and route all inter-VPC traffic through that external location, which is convoluted, introduces significant latency, and incurs hourly connection charges for each VPN tunnel. Unlike VPC peering, which uses AWS's private backbone, a Site-to-Site VPN relies on the public internet, so traffic is exposed to encryption overhead and potential variability in network performance. Even in the unlikely scenario where both VPCs are configured with VPN connections to the same endpoint, the architecture would be far more expensive and complex than a simple peering connection, making it an inappropriate choice for same-region inter-VPC connectivity.

Use AWS PrivateLink by creating a Network Load Balancer in VPC C and configuring VPC endpoints in VPC A and VPC B to access the services.

Why wrong: Incorrect. PrivateLink only provides access to specific services (e.g., via NLB and VPC endpoints), not general IP communication between all resources in the VPCs. It does not fulfill the requirement of enabling private IP communication between the VPCs.

Create two VPC peering connections: one between VPC A and VPC C, and one between VPC B and VPC C.

Why wrong: Incorrect. VPC peering does not support overlapping CIDR blocks, so peering between VPC A and VPC C (both using 10.0.0.0/16) would fail due to conflicts.

Set up two AWS Site-to-Site VPN connections from VPC C to VPC A and VPC B using virtual private gateways.

Why wrong: Incorrect. Site-to-Site VPN is typically used for connecting on-premises networks to VPCs, not for VPC-to-VPC communication in the same region. It adds complexity and does not address overlapping CIDRs.

Amazon CloudFront with origins configured for both dynamic and static content

Why wrong: Amazon CloudFront is a CDN that caches HTTP/HTTPS content at edge locations to reduce latency for web traffic. However, it only supports HTTP and HTTPS protocols, so it cannot carry UDP traffic, which is critical for many real-time gaming applications that use UDP for game state and voice. Even with origins configured for dynamic and static content, CloudFront's HTTP/S-only nature and caching model do not accelerate raw TCP/UDP sockets, and dynamic requests still traverse the public internet to the origin. Thus, CloudFront is unsuitable for gaming workloads requiring UDP or global network path optimization.

AWS Shield Advanced

Why wrong: AWS Shield Advanced provides enhanced DDoS detection and mitigation, including 24/7 access to the DDoS Response Team, AWS WAF integration, and cost protection against scaled resource spikes. It is a security service that monitors and scrubs malicious traffic, but it does not alter the network path, provide edge points of presence, or improve routing for legitimate packets. As a result, Shield Advanced has no effect on baseline latency, UDP support, or the speed of data transfer, and it cannot address the gaming application's need for low-latency global connectivity.

AWS App Mesh

Why wrong: AWS App Mesh is a service mesh that manages east-west traffic between microservices using Envoy sidecar proxies, providing features like traffic routing, retries, and observability. It operates inside a customer's VPC or Kubernetes cluster and is not deployed at AWS edge locations, so it cannot optimize the network path from end users to the application. App Mesh also does not handle UDP or anycast IPs; its focus is on application-level service-to-service communication, not on edge acceleration or external protocol support. Therefore, it does not improve latency for gaming clients.

AWS Transit Gateway

Why wrong: AWS Transit Gateway is incorrect because, whilst it facilitates private IP connectivity and offers high throughput, it is engineered for complex, large-scale network topologies involving numerous VPCs, hybrid cloud environments, or centralised routing. For a simple connection between only two VPCs, it introduces unnecessary cost and management overhead, failing the "simple, low-cost" requirement of the scenario. It is tempting as it provides the desired connectivity, but it is specifically designed for scaling network connectivity beyond a simple two-VPC peering.

AWS Direct Connect

Why wrong: AWS Direct Connect is a dedicated physical fiber connection from an on-premises location to an AWS endpoint, not a mechanism for connecting two VPCs. Using it to link VPC A and VPC B would require deploying a Direct Connect gateway, virtual interfaces, and a transit VPC or router, adding infrastructure complexity and monthly costs. The scenario has no on-premises component, so Direct Connect is entirely mismatched for this simple VPC-to-VPC requirement.

Internet Gateway

Why wrong: Each VPC gets its own Internet Gateway, which is a horizontally scaled, redundant component for enabling inbound and outbound public internet traffic. It does not route traffic between VPCs; any VPC-to-VPC communication would traverse the public internet, losing the private, low-cost, and high-throughput benefits required. An IGW is designed for internet-facing workloads, not for private interconnectivity between VPCs.

Create a NAT gateway in a public subnet and update the private route tables to point 0.0.0.0/0 to the NAT gateway.

Why wrong: A NAT gateway placed in a public subnet enables outbound internet connectivity, but any traffic sent to Amazon S3 through that path will traverse the public internet to reach the S3 endpoint. This violates the requirement to keep traffic private, and the NAT gateway also incurs hourly charges plus per-GB data processing costs. In contrast, a Gateway VPC endpoint provides direct, private access to S3 by adding a route to the S3 prefix list, so the NAT gateway is neither necessary nor optimal.

Create a VPC endpoint for S3 (Interface type) and assign a security group to the endpoint.

Why wrong: An Interface VPC endpoint for S3, while preventing internet traversal, requires a security group and incurs hourly costs, but the correct solution is a Gateway VPC endpoint that uses route table entries and is free. This option is tempting because Interface endpoints are necessary for services like SQS or DynamoDB, where Gateway endpoints do not exist, and security groups offer granular control.

Create an AWS Direct Connect connection and route traffic to S3 through the on-premises network.

Why wrong: AWS Direct Connect establishes dedicated network connectivity from your on-premises data center to AWS, not from your VPC to S3 within the same region. To use it for S3 access, traffic would need to egress the VPC through a virtual private gateway or transit gateway, travel to the on-premises location, and then return to AWS — a round-trip that adds latency, complexity, and cost. A Gateway S3 endpoint is the region-internal, lowest-cost solution and eliminates the need for Direct Connect in this scenario.

Establish a single Direct Connect connection with a VPN backup.

Why wrong: While a VPN over the public internet can serve as a failover path, it introduces variable latency, jitter, and throughput because it traverses the public internet. The primary Direct Connect remains a single point of failure at the physical connection level, and the VPN does not meet the same SLA or consistent performance expected for critical workloads. For high availability, dedicated redundant connections are preferred.

Establish two Direct Connect connections to the same AWS Direct Connect location.

Why wrong: Establishing two connections at the same Direct Connect location provides device-level redundancy (e.g., different routers or ports) but still creates a single point of failure at the facility level. If the location experiences an outage due to power loss, fiber cut, or provider failure, both connections become unavailable simultaneously. AWS advises diverse locations to achieve true resilience.

Use multiple virtual interfaces on a single Direct Connect connection.

Why wrong: Multiple virtual interfaces (VIFs) on a single Direct Connect connection provide logical segmentation for different services or VPCs, but they all rely on the same physical infrastructure. If the connection suffers a cable cut, hardware failure, or facility outage, every VIF becomes unavailable simultaneously. This configuration offers no physical resilience, making it unsuitable for high-availability requirements.

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

Why wrong: 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.

Create a VPC endpoint for the external API service.

Why wrong: 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 wrong: 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.

AWS Transit Gateway

Why wrong: While AWS Transit Gateway can connect two VPCs, it introduces a hub-and-spoke architecture with hourly per-attachment costs and data-processing fees. You would need to create a transit gateway, attach both VPCs, and configure route tables, which is unnecessary for a simple two-VPC connection. VPC peering provides the same private connectivity with lower latency, no extra hop, and no hourly charge.

AWS Direct Connect

Why wrong: AWS Direct Connect is a dedicated physical connection from an on-premises location into AWS, not a VPC-to-VPC service. Even with Direct Connect, you would need a Virtual Private Gateway and either a transit VPC or VPN to relay traffic between the two VPCs, adding complexity and cost. It exists to reduce network expenses for hybrid workloads, not to provide inter-VPC communication within a region.

AWS VPN CloudHub

Why wrong: VPN CloudHub is a hub-and-spoke VPN topology that lets remote branch offices with customer gateways connect to a single Virtual Private Gateway attached to one VPC, enabling inter-site communication over encrypted tunnels. It does not provide native VPC-to-VPC peering; to connect the two VPCs you would have to route through an on-premises VPN, which adds unnecessary latency and complexity. It is purpose-built for multi-site VPN connectivity, not direct private VPC linking.

Upload a third-party certificate to IAM and associate it with the ALB.

Why wrong: Although an ALB can use a server certificate imported into IAM, IAM provides no renewal lifecycle management—it simply stores the certificate and key. You would have to manually track expiration, request a new certificate from your third-party CA, re-upload it to IAM, and update the ALB listener before the old one expires. This creates a recurring operational risk and is a legacy path that AWS now discourages in favor of ACM, which automates renewal and validation.

Store the certificate in Amazon S3 and configure the ALB to read from S3.

Why wrong: The ALB has no feature to read certificates from an S3 bucket; its TLS listener only accepts a certificate identifier from AWS Certificate Manager or an IAM server certificate ARN. Placing a certificate in S3 merely treats it as an object, and the load balancer cannot perform the TLS handshake with that object. Additionally, storing private keys in S3 is a security concern because it widens the access control surface and does not integrate with ALB's TLS configuration at all.

Use a self-signed certificate on each EC2 instance and configure the ALB for TCP passthrough.

Why wrong: Configuring the ALB for TCP passthrough means it does not terminate TLS; encrypted traffic goes straight to instances, so each EC2 instance would still need its own self-signed certificate and manual rotation. Self-signed certificates are not trusted by public browsers, causing security warnings, and you lose ALB features that require inspecting HTTP headers, such as path-based routing and sticky sessions. This approach also makes certificate management linearly harder as the Auto Scaling group grows, so it is neither scalable nor operationally sound.

Route 53 Resolver inbound endpoints

Why wrong: Route 53 Resolver inbound endpoints are designed for the opposite direction: they let DNS resolvers on-premises forward queries to Route 53 for names hosted in AWS private hosted zones. An inbound endpoint provides one or more ENIs in your VPC with private IPs that act as DNS entry points, but it cannot intercept queries originating inside the VPC and forward them out to on-premises DNS servers. Because this scenario requires VPC-to-on-premises resolution for corp.example.com, an inbound endpoint would not satisfy the requirement.

VPC peering between the VPC and the on-premises network

Why wrong: VPC peering provides Layer 3 connectivity between two VPCs, allowing private IP routing and traffic exchange, but it cannot extend to an on-premises network because VPC peering only works between VPCs within AWS. Even if you established a VPN or Direct Connect connection separately, VPC peering itself does not include any DNS-forwarding capability or integration with Route 53 Resolver. Therefore, using VPC peering here would neither connect the VPC to on-premises infrastructure nor resolve corp.example.com from instances in the VPC.

Route 53 private hosted zone for corp.example.com

Why wrong: A Route 53 private hosted zone for corp.example.com would make Route 53 authoritative for that domain inside the associated VPC, meaning it can answer queries with records you define in AWS. However, it does not forward queries to on-premises DNS servers, so any on-premises DNS records—such as hostnames or service records that are dynamically maintained—would not appear unless you manually duplicate them in the hosted zone. This approach lacks the conditional forwarding behavior needed to resolve names that live on the on-premises DNS infrastructure, making it incorrect for this hybrid DNS scenario.

Place the EC2 instances in a public subnet and configure security group inbound rules to block all traffic.

Why wrong: Instances in a public subnet have direct internet access but are still reachable from the internet if security groups are misconfigured; this does not guarantee the required security posture and does not fully prevent inbound traffic.

Launch a NAT instance in a public subnet with an Elastic IP address and configure route tables accordingly.

Why wrong: While a NAT instance in a public subnet with an Elastic IP can also enable outbound access, it is essentially an EC2 instance you must configure and manage yourself. You are responsible for OS patching, disabling source/destination-check, tuning the security group, and scaling if traffic grows. It also becomes a single point of failure unless you build custom high-availability mechanisms. This operational burden directly contradicts the goal of minimizing overhead.

Attach an Internet Gateway to the VPC and add a route to the private subnet route table pointing 0.0.0.0/0 to the Internet Gateway.

Why wrong: Attaching an Internet Gateway and routing 0.0.0.0/0 from the private subnet directly to it is a fundamental VPC design error. An Internet Gateway only works for instances with public IPs; it does not perform source-NAT, so private instances would either have no connectivity or, if assigned public IPs, would be directly exposed to inbound internet traffic. This defeats the purpose of a private subnet and creates a security vulnerability, unlike a managed NAT Gateway that provides one-way connectivity.

Configure a NAT Gateway and use security group outbound rules to restrict destinations.

Why wrong: Security groups are stateful firewalls that evaluate rules based on IP addresses, ports, and protocols—they cannot match DNS names or URLs, so they are fundamentally incapable of restricting outbound traffic by domain. Moreover, a NAT Gateway is a fully managed AWS service that does not support attaching security groups directly to it; you could attach a security group to the private instances, but that group's outbound rules still only allow or deny CIDR ranges, not domain names. Thus, while a NAT Gateway provides basic IPv4 outbound connectivity, it offers no mechanism to enforce domain-based allow lists, making this combination insufficient for the stated requirement.

Configure an egress-only Internet Gateway and route private subnet traffic to it.

Why wrong: An egress-only Internet Gateway (EIGW) is a VPC component designed exclusively for IPv6 traffic that originates from resources in a VPC and is destined for the internet; it does not support IPv4 at all. Even if your workload were IPv6-only, the EIGW simply forwards outbound packets and provides no capability to inspect, filter, or restrict destinations by domain name or URL—it is effectively a transparent path for all outbound IPv6 traffic. Therefore, this option not only fails to address IPv4 connectivity but also lacks the domain-based control explicitly required, so it is incorrect.

Configure a VPC endpoint for HTTPS and route private subnet traffic to it.

Why wrong: A VPC endpoint provides private, high-bandwidth connectivity only to supported AWS services or to your own services via AWS PrivateLink; it cannot be used to reach general internet destinations. For example, an HTTPS interface endpoint connects only to specific AWS services (like API Gateway or a service you expose behind a Network Load Balancer), not to arbitrary public websites, so it does not provide outbound internet access to the VPC as a whole. Consequently, routing private subnet traffic to a VPC endpoint would not enable instances to browse generic internet domains, and it offers no domain-level filtering, making this option invalid.

Create a NAT gateway in a public subnet and route private subnet traffic to it.

Why wrong: Although a NAT gateway in a public subnet can provide outbound internet access, it would force S3 traffic to traverse the internet gateway, breaking the private connectivity assumption and incurring NAT gateway hourly charges plus data transfer costs for every object retrieval or upload. NAT gateways are also AZ-scoped and require one per AZ for high availability, adding even more cost and complexity. This solution fails the 'fully private and cost-effective' requirement because the traffic is not contained within the AWS network.

Create an S3 Interface Endpoint and assign a security group.

Why wrong: An S3 Interface Endpoint creates a private ENI with an IP address in your subnet and is backed by AWS PrivateLink, but it is metered per hour and per gigabyte of data processed, making it significantly more expensive than a Gateway Endpoint for high-volume S3 access. It also requires a security group to control access, adding management overhead that a Gateway Endpoint does not require. For a simple private-subnet-to-S3 connection, this is over-engineered and costlier than necessary.

Use AWS PrivateLink to connect to S3.

Why wrong: AWS PrivateLink is the underlying service that enables interface endpoints, so using PrivateLink to connect to S3 is effectively the same as deploying an interface endpoint. This approach incurs hourly endpoint charges and per-GB data processing fees, and it requires additional configuration such as security groups and endpoint policies. Because S3 supports Gateway Endpoints, which are free and purely private, using PrivateLink is an unnecessarily expensive and complex alternative for this scenario.

Attach an Internet Gateway to the VPC and add a default route (0.0.0.0/0) to the Internet Gateway in the private subnet route tables.

Why wrong: Instances in private subnets do not have a public IP; adding a default route to an Internet Gateway will not work because the Internet Gateway requires instances to have public IPs or Elastic IPs for outbound traffic.

Create a VPC endpoint for Amazon S3 and route traffic through it.

Why wrong: A VPC endpoint for Amazon S3 (an interface or gateway endpoint) provides private connectivity only to the S3 service, using the AWS network and never traversing the public internet. It does not offer general internet access, so instances cannot use it to download operating system patches, package updates, or any other external content not hosted in S3. Even if patches were stored in S3, a VPC endpoint would not help with reaching arbitrary external repositories or service providers; it is scoped solely to S3 API calls. Therefore, routing traffic through an S3 VPC endpoint fails to satisfy the requirement for internet access and would not be a substitute for a NAT gateway.

Set up an AWS Direct Connect connection and route all internet-bound traffic through it.

Why wrong: AWS Direct Connect establishes a dedicated private network connection from your on-premises data center to AWS, but it does not natively provide internet access for your VPC resources. To use Direct Connect for internet-bound traffic, you would still need an internet gateway attached to the VPC, public IP addressing for instances, and a route design that sends traffic over the Direct Connect virtual interface to a separate internet connection — which is complex and not inherently available. Direct Connect is primarily for low-latency, private connectivity to AWS services, not for general egress to the public internet. Even if you configured internet access through your on-premises network, it would introduce a single dependency on that facility and would not be the highly available, AWS-managed solution that NAT gateways provide.

A NAT Gateway

Why wrong: A NAT Gateway provides outbound internet access, but traffic still traverses the internet and incurs NAT Gateway data processing charges. It does not provide a private path to S3.

An Internet Gateway

Why wrong: An Internet Gateway enables general outbound internet access but requires public IPs and uses the internet. It does not provide a private or cost-optimized path to S3.

VPC Peering

Why wrong: VPC Peering connects two VPCs, allowing private IP communication between them. It does not provide access to a service endpoint like S3.

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

Why wrong: 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 wrong: 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 wrong: 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.

Create a single Transit Gateway route table and add routes for all VPCs and the on-premises network.

Why wrong: A single Transit Gateway route table forces every VPC attachment and the on-premises attachment into one shared routing domain. With overlapping CIDRs, the TGW cannot uniquely resolve destinations because multiple VPC attachments advertise the same prefix, creating ambiguous next hops and unpredictable routing. Additionally, all VPCs would be able to route to each other, violating the isolation requirement. This design also propagates on-premises routes identically to all VPCs, but the fundamental flaw is that overlapping prefixes cannot coexist in one table.

Use VPC peering instead of Transit Gateway to connect VPCs, and use Direct Connect Gateway for on-premises connectivity.

Why wrong: VPC peering does not support overlapping CIDR ranges—you cannot create a peering connection between VPCs whose CIDRs overlap, so the core requirement is impossible. Peering is also non-transitive, meaning you would need a mesh of connections, and it does not offer a hub-and-spoke model with route-table isolation. Adding a Direct Connect Gateway only manages DX-based connectivity to on-premises; it does not provide inter-VPC routing or segmentation. Thus this combined approach fails on both overlapping CIDRs and isolation.

Configure VPN connections between each VPC and the on-premises network, bypassing Transit Gateway.

Why wrong: Establishing individual VPN connections from each VPC to the on-premises network creates a set of point-to-point links that do not enable inter-VPC communication; VPCs would still be isolated from one another unless you also add separate peering or routing. Overlapping CIDRs remain problematic because on-premises routers cannot distinguish identical prefixes from different VPCs, and each VPN tunnel would carry conflicting routes. This approach adds operational complexity and per-VPN cost without delivering the centrally managed, isolated hub-and-spoke architecture that Transit Gateway provides. It also leaves the requirement for isolated communication groups entirely unaddressed.

Enable versioning

Why wrong: Enabling versioning preserves every overwritten or deleted object, allowing recovery from accidental changes, but it does not create an HTTP endpoint or serve any content. The website feature is a separate bucket configuration that activates a web server on the S3 service; without it, the bucket remains a private object store. Versioning is therefore entirely orthogonal to hosting a static website.

Configure a bucket policy to allow public read access

Why wrong: Block public access settings and a bucket policy that grants public read access are prerequisites for anyone to view the objects, but they only affect object permissions via the REST API. The static website hosting feature itself must be activated separately to produce a website endpoint and to interpret index/error documents. A public bucket policy alone leaves the bucket as an object store, not a website.

Attach a CloudFront distribution

Why wrong: Attaching a CloudFront distribution is an optional enhancement that provides low-latency delivery, HTTPS, and custom domain support using the S3 bucket as an origin. It does not itself enable S3's static website hosting; if the bucket is not configured for website hosting, CloudFront will use the REST API endpoint, which requires proper permissions and does not serve website features like index documents. Since the question asks to host a static website, CloudFront is not the enabling action.