Networking and Content Delivery practice questions

VPC IPv6 addresses are globally unique and publicly routable, so IPv6 has no NAT. The egress-only internet gateway is the IPv6 construct for outbound-only access: instances can initiate connections out, and all inbound-initiated traffic is blocked.

Routing ::/0 to an egress-only internet gateway gives the instances outbound IPv6 access while its stateful behavior blocks anything the internet initiates. A NAT gateway is wrong because it handles IPv4 only; a standard internet gateway is wrong because it exposes the publicly routable IPv6 addresses to inbound connections; and a gateway endpoint only reaches S3 and DynamoDB, not internet repositories.

1. Create an egress-only internet gateway and attach it to the VPC.
2. In the private subnets' route tables, add a route sending ::/0 to the egress-only internet gateway.
3. Verify security groups and NACLs permit the outbound traffic and (for NACLs) the ephemeral-port return traffic.
4. Confirm instances can reach the repositories while inbound IPv6 connection attempts fail.

Exam tip: "IPv6, outbound only" always maps to an egress-only internet gateway — there is no IPv6 NAT.

Gateway VPC endpoints support exactly two services — Amazon S3 and DynamoDB — and are free: no hourly fee and no data-processing fee. They work by inserting a managed prefix-list route into the route tables you select, steering service traffic through the endpoint instead of the internet path.

A gateway endpoint satisfies both constraints at once: the traffic stays on the AWS network and the endpoint costs nothing, eliminating the NAT data-processing charges for S3 traffic. An interface endpoint is private but billed hourly plus per GB, a second NAT gateway compounds the cost problem, and Transfer Acceleration is a paid performance feature that still uses public endpoints.

1. Create a gateway VPC endpoint for the S3 service in the VPC.
2. Select the private subnets' route tables during creation so AWS inserts the prefix-list route.
3. Optionally attach an endpoint policy restricting access to approved buckets.
4. Verify S3 traffic flows through the endpoint and NAT data-processing charges for it disappear.

Exam tip: "Private S3 access at no additional cost" is always a gateway VPC endpoint — the classic fix for NAT data-processing spend.

AWS Shield Standard is automatic and free for every AWS customer, absorbing common layer 3 and 4 DDoS attacks at the edge with nothing to configure. Shield Advanced is the optional paid tier that adds enhanced detection, cost protection against DDoS-driven scaling charges, and access to the Shield Response Team.

The accurate audit answer is that Shield Standard already covers common network-layer floods at no cost. Shield Advanced is never on by default, WAF operates at layer 7 and does not absorb SYN floods, and Network Firewall inspects routed VPC traffic rather than providing automatic edge DDoS defense.

1. Identify the attack layer in the question: SYN floods and UDP reflection are layer 3/4 events.
2. Map layer 3/4 DDoS absorption to AWS Shield — Standard is automatic and free.
3. Reserve Shield Advanced for requirements like cost protection or the Shield Response Team.
4. Keep WAF (layer 7 web requests) and Network Firewall (routed VPC inspection) in their own lanes.

Exam tip: Shield Standard is automatic and free for layer 3/4 DDoS; Shield Advanced is a paid, opt-in upgrade.

Every VPC has one main route table, and each subnet uses exactly one route table. Subnets with no explicit association fall back to the main table. Creating a custom route table does nothing for a subnet until you associate the subnet with it.

The instances have public IPs and the custom table has the IGW route, so the missing piece is the association: the new subnet is defaulting to the main table, which has no IGW route. The local route cannot be missing (it is automatic and unremovable), internet gateways attach to the VPC rather than living in subnets, and IPv6 egress has nothing to do with inbound IPv4 access.

1. Check which route table the subnet actually uses — an unassociated subnet shows the main table.
2. Associate the subnet explicitly with the custom route table containing the 0.0.0.0/0 route to the IGW.
3. Confirm the instances hold public IPv4 or Elastic IP addresses.
4. Retest reachability, then review security groups and NACLs if it still fails.

Exam tip: A custom route table does nothing until the subnet is associated with it — unassociated subnets silently use the main route table.

When multiple routes in a table match a destination, the VPC router uses the most specific (longest) prefix: a /32 beats a /16, which beats 0.0.0.0/0. The unremovable local route always handles intra-VPC traffic for the VPC's own CIDR.

172.16.40.9 matches both 0.0.0.0/0 and 172.16.0.0/16, and the /16 is more specific, so traffic goes to the peering connection. The default-route answer ignores longest-prefix matching, "dropped" wrongly treats overlap as a conflict, and the local route only covers 10.0.0.0/16.

1. List every route whose prefix contains the destination address.
2. Compare prefix lengths — the longest prefix (largest number after the slash) wins.
3. Here 172.16.0.0/16 beats 0.0.0.0/0, so the peering connection carries the packet.
4. Remember the same logic explains why a gateway-endpoint prefix route diverts S3 traffic away from a NAT default route.

Exam tip: VPC routing always picks the most specific matching prefix — the default route only carries what nothing narrower claims.

A NAT gateway is an AZ-resident appliance. The resilient production pattern is one NAT gateway per AZ, with each private subnet routing to the NAT in its own AZ, so no AZ depends on another AZ's gateway.

Per-AZ NAT gateways with AZ-local routes are the only listed option that removes the cross-AZ dependency: losing AZ A then affects only AZ A. "Multi-AZ mode" does not exist for NAT gateways, a second gateway in the same AZ shares the same failure domain, and a NAT gateway in a private subnet has no path to the internet at all.

1. Create a public subnet (if needed) and a NAT gateway with an Elastic IP in each AZ.
2. Give each AZ's private subnets their own route table.
3. In each route table, send 0.0.0.0/0 to the NAT gateway in the same AZ.
4. Verify egress per AZ, and note the trade-off: three hourly charges instead of one, in exchange for AZ independence and no cross-AZ data fees.

Exam tip: NAT gateways are zonal — high availability means one per AZ, each serving only its own AZ's subnets.