VPC practice questions

Add an internet gateway and move the instances into public subnets.

Why wrong: This changes the routing model and security exposure, but it does not reduce the amount of traffic the application sends to AWS services. It also does nothing to remove NAT-related charges for private service access.

Replace the NAT Gateway with a Site-to-Site VPN connection.

Why wrong: A VPN is meant for connectivity to on-premises or external networks. It does not eliminate the need to reach S3 and DynamoDB privately, so it does not directly solve the NAT data-processing-cost problem.

Create an interface endpoint for S3 instead of a gateway endpoint.

Why wrong: An interface endpoint can work for some S3 use cases, but it adds hourly and data-processing charges. For the specific goal of lowering NAT charges for S3 access from private subnets, the S3 gateway endpoint is the lower-cost choice.

Place a NAT gateway in the public subnet so the private instances can reach AWS services.

Why wrong: A NAT gateway sends outbound traffic to the internet and adds cost and exposure that the requirement explicitly forbids. It is not a private-only connectivity solution.

Assign public IPv4 addresses to the instances and restrict them with security groups.

Why wrong: Public IPs contradict the requirement to stay private and do not remove internet exposure. Security groups alone do not make a workload private.

Use VPC peering to the AWS service endpoints instead of VPC endpoints.

Why wrong: VPC peering is for connectivity between VPCs, not for reaching managed AWS service endpoints. It is not the right mechanism for private service access.

A Gateway VPC endpoint for secretsmanager

Why wrong: Gateway endpoints are used for certain AWS services (commonly S3 and DynamoDB). Secrets Manager uses Interface endpoints, not gateway endpoints.

A NAT gateway in the private subnet route table

Why wrong: A NAT gateway provides outbound internet egress. This contradicts the stated constraint of no NAT gateway (and, by implication, no internet routing).

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

Why wrong: VPC peering is not the mechanism used to reach AWS service endpoints like Secrets Manager. The supported approach for private access to these APIs is AWS PrivateLink interface endpoints.

Continue using the NAT Gateway but reduce CloudWatch log retention to 1 day.

Why wrong: Reducing log retention can lower CloudWatch storage costs, but it does not reduce NAT Gateway data processing charges for outbound API calls from the workload.

Launch a bastion host in a public subnet and force private instances to use SSH tunneling for API calls.

Why wrong: SSH tunneling adds complexity and does not inherently remove NAT data charges. The bastion would still require outbound connectivity paths, which typically still involve NAT if access is not otherwise endpoint-based.

Switch to public subnets and attach security groups with the same rules to limit inbound access.

Why wrong: Moving to public subnets changes the exposure model and does not satisfy the requirement to avoid traversing the public internet. It also may not reduce NAT-related billing in the intended way.

Keep the bastion host but move it into a private subnet; engineers can connect by using a corporate VPN into the VPC.

Why wrong: A bastion host remains a high-value target and still requires controlled network access. Even if the bastion is private, inbound connectivity and SSH exposure remain. Session Manager provides a more direct elimination of the bastion as well as auditability.

Attach a public IP to each private instance so engineers can SSH directly and use security groups to restrict access.

Why wrong: Public IPs for instances in private subnets defeat the private-subnet isolation and increase attack surface. While security groups could limit access, it’s still direct internet exposure rather than brokered, permissioned management via AWS SSM.

Create a security group rule that allows engineers’ source IP addresses to reach instances over RDP on port 3389.

Why wrong: Allowing RDP with IP-based controls still requires a management network path and does not remove exposure. It also doesn’t align with using AWS SSO-based authentication for secure access auditing and operational workflows.

Deploy a NAT Gateway in each Availability Zone and route artifact traffic through it.

Why wrong: A NAT Gateway would work for connectivity, but it creates exactly the cost the team wants to remove. The gateway endpoint is the cost-optimized private option.

Use the S3 static website endpoint because it automatically enforces HTTPS.

Why wrong: S3 website endpoints are not the right choice for private CI uploads and do not provide the required transport and encryption controls. They are intended for public website hosting patterns.

Expose the NLB to the internet with an Elastic IP and restrict access using the NLB’s security group only.

Why wrong: Making the NLB internet-facing violates non-public requirements, even if security groups limit allowed sources.

Use VPC peering between VPC A and the partner VPC and update route tables to resolve the overlap.

Why wrong: VPC peering cannot handle overlapping CIDRs, and route-table changes cannot resolve IP address overlap safely.

Deploy a NAT gateway in VPC A and route the partner’s traffic to the NLB through the NAT gateway.

Why wrong: NAT gateways enable outbound internet egress for instances, not private, deterministic access to internal load balancers across accounts.

Keep the NAT gateway, but add AWS WAF rules to block non-service outbound requests to reduce NAT usage.

Why wrong: WAF rules don’t control arbitrary outbound TCP connections initiated from EC2 instances. NAT gateway charges are driven by actual outbound traffic volume (data processed) and active connections, not by WAF policy. Unless the instances themselves stop making those outbound calls, the NAT gateway still processes the traffic and continues to incur charges.

