4 of the 8 questions we have for this objective, shown with the answer and the reasoning.
Design and implement Azure Firewall and Azure Firewall Manager
Stonegate Holdings uses Azure Firewall Manager to govern 12 Azure Firewall Premium instances across business units. The central security team defines a base policy named afwp-base containing a network rule collection at priority 100 that denies TCP 23 (Telnet) to any destination and threat intelligence set to Alert and deny. The Finance team manages a child policy named afwp-finance that inherits afwp-base and contains a network rule collection at priority 50 that allows TCP 23 to 10.200.1.0/24 for a legacy device. After deployment, Finance reports that Telnet to 10.200.1.0/24 is blocked.
Why is the Telnet traffic blocked, and what is the correct remediation that respects central policy management?
- ARule collections inherited from the parent policy are always processed before the child policy's rule collections of the same type regardless of priority number; the central team must add the exception to afwp-base.Inheritance places parent rule collections ahead of child ones for each rule type, so the parent deny at 100 is evaluated before the child allow at 50. Exceptions to a central deny must be made centrally.
- BThe child policy's priority 50 is numerically lower than the parent's 100, so it should win; the deployment has not finished propagating and will resolve itself.Priority numbers are only compared among rule collections at the same level; a child collection can never outrank a parent collection of the same rule type.
- CThreat intelligence in deny mode is blocking Telnet because port 23 is on the malicious-port list; set threat intelligence to Alert only in afwp-finance.Threat intelligence blocks known-malicious IP addresses and domains from the Microsoft feed, not protocols or ports, and a child policy inherits the parent threat intelligence mode and cannot weaken it.
- DThe Finance team should remove the inheritance from afwp-finance so that only its own rules are applied to the Finance firewalls.Breaking inheritance restores the allow but defeats the purpose of central policy management, which the scenario requires to be respected.
Why: Azure Firewall Manager supports a hierarchy in which a child policy inherits a parent (base) policy. Rule collections inherited from the parent take precedence over rule collections of the same rule type defined in the child, regardless of the priority numbers assigned, and within each level Azure Firewall still processes DNAT, then network, then application rule collections. The parent deny for TCP 23 therefore always matches before the child allow is reached. Threat intelligence mode and some other settings are also inherited and cannot be relaxed by the child. The deciding constraint is respecting central policy management, which means the exception must be added to the base policy by the central team (for example a higher-priority allow for 10.200.1.0/24 above the deny) rather than removing inheritance. Option B describes a common misconception that priority numbers alone decide the order across parent and child.
Design and implement Azure Firewall and Azure Firewall Manager
Vantage Robotics publishes an internal jump server at 10.30.2.10 through an Azure Firewall Standard instance with public IP 20.45.100.7. The firewall policy contains: a DNAT rule collection at priority 300 translating TCP 20.45.100.7:50022 to 10.30.2.10:22 from source 203.0.113.0/24; a network rule collection at priority 100 (Deny) blocking TCP 22 from any source to 10.30.2.0/24; and an application rule collection at priority 200 (Allow) permitting Https to *.microsoft.com from 10.30.0.0/16. A partner at 203.0.113.50 connects to 20.45.100.7:50022 and the SSH session succeeds, which surprises the security team because of the deny rule at priority 100.
Why does the SSH session succeed?
- ADNAT rules are always processed before network rules regardless of rule collection priority, and a matched DNAT rule adds an implicit network rule that allows the translated traffic.Azure Firewall evaluates DNAT, then network, then application rules. The DNAT match at priority 300 wins before the deny at 100 is considered, and the implicit allow permits the translated flow to 10.30.2.10:22.
- BThe network deny rule applies only to traffic originating inside the virtual network, so inbound internet traffic is never evaluated against network rules.Network rules apply to inbound and outbound traffic alike. The reason the deny is not hit is the processing order, not the direction of the traffic.
- CThe application rule collection at priority 200 allows the session because the partner used an HTTPS-capable SSH client on a Microsoft domain.Application rules only apply to HTTP, HTTPS and MSSQL traffic that was not already matched by a network rule, and SSH on port 22 is none of those.
- DRule collections with a higher priority number are processed first, so the DNAT collection at 300 is evaluated before the network collection at 100.Within a rule type, lower priority numbers are processed first. The DNAT collection wins because of its rule type, not because 300 is greater than 100.
Why: Azure Firewall processes rules by type in a fixed sequence: DNAT rules first, then network rules, then application rules, and only within each type does the rule collection priority (100 to 65000, lowest first) and then rule order matter. Once a rule matches, processing stops; a network rule match means application rules are never evaluated for that flow. Because the DNAT rule matches the inbound packet to 20.45.100.7:50022 from 203.0.113.0/24, it translates the destination and implicitly allows the translated traffic, so the network deny at priority 100 never gets a chance. The lesson for the security team is that exposing a port through DNAT is itself an allow decision; restricting the DNAT rule source (which is already done here) is the correct control, not a later network deny. Threat intelligence in deny mode is the one check that runs before any rule, which is why it is the recommended backstop.
Design and implement Azure Firewall and Azure Firewall Manager
Wexford Global has a Virtual WAN with a hub in North Europe that connects 25 spoke virtual networks and 8 branch sites over site-to-site VPN. The company wants every internet-bound flow and every spoke-to-spoke and branch-to-spoke flow to be inspected by Azure Firewall, with the routing to the firewall configured centrally rather than by maintaining user-defined routes in each spoke. The firewall rules must be managed as a Firewall Manager policy.
What should you do?
- AConvert the hub to a secured virtual hub by deploying Azure Firewall into it through Firewall Manager, associate the firewall policy, and enable routing intent with internet and private traffic routing policies that send traffic to the firewall.A secured virtual hub is a Virtual WAN hub with Azure Firewall deployed via Firewall Manager; routing intent centrally steers internet and private traffic through the firewall without per-spoke UDRs.
- BCreate a new hub virtual network peered to the Virtual WAN hub, deploy Azure Firewall into it, and add a route table to each spoke with 0.0.0.0/0 and the private prefixes pointing to the firewall.A hub virtual network is a customer-managed VNet and requires you to maintain UDRs in every spoke, which the scenario rules out. It also does not integrate with Virtual WAN hub routing for branch traffic.
- CDeploy Azure Firewall into an AzureFirewallSubnet inside the Virtual WAN hub and add a static route in the hub default route table pointing 0.0.0.0/0 to the firewall private IP.You cannot create subnets inside a Virtual WAN hub; the hub is a Microsoft-managed resource, and the firewall is deployed into it only through Firewall Manager as a secured hub.
- DDeploy a Network Virtual Appliance in each spoke virtual network and configure Virtual WAN hub routing to forward traffic to the appliances.Per-spoke appliances multiply cost and management and do not provide the single centrally managed inspection point that Firewall Manager policy requires.
Why: Azure Firewall Manager distinguishes two architectures. A hub virtual network is a standard virtual network you create and manage, into which you deploy Azure Firewall and for which you manage routing with user-defined routes. A secured virtual hub is a Virtual WAN hub into which Firewall Manager deploys Azure Firewall, with policy association and routing handled centrally. Routing intent (with internet and private traffic routing policies) tells the hub to send internet-bound traffic and traffic between spokes and branches through the firewall without touching spoke route tables. The deciding constraints are the existing Virtual WAN, the requirement to inspect branch traffic and the prohibition on per-spoke UDR maintenance, all of which point to a secured virtual hub. Option C fails because a Virtual WAN hub does not expose subnets for customer deployments.
Design and implement Azure Firewall and Azure Firewall Manager
Rookwood Software uses an Azure Firewall Standard instance with a firewall policy named afwp-prod. Build agents in subnet 10.8.4.0/24 must be allowed to download packages over HTTPS from *.nuget.org and api.github.com, and to synchronize time with time.windows.com over UDP 123. All other outbound traffic must be denied. The security lead insists on least privilege and wants the rules to match hostnames rather than IP addresses wherever the protocol allows.
Which rules should you configure in afwp-prod?
- AAn application rule collection (Allow) with source 10.8.4.0/24, protocol Https:443, target FQDNs *.nuget.org and api.github.com; and a network rule collection (Allow) with source 10.8.4.0/24, protocol UDP, destination FQDN time.windows.com, destination port 123, with DNS proxy enabled.HTTPS to named hosts is exactly what application rules filter on, and non-HTTP protocols such as NTP must be handled by network rules, which support destination FQDNs when DNS proxy is enabled.
- BA network rule collection (Allow) with source 10.8.4.0/24, protocol TCP, destination FQDNs *.nuget.org and api.github.com, port 443; and an application rule collection (Allow) with protocol Udp:123 and target FQDN time.windows.com.Application rules support only HTTP, HTTPS and MSSQL protocols, so a UDP 123 application rule is invalid. HTTPS by hostname belongs in application rules for SNI-based matching.
- CA DNAT rule collection translating 10.8.4.0/24 to the public IP addresses of nuget.org, github.com and time.windows.com on their respective ports.DNAT rules translate inbound traffic arriving at the firewall public IP to internal destinations; they are not used for outbound filtering.
- DA network rule collection (Allow) with source 10.8.4.0/24, protocol Any, destination the Internet service tag, port 443 and 123.Allowing the entire internet on those ports permits far more than the three approved destinations and violates least privilege.
Why: Azure Firewall policy has three rule types with distinct roles. Application rules filter outbound HTTP, HTTPS and MSSQL traffic by FQDN (and FQDN tags or web categories), matching HTTPS on the SNI header without decryption. Network rules filter by IP address, service tag or, when DNS proxy is enabled, destination FQDN, on any protocol and port, which is the right place for UDP 123 to time.windows.com. DNAT rules translate inbound traffic and are irrelevant here. The least-privilege constraint rules out broad service-tag allows, and the hostname preference pushes the NTP rule toward a network rule with a destination FQDN rather than a hard-coded IP. The default behavior of Azure Firewall is to deny everything not explicitly allowed, so no separate deny rule is needed.