VPC practice questions

Replace the security group egress rule to allow all outbound traffic to 0.0.0.0/0 on TCP 443.

Why wrong: Allowing 0.0.0.0/0 does not create a route to the S3 service without NAT. Security groups do not override routing; if traffic is not routed through the S3 VPC endpoint, the connection will still time out.

Add an Internet Gateway to the VPC and route the private subnet’s 0.0.0.0/0 to the IGW.

Why wrong: Adding an Internet Gateway and public routing would defeat the purpose of using private subnets without NAT and increases exposure. The correct solution is service-specific private connectivity using a VPC endpoint for S3.

Switch from network ACLs to security groups by removing the existing NACL allow rules for ephemeral ports.

Why wrong: If DynamoDB works, NACL rules are likely not the blocker for outbound traffic in general. Also, the primary requirement for reaching S3 without NAT is routing via the S3 endpoint. NACL changes would be unnecessary if endpoint routing is already correct.

Place the Auto Scaling group in only one subnet so instance launches are simpler.

Why wrong: Using only one subnet/AZ removes redundancy. An AZ outage would still take down capacity until manual action occurs.

Increase the target group deregistration delay to allow old instances to stay longer.

Why wrong: Changing deregistration delay affects connection draining, not capacity placement across AZs. It doesn’t create additional resilient instances.

Use a Network Load Balancer, but keep all subnets in a single Availability Zone.

Why wrong: Switching load balancer type doesn’t fix the root cause. If capacity is only in one AZ, failures will still impact the service.

NACLs are stateful and automatically track connections; the fix is to add a new inbound rule to the security group for client source ports.

Why wrong: NACLs are stateless; connection tracking occurs at the security group level only. Adding SG inbound rules won’t unblock outbound traffic blocked by the NACL.

The issue is caused by ALB health checks; configure a new target group health check on port 80 so traffic can be routed.

Why wrong: Health checks may affect routing, but the symptom points to NACL blocking return packets. Changing health check ports won’t address NACL stateless behavior.

Because instances are in private subnets, add a NAT gateway so return traffic can reach the internet over dynamic routing.

Why wrong: NAT affects internet egress, not east-west return paths inside the VPC subnet. The observed NACL rule gap is within the subnet path.

Create an S3 Gateway VPC endpoint and use it for Secrets Manager requests because both services use HTTPS.

Why wrong: Gateway VPC endpoints are service-specific (for S3 and a limited set of related services) and do not provide connectivity for Secrets Manager API calls. HTTPS does not make an S3 endpoint usable for other services.

Assign a public IP address to the tasks so they can call Secrets Manager over the internet without NAT.

Why wrong: Assigning a public IP address to the microservice tasks would allow them to communicate with AWS Secrets Manager, but this communication would occur over the public internet. This approach directly contradicts the implicit requirement for private networking, as it introduces public internet egress for the microservice. Furthermore, exposing backend tasks directly to the internet via public IPs is generally considered a security anti-pattern, increasing the attack surface.

Change the route table to send all 0.0.0.0/0 traffic directly to an Internet Gateway.

Why wrong: Changing the route table to direct all 0.0.0.0/0 traffic to an Internet Gateway would indeed enable the microservice to reach Secrets Manager. However, this configuration routes all outbound traffic from the private subnet, including that destined for AWS services, through the public internet. This violates the principle of maintaining private network connectivity for sensitive service interactions and introduces unnecessary public exposure for all outbound traffic from the microservice.

Create an Interface VPC endpoint for S3 and point the instances to it

Why wrong: Interface VPC endpoints (powered by AWS PrivateLink) use elastic network interfaces (ENIs) in your subnets and are supported for many services, but Amazon S3 is a special case. For S3, the supported private connectivity model is a Gateway VPC endpoint that integrates with route tables, not an interface endpoint.

Create a NAT gateway and allow outbound HTTPS to S3

Why wrong: A NAT gateway provides outbound internet connectivity. Even if the destination is S3 over HTTPS, traffic still traverses the NAT gateway and leaves the VPC via the internet path, which violates the requirement to avoid NAT/internet egress.

Create a VPC endpoint service and manually register S3 as a provider endpoint

Why wrong: VPC Endpoint Services are for exposing your own services privately (or consuming privately exposed endpoint services). S3 is not registered as a provider endpoint service by customers. The correct AWS-managed approach for S3 is a Gateway VPC endpoint.

Add an S3 bucket policy Deny statement that blocks requests unless the principal uses MFA.

Why wrong: MFA affects authentication for interactive identity flows. It does not provide any guarantee about the network path or whether the request traversed a specific VPC endpoint, so it cannot enforce the required endpoint-level routing constraint.

Enable Block Public Access and remove the public bucket policy statement.

