Exam Professional Cloud Architect All Questions

View all questions & answers for the Professional Cloud Architect exam

Exam Professional Cloud Architect topic 1 question 183 discussion

Actual exam question from Google's Professional Cloud Architect

Question #: 183
Topic #: 1

[All Professional Cloud Architect Questions]

Your company recently acquired a company that has infrastructure in Google Cloud. Each company has its own Google Cloud organization. Each company is using a Shared Virtual Private Cloud (VPC) to provide network connectivity for its applications. Some of the subnets used by both companies overlap. In order for both businesses to integrate, the applications need to have private network connectivity. These applications are not on overlapping subnets. You want to provide connectivity with minimal re-engineering. What should you do?

A. Set up VPC peering and peer each Shared VPC together.
B. Migrate the projects from the acquired company into your company's Google Cloud organization. Re-launch the instances in your companies Shared VPC.
C. Set up a Cloud VPN gateway in each Shared VPC and peer Cloud VPNs.
D. Configure SSH port forwarding on each application to provide connectivity between applications in the different Shared VPCs.

Show Suggested Answer

Suggested Answer: C 🗳️

by EricG77 at Sept. 4, 2022, 2:19 p.m.

Comments

Submit Cancel

6721sora

Highly Voted 2 years, 3 months ago

Selected Answer: C

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

upvoted 29 times

...

jlambdan

Highly Voted 1 year, 7 months ago

Selected Answer: C

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.

upvoted 9 times

...

Pime13

Most Recent 10 months, 2 weeks ago

Selected Answer: C

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

upvoted 2 times

...

Ahmed_Safwat

1 year ago

Selected Answer: C

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

upvoted 3 times

...

kratosmat

1 year, 8 months ago

Selected Answer: C

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

upvoted 4 times

...

HD2023

1 year, 8 months ago

Selected Answer: C

omermahgoub said it best. C

upvoted 1 times

...

rr4444

1 year, 9 months ago

Selected Answer: B

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."

upvoted 1 times

BiddlyBdoyng

1 year, 6 months ago

This applies to static routes only. "A dynamic route can overlap with a subnet route in a peer network. For dynamic routes, the destination ranges that overlap with a subnet route from the peer network are silently dropped. Google Cloud uses the subnet route.". https://cloud.google.com/vpc/docs/vpc-peering

upvoted 1 times

...

RVivek

1 year, 10 months ago

Selected Answer: C

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."

upvoted 1 times

...

omermahgoub

1 year, 11 months ago

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.

upvoted 9 times

omermahgoub

1 year, 11 months ago

One solution in this case would be to set up a Cloud VPN gateway in each Shared VPC and peer Cloud VPNs. This will allow you to create a secure, private network connection between the two VPCs, and it will allow the applications in each company's Shared VPC to communicate with each other over the private connection. The correct answer is C: Set up a Cloud VPN gateway in each Shared VPC and peer Cloud VPNs. Option A: Setting up VPC peering and peering each Shared VPC together would not be a viable solution in this case, because the subnets used by both companies overlap, and VPC peering does not support overlapping subnets.

upvoted 11 times

...

colombrican

2 years ago

Selected Answer: C

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

upvoted 1 times

...

megumin

2 years ago

Selected Answer: A

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

upvoted 4 times

BalaGCPArch

2 years ago

C should be the Answer : same explaination goes here "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."

upvoted 6 times

enado

1 year, 5 months ago

Thanks for this

upvoted 1 times

...

Mahmoud_E

2 years, 1 month ago

Selected Answer: C

C is correct answer

upvoted 1 times

...

AzureDP900

2 years, 2 months ago

C is best option

upvoted 1 times

...

charlie_lee

2 years, 2 months ago

Selected Answer: A

These applications ARE NOT on overlapping subnets

upvoted 2 times

SerGCP

2 years, 2 months ago

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.

upvoted 3 times

...

sTree100

2 years, 2 months ago

the answer is A

upvoted 1 times

...

kiappy81

2 years, 3 months ago

Selected Answer: B

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?

upvoted 1 times

zellck

2 years, 3 months ago

you need minimal re-engineering. migrating projects and relaunching instances will be a significant effort.

upvoted 5 times

...

alexandercamachop

2 years, 3 months ago

Selected Answer: C

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

upvoted 1 times

...

Load full discussion...