AZ-104 · Question #556
Case Study 5 - Contoso, Ltd Overview General Overview Contoso, Ltd. is a consulting company that has a main office in Montreal and branch offices in Seattle and New York. Environment Existing…
The correct answer is From VM1, you can establish a Remote Desktop session to VM2. = Yes; From VM2, you can ping VM3. = Yes; From VM2, you can establish a Remote Desktop session to VM3. = No. Subnet-level NSGs evaluate all traffic entering and leaving the VMs in that subnet, including intra-subnet traffic, which dictates the success or failure of RDP and Ping connections.
Question
Exhibits
Answer Area
- From VM1, you can establish a Remote Desktop session to VM2.Yes
- From VM2, you can ping VM3.Yes
- From VM2, you can establish a Remote Desktop session to VM3.No
Explanation
Subnet-level NSGs evaluate all traffic entering and leaving the VMs in that subnet, including intra-subnet traffic, which dictates the success or failure of RDP and Ping connections.
Approach. The question evaluates network connectivity after the 'Planned Changes' are implemented. Based on this standard AZ-104 case study, VM1 resides in VNET1/Subnet1, while VM2 and VM3 reside in VNET1/Subnet2. The planned changes apply NSG2 to Subnet2, and NSG2 contains a custom rule that DENIES outbound TCP port 3389 (RDP traffic).
- 'From VM1... RDP to VM2': Yes. Traffic originates from Subnet1 (no outbound block) and enters Subnet2. NSG2's custom rule only blocks outbound 3389; inbound RDP from VM1 is permitted by the default 'AllowVnetInBound' rule.
- 'From VM2... ping VM3': Yes. Both VMs are in Subnet2. Ping uses the ICMP protocol, which is unaffected by the TCP 3389 block. It is allowed by default VNet NSG rules and the default intra-subnet Windows Firewall rules.
- 'From VM2... RDP to VM3': No. When VM2 attempts to RDP into VM3, the traffic must first leave VM2. Subnet2's NSG2 evaluates this outbound traffic. Because NSG2 explicitly denies outbound TCP 3389, the connection is blocked from leaving VM2, even though the destination (VM3) is in the exact same subnet.
Common mistakes.
- common_mistake. A frequent misconception is that NSGs attached to a subnet only filter traffic crossing the subnet's perimeter (entering from or leaving to another subnet/network). In Azure, subnet-attached NSGs evaluate ALL traffic passing through the network interfaces of the VMs within that subnet, including intra-subnet communication. Test-takers often mistakenly assume VM2 and VM3 can freely communicate over RDP simply because they share the same subnet.
Concept tested. Network Security Group (NSG) rule evaluation, inbound vs. outbound traffic flow boundaries, and intra-subnet micro-segmentation behavior.
Reference. https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
Topics
Community Discussion
No community discussion yet for this question.

