VPC practice questions

Internet gateway attached to the VPC

Why it fails: An internet gateway only enables public IPv4 connectivity for resources with public addresses; private subnets have no route to it, so S3 and Parameter Store traffic cannot traverse it. It is tempting because it is the standard egress path for public subnets, and would be correct if the instances held Elastic IPs and the requirement permitted internet routing.

NAT gateway in each Availability Zone

Why it fails: A NAT gateway routes traffic to the public internet via an internet gateway, which the stem explicitly forbids; it also cannot reach S3 or Parameter Store without public endpoints. It is tempting because NAT gateways are the usual answer for private-subnet egress, and would be correct if outbound internet access were permitted.

Increase DesiredCapacity to 4 while keeping all instances in subnet-a1.

Why it fails: This adds more instances, but they are still all in the same Availability Zone. If us-east-1a fails, every instance is lost together and the application still goes down. Capacity is not the same as fault isolation.

Replace the Application Load Balancer with a Network Load Balancer.

Why it fails: A Network Load Balancer changes the load-balancing layer, but it does not fix the root problem: all instances are still in one AZ. If that AZ fails, there are still no healthy targets to receive traffic.

Enable EBS encryption on the launch template volumes.

Why it fails: Enabling EBS encryption on the launch template volumes encrypts data at rest, which protects the confidentiality of data stored on the volumes, but it has no impact on availability or failover behavior. The Auto Scaling group still launches all EC2 instances in subnet-a1 within us-east-1a, so if that Availability Zone experiences an outage, all instances and their encrypted volumes become unreachable simultaneously. Encryption is a security control, not a resilience mechanism; it neither introduces redundant compute in another zone nor changes the failure domain, and it does not alter how the load balancer routes traffic or how the ASG replaces unhealthy instances.

Internet gateway attached to the VPC

Why it fails: An internet gateway is a horizontally scaled, redundant component that enables communication between a VPC and the public internet. It is not used by private subnets because private subnets have no route to an internet gateway, and even if one were added, traffic would traverse the public internet and not be private. Internet gateways also do not provide private connectivity to AWS services, so this option cannot satisfy the requirement.

NAT gateway in each Availability Zone

Why it fails: A NAT gateway allows instances in private subnets to initiate outbound internet traffic, but it does so by routing packets through the internet gateway to the public internet. For private access to Systems Manager, this would mean traffic leaving the AWS network and traveling over public infrastructure, violating the requirement for private connectivity. Additionally, NAT gateways incur hourly charges and data processing fees, and they are not designed as a private endpoint service.

Create a read replica in a different Availability Zone and configure the application to fail over manually.

Why it fails: A read replica uses asynchronous replication and cannot be promoted to a standalone primary without a failover process that incurs replication lag, potential data loss, and manual steps. Configuring the application for manual failover requires updating connection strings and does not offer automatic detection of the primary's failure, so it fails to meet the need for rapid, unattended recovery. Also, reading from a replica would serve stale data until it catches up, which is not acceptable for a database that must remain consistent and available.

Switch the database to use EBS snapshots more frequently and restore in case of failure.

Why it fails: EBS snapshots are a backup mechanism, not a high-availability feature; restoring from a snapshot creates a brand-new DB instance, which takes time to provision and does not preserve the original endpoint. The restore process also loses any transactions committed after the last snapshot, resulting in a potentially high RPO, and the RTO is measured in minutes or more. This approach is appropriate for disaster recovery, not for meeting an aggressive RTO with automatic failover.

Pin the DB to a specific instance type with higher CPU credits to prevent CPU-related disconnects.

Why it fails: Burstable instance classes (t2/t3/t4g) earn CPU credits, but pinning the DB to a specific instance type with higher CPU credits only addresses potential CPU throttling during sustained load. It does nothing to protect against an Availability Zone outage, which is the underlying failure scenario. Higher CPU credits cannot provide redundancy, failover capability, or automatic re-routing of traffic, so this option would leave the database still vulnerable to AZ-level loss.

A single EC2 instance with detailed monitoring

