Skip to main content

Technical Lab: Create and implement an Azure Firewall deployment

Questions​

Question 1 — Multiple Choice​

A team plans to deploy Azure Firewall in a hub-and-spoke architecture. The hub contains a VNet with the prefix 10.0.0.0/16. The architect needs to create the dedicated subnet for Azure Firewall within this VNet.

Which statement correctly describes the mandatory requirements for this subnet?

  • A) The subnet must be named AzureFirewallSubnet and have a minimum size of /26; NSGs can be associated with it to restrict management traffic.
  • B) The subnet must be named AzureFirewallSubnet and have a minimum size of /26; NSGs are not supported on this subnet.
  • C) The subnet can have any name, as long as it's identified as a firewall subnet during deployment, and must have a minimum size of /24.
  • D) The subnet must be named AzureFirewallSubnet and have a minimum size of /24; UDRs cannot be associated with it.

Question 2 — Technical Scenario​

An organization deploys Azure Firewall in centralized hub mode to inspect all outbound traffic from spokes to the internet. After deployment, VMs in the spokes continue accessing the internet directly, without going through the firewall. The administrator verifies that Azure Firewall is provisioned and has Running status.

Spoke VNet: 10.1.0.0/16
Hub VNet:   10.0.0.0/16
Peering:    Spoke <-> Hub (configured and active)
Firewall private IP: 10.0.1.4

What is the most likely cause of the observed behavior?

  • A) Peering between the spoke and hub doesn't automatically propagate routes; it's necessary to enable the Use Remote Gateways option in the spoke peering for traffic to be redirected to the firewall.
  • B) User Defined Routes (UDRs) were not created in the spoke subnets with a default route (0.0.0.0/0) pointing to the Azure Firewall private IP as next hop.
  • C) Azure Firewall only inspects outbound traffic when an application rule with Internet destination is configured; without it, outbound traffic is released directly by the system route.
  • D) Hub-and-spoke peering doesn't allow transitive traffic by default; to route traffic from spokes through the firewall in the hub, it's necessary to configure a VPN Gateway in the hub.

Question 3 — True or False​

Azure Firewall, when deployed without using Azure Firewall Manager, can be associated with multiple VNets simultaneously, allowing a single firewall resource to protect multiple VNets natively.

Question 4 — Technical Scenario​

A company decides to migrate from a traditional Azure Firewall deployment managed by classic rules to an architecture managed by Azure Firewall Manager with Firewall Policy. During planning, the architect identifies that there are local rules configured directly on the current firewall that conflict with the parent policy rules that will be inherited.

What is the expected behavior of Azure Firewall Manager in this policy inheritance scenario?

  • A) Parent policy rules always take precedence over local rules of the child firewall; conflicting local rules are silently ignored.
  • B) Parent policy rules are processed before child policy rules; within each policy, rule collections follow the configured priority order.
  • C) Local firewall rules take precedence over the parent policy because they are closer to the resource; the parent policy functions only as fallback.
  • D) Azure Firewall Manager doesn't allow coexistence of local rules and parent policies on the same firewall; migration requires complete removal of local rules before associating a policy.

Question 5 — Multiple Choice​

A company needs Azure Firewall to distribute inbound traffic among multiple backend servers without directly exposing the private IPs of those servers. The architect considers using DNAT rules in Azure Firewall to meet this requirement.

What is the correct limitation of Azure Firewall DNAT rules that the architect should consider in the solution design?

  • A) DNAT rules translate the public destination IP to a single private IP per rule; for load balancing among multiple backends, it's necessary to combine Azure Firewall with an internal Azure Load Balancer as the DNAT destination.
  • B) DNAT rules natively support traffic distribution among multiple destination IPs using round-robin; the limit is up to 5 IPs per rule in the Standard SKU.
  • C) DNAT rules in Azure Firewall are limited to TCP and UDP protocols, but support multiple destination IPs when combined with IP groups.
  • D) DNAT rules require destination IPs to be in the same subnet as Azure Firewall; backends in different hub subnets are not supported.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

The dedicated subnet for Azure Firewall has two mandatory and immutable requirements: the name must be exactly AzureFirewallSubnet (case-sensitive) and the minimum size must be /26. This size is necessary because Azure Firewall internally allocates multiple private IPs to support scalability and high availability.

NSGs are not supported on the AzureFirewallSubnet. Associating an NSG with this subnet can prevent proper firewall operation, as the service control plane requires unrestricted access to certain management flows. Alternative A is the most dangerous distractor because it's almost correct, but wrong in stating that NSGs are allowed. Alternative C is wrong in both name and size. Alternative D is wrong in the minimum size and incorrectly prohibits UDRs, which are supported on the firewall subnet.

Answer Key — Question 2​

Answer: B

Azure Firewall, by itself, doesn't alter the routing behavior of VNets connected by peering. To force spoke traffic to go through the firewall, it's necessary to create UDRs in the spoke subnets with a default route 0.0.0.0/0 having the Azure Firewall private IP as next hop of type Virtual Appliance. Without this configuration, VMs continue using system routes, which send internet traffic directly through the VNet's default gateway.

Alternative A confuses Use Remote Gateways with traffic redirection; this option is relevant for VPN/ExpressRoute routing, not for firewall. Alternative C is wrong: the absence of application rules doesn't release traffic, it blocks it through implicit deny. Alternative D is wrong: hub-and-spoke peering with UDRs is exactly the supported pattern for transitive traffic via firewall, without needing a VPN Gateway.

Answer Key — Question 3​

Answer: False

Azure Firewall is a resource deployed within a single VNet, specifically in the AzureFirewallSubnet of that VNet. It cannot be associated with multiple VNets simultaneously natively. To protect multiple VNets, the recommended architecture is the hub-and-spoke model, where the firewall resides in the hub and spoke traffic is routed via UDRs and peering.

Azure Firewall Manager with Virtual WAN or secured virtual hubs is the mechanism to manage multiple firewalls in multiple regions from a centralized interface, but each firewall still resides in its own VNet or hub. The statement is false because it suggests that a single resource can be natively associated with multiple VNets, which is not supported.

Answer Key — Question 4​

Answer: B

In Azure Firewall Manager, policy inheritance follows a clear hierarchy: parent policy rules are processed before child policy (local) rules. Within each policy, rule collections are evaluated in ascending numerical priority order. This means centralized organizational rules (parent policy) are applied first, and environment-specific local rules (child policy) are evaluated in sequence.

Alternative A is wrong in stating that conflicts are silently ignored; rules are processed in sequence and the first match determines the verdict. Alternative C reverses the correct hierarchy. Alternative D is wrong: Firewall Manager supports coexistence of local rules and parent policies, this being exactly the inheritance model that enables centralized governance with local flexibility.

Answer Key — Question 5​

Answer: A

Azure Firewall DNAT rules translate an inbound public IP address to a single private destination IP per rule. The feature doesn't natively support traffic distribution among multiple backends. To implement load balancing, the correct pattern is to configure DNAT pointing to the IP of an internal Azure Load Balancer, which then distributes traffic among backend servers.

Alternative B describes behavior that doesn't exist: DNAT rules don't support multiple destination IPs with round-robin. Alternative C is partially correct in mentioning TCP and UDP protocol limitation, but wrong in claiming support for multiple IPs via IP groups in DNAT context. Alternative D describes a non-existent restriction: the DNAT destination can be any private IP reachable by the firewall, regardless of subnet.