AZ-104 Implement and Manage Virtual Networking Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  A user-defined route that sends frontend traffic to the backend subnet.

  Why it's wrong here

  A user-defined route (UDR) changes the next-hop path for traffic; it cannot block or allow flows. Within a single VNet, Azure already routes traffic between subnets on the same virtual network, and a custom route to the backend subnet would only override that default path, not provide any filtering logic. Moreover, because both VMs are in the same subnet, a UDR cannot even distinguish the frontend VM from the backend VM at the routing layer, making it irrelevant to selecting on application role.

  When this WOULD be correct

  An administrator needs to force traffic from the frontend subnet to the backend subnet through a network virtual appliance (NVA) for inspection. A UDR with the next hop set to the NVA IP would be correct.

• ✗

  A network security group rule that references both subnets by address prefix only.

  Why it's wrong here

  An NSG rule that references both subnets by address prefix only is too broad and, in this exact topology, impossible: the frontend and backend VMs are in the same subnet, so a single subnet prefix cannot tell them apart. Even if they were in separate subnets, a prefix-based rule would apply the same access policy to every VM in those subnets, preventing any per-role or per-VM granularity. Proper least-privilege design requires identity of the workload, such as an ASG, rather than a coarse L3 prefix.

  When this WOULD be correct

  This option would be correct if the question required allowing traffic between all VMs in two subnets (e.g., allow all traffic from subnet A to subnet B on TCP 443) without needing to specify individual VM IPs. For example: 'Allow all VMs in the frontend subnet to communicate with all VMs in the backend subnet on TCP 443.'

• ✓

  Application security groups for the frontend and backend VMs.

  Why this is correct

  Application security groups (ASGs) are the correct mechanism because they let you group VM NICs by workload role (frontend or backend) and then write NSG rules that use those groups as source and destination. This works even when both tiers share the same subnet because the grouping is by application attribute, not IP topology. ASG-based rules also survive IP address changes and simplify maintenance by centralizing the role definition outside the NSG.

• ✗

  A VNet peering connection between the two tiers.

  Why it's wrong here

  VNet peering connects two separate virtual networks to enable private routing between them; it has no role in filtering traffic between tiers. Here the frontend and backend VMs are placed in the same subnet, so there is no VNet boundary to peer, and peering would not add any security policy. At best, peering changes reachability, but you still need NSG rules (typically with ASGs) to enforce which workloads may communicate.

  When this WOULD be correct

  A question where two VNets need to communicate, such as connecting a hub VNet to a spoke VNet, and the goal is to enable cross-VNet traffic without using a VPN gateway or ExpressRoute.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Go deeper

Related to this question