Why it fails: Detailed monitoring with CloudWatch (1-minute metrics) only increases the frequency of metric collection and alarms; it has no effect on fault tolerance or instance replacement. A single EC2 instance still resides in one Availability Zone, so an AZ outage, hardware failure, or maintenance event terminates the instance and takes the dashboard offline until manual intervention or a separate recovery mechanism acts. Detailed monitoring can help you react faster to performance issues, but it cannot restart, replace, or relocate the instance, leaving the application with a single point of failure.

All instances in one larger subnet

Why it fails: Expanding a subnet to include more IP addresses does not change the underlying physical location; a subnet exists entirely within a single Availability Zone. If all EC2 instances are launched into that one larger subnet, they all share the same AZ, so any failure of that AZ—power loss, network partition, or cooling failure—takes every instance down simultaneously. Larger subnets only provide more capacity for launching instances, not geographical or fault-domain diversity, and therefore do not address availability or redundancy requirements.

A Network Load Balancer in one subnet

Why it fails: A Network Load Balancer (NLB) is a regional service that can route traffic to targets across multiple AZs; however, if the NLB itself is placed in a single subnet (single AZ), it becomes a single point of failure at the network layer. Even if the backend instances are in multiple AZs, an AZ failure that includes the NLB's subnet will make the load balancer unreachable, and the entire application loses connectivity. NLB nodes must be deployed in at least two AZs—or the NLB must automatically have a node in each enabled AZ—to provide high availability; simply having a load balancer in one subnet adds a dependency that defeats resilience.

All instances in one larger subnet

Why it fails: Even if the subnet is large (i.e., has many IP addresses), all instances reside within a single Availability Zone. An AZ failure, such as a power outage or network partition, would take down every instance in that subnet, making the system unavailable. Scaling by adding more instances within the same AZ does not provide redundancy against AZ-level failures; it only adds capacity within a failure domain.

A Network Load Balancer in one subnet

Why it fails: The NLB itself is a single point of failure when placed in only one subnet/AZ. If that AZ fails, the NLB becomes unreachable, and all traffic to the application is lost, regardless of how many EC2 instances are running behind it. A properly designed NLB should be placed in multiple subnets across AZs, or use an Application Load Balancer that is inherently multi-AZ, to ensure the load balancer itself survives an AZ outage.

A single EC2 instance with detailed monitoring

Why it fails: Detailed monitoring (CloudWatch metrics at 1-minute frequency) only provides better visibility into the instance's health, but it does not provide any redundancy. If the instance fails, no automatic replacement occurs, and the ticket booking system remains down until manual intervention. There is still a single point of failure in both compute and the AZ.

S3 Object Lambda

Why it fails: S3 Object Lambda lets you add custom code to process data returned from S3 GETs, but it operates at the request/response layer, not the network path. It does not remove the need for traffic to traverse a NAT gateway, nor does it affect data processing charges. In fact, it adds per-request Lambda costs and can increase latency, making it the opposite of a cost-saving network solution.

AWS Shield Advanced

Why it fails: AWS Shield Advanced is a Distributed Denial of Service (DDoS) protection service that provides enhanced detection and mitigation for sophisticated attacks, along with cost protection against scaling incurred during an attack. It does not modify the network architecture or reduce NAT gateway data processing charges for normal traffic. Its purpose is security posture, not cost optimization for VPC-to-S3 connectivity.

A larger NAT gateway

Why it fails: NAT gateways are managed services billed by hourly usage and data processing per GB; they scale automatically to support increased throughput, so choosing a larger size is not even a configurable option—all NAT gateways support up to 100 Gbps. Even if you could select a larger size, it would increase the hourly cost without affecting the per-GB processing charge, making it more expensive, not cost-optimized. The only way to avoid NAT processing costs is to bypass the NAT gateway entirely.

A Gateway VPC endpoint for secretsmanager

Why it fails: Gateway VPC endpoints are only supported for Amazon S3 and DynamoDB. They work by adding a prefix list entry to the route table, not by attaching an ENI. Secrets Manager does not offer a gateway endpoint; the only private connectivity option is an Interface VPC endpoint (AWS PrivateLink), so a gateway endpoint would not be able to route traffic to the Secrets Manager API.

A NAT gateway in the private subnet route table

Why it fails: A NAT gateway provides outbound internet access from private subnets, but the question explicitly states there is no NAT gateway and, by implication, no internet routing. Even if one existed, using a NAT gateway would force Secrets Manager API calls to travel over the internet to the public endpoint, which violates the requirement to keep traffic private. A NAT gateway is also an egress-only mechanism and does not provide the secure, native private connectivity that an interface endpoint offers.

