These questions cover VPC connectivity architecture and troubleshooting — the highest-weighted topics on ANS-C01 and where the exam tests design trade-offs rather than just feature recognition.
Question 1
A company has 50 VPCs across three AWS accounts that all need to communicate with each other and share a single egress point to the internet. Which architecture is most operationally scalable?
- A) VPC peering between every pair of VPCs (full mesh)
- B) Transit Gateway with a shared egress VPC and a default route
- C) VPC sharing via AWS Resource Access Manager for all 50 VPCs
- D) A hub-and-spoke VPN with a customer-managed router
Answer: B — Transit Gateway with a shared egress VPC
VPC peering is non-transitive and doesn't scale. A full mesh of 50 VPCs requires 1,225 peering connections (n*(n-1)/2), each managed independently. Transit Gateway (TGW) acts as a regional hub: each VPC attaches once, and routing is managed centrally via TGW route tables.
The scalable pattern:
- All 50 VPCs attach to Transit Gateway
- Spoke VPCs have a default route (
0.0.0.0/0) pointing to TGW - TGW routes internet-bound traffic to an egress VPC containing NAT Gateways
- Inspection VPC (optional) sits inline for centralized firewall inspection
| Approach | Max connections | Transitive routing | Central management |
|---|---|---|---|
| VPC Peering | n*(n-1)/2 | No | No |
| Transit Gateway | Thousands | Yes | Yes |
VPC sharing via RAM shares subnets into other accounts but doesn't solve routing between 50 VPCs.
</details>Question 2
A company uses AWS Direct Connect with a private VIF to reach their VPCs. After adding a new VPC, the on-premises network cannot reach it. What is the most likely cause?
- A) Direct Connect only supports a single VPC per private VIF
- B) The new VPC's CIDR has not been advertised to the Direct Connect gateway or virtual private gateway
- C) Direct Connect requires a new physical connection for each additional VPC
- D) The new VPC is in a different Availability Zone than the Direct Connect connection
Answer: B — The new VPC's CIDR isn't being advertised
AWS advertises VPC CIDR blocks to on-premises via BGP over the Direct Connect connection. When you add a new VPC, routing doesn't happen automatically — the VPC must be associated with the Direct Connect Gateway (DXGW) or Virtual Private Gateway (VGW), and the CIDR must be included in the allowed prefixes.
Common Direct Connect routing issues:
| Cause | Symptom | Fix |
|---|---|---|
| VPC not attached to DXGW | No route to new VPC | Associate VPC with DXGW |
| Allowed prefixes not updated | Route not advertised to on-prem | Update allowed prefixes on DXGW association |
| BGP not established | No routes at all | Check BGP neighbour state |
| Overlapping CIDRs | Traffic routed incorrectly | Resolve CIDR conflicts |
Direct Connect connections support multiple VPCs via DXGW with Transit Gateway or multiple private VIFs.
</details>Question 3
A security team reports that an EC2 instance in a private subnet cannot reach an S3 VPC endpoint. CloudWatch shows no dropped traffic at the NACL level. What tool should you use to diagnose the connectivity path?
- A) VPC Flow Logs filtered on the instance ENI
- B) AWS Network Manager topology view
- C) VPC Reachability Analyzer with the instance as source and the S3 endpoint as destination
- D) AWS CloudTrail to check API calls from the instance
Answer: C — VPC Reachability Analyzer
Reachability Analyzer performs a logical network path analysis between a source and destination without sending actual traffic. It evaluates route tables, NACLs, security groups, and gateway configurations and returns either a reachable path or the specific component causing the block.
For an S3 gateway endpoint issue, it would identify whether:
- The route table lacks an entry for the S3 prefix list pointing to the endpoint
- A security group outbound rule is blocking port 443
- A NACL rule is blocking the traffic (despite CloudWatch showing nothing at the NACL level — Reachability Analyzer uses configuration analysis, not traffic counters)
Networking diagnostic tools:
| Tool | Method | Best for |
|---|---|---|
| Reachability Analyzer | Configuration analysis | Diagnosing blocked paths without sending traffic |
| VPC Flow Logs | Packet metadata logging | Seeing what traffic actually flowed or was dropped |
| Traffic Mirroring | Packet capture | Deep packet inspection |
Flow Logs tell you what happened; Reachability Analyzer tells you what the configuration says should happen.
</details>Key Takeaways
- Transit Gateway scales to thousands of VPCs with transitive routing; VPC peering requires n*(n-1)/2 connections and is non-transitive
- New VPCs on Direct Connect need explicit CIDR advertisement via DXGW allowed prefixes — it doesn't happen automatically
- Reachability Analyzer diagnoses path configuration without sending traffic; Flow Logs show what actually traversed the network