Exam Professional Cloud Architect topic 1 question 183 discussion

VPC peering cannot be established between VPCs if there is IP range overlap. C is ok since you can establish VPN across these VPCs and only include the applications required IP ranges as its mentioned that they do not overlap

VPC peering is generally possible even if there are overlapping subnets between the two VPCs. However, there are some considerations to keep in mind if there's overlapping subnets: 1. You will not be able to route traffic between the overlapping subnets. If needed, you will have to use a different method (such as a Cloud VPN connection or a Cloud Router) to connect the VPCs. 2. You will need to ensure that the overlapping subnets are not used by any resources in either VPC. This means that you will need to either modify the existing network configuration to avoid using the overlapping subnets, or you will need to create new subnets that do not overlap. 3. You may need to update any existing firewall rules or routes that refer to the overlapping subnets to ensure that they are still valid after the VPCs are peered. In the question, you want to provide private network connectivity between the two companies' applications, which are not on overlapping subnets. However, there is overlap in the subnets used by both companies, which means that you will not be able to use VPC peering to connect the two VPCs.

c -> https://cloud.google.com/vpc/docs/using-vpc-peering#no_subnet_ip_range_overlap_across_peered_networks

No subnet IP range overlap across peered VPC networks https://cloud.google.com/vpc/docs/using-vpc-peering

looks like the following best practice: https://cloud.google.com/architecture/best-practices-vpc-design#shared-service Cloud VPN is another alternative. Because Cloud VPN establishes reachability through managed IPsec tunnels, it doesn't have the aggregate limits of VPC Network Peering. Cloud VPN uses a VPN Gateway for connectivity and doesn't consider the aggregate resource use of the IPsec peer. The drawbacks of Cloud VPN include increased costs (VPN tunnels and traffic egress), management overhead required to maintain tunnels, and the performance overhead of IPsec.

It seems to be C because VPN peering use BGP protocol that manages the overlaps. https://cloud.google.com/network-connectivity/docs/vpn/how-to/configuring-peer-gateway

omermahgoub said it best. C

B to reorg it all under one org cos it's a mess. You cant have shared RFC1918 ranges between peered networks OR VPNs... Don't know why everyone thinks VPNs avoid that problem. https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn2 "You can connect two VPC networks together as long as the primary and secondary subnet IP address ranges in each network don't overlap."

Please check answer from BalaGCPArch "https://cloud.google.com/vpc/docs/vpc-peering#overlapping_subnets_at_time_of_peering Overlapping subnets at time of peering At the time of peering, Google Cloud checks to see if there are any subnets with overlapping IP ranges between the two VPC networks or any of their peered networks. If there is an overlap, peering is not established. Since a full mesh connectivity is created between VM instances, subnets in the peered VPC networks can't have overlapping IP ranges as this would cause routing issues."

Answer is C A is wrong because you cannot peer VPCs with overlapping subnets: https://cloud.google.com/vpc/docs/vpc-peering#interaction-subnet-subnet IPv4 subnet routes in peered VPC networks can't overlap: - Peering prohibits identical IPv4 subnet routes. For example, two peered VPC networks can't both have an IPv4 subnet route whose destination is 100.64.0.0/10. - Peering prohibits a subnet route from being contained within a peering subnet route. For example, if the local VPC network has a subnet route whose destination is 100.64.0.0/24, then none of the peered VPC networks can have a subnet route whose destination is 100.64.0.0/10. B and D are ruled out because it breaks the requirement "with minimal re-engineering" to the applications

A is ok: The applications are not on overlapping subnets. So use VPC peering. You want to provide connectivity with minimal re-engineering. VPC Network Peering accomplishes this. https://cloud.google.com/vpc/docs/vpc-peering

C is correct answer

C is best option

These applications ARE NOT on overlapping subnets

the answer is A

Can someone explain my why not B? It's fine to eliminate A due to overlapping and also D because is out of discussion, but why C is better than B?

Google Documentation " When a VPC subnet is created or a subnet IP range is expanded, Google Cloud performs a check to make sure the new subnet range does not overlap with IP ranges " I know the subnets where the application is hosted, does not overlap, however it will not allow a VPC peering because of that overlap, so the only possible answer is C. https://cloud.google.com/vpc/docs/vpc-peering