A VPC peering connection to the AWS public network hosting Secrets Manager

Why it fails: VPC peering establishes connectivity between two VPCs, not between your VPC and AWS managed services like Secrets Manager. There is no 'AWS public network' VPC available to peer with, and the supported way to privately access Secrets Manager APIs is via an Interface VPC endpoint (AWS PrivateLink). Peering would not give your subnets a private, stable route to the Secrets Manager service endpoint and is not a valid pattern for this scenario.

Create an S3 gateway endpoint for Secrets Manager and use the existing S3 gateway endpoint for both secret retrieval and KMS decryption.

Why it fails: Gateway endpoints are not used for Secrets Manager or KMS. They are specifically for supported services such as S3 and DynamoDB. The existing S3 endpoint does not provide network path or name resolution for the secret or decrypt operations.

Add a NAT gateway in a public subnet and route 0.0.0.0/0 from the private subnets to the NAT gateway.

Why it fails: A NAT gateway would allow outbound internet access, but the requirement says to keep traffic off the internet. It would also introduce additional cost and does not meet the private connectivity constraint. AWS PrivateLink endpoints are the correct design.

Move the application into a public subnet so it can call the public Secrets Manager endpoint directly.

Why it fails: Moving the application into a public subnet still uses the public Secrets Manager endpoint, which requires an internet path and exposes the workload to a broader network attack surface. This directly contradicts the stated requirement to keep all traffic within AWS private networking and avoid internet egress. It also does nothing to address the need for private access to the customer-managed KMS key for decryption, so the application would still need a way to reach KMS securely. Proper architecture uses interface VPC endpoints with private DNS to keep both Secrets Manager and KMS traffic fully inside the AWS backbone.

Add a NAT gateway to the private subnet route table and keep using the public Secrets Manager endpoint.

Why it fails: A NAT gateway gives your private subnet outbound internet connectivity, so the application could reach the public Secrets Manager endpoint, but that path travels through the internet gateway and leaves the AWS private network. This exposes sensitive API traffic to the public path, incurs NAT gateway hourly and data-processing charges, and adds a single point of failure. It also requires a public IP for the NAT gateway and an internet gateway, which is less secure and more expensive than using a VPC endpoint.

Create a gateway VPC endpoint for Secrets Manager and point the route table to it.

Why it fails: Gateway VPC endpoints are route-table-based and are only supported for Amazon S3 and DynamoDB; AWS Secrets Manager is not eligible. A gateway endpoint works by adding a prefix list to a route table, which does not apply to Secrets Manager because it is a Regional service exposed through an API. Pointing the route table to such an endpoint would not create any path to the Secrets Manager API, leaving the application without connectivity to retrieve secrets.

Use VPC peering to connect the application subnet to another VPC that already has internet access.

Why it fails: VPC peering connects two VPCs privately, but it does not let you use the peered VPC's internet gateway for egress because peering does not support transitive or shared internet access. Even if the peered VPC has full internet connectivity, your application subnet would still need its own NAT gateway or internet gateway to reach the public Secrets Manager endpoint. If the peered VPC instead contained an interface endpoint, you would need custom routing and additional components like a Network Load Balancer to make it usable, so this option is not a direct or simple solution.

Expose the NLB with an Internet Gateway route and restrict access using a security group attached to the NLB.

Why it fails: Security groups cannot be attached directly to NLBs for this purpose in the way implied, and exposing the service via the public internet violates the private-only requirement. PrivateLink is designed for private connectivity without relying on public exposure.

Create an S3 Gateway endpoint in the consumer VPC and store the service hostname in SSM Parameter Store so clients can resolve privately.

Why it fails: An S3 Gateway endpoint is a route-based mechanism that grants private connectivity only to S3 and DynamoDB; it cannot reach an arbitrary internal service hosted behind a Network Load Balancer. Storing the service hostname in SSM Parameter Store merely lets clients look up a DNS name—it does not create any private network path, and the clients would still try to traverse the public internet or existing routes. PrivateLink requires an interface VPC endpoint, which is an elastic network interface with a private IP in the consumer VPC, not a gateway device. This option conflates centralised configuration with connectivity and selects the wrong endpoint type for the required AWS PrivateLink architecture.

