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 VPC A do not have a route to VPC B's CIDR.

  Why it's wrong here

  The claim that route tables in VPC A lack a route to VPC B's CIDR is contradicted by the fact that ping succeeds. ICMP packets traveling from VPC A to VPC B require a route in VPC A's route table targeting the VPC peering connection for VPC B's CIDR, and a corresponding return route in VPC B's route table. If either route were missing, ping would fail due to packet drop. Since connectivity works, the route tables are correctly configured for network traffic, so they cannot be the cause of failed DNS resolution.

• ✗

  The security groups in VPC B block DNS traffic (port 53).

  Why it's wrong here

  Security groups in VPC B cannot block DNS traffic (port 53) in this scenario because DNS queries across a VPC peering connection are handled by the VPC's built-in DNS resolver (available at the VPC CIDR base plus two, or the Route 53 Resolver), not by the instances themselves. When an instance in VPC A resolves a private DNS name for an instance in VPC B, the query is sent to the DNS resolver in VPC A, which then uses the peering connection to resolve the name. Security groups are virtual firewalls applied to instance ENIs and only filter traffic destined to or originating from those instances; they do not intercept control-plane traffic to the VPC DNS service. Therefore, security groups on VPC B instances are irrelevant to cross-VPC DNS resolution.

• ✓

  The VPC Peering connection does not have 'Enable DNS Resolution' enabled.

  Why this is correct

  The correct issue is that the VPC peering connection does not have the 'Enable DNS Resolution' option enabled. AWS VPC peering does not automatically allow private DNS hostnames from the peer VPC to be resolved; you must explicitly enable this option on the peering connection. Specifically, the VPC owner must set 'Allow DNS resolution from peer VPC' (or 'Enable DNS Resolution') for the requester VPC to query names from the accepter VPC, and a corresponding option is needed for the reverse direction. Without this setting, the VPC DNS resolver ignores the peering connection when resolving private hostnames, causing DNS resolution to fail even though raw IP connectivity (like ping) works perfectly. This is a common, nuanced misconfiguration that is invisible to basic connectivity tests.

• ✗

  The VPCs have overlapping CIDR blocks.

  Why it's wrong here

  Overlapping CIDR blocks would prevent the VPC peering connection from being established in the first place, because AWS requires that peered VPCs have non-overlapping address ranges to avoid ambiguous routing. If the CIDRs overlapped, the peering connection request would be rejected or the connection could not function. Since ping works, the peering connection is active and functional, which is impossible with overlapping CIDRs. Thus, overlapping CIDR cannot explain a DNS resolution failure in an already-established peering, and the actual cause must be a configuration specific to DNS, such as the peering DNS resolution option.

Go deeper

Related to this question