SOA-C02 Router R1 Cannot Reach R3 Practice Questions

Explanation: For a NAT gateway to work, it must be placed in a public subnet that has a route to an internet gateway. The NAT gateway uses the internet gateway to send traffic to the internet. The most common oversight is that the public subnet's route table does not have a default route pointing to an internet gateway. Without this, the NAT gateway cannot forward traffic to the internet. While a NAT gateway requires an Elastic IP, it must be assigned during creation; the question states the NAT gateway was configured, so an EIP was likely attached. Network ACLs are default-allowed, so they are not typically the issue.

Explanation: VPC peering is the simplest and most cost-effective way to connect two VPCs in the same region. It uses the AWS network and provides high throughput. AWS Transit Gateway is a hub-and-spoke solution better suited for many VPCs. AWS Direct Connect and AWS VPN CloudHub are primarily for hybrid connectivity and add unnecessary complexity and cost.

Explanation: VPC peering does not support overlapping CIDR blocks. AWS Transit Gateway supports multiple VPC attachments and can route traffic based on route tables, but it still cannot resolve overlapping IP addresses; you cannot have two VPCs with identical CIDR blocks communicating directly because the Transit Gateway would not know which VPC to forward traffic to for a given IP. However, the question says VPC A and VPC B both have 10.0.0.0/16, and they do not need to communicate directly. VPC C has 10.1.0.0/16, so VPC C is unique. VPC A and VPC B can each connect to VPC C as long as they use different route tables. But the overlapping CIDR issue still exists: if VPC A sends traffic to an IP in 10.0.0.0/16, Transit Gateway would route based on the most specific route; but since both VPC A and VPC B use the same CIDR, the Transit Gateway cannot distinguish. However, for traffic from VPC A to VPC C (which is 10.1.0.0/16) there is no conflict. Similarly from VPC B to VPC C. The problem arises if VPC A wants to reach an IP in 10.0.0.0/16 that might be in VPC B, but that is not required. Transit Gateway can handle this by using different route tables for VPC A and VPC B: each route table will have a route for 10.1.0.0/16 pointing to the VPC C attachment, and a route for the local VPC's CIDR pointing to the local attachment (or blackhole). But VPC A's route table might have a route for 10.0.0.0/16 pointing to local, but if VPC A tries to reach an IP in 10.0.0.x, it will be routed locally within VPC A. So Transit Gateway can work. However, AWS recommends that for overlapping CIDRs, you use solutions like NAT or PrivateLink, but Transit Gateway has limitations. The better answer for today's AWS architecture is to use AWS PrivateLink to allow VPC A and VPC B to access services in VPC C via Network Load Balancer endpoints. This avoids routing issues due to overlapping CIDRs and is scalable. Transit Gateway with Network Manager could work, but overlapping CIDRs are not recommended and require careful route table design and may cause asymmetric routing. The question says 'supports growing number of VPCs' - Transit Gateway is designed for that. But given the overlapping CIDR issue, PrivateLink or VPN might be more appropriate. However, PrivateLink requires services in VPC C to be exposed via NLB and endpoints in VPC A and B. This is a valid solution and avoids CIDR overlap. AWS PrivateLink supports inter-VPC communication without peering or transit gateway, and it works with overlapping CIDRs because it uses private IP addresses in the endpoint's subnet. So this is likely the correct answer. Option: Use AWS PrivateLink with Network Load Balancers in VPC C and VPC endpoints in VPC A and VPC B. That meets all requirements.

Explanation: VPC Peering connections across regions do not support reflexive DNS resolution by default. By enabling 'DNS resolution' from the requester VPC and 'DNS hostname' in the accepter VPC, instances can resolve private DNS names of peered VPC instances, which may lead to more direct routing. However, cross-region VPC peering traffic is routed through AWS backbone, but DNS resolution can affect whether the private IP of the instance is used or if traffic goes via public internet. Increasing MTU might help but the issue is likely DNS resolution. Transit Gateway does not inherently reduce latency across regions. The ECMP (Equal-cost multi-path routing) is not applicable to VPC peering.

Explanation: AWS Transit Gateway supports separate route tables. By attaching each VPC to a specific route table, you can control which VPCs can communicate. Overlapping CIDRs require route tables to be isolated to avoid conflicts, and VPCs that need isolation should not share the same route table.