Use a bastion host in the provider VPC and allow the consumer VPC to SSH to it; from there, the consumer makes HTTP calls to the NLB.

Why it fails: A bastion host provides interactive SSH access for administrative tasks, not a scalable, least-privilege service endpoint; the consumer team would need to manage SSH keys and sessions, and the NLB’s traffic remains unexposed to PrivateLink’s VPC endpoint security groups. This option is tempting because bastion hosts are a common pattern for secure remote administration of private resources, and they would be correct if the consumer needed occasional SSH-based management of the provider’s instances rather than automated HTTP calls from another VPC.

Disabling route tables

Why it fails: Disabling route tables would not reduce cost and would actually break all network traffic in the sandbox. Route tables are mandatory for any subnet to function; they determine how traffic is directed, including the default route to the NAT gateway. Removing or disabling them would make private subnets unable to route any packets, not even to the VPC's local network, thus undermining the entire environment. Cost optimization must not sacrifice fundamental routing, and this option is neither practical nor targeted at the NAT gateway expense.

Replacing every NAT gateway with an internet gateway attached to private subnets

Why it fails: An internet gateway (IGW) does not perform NAT for private instances; it only enables communication for resources with public IP addresses. If you attach an IGW to a private subnet, instances still lack public IPs and a route to the IGW, so outbound internet traffic will simply fail. To make it work, you would have to assign public IPs and convert your private subnets into public ones, which defeats the purpose of having a private subnet and exposes instances directly to the internet. Thus, this is not a like-for-like replacement and does not address the NAT gateway cost while maintaining the same architecture.

Moving all workloads to public subnets

Why it fails: Migrating all workloads to public subnets would eliminate the need for NAT gateways, but at the cost of removing the security boundary provided by private subnets. Public instances are directly reachable from the internet, requiring tight security group rules and exposing the attack surface; this is a security regression, not a cost-first best practice. Even if you maintain security groups, anything accidentally misconfigured could lead to data exposure. The question is focused on cost reduction without compromising the sandbox's architectural integrity, so this option is wrong because it trades security for cost rather than optimizing within the existing design.

Keep the ASG in one Availability Zone, but reduce ALB health check intervals.

Why it fails: Reducing health check intervals only changes how quickly the ALB marks targets unhealthy. It does not create capacity in other AZs, so the ALB still has no healthy instances to route to when the only ASG AZ fails.

Switch the load balancer from an ALB to an NLB to remove HTTP health check dependency.

Why it fails: An NLB still relies on the same single-AZ subnets, so the AZ outage persists; swapping listener type does not add subnets. NLB suits TCP/UDP workloads needing static IPs or extreme throughput, not HTTP resilience. The fix is adding subnets in a second AZ to the ASG.

Add an Amazon SQS queue to buffer requests during failures.

Why it fails: A queue can help with asynchronous work, but a typical web request/response path still requires immediate compute capacity to accept and handle requests. Queueing does not eliminate the loss of in-AZ instances when the only ASG AZ fails.

Create an Interface VPC endpoint (powered by PrivateLink) for S3

Why it fails: Interface endpoints are used by many AWS services, but S3 is specifically accessed via a Gateway endpoint. Using an Interface endpoint for S3 would not provide the intended S3 connectivity pattern for private subnets in the standard AWS design.

Use a Transit Gateway to route to S3 over the internet

Why it fails: A Transit Gateway routes traffic between networks/VPCs, but it does not replace the service-specific private connectivity required to reach S3 without public internet. You would still need an appropriate private path (such as a gateway endpoint) rather than sending traffic over the internet.

Place a NAT Gateway and restrict security group egress to port 443 to reduce exposure

Why it fails: Adding a NAT Gateway would directly violate the stated constraint of having no NAT Gateway, and a NAT Gateway requires an internet gateway and public subnet to function. Even if you restrict security group egress to HTTPS port 443, the NAT route would force S3 traffic out to the public internet, incurring data transfer costs and exposing traffic to potential interception. A Gateway VPC endpoint instead keeps S3 traffic entirely within the AWS network, without any NAT device.