Disable IPv4 on the VPC subnets and rely on IPv6-only egress to reduce NAT gateway costs.

Why wrong: NAT gateways are used specifically for private IPv4 egress to reach the internet or other networks. Switching to IPv6-only does not inherently eliminate the cost drivers for private service connectivity; it also requires a correct egress architecture for reaching AWS services and may introduce other components/changes. This does not directly address the most direct cost lever: using VPC endpoints to avoid NAT for calls to S3 and Secrets Manager.

Replace the NAT gateway with a VPC firewall appliance instance to proxy outbound calls and reduce NAT fees.

Why wrong: Using a self-managed proxy/firewall appliance adds additional compute cost, scaling/availability overhead, and operational burden (patching, upgrades, monitoring). It also does not provide the same purpose-built, service-specific private connectivity model that VPC endpoints provide for S3 and Secrets Manager, so it is unlikely to be more cost-effective than adding the correct endpoints.

Increase the instance size so each server can handle more traffic alone.

Why wrong: A larger instance may improve capacity, but it does not protect against an Availability Zone failure. If the Zone goes down, all instances in that Zone are still lost regardless of their size.

Disable ALB health checks so instances stay registered longer.

Why wrong: Health checks are useful for removing unhealthy targets quickly. Disabling them would make failover and recovery worse because the load balancer could keep sending traffic to broken instances.

Run the whole stack in one Availability Zone for simpler networking.

Why wrong: A single Availability Zone creates a clear single point of failure. Simplicity may be appealing, but it does not meet the goal of surviving a Zone outage.

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.

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.

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.

Use an Application Load Balancer because path-based routing improves throughput for binary protocols.

Why wrong: Incorrect because ALB is an HTTP/HTTPS layer-7 load balancer. Its routing features do not help a custom TCP protocol and add unnecessary protocol overhead.

Expose the service through API Gateway because it supports raw TCP and UDP pass-through.

Why wrong: Incorrect because API Gateway is for API protocols such as HTTP and WebSocket, not raw TCP or UDP pass-through. It is not the right fit for a custom binary telemetry stream.

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.

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.

Reduce the ASG desired capacity by 1 and rely on the ALB to route traffic to fewer instances during the outage.

Why wrong: Reducing desired capacity makes the ASG intentionally maintain less capacity. It does not address why instances are not being replaced, so capacity may not recover automatically to the original level after the outage.

Move the ALB to only one subnet so health checks and routing remain consistent during the outage.

Why wrong: An ALB can only route traffic through the load balancer nodes placed in the selected subnets/AZs. If the single selected subnet/AZ is affected, the ALB can become unavailable even if the ASG launches healthy instances elsewhere.

Add an S3 event trigger to terminate unhealthy instances so the ASG can scale back out using its scheduled actions.

Why wrong: S3 events do not correlate with ALB target health or Availability Zone failures for EC2 instances. Scheduled scaling actions may also not run immediately in response to health deterioration, so this approach will not directly fix the recovery mechanism.

Enable cross-zone load balancing so all targets receive traffic from every AZ.

Why wrong: Enabling cross-zone generally increases cross-AZ traffic and can raise inter-AZ transfer costs.

Move the NLB to a different Region so traffic is always kept local.

Why wrong: Changing Region does not eliminate inter-AZ traffic within the new Region and can add Region transfer costs.

Replace the NLB with a NAT gateway to reduce data charges between AZs.

Why wrong: NAT gateways affect egress to the internet; they do not control inter-AZ routing for load balancer traffic.

A NAT Gateway in the public subnet.

Why wrong: A NAT Gateway provides outbound internet access for private subnets. That violates the requirement to forbid internet egress and also adds cost and operational dependency.

An Internet Gateway attached to the VPC.

Why wrong: An Internet Gateway is used for public subnet routing and public internet access. It is unnecessary here and conflicts with the requirement to keep the workload private.

A DynamoDB gateway endpoint for the log upload path.

Why wrong: A DynamoDB endpoint is only for DynamoDB traffic. It does not help with S3 log uploads or Secrets Manager retrieval.

Add a public DNS entry in the instance /etc/hosts pointing Secrets Manager to the instance’s private IP so requests do not leave the VPC.

Why wrong: Secrets Manager is not reachable by mapping it to arbitrary private IPs; you need an AWS-managed private endpoint or NAT/internet for real service routing.

Attach an internet gateway to the private route table so that Secrets Manager traffic can reach public endpoints without NAT.

Why wrong: An internet gateway on a private route table effectively makes the subnet internet-reachable, violating the stated NAT-free and tightened network requirement.

Enable S3 VPC endpoint and store the secrets in an S3 bucket instead of Secrets Manager, then retrieve them using S3 gateway endpoints.

Why wrong: This changes the service and does not solve the Secrets Manager connectivity failure. It also weakens secret lifecycle controls provided by Secrets Manager.

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.

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.