Exam AZ-700 topic 1 question 11 discussion

YYY / tested in lab VM1 and VM5 can communicate. 'Traffic to remove virtual network : Block' setting in Vnet5 does not block communication between VM5 and GW4, while it blocks communication between VM5 and VM4.

YYY, tested in lab. vnet5 peering is disabled, but remote gateway is enabled, allowing the vm5 to be accessed from other vnets. Only VM4 cannot access VM5 (peering blocked). Note that BGP needs to be configured, user routes does not work.

YYY is worked

there isn't a peering configuration for VNet3 and the default is not to allow. Wouldn't the answer be NYN

The answer is correct it is YYN tested in lab! The remote gateway and allow gateway transit only applies to Vnet peering in this case between Vnet 2 and Vnet 1, and another is between Vnet 4 and Vnet 5. Because the connection between the Vnet 1, 3, and 4 is using BGP no option to set remote gateway and transit gateway. All the routes are forwarded to Vnet 2 and Vnet 5 but because Vnet 5 is blocking the traffic to Vnet 4 VM1 can't reach VM5 but rest all can reach each other.

I think it would be NNN because the option "Use remote gateway" of VNET 1 is disabled, someone disagrees ?

Appeared on Exam 05 Sep 2023

YYY is correct

Hi everyone, I tried a lot of configuration to test the last point. With wireshark on both sides, and traffic flow always on (ping and http request), the result is quite clear even if it is not logical at the first look. When you choose the option BLOCK on one side, the entire communication is blocked. If you want to have the "expected" behavior (vm4 to vm5 ok but not the other way), you must set a NSG with an explicit rule wich allows the traffic.

YYY: for 3rd: - Select Block all traffic to the remote virtual network if you don't want traffic to flow to the peered virtual network by default. You can select this setting if you have peering between two virtual networks but occasionally want to disable default traffic flow between the two. You may find enabling/disabling is more convenient than deleting and re-creating peerings. When this setting is selected, traffic doesn't flow between the peered virtual networks by default; however, traffic may still flow if explicitly allowed through a network security group rule that includes the appropriate IP addresses or application security groups.

YYN To test the 'block' on the peering between vNet4 and vNet5 I did the following: Deployed two vNets. On the second vNet, I selected the "Block all traffic to the remote virtual network" and the Portal displays "Resources in vnet-2 cannot communicate to resources in the vnet-1" When I do a Connection Troubleshoot test, it fails with "Traffic blocked due to the following network security group rule: DefaultRule_DenyAllInBound". When I set the peering setting to "Allow (default)", the Connection Troubleshoot is successful.

To me YYN seems correct. I think the last option is a NO, bc the statement says "VM1 and VM5 can communicate" to me it implies a bidirectional communication. And the table states that Vnet 5 blocks traffic going to a differnt vnet, such as vnet1, thus (bidirectional) communication between them its not possible.

YYY seems right

This came in Dec 2022

I say YYN No becuase: Select Block all traffic to the remote virtual network if you don't want traffic to flow to the peered virtual network by default. You can select this setting if you have peering between two virtual networks but occasionally want to disable default traffic flow between the two. You may find enabling/disabling is more convenient than deleting and re-creating peerings.

YYY For the 3rd question, if you read carefully and look closely to the chart, it means Traffic to remote network from VNET5. Meaning, From VNET5 to any of the remote networks will be blocked but not inbound. This is why the answer is Yes.

YYN, for 3rd questions, does this explanation makes sense? "VM1 can reach VM4 through GW1, but not VM5 as VNEt1 does not use remote Gateways."