Add a more permissive security group rule allowing outbound 0.0.0.0/0 on all ports.

Why it fails: Security group rules are evaluated after routing decisions, so adding an outbound 0.0.0.0/0 rule does not provide a path to the internet or to AWS services. Without a route through a NAT gateway/internet gateway or a VPC endpoint, traffic is still dropped. Moreover, Systems Manager requires interface endpoints for each service, and S3 requires a gateway endpoint or NAT; a permissive SG alone cannot enable these private connections.

Replace the NAT gateway with a network ACL that allows ephemeral ports to the internet.

Why it fails: A network ACL is a stateless packet filter, not a routing or connectivity construct. Even if you allow ephemeral ports, the subnet has no route to an internet gateway or NAT device, so outbound traffic cannot leave the VPC. Additionally, Session Manager and S3 access in a private subnet rely on VPC endpoints or NAT, and NACLs cannot create those private connections.

Move the instances to public subnets so they can reach AWS services directly.

Why it fails: Moving instances to public subnets would route S3 and Systems Manager traffic through an internet gateway, violating the requirement to keep traffic on the AWS private network. Public subnets also assign public IPs and expose instances to inbound internet traffic, increasing the attack surface. A private subnet with VPC endpoints is the correct way to reach these AWS services without traversing the internet.

Replacing every NAT gateway with an internet gateway attached to private subnets

Why it fails: An internet gateway (IGW) is a VPC-level resource, not a per-subnet device, and it cannot be 'attached' to private subnets. When a private subnet routes 0.0.0.0/0 to an IGW, instances would need public IP addresses to actually reach the internet; without them the route is ineffective, and with them the subnet is effectively public. An IGW permits bidirectional traffic, so inbound connections from the internet can reach those resources, completely undermining the isolation that private subnets and NAT gateways are designed to provide. Replacing NAT gateways with IGWs does not preserve outbound-only access and is not a valid cost optimization.

Disabling route tables

Why it fails: Disabling route tables is not a valid operation in AWS, and more importantly, route tables are the essential mechanism that tells each subnet where to send traffic. Every private subnet that uses a NAT gateway must have a route table with a 0.0.0.0/0 entry pointing to that gateway; without that route, the batch job's outbound internet traffic would have no path and would be dropped, breaking the analytics pipeline. Disabling or deleting route tables would also disrupt internal VPC routing, not just internet access, so it would cause a full network outage rather than any cost savings. The correct optimization is to simplify or consolidate routing, not to remove the routing layer itself.

Moving all workloads to public subnets

Why it fails: Moving all workloads to public subnets would require assigning public IP addresses and routing traffic directly through an internet gateway, which exposes the batch analytics instances to unsolicited inbound internet traffic. This fundamentally violates defense-in-depth principles because private subnets exist to keep sensitive data and processing logic inaccessible from the public internet, and many compliance frameworks mandate that data-processing workloads remain private. While this change could eliminate NAT gateway costs, it is not a cost-first best practice because the security risk and potential compliance breach far outweigh the savings; a better cost play is to right-size the NAT gateway count, not expose the workload.

A security group rule that allows HTTPS to S3

Why it fails: Security groups are stateful filters that attach to Elastic Network Interfaces of EC2 instances; they cannot be attached to an S3 bucket, which is a regional service with no ENI. A rule allowing HTTPS to S3 might govern outbound traffic from the instance, but it cannot validate that the traffic actually reached the S3 endpoint as intended. More importantly, it provides no way to restrict the S3 bucket to accept requests only from that specific instance, so it fails to enforce the private, endpoint-based network path.

A condition that matches aws:RequestedRegion to the bucket Region

Why it fails: The aws:RequestedRegion condition key in IAM or bucket policies restricts the AWS Region to which the API call is destined, but it has no knowledge of the network path taken. A request from a public IP to the S3 endpoint in the same Region would satisfy this condition just as easily as a request traveling through the VPC endpoint. Therefore, it cannot prove that the EC2 instance's traffic used the VPC endpoint, leaving the public internet path available and violating the 'must access via endpoint' requirement.

A deny statement for all IAM users except the EC2 role

