Exam Professional Cloud Network Engineer topic 1 question 67 discussion

Answer is B & D. B: Minimizes cost and quickly. D: You need to create firewall rules to allow traffic between subnets over each VPC.

B and D 100% -First of all, we only have 2 separate VPCs in 2 different projects each where each project resides in the same organization. This set-up already yells that we need NW peering! -In addition, to be able to use a Shared VPC we need to delete existing service project resources and recreate them in the shared VPC subnet, which is something the question statement does not want, so Shared VPC is automatically eliminated -Lastly, with nw peering, the subnet routes of both VPCs are automatically shared, but we still need to create firewall rules to allow incoming requests for both ends. Hence B and D

B and D

B & D are the best bet

This question is confusing - It clearly states in the document (https://cloud.google.com/vpc/docs/vpc-peering): You can't disable the subnet route exchange or select which subnet routes are exchanged. After peering is established, all resources within subnet IP addresses are accessible across directly peered networks. VPC Network Peering doesn't provide granular route controls to filter out which subnet CIDR ranges are reachable across peered networks. You must use firewall rules to filter traffic if that's required. This is why to me D doesn't make sense as they want unfettered access between their subnets for the 2 projects (FW rules only required for granular access).

Along with VPC-Peering we will need firewall rules also in place to allow unrestricted communication across two VPCs.

Key point is STEP SHOULD BE FOLLOWED 1st VPC peering 2nd Allow firewall policy b/w 2 VPCs ==== Cloud VPN is one option but it will increase the cost.

B D are correct

DDDDDDD&&&&&&&&BBBBBBBBBB

Answer is : B and D

Answer is B & D.

it B and D https://cloud.google.com/vpc/docs/vpc-peering#firewall When you connect networks using VPC Network Peering, firewall rules are not exchanged between them. To allow ingress traffic from VM instances in a peer network, you must create ingress allow firewall rules. By default, ingress traffic to VMs is blocked by the implied deny ingress rule. If you need to restrict access to VMs such that only other VMs in your VPC network have access, ensure that the sources for your ingress allow firewall rules only identify VMs in your VPC network, not ones from peer networks. For example, you can specify source IP ranges for just the subnets in your VPC network. To restrict access to an internal TCP/UDP load balancer, create ingress firewall rules that apply to the load balancer's backend VMs.

Has to be A and B. D would not work as VPCs are in different projects, allowing all traffic would expose resources on it externally, you can't allow the subnet private ranges as it would reach the VPC with an external IP through Internet and not the source subnet private IP ranges.

B and D

How about A and B?

B and D,

I'm sure about B, not that sure about D...but it's the only other option -by exclusion- that makes sense to me