Deepen your understanding of advanced VPC peering, including routing, security, transitivity, and peering limitations. This quiz is designed to help users grasp key concepts essential for effective and secure VPC interconnections.
In a network setup where VPC A is peered with VPC B, and VPC B is peered with VPC C, can VPC A communicate directly with VPC C through peering connections?
Explanation: VPC peering is inherently non-transitive, which means that even if both VPC A and C are peered with B, they cannot automatically communicate with each other. Choosing 'Yes, traffic will automatically route' and 'Yes, if the correct route tables are set up' is incorrect, as route tables cannot create transitive relationships between VPCs. The availability zone does not affect transitivity, making that distractor incorrect. Direct communication requires a separate peering connection between A and C.
Why can't two VPCs with overlapping CIDR blocks be peered together?
Explanation: Peering two VPCs with overlapping CIDR ranges would result in ambiguous network routes, leading to routing conflicts. The protocols used or Equal Cost Multi-Path are not relevant to the basic requirement for distinct address ranges. The statement about public subnets is incorrect, as peering applies to all subnets, not just public ones. Thus, avoiding overlapping CIDRs is essential for ensuring clear routing.
After creating a VPC peering connection, what is the next necessary step to enable resource communication across peered VPCs?
Explanation: Even after a peering connection is established, resources can communicate only if the route tables in both VPCs are updated to allow traffic to the corresponding CIDR blocks. Activating NAT gateways or installing firewalls is unnecessary for peering communication. Restarting instances is not required and has no effect on peering connectivity. Using correct routing enables resources to communicate successfully.
What is the primary difference between same-region and inter-region VPC peering?
Explanation: Inter-region VPC peering often results in extra data transfer charges due to cross-region communication. Same-region peering does not always encrypt traffic by default, and both can support similar protocols depending on configuration. Peering communications use private IP addresses, not public, making that distractor incorrect.
If a VPC has reached its maximum number of allowed peering connections, what can be done to establish more connections?
Explanation: The correct action when hitting the peering connection limit is to request a limit increase, which raises the cap. Deleting subnets or increasing instance size does not affect the peering connection limit. Changing the CIDR block is unrelated to limits and may introduce other issues. The quota is controlled as a soft limit by provider configuration.
Which setting must be enabled to allow private DNS names to resolve for peered VPC resources?
Explanation: To allow private DNS resolution for resources across VPC peerings, DNS resolution must be enabled in the peering connection's settings. Assigning Elastic IPs or using VPNs are unnecessary for DNS resolution in this case. Modifying network ACLs alone will not enable private DNS resolution unless the explicit setting is configured.
Can resources in a peered VPC access the internet through the other VPC's internet gateway?
Explanation: Internet gateways are tied to individual VPCs and are not usable across peering connections. Updating route tables does not permit sharing gateways. Inter-region peering does not change this limitation, and enabling NAT only affects private to public traffic within a VPC. Resources must use their own VPC's internet gateway for outbound traffic.
Why is tagging VPC peering connections considered a best practice?
Explanation: Tagging peering connections assists with managing, identifying, and fostering organization, especially in environments with many connections. Tags do not affect performance or security, making faster peering and default encryption incorrect. Tags are metadata for resource management, not a security or speed feature.
What must be considered about security group rules when setting up VPC peering?
Explanation: When peering VPCs, security group rules need to explicitly allow access from the CIDR range of the peered VPC to enable communication. Assuming all traffic is allowed or that security groups are disabled is incorrect and risky. Both inbound and outbound rules may need adjusting, so focusing on only inbound is not sufficient.
Does creating a VPC peering connection automatically update all route tables to allow traffic between VPCs?
Explanation: Peering connections by themselves do not update any route tables—administrators must manually add route entries to enable traffic. There is no automatic update or propagation to subnet routes. Route tables never update themselves after a delay in response to peering connections. Only explicit configuration allows peered traffic.