Why it fails: A deny statement for all IAM users except the EC2 role is an identity-based restriction that limits which principals can call S3, regardless of where they are located. This does nothing to control the network route; the EC2 role's credentials could be used from any machine, and requests could still travel over the internet. It also would block legitimate access from other services like Lambda or other VPCs, whereas the requirement is specifically about network path enforcement, not principal scoping.

Set the ECS deployment configuration to maximum percent 100 so tasks replace instances faster during rollouts.

Why it fails: Setting maximumPercent to 100 only controls how ECS performs rolling deployments, specifying that no additional tasks beyond the desired count can be launched. This does not affect the number of EC2 instances or their distribution across Availability Zones, so it cannot provide spare capacity during an AZ failure. In fact, it can make deployments riskier because old tasks must be stopped before new ones start, but it is irrelevant to infrastructure-level redundancy.

Enable ALB connection draining longer than expected so existing connections survive longer during an AZ event.

Why it fails: ALB connection draining is a deregistration delay that allows in-flight requests to complete when a target is intentionally removed from the target group. It cannot preserve connections for an entire Availability Zone loss, because the underlying instances are unreachable and the ALB will mark the targets unhealthy and stop sending traffic to them. The feature also does not provision any new capacity, so it leaves the service unable to handle new requests without healthy instances in another AZ.

Reduce task memory reservations to pack both tasks onto a single EC2 instance.

Why it fails: Reducing task memory reservations simply allows the ECS scheduler to place more tasks on each EC2 instance, encouraging consolidation rather than distribution. If all tasks are packed onto a single instance, the blast radius of a failure is maximized—losing that one instance or its AZ takes down every task. This directly undermines high availability, which requires spreading tasks across instances and AZs, not fitting them onto fewer machines.

S3 Object Lambda

Why it fails: S3 Object Lambda enables you to run custom Lambda code on the object content returned by S3 GET requests, primarily for transforming or filtering data in real time. It does not provide or modify VPC routing; requests still originate from the instance and traverse whichever network path exists, including a NAT gateway. It adds compute time and Lambda invocation costs while leaving NAT data processing charges on the underlying S3 traffic fully intact.

AWS Shield Advanced

Why it fails: AWS Shield Advanced is a managed DDoS protection service that operates at the network edge to absorb volumetric attacks; it does not change the network path between a private subnet and Amazon S3. Because media processing still egresses through a NAT gateway, S3 traffic continues to incur NAT data processing charges. Shield Advanced protects availability, not cost, so it cannot address the NAT cost issue.

A larger NAT gateway

Why it fails: NAT gateways do not have a user-selectable 'larger' size; they are managed, horizontally scaled resources that automatically adjust to handle traffic up to their bandwidth limits. The NAT gateway pricing model includes both an hourly charge and a per-GB data processing fee, so attempting to increase capacity would either have no effect on the per-GB fee or increase the monthly cost. To reduce S3-related charges, you must route S3 traffic away from the NAT gateway entirely, not increase its size.

Attach Elastic IP addresses to instances in private subnets

Why it fails: Elastic IP addresses are static public IPv4 addresses that require an instance to reside in a public subnet with a route to an Internet Gateway to be useful for egress; they do not create any private path from a private subnet to AWS service APIs. Even if you attach an EIP to an instance in a private subnet, outbound traffic would still need a NAT Gateway or similar egress device, so it cannot satisfy the cost-avoidance goal. EIPs also incur additional charges for idle addresses and fail to provide the PrivateLink-like connectivity that VPC endpoints offer.

Install a NAT Gateway in every subnet to minimize routing hops

Why it fails: Installing a NAT Gateway in every subnet does not remove the need for an Internet Gateway (IGW) nor does it bypass pay-per-hour and per-GB data processing charges; in fact, it compounds those costs across multiple gateways. NAT routing still forces traffic through the public border (IGW) before reaching AWS services, adding latency and complexity, which is the opposite of the low-hop private path provided by a VPC endpoint. The premise of 'minimizing routing hops' is also incorrect: a gateway endpoint for S3 or an interface endpoint for other services routes directly from your VPC to the service, without any NAT device.

Open outbound internet access with a security group rule to reach service endpoints directly

Why it fails: Reaching AWS service endpoints via the internet typically reintroduces outbound connectivity (and associated data-transfer costs and security considerations). It also does not provide the NAT-avoidance behavior of VPC endpoints for private access to AWS services.