Skip to content

Quiz: AWS Networking

← Back to quiz index

6 questions

L1 (4 questions)

1. You create a /24 subnet and plan to run 250 instances. At 251, instance launch fails with 'InsufficientFreeAddressesInSubnet'. A /24 has 256 addresses. Where did the other 5 go?

Show answer AWS reserves 5 IP addresses in every subnet:
1. Network address (x.x.x.0).
2. VPC router (x.x.x.1).
3. DNS server (x.x.x.2).
4. Reserved for future use (x.x.x.3).
5. Broadcast address (x.x.x.255). So a /24 subnet gives 251 usable IPs, not
256. This scales with subnet size: a /28 (16 addresses) only has 11 usable. When planning CIDR blocks, account for these reservations plus any addresses consumed by load balancers, NAT gateways, and other AWS-managed resources that also consume subnet IPs.

2. All private subnets in your VPC route through a single NAT Gateway in us-east-1a. AZ-a has an outage. What happens to outbound internet traffic from instances in us-east-1b and us-east-1c?

Show answer All outbound internet traffic from private subnets fails because the NAT Gateway in us-east-1a is unavailable. NAT Gateways are AZ-scoped resources — they only provide HA within their own AZ. When that AZ goes down, all subnets routing through it lose internet access. Fix: deploy one NAT Gateway per AZ and configure each AZ's route table to use its local NAT Gateway. This costs more (NAT Gateway hourly charge per AZ) but provides true AZ independence. For cost savings in non-production: accept the single-AZ risk, or use a NAT Instance with a failover script (cheaper but more operational overhead).

3. You have two route table entries: 10.0.0.0/8 → Transit Gateway, and 10.0.1.0/24 → VPC Peering. Traffic to 10.0.1.50 uses which route?

Show answer The VPC Peering route wins. AWS route tables use longest-prefix match — the most specific (longest) CIDR prefix that matches the destination IP is selected. /24 is more specific than /8, so 10.0.1.50 matches 10.0.1.0/24 (VPC Peering). Traffic to 10.0.2.50 would match 10.0.0.0/8 (Transit Gateway) because there is no more specific route. If you added 10.0.1.0/25 → VPN, traffic to 10.0.1.50 (which is in the 10.0.1.0-10.0.1.127 range) would use the /25 VPN route. This is the same longest-prefix-match algorithm used in traditional IP routing.

4. Your Security Group allows all outbound traffic (0.0.0.0/0 on all ports). A compromised EC2 instance begins exfiltrating data to an external server. Should you restrict egress rules, and what is the operational trade-off?

Show answer Yes, restricting egress is a defense-in-depth best practice. Allow only:
1. HTTPS (443) to known endpoints (AWS services, your CDN, package repositories).
2. DNS (53) to VPC resolver (10.0.0.2).
3. Internal traffic to your VPC CIDR. Block everything else. Trade-offs:
1. Operational overhead — every new external dependency requires a rule update.
2. Debugging difficulty — blocked outbound traffic causes subtle failures.
3. Service discovery — if you use many AWS services, you need VPC endpoints to avoid routing through the internet. Compromise: start with allow-all in dev, restrict to known destinations in staging/prod. Use VPC Flow Logs to identify required outbound destinations before tightening rules.

L2 (2 questions)

1. Your NACL allows inbound TCP port 443 but does not have an outbound rule for ephemeral ports (1024-65535). HTTPS requests from the internet reach your instance but responses never arrive. Why?

Show answer NACLs are stateless — they evaluate inbound and outbound traffic independently, unlike Security Groups which are stateful. When a client sends a request to port 443, the response goes back on a random ephemeral port (1024-65535). The inbound rule allows the request in, but without an outbound rule allowing the ephemeral port range, the response packet is dropped by the NACL. Fix: add an outbound NACL rule allowing TCP ports 1024-65535 to 0.0.0.0/0 (or your specific CIDR). This is the most common NACL misconfiguration. Security Groups handle this automatically because they track connection state — response traffic is automatically allowed.

2. You need private access to S3 from instances without internet. What is the difference between a Gateway endpoint and an Interface endpoint for S3, and when would you choose each?

Show answer Gateway endpoint: free, added as a route table entry, traffic stays on the AWS network, only works for S3 and DynamoDB, does not get a private IP (uses S3's public IP ranges via the route table). Interface endpoint (PrivateLink): costs per hour + per GB, creates an ENI with a private IP in your subnet, works for any AWS service, supports DNS resolution to the private IP, and can be accessed from on-premises via VPN/Direct Connect. Choose Gateway for: simple S3 access from within the VPC (free, no config beyond route table). Choose Interface for: on-premises access to S3 via Direct Connect/VPN, when you need a fixed private IP for firewall rules, or when your architecture requires consistent DNS-based routing. Most VPCs should have both.