AZ-104 · Question #556
AZ-104 Question #556: Real Exam Question with Answer & 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.
Question
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 Environment Contoso has an Azure subscription named Sub1 that is linked to an Azure Active Directory (Azure AD) tenant. The network contains an on-premises Active Directory domain that syncs to the Azure AD tenant. The Azure AD tenant contains the users shown in the following table. Sub1 contains two resource groups named RG1 and RG2 and the virtual networks shown in the following table. User1 manages the resources in RG1. User4 manages the resources in RG2. Sub1 contains virtual machines that run Windows Server 2019 as shown in the following table No network security groups (NSGs) are associated to the network interfaces or the subnets. Sub1 contains the storage accounts shown in the following table. Requirements Planned Changes Contoso plans to implement the following changes: Create a blob container named container1 and a file share named share1 that will use the Cool storage tier. Create a storage account named storage5 and configure storage replication for the Blob service. Create an NSG named NSG1 that will have the custom inbound security rules shown in the following table. Associate NSG1 to the network interface of VM1. Create an NSG named NSG2 that will have the custom outbound security rules shown in the following table. Associate NSG2 to VNET1/Subnet2. Technical Requirements Contoso must meet the following technical requirements: Create container1 and share1. Use the principle of least privilege. Create an Azure AD security group named Group4. Back up the Azure file shares and virtual machines by using Azure Backup. Trigger an alert if VM1 or VM2 has less than 20 GB of free space on volume C. Enable User1 to create Azure policy definitions and User2 to assign Azure policies to RG1. Create an internal Basic Azure Load Balancer named LB1 and connect the load balancer to VNET1/Subnet1 Enable flow logging for IP traffic from VM5 and retain the flow logs for a period of eight months. Whenever possible, grant Group4 Azure role-based access control (Azure RBAC) read-only permissions to the Azure file shares. Hotspot Question You implement the planned changes for NSG1 and NSG2. For each of the following statements, select Yes if the statement is true. Otherwise, select No. NOTE: Each correct selection is worth one point. Answer:
Options
- __typehotspot
- variantyes_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.