AZ-500 Secure 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.

• ✗

  Use service endpoints for each tier.

  Why it's wrong here

  Service endpoints are designed to secure outbound access from a subnet to specific Azure PaaS services by binding the subnet's identity, but they do not provide any mechanism to filter traffic between subnets within the same VNet. Even if you enabled service endpoints on each tier's subnet, traffic from the web tier to the app tier would still be allowed by default, because service endpoints do not inspect packets or enforce rules based on ports or protocols. The only way to isolate tiers is to apply traffic filtering rules, which service endpoints cannot do. Therefore, this option entirely fails to address the requirement for network isolation between subnets.

• ✗

  Create separate VNets for each tier and use VNet peering.

  Why it's wrong here

  Creating separate VNets and using peering fails here because the question explicitly states all tiers reside in different subnets of the *same* VNet. This option fundamentally contradicts that design constraint, as VNet peering connects distinct virtual networks, not subnets within a single VNet. It is tempting because peering is the correct solution for securely connecting applications or services distributed across multiple, isolated virtual networks, particularly when strong administrative or subscription separation is required.

• ✗

  Deploy Azure Firewall in the VNet and route all traffic through it.

  Why it's wrong here

  Azure Firewall is a managed, stateful firewall that can inspect and filter inter-subnet traffic, but deploying it here would require adding a dedicated firewall subnet, creating user-defined routes to force all traffic through the firewall's private IP, and paying hourly and data-processing fees for every packet. This approach is significantly overengineered and costly for the simple task of isolating three tiers within a single VNet, where NSGs can enforce the same allowed flows at no charge and with no routing changes. Azure Firewall is better suited for perimeter security, internet-bound traffic inspection, or centralized logging and should complement NSGs rather than replace them. Thus, it is a valid but impractical solution for this requirement.

• ✓

  Configure NSGs on each subnet with appropriate allow rules.

  Why this is correct

  Network Security Groups are the native Azure mechanism for filtering traffic between subnets, as they contain stateful rules that allow or deny traffic based on source and destination IP, port, and protocol. By assigning a distinct NSG to the web, app, and data subnets, you can explicitly permit only the necessary flows—for instance, web tier to app tier on port 443, and app tier to data tier on port 1433—while blocking all other traffic by default. NSGs are applied directly to subnets or NICs, incur no additional cost, and require no custom routing, making them the most efficient and cost-effective solution for east-west traffic isolation within a VNet. This aligns with Azure's defense-in-depth guidance of securing every subnet with an NSG.

Go deeper

Related to this question