Why wrong: Block Public Access prevents public exposure of the bucket, but it does not restrict access to a specific VPC endpoint. Private requests from other network locations (that can still reach S3 with valid credentials) would remain possible.

Attach an IAM policy to the workload role that allows s3:PutObject only to the bucket ARN.

Why wrong: Least-privilege IAM limits which actions and resources are permitted, but IAM cannot constrain the origin network path (for example, forcing traffic to traverse vpce-0abc123example). A valid principal could still call S3 from anywhere that has network reachability and credentials.

Put the service behind API Gateway REST API and use Lambda integration.

Why wrong: API Gateway is designed for API requests, not arbitrary custom binary TCP sessions. It would not preserve the required protocol semantics or satisfy the static allowlisting requirement for this use case. It is the wrong abstraction for raw TCP traffic.

Use CloudFront to cache the binary packets at edge locations.

Why wrong: CloudFront is optimized for HTTP and HTTPS content delivery and caching, not for arbitrary TCP application protocols. It does not solve static IP allowlisting or source-IP preservation for a custom binary service. Caching is irrelevant to the described workload.

Terminate the traffic with an Amazon RDS proxy to stabilize the connections.

Why wrong: RDS Proxy is for database connection management, not for fronting a TCP application service. It has no role in preserving source IP for a custom binary protocol or in providing allowlisted endpoint addresses. This is a mismatch to the workload.

Keep the ASG in one subnet/AZ, but enable ALB stickiness to reduce session interruption.

Why wrong: Stickiness affects session routing but does not create targets in a second AZ during an AZ outage.

Add a NAT gateway in the public subnets so instances can reach the internet during maintenance events.

Why wrong: NAT affects outbound connectivity, not target placement or health during an AZ outage.

Create a second ALB in the same Availability Zone and route traffic using DNS failover.

Why wrong: DNS failover adds complexity and still depends on healthy targets; without multi-AZ instances, failover won’t help much.

S3 Object Lambda

Why wrong: Object Lambda transforms S3 responses and does not remove NAT gateway traffic cost.

AWS Shield Advanced

Why wrong: Shield Advanced protects against DDoS and does not reduce S3 NAT traffic charges.

A larger NAT gateway

Why wrong: NAT gateways scale automatically; increasing size is not a cost optimization option.

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

Why wrong: Read replicas improve read scaling, but manual failover and replication lag can still harm failover objectives.

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

Why wrong: Snapshot restore is a backup/recovery approach and typically does not meet fast failover requirements.

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

Why wrong: Instance sizing affects performance but not AZ-level failover behavior or redundancy.

A security group rule that allows HTTPS to S3

Why wrong: Security groups do not attach to S3 buckets and cannot enforce S3 bucket access.

A condition that matches aws:RequestedRegion to the bucket Region

Why wrong: RequestedRegion limits API calls by Region but does not prove traffic used the endpoint.

A deny statement for all IAM users except the EC2 role

Why wrong: This controls identity but does not enforce the network path through the endpoint.

Set the ASG min capacity to 0 so instances can be recreated faster when an AZ recovers.

Why wrong: Lowering min capacity to 0 makes it more likely the ASG can run with too little (or no) capacity in the remaining AZ(s) when one AZ is down. That can increase request failures and performance issues until capacity scales back, and it does not guarantee the ALB can maintain sufficient healthy targets during the outage.

Increase the ALB idle timeout to 120 seconds to reduce connection drops.

Why wrong: Changing the ALB idle timeout affects long-idle TCP/HTTP connections, but it does not create additional healthy targets when one AZ is unavailable. If intermittent failures are driven by reduced capacity/instance count during the outage, idle timeout alone will not reliably fix the problem.

Disable health checks on the target group so instances are not deregistered during the maintenance window.

Why wrong: Disabling health checks prevents the ALB from removing unhealthy instances, which can increase error rates by routing to targets that are failing or overloaded. It also does not address the root resilience gap: insufficient AZ coverage in the ASG.

Place instances in private subnets but use NAT gateways so traffic to S3 and Secrets Manager goes through the internet; restrict security groups to instance-to-instance only.

Why wrong: NAT still routes traffic through the internet path and contradicts the cost and private-connectivity requirement. Restricting instance-to-instance rules does not prevent public service access through NAT.

Use public subnets with instances that have no security group rules; rely on AWS services to reject unauthorized traffic.

Why wrong: Public subnets plus missing security controls violates baseline security. Relying on AWS service rejection does not provide explicit network segmentation or deterministic access control.

Create an S3 bucket policy that allows requests from the application instances’ private IP addresses and enable public access to Secrets Manager via the default service endpoint.

Why wrong: Bucket policy cannot safely replace network-level private connectivity. Secrets Manager still requires private endpoint configuration or NAT/IGW routing for private subnets; public access contradicts requirements.

