Your company has a project in Google Cloud with three Virtual Private Clouds (VPCs). There is a Compute Engine instance on each VPC. Network subnets do not overlap and must remain separated. The network configuration is shown below.
Instance #1 is an exception and must communicate directly with both Instance #2 and Instance #3 via internal IPs. How should you accomplish this?
In order to achieve connectivity between Instance #1 and both Instance #2 and Instance #3 without merging the VPCs or creating transit routes, adding additional network interfaces (NICs) to Instance #1 is an effective solution. This allows Instance #1 to have direct access to the subnets in VPC #2 and VPC #3 while keeping the network subnets separate. By configuring each NIC with the appropriate VPC and subnet, Instance #1 can communicate with the other instances using internal IP addresses. Updating firewall rules is necessary to ensure that traffic can pass between the instances securely. This configuration adheres to the requirement that only Instance #1 needs to communicate with Instance #2 and Instance #3 directly.
According to my understanding the requirement is that only VM1 shall be able to communicate with VM2 and VM3, but not VM2 with VM3. We can exclude d) as d) would enable VM2 to communicate with VM3 as well - my assumption is, that if the quizzer wanted that d) is the correct answer, he would make just 2 peerings - 1x between VM1 and VM2 and 1x between VM1 and VM3 repectively the VPCs. We can exclude c) as well - there is no connection between VPC1 and VPC3. IMHO a) will not work. So the only correct answer seems to be b) - what I don't understand is why we have to update the firewall rules as IMHO the default firewall rules enable such communication (maybe some restrictive rules are implemented - not enough details in the question to clarify that part). Please correct me if I am wrong.
Correct, maybe fw on the VM
I think it is because the instances are in separate VPCs. "Google Cloud Virtual Private Cloud (VPC) networks are by default isolated private networking domains. Networks have a global scope and contain regional subnets. VM instances within a VPC network can communicate among themselves using internal IP addresses as long as firewall rules permit. However, NO INTERNAL IP ADDRESS COMMUNICATION IS ALLOWED BETWEEN networks, unless you set up mechanisms such as VPC Network Peering or Cloud VPN." The instructions for setting up multiple interfaces tells you to check your firewall rules as as the firewall rules of the VPC apply to the network interface that it is attached to. https://cloud.google.com/vpc/docs/multiple-interfaces-concepts#firewall_rules_and_multiple_network_interfaces
The answer is "B". The following link has this - "Use multiple network interfaces when an individual instance needs access to more than one VPC network, but you don't want to connect both networks directly." https://cloud.google.com/vpc/docs/multiple-interfaces-concepts
you can not add additional network interface to existing VM's
The answer is "B". The following link has this - "Use multiple network interfaces when an individual instance needs access to more than one VPC network, but you don't want to connect both networks directly." https://cloud.google.com/vpc/docs/multiple-interfaces-concepts
B will not work. VM instances within a VPC network can communicate among themselves using internal IP addresses as long as firewall rules permit. However, no internal IP address communication is allowed between networks, unless you set up mechanisms such as VPC Network Peering or Cloud VPN.
this link says VM can have multiple NICs and attached to different VPCs. https://cloud.google.com/vpc/docs/create-use-multiple-interfaces so B is the answer
Answer is B
Instances are exist. You can not add or remove additional NICs to a VM
- A seems incomplete and not compliant with "network subnets must remain separated" requirement. - B makes no sense, because if you add NICs with IPs of other subnet, the firewall rules are not needed. Therefore, typically this type of configuration is considered a safety hole. - D is incorrect because peering is not transitive. - So, remains only C.
As stated here, You should check firewalls rules because it will be applied to the NIC. check this https://cloud.google.com/vpc/docs/multiple-interfaces-concepts#firewall_rules_and_multiple_network_interfaces
B will not work. accroding to https://cloud.google.com/vpc/docs/create-use-multiple-interfaces , You can only configure a network interface when you create an instance. You cannot add or remove network interfaces from an existing VM.
All answers are incorrect: subnets do not overlap and must remain separated. => can't choose A or C or D. Which leaves us with A: you can't attach nics to a compute engine instance after creation : see: https://cloud.google.com/vpc/docs/create-use-multiple-interfaces
B is ok. C&D are wrong because they connect 1 to 2 and 2 to 3 , not 1 to3. 2 and 3 must be unreachable
B is wrong. NIC can only be configured while creating the instance. Here the instance is already created. C is correct answer. Refer limitation in this link: https://cloud.google.com/vpc/docs/create-use-multiple-interfaces
B would be incorrect --> As without VPC peering or VPN it will not come into Play. D --> This is good as once VPN is established from 1 --> 2 and from 2 --> 3 ... data can flow from 1 to 3 via 2 ...
I mean C should be correct ..
Only solution is peering. N1 peering to n3 and n3 to n1 makes all network peered. So answer should be D
best practice is to add NIC to first instance
B is the correct answer, Connect the VPC1 instance to VPC2 instance with NIC1 and Connect VPC1 instance to VPC3 instance with NIC2. And update firewall rules to enable traffic between them. https://cloud.google.com/vpc/docs/multiple-interfaces-concepts#firewall_rules_and_multiple_network_interfaces
B: NIC usecase when an individual instance needs access to more than one VPC network, but you don't want to connect both networks directly https://cloud.google.com/vpc/docs/multiple-interfaces-concepts
I vote for B: VPC peering does not support "cascading". Peer VPC 1 with VPC 2, and VPC 2 with VPC 3 does not allow traffic from VPC 1 to VPC 3.
Is D the correct, peering with adeguate forewall rule for only communication of Instance 1 with Instance 2 and 3
Router, VPN and VPC Peering for all 3 network is not required. Only option B solves the given scenario.
Option B allows you to add additional NICs to Instance #1, each connected to a different VPC, facilitating direct communication between Instance #1 and the other instances while maintaining separate subnets.
B for sure
VPC peering will allow access to instance 2 & 3 from 1 with internal IP, with necessary firewall rules added.