SOA-C02 Networking and Content Delivery Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  The route tables in both VPCs do not have routes to the peer VPC CIDR.

  Why this is correct

  For a VPC peering connection to function, each VPC must have an explicit route in its route table that targets the peering connection (pcx-*) and points to the peer VPC's CIDR block. Even if the peering connection is in the 'active' state, traffic will be dropped at the source VPC if no such route exists, because the source instance has no path to the destination CIDR. Both route tables must be updated for bidirectional communication; a missing route on either side breaks connectivity for traffic originating in that direction, and ICMP ping is a common test that will fail immediately without these routes.

• ✗

  VPC peering does not support cross-account connections.

  Why it's wrong here

  AWS VPC peering fully supports cross-account connections, allowing VPCs in different AWS accounts to communicate privately as long as the VPCs are in the same region (or different regions with inter-region peering). To establish peering, the requester sends a request to the accepter account, and the accepter must approve it; each account must also authorize the peering attachment in their own route tables. Therefore, cross-account peering is not a limitation and cannot be the cause of connectivity failure, provided the request is accepted and IAM permissions are correctly configured.

• ✗

  The CIDR blocks overlap, causing routing conflicts.

  Why it's wrong here

  The scenario explicitly states that the VPC CIDR blocks are non-overlapping, so route conflicts due to overlapping ranges are impossible. Even if the CIDRs did overlap, VPC peering would not allow communication because the route tables would have ambiguous destinations, and AWS would not permit the peering connection to be used for overlapping ranges. Since the problem provides non-overlapping CIDR blocks, this option is irrelevant; if there were an overlap, the peering connection would either fail to route or be rejected, but that is not the situation here.

• ✗

  The security groups in VPC-B do not allow inbound ICMP traffic from VPC-A.

  Why it's wrong here

  Security groups can indeed block ICMP traffic if no inbound rule allows it, but security groups are only evaluated after the packet reaches the network interface of the destination instance. If the route tables in the VPCs lack routes to the peer CIDR, the packet is discarded at the router level before it ever reaches the security group, so the ping would time out regardless of security group rules. Additionally, security groups are stateful, but they still require an explicit inbound rule for ICMP; however, this is a secondary issue that would only surface after routing is correctly configured. Therefore, missing routes are the most probable and first cause to investigate, not security group configuration.

Go deeper

Related to this question