Add a condition that allows secretsmanager:GetSecretValue only when aws:SourceIp is within 10.0.0.0/8.

Why wrong: Source IP conditions cannot reliably prove that the traffic used the required Interface VPC endpoint. Requests can be translated by NAT gateways, proxies, or load balancers, and the observed Source IP may not uniquely identify the endpoint path.

Require TLS by adding a condition on aws:SecureTransport for the Secrets Manager permission.

Why wrong: aws:SecureTransport enforces that the request uses HTTPS, but it does not restrict which network path was used to reach Secrets Manager. A call could still reach the public endpoint over an unintended route while using TLS.

Add a KMS condition using kms:ViaService=secretsmanager.us-east-1.amazonaws.com instead of restricting Secrets Manager directly.

Why wrong: The kms:ViaService condition affects whether a key can be used via a particular AWS service context, but the question’s requirement is about the network path to the Secrets Manager API. This does not constrain the request to originate from the specified Interface VPC endpoint.

Enable S3 Transfer Acceleration on the bucket to reduce the number of S3 calls that go through the NAT Gateway.

Why wrong: S3 Transfer Acceleration changes how clients connect to S3 at the edge (typically for publicly addressed buckets and internet clients). It does not change the network path used by EC2 instances in private subnets. Without an S3 VPC endpoint, the instances’ traffic to S3 will still be routed to the NAT Gateway for reaching the public S3 endpoints.

Switch the EC2 instances to public subnets so S3 calls can use direct internet routing without NAT.

Why wrong: Moving instances to public subnets changes the network exposure model and does not align with the stated requirement to keep the application in private subnets. Even if S3 connectivity works, this does not directly target NAT cost drivers for private-subnet S3 access and may increase security and management overhead.

Increase the NAT Gateway TCP idle timeout so fewer connections are billed separately for S3 traffic.

Why wrong: NAT Gateway billing is based on gateway uptime (per-hour) and the amount of data processed (per-GB), not on how long TCP connections remain idle. Adjusting timeouts does not eliminate or significantly reduce the NAT data-processing charges for S3 traffic; routing S3 through a VPC endpoint is the effective approach.

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

Why wrong: 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 wrong: Changing from ALB to NLB does not address the root cause: there is no instance capacity in other AZs. Without multi-AZ compute capacity, any load balancer cannot serve traffic during the AZ outage.

Add an Amazon SQS queue to buffer requests during failures.

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

All instances in one larger subnet

Why wrong: One AZ remains a single point of failure.

A Network Load Balancer in one subnet

Why wrong: A load balancer in one AZ does not make the application resilient to AZ failure.

A single EC2 instance with detailed monitoring

Why wrong: Monitoring does not provide redundancy.

NACLs are stateful and automatically track connections; the fix is to add a new inbound rule to the security group for client source ports.

Why wrong: NACLs are stateless; connection tracking occurs at the security group level only. Adding SG inbound rules won’t unblock outbound traffic blocked by the NACL.

The issue is caused by ALB health checks; configure a new target group health check on port 80 so traffic can be routed.

Why wrong: Health checks may affect routing, but the symptom points to NACL blocking return packets. Changing health check ports won’t address NACL stateless behavior.

Because instances are in private subnets, add a NAT gateway so return traffic can reach the internet over dynamic routing.

Why wrong: NAT affects internet egress, not east-west return paths inside the VPC subnet. The observed NACL rule gap is within the subnet path.

Increase the desired capacity in AZ-a so more instances can absorb the failure of that same Availability Zone.

Why wrong: Adding more instances in the same Availability Zone does not protect against an AZ-wide outage because all of those instances fail together.

Disable health checks so the ALB stops removing targets during brief infrastructure issues.

Why wrong: Disabling health checks hides failures instead of recovering from them. The load balancer would continue sending traffic to unhealthy targets, which makes the outage worse rather than better.

Move the application to a single larger instance type so the fleet has fewer moving parts.

Why wrong: A single larger instance increases concentration risk and does not remove the Availability Zone single point of failure. It reduces the number of instances, but it also reduces redundancy.

Move the instances into a public subnet and restrict inbound access with security groups.

Why wrong: That would expose the workload to the internet, which directly violates the private connectivity requirement. Security groups do not replace the need for private network design.

Add a NAT instance and disable the managed NAT gateway to lower cost.

Why wrong: A NAT instance still sends traffic through an internet path and adds operational overhead. It does not remove public exposure for AWS service calls.

Use VPC peering to a shared services VPC and route all AWS service traffic through that VPC.

Why wrong: VPC peering does not provide native endpoints for AWS managed services and does not eliminate the internet path for those service APIs. It also adds routing complexity without solving the core problem.