AZ-305 Design infrastructure solutions 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.

• ✗

  Place all VMs in the same subnet and use a single Azure Load Balancer to distribute traffic.

  Why it's wrong here

  This design eliminates any network segmentation between application and database tiers, so an attacker who compromises the web tier can directly reach backend databases on open ports, and a single public-facing load balancer exposes all VMs to the internet, including the data tier. An Azure Load Balancer (L4) only performs TCP/UDP distribution; it cannot provide layer-7 filtering, URL routing, or web application firewall protection, and it gives no mechanism to restrict traffic between tiers within the same subnet.

• ✗

  Use separate VNets for each tier and connect them with VNet peering.

  Why it's wrong here

  Creating a separate VNet for each tier and interconnecting them with VNet peering introduces unnecessary overhead: peering is non-transitive, so you must manage multiple peering connections and complex network security groups across VNets, and you cannot leverage a single Azure Application Gateway in front of all tiers without additional hub infrastructure. Subnets inside one VNet already provide isolation with full control via NSGs and allow an application gateway to sit in the same VNet, giving the same security benefit at far lower complexity and cost.

• ✗

  Deploy all VMs in a single subnet and use Azure Firewall to inspect all inbound and outbound traffic.

  Why it's wrong here

  Placing every VM in a single subnet collapses compartmentalization and forces Azure Firewall to act as a central inspection point for all traffic if you add complex user-defined routes; however, Azure Firewall is a managed stateful network firewall, not a substitute for subnet isolation, so you lose the ability to apply different NSG policies per tier and you incur significant cost for features that could be handled by simpler subnet-level NSGs. Furthermore, Azure Firewall does not provide web application firewall capabilities, so you still need an Application Gateway or other WAF device, making this design both expensive and architecturally flawed.

• ✓

  Deploy all tiers in the same VNet with separate subnets, and use NSGs to restrict traffic. Place an Azure Application Gateway with WAF in front of the web tier.

  Why this is correct

  This architecture separates each application tier into its own subnet and applies per-subnet NSG rules to allow only required communication (e.g., web-to-app on port 443, app-to-data on port 3306), ensuring that a compromise in one tier does not implicitly expose another. An Azure Application Gateway with its WAF sits in a dedicated gateway subnet, providing the single internet-facing HTTPS endpoint, SSL offload, cookie-based session affinity, path-based routing, and OWASP Top-10 protection—all before traffic reaches the web tier. This is the recommended pattern because it balances security and operational simplicity.

Go deeper

Related to this question