For AZ-305 network-security questions, network security groups (NSGs), Azure Firewall, and Azure Web Application Firewall (WAF) are three separate controls. The boundary the scenario names decides the answer. Use NSGs for subnet or network-interface allow/deny rules. Use Azure Firewall when the design needs centralized stateful network policy, egress filtering, threat intelligence, DNAT, or hub-spoke inspection. Use WAF when the risk is HTTP(S) web-app attacks such as SQL injection or cross-site scripting. Microsoft's study guide (skills measured as of April 17, 2026) lists the task "Recommend a solution to optimize network security" under Design network solutions in the Design infrastructure solutions domain, which carries 30-35% of the exam (AZ-305 study guide, AZ-305 exam page).
Compact decision shortcut
- Choose an NSG when the requirement is local traffic filtering at a subnet or NIC boundary: source, destination, protocol, port, direction, priority, and allow/deny behavior (NSG overview).
- Choose Azure Firewall when the requirement is centralized inspection or policy across VNets, subscriptions, hub-spoke networks, internet egress, non-HTTP(S) flows, DNAT, FQDN-based application rules, or threat-intelligence filtering (Azure Firewall overview).
- Choose WAF when the workload is a web app and the requirement is protection from common web exploits and vulnerabilities at the HTTP layer (Azure WAF overview).
- Use more than one when the scenario has more than one boundary. Microsoft explicitly describes Azure Firewall and Application Gateway/WAF as complementary services for network and application-layer protection (Azure Architecture Center).
The boundary diagram
The wrong answer on these questions is usually replacing a layered design with one product. An NSG can block an unexpected port on a subnet, but it does not give the same centralized egress control as Azure Firewall. Azure Firewall can filter network and application traffic, but in the Microsoft design the web-attack boundary sits on WAF, because WAF is built for HTTP-layer traffic (Azure Architecture Center). WAF protects the web application path, but it does not replace subnet-level guardrails or outbound network policy.
The three boundaries, and when each one wins
NSG: Subnet and NIC guardrail
Use an NSG when the scenario asks for traffic filtering between Azure resources in a virtual network, or when a subnet or NIC needs explicit inbound or outbound allow/deny rules. Microsoft describes NSGs as security rules that filter inbound and outbound network traffic for Azure resources in virtual networks, evaluated in priority order on the five-tuple (NSG overview).
Exam clue: "Only the application subnet should accept TCP 443 from the gateway subnet." That is an NSG-style boundary. It is local, rule-based, and tied to subnet or NIC placement.
An NSG is not the right answer for centralized FQDN egress filtering, internet-scale threat intelligence, or HTTP request inspection. NSGs are stateful. If you allow an outbound connection, you do not need a matching inbound rule for the response traffic.
Azure Firewall: Central network policy
Use Azure Firewall when the architecture needs a managed, stateful firewall service for centralized policy. Microsoft describes Azure Firewall as cloud-native, fully stateful, highly available, and scalable; Standard offers L3-L7 filtering and threat-intelligence feeds, and Premium adds IDPS capabilities (Azure Firewall overview).
Exam clue: "All spoke VNets must send outbound internet traffic through a central security service, and only approved FQDNs should be reachable." That is an Azure Firewall-style boundary. The design usually includes a hub or secured virtual hub, route tables, firewall policies, logging, and an egress allow list.
Do not confuse Azure Firewall with a web application firewall. Azure Firewall can sit in inbound and outbound designs, but in the Microsoft reference design WAF sits on the web path, because WAF is the control for common application exploits (Azure Architecture Center).
WAF: Web application attack protection
Use WAF when the scenario is about HTTP(S) applications and the risk is web-layer attacks. Microsoft says Azure WAF provides centralized protection for web applications from common exploits and vulnerabilities, including examples such as SQL injection and cross-site scripting, and can be deployed with Application Gateway, Application Gateway for Containers, Front Door, and Azure CDN (Azure WAF overview).
Exam clue: "The public web app must be protected from OWASP-style attacks while preserving Layer 7 routing." That points to WAF on Application Gateway or Front Door, depending on whether the routing requirement is regional or global. If the real question is choosing between Front Door, Application Gateway, Traffic Manager, or Load Balancer, that is a Layer 7 routing decision, and the routing choice decides where WAF sits.
Do not use WAF as the answer for SSH, RDP, custom TCP, general subnet segmentation, or outbound allow-listing. WAF is about web application traffic.
Worked scenario: public app, private admin, controlled egress
A company hosts a payment portal on VMs in a spoke VNet. Internet users reach the app over HTTPS. Administrators connect from on-premises through a private network path. Security requires three things:
- block common web attacks before requests reach the app;
- allow the web subnet to receive traffic only from the gateway tier;
- force outbound traffic from workload subnets through a central inspection point.
First pass: put WAF in the web ingress path. If the app is regional and the back ends are private, WAF on Application Gateway is a natural fit. If the app needs a global edge entry point, compare Front Door with WAF. That is a web attack boundary, not just a port boundary.
Second pass: use NSGs on the application subnets to keep local rules tight. The app subnet should accept the expected ports only from the gateway tier or approved source ranges. The database subnet should not accept random spoke traffic just because the VNet is peered.
Third pass: send outbound workload traffic through Azure Firewall by route table when the scenario asks for centralized egress control, FQDN filtering, logging, or threat-intelligence enforcement. Microsoft says a common parallel design uses WAF on Application Gateway for inbound web traffic while Azure Firewall covers outbound flows and non-HTTP(S) workloads (Azure Architecture Center).
Exam-ready answer: WAF for public web attack protection, NSGs for subnet-level guardrails, and Azure Firewall for centralized egress and non-web network inspection. If the same scenario starts talking about VPN Gateway, ExpressRoute, Virtual WAN, Private Link, or hybrid DNS, that is a transport and private-access boundary, and the answer changes with it.
What wrong answers reveal
- Choosing only an NSG for centralized egress control usually means you missed the hub-spoke policy requirement.
- Choosing Azure Firewall as the only answer for SQL injection usually means you missed the HTTP application-layer clue.
- Choosing WAF for RDP, SSH, or custom TCP usually means you mapped "firewall" to the wrong traffic type.
- Choosing WAF because Application Gateway appears in an answer choice may mean the real question was about Layer 7 load balancing, which decides where WAF sits.
- Choosing Private Link for every security problem means you drifted into private service access. A private endpoint is mapped to an instance of a PaaS resource, and access to any other resource in the service is blocked (Private Link overview). It reduces exposure to a PaaS resource, but it is not a replacement for NSGs, Firewall, or WAF.
Study drill for AZ-305
Practice changing one requirement at a time:
- If the requirement changes from "block internet inbound to a subnet" to "allow only approved outbound domains," does Azure Firewall become stronger than an NSG?
- If the requirement changes from "HTTP app attacks" to "custom TCP protocol," does WAF drop out?
- If the requirement changes from "single subnet rule" to "many spokes and subscriptions," does centralized firewall policy matter?
- If the requirement changes from "regional private web back end" to "global edge routing," do you need to revisit Front Door versus Application Gateway?
For this topic, the useful learning loop is to identify whether a wrong answer came from local filtering, centralized network policy, web-layer protection, routing, or private connectivity, then fix that one boundary instead of rereading the whole networking domain.
When you want to see which boundary is costing you points, take the free AZ-305 assessment. It returns a Readiness Report with your top gaps. In the full path, CramHQ builds your Pass Plan from your practice on CramHQ: a list of repair tasks, ordered so the gap that would cost you the most exam points comes first. As you keep answering questions, it re-checks which boundaries you still miss and re-orders the plan, so the order reflects your current misses rather than only the free assessment you took at the start. The practice tests and the timed final simulation check readiness. For AZ-305, the full path is US$34.99 for 12 months of access, and the first repair is free.