Skip to main content

Technical Lab: Design an Azure Firewall deployment

Questions​

Question 1 — Multiple Choice​

An organization needs to deploy Azure Firewall in a hub-and-spoke architecture with 12 spoke VNets distributed across two regions. The central requirement is that firewall policies be managed centrally, with regional variations for environment-specific rules. Which combination of Azure Firewall features meets this requirement?

A) Deploy one Azure Firewall per spoke and use local Firewall Policy on each instance, without inheritance between policies.

B) Create a base Firewall Policy with global rules and derive regional child policies that inherit and extend the rules from the parent policy.

C) Use a single global Firewall Policy associated with all firewalls, adding region tags to filter rules during evaluation.

D) Deploy Azure Firewall Manager as a separate instance in each region and manually synchronize policies between instances.

Question 2 — Technical Scenario​

A team designs the Azure Firewall deployment in a hub VNet. The subnet intended for the firewall was created with the name AzureFirewallSubnet and a /26 prefix. After deployment, the team realizes they cannot associate an NSG to this subnet to add an extra layer of ingress control.

Subnet name  : AzureFirewallSubnet
Address space: 10.0.0.0/26
NSG          : nsg-firewall (association attempt failed)

What is the cause of this limitation?

A) The /26 prefix is insufficient for Azure Firewall; the minimum required is /24, and Azure blocks NSG association on undersized subnets.

B) The AzureFirewallSubnet does not support NSG association by design, as Azure Firewall itself manages traffic control on this subnet.

C) The NSG needs to be created in the same availability zone as Azure Firewall before being associated with the subnet.

D) NSGs can only be associated with AzureFirewallSubnet when Azure Firewall is in Premium SKU; Standard SKU does not support this feature.

Question 3 — Multiple Choice​

When designing an Azure Firewall with availability zone support, an architect needs to understand the implications for the associated public IP address. Which statement correctly describes the requirement for the public IP in this scenario?

A) The public IP can be Basic SKU, as Azure Firewall internally manages redundancy across zones without dependency on IP SKU.

B) The public IP must be Standard SKU and have zone redundancy enabled to support firewall deployment across multiple availability zones.

C) Each availability zone requires a dedicated public IP; therefore, a deployment across three zones mandatorily requires three distinct public IPs.

D) The public IP must be Standard SKU, but zone redundancy is configured exclusively on Azure Firewall and not on the public IP resource.

Question 4 — Technical Scenario​

A company needs Azure Firewall to inspect outbound TLS traffic from VMs to the internet, identifying threats in HTTPS connections. The firewall was deployed with Standard SKU and an associated Firewall Policy. The responsible engineer tries to enable TLS inspection, but the option is not available in the policy.

What is the correct cause of the limitation encountered?

A) TLS inspection requires Azure Firewall to be deployed in a Virtual WAN hub (Secured Virtual Hub), not in a conventional VNet.

B) TLS inspection is not available in Standard SKU; this feature is exclusive to Premium SKU, which offers IDPS and TLS inspection mechanisms.

C) TLS inspection requires prior configuration of an intermediate CA certificate in Key Vault, and the option is blocked until this dependency is satisfied.

D) The Firewall Policy needs to be at Premium level to enable TLS inspection, regardless of the deployed Azure Firewall SKU.

Question 5 — True or False​

In Azure Firewall, application rules are evaluated before network rules when both match the same outbound traffic, because application rules operate at a higher layer and have precedence by design.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Explanation:

  • Azure Firewall Manager supports policy inheritance: a parent Firewall Policy contains global rules (common to all environments), and child policies inherit these rules, being able to add specific regional or environment rules without modifying the base policy. This model is exactly what the requirement describes: centralized governance with local flexibility.
  • Alternative A eliminates centralized management by isolating policies per instance, directly contradicting the requirement.
  • Alternative C is incorrect because Azure Firewall Policy does not have a tag filtering mechanism during rule evaluation; tags are used for resource organization, not for rule segmentation.
  • Alternative D confuses Azure Firewall Manager with a separable and replicable instance; Firewall Manager is a management plane, not a firewall instance per region.

Answer Key — Question 2​

Answer: B

Explanation:

  • The AzureFirewallSubnet is a subnet with platform restrictions: NSGs cannot be associated with it. This limitation exists because Azure Firewall has its own traffic control mechanism and associating an NSG could interfere with traffic processing by the firewall, generating unpredictable behaviors or unwanted blocks.
  • Alternative A is partially incorrect: the minimum prefix for AzureFirewallSubnet is /26 (not /24), so the subnet in the scenario is correctly sized. The subnet size is not the cause of the problem.
  • Alternative C is incorrect because availability zones are configured during firewall deployment and do not affect the ability to associate NSGs with the subnet.
  • Alternative D is a plausible distractor, but incorrect: the NSG restriction on AzureFirewallSubnet applies to all Azure Firewall SKUs, not just Standard.

Answer Key — Question 3​

Answer: B

Explanation:

  • When Azure Firewall is deployed with availability zone support, the associated public IP must be Standard SKU and must have zone redundancy property enabled. Zone-redundant public IPs are replicated across physically separate zones, ensuring the address remains accessible even in case of zone failure.
  • Alternative A is incorrect because Basic SKU public IPs do not support availability zones; Standard SKU is mandatory.
  • Alternative C represents a common misconception: one public IP per zone is not necessary; a single Standard IP with zone redundancy covers all three zones simultaneously.
  • Alternative D is subtly incorrect: zone redundancy must be configured on the public IP resource, not just on Azure Firewall. If the public IP does not have zone redundancy enabled, the multi-zone firewall deployment will not have the expected resilience in the addressing plane.

Answer Key — Question 4​

Answer: B

Explanation:

  • TLS inspection is an exclusive feature of Azure Firewall Premium SKU. Standard SKU does not have the IDPS inspection engine nor the capability to perform TLS man-in-the-middle for encrypted content inspection. To enable this feature, both Azure Firewall and the associated Firewall Policy need to be Premium type.
  • Alternative A is incorrect: TLS inspection is available in both conventional VNet deployments and Secured Virtual Hub, as long as Premium SKU is used.
  • Alternative C describes a real dependency (the CA certificate in Key Vault is necessary to configure TLS inspection), but it is not the cause of the described block: the option does not even appear because the SKU does not support the feature, not because a dependency is pending.
  • Alternative D represents a partial misconception: Premium Firewall Policy is necessary, but the root cause is the firewall SKU, not just the policy. Both need to be Premium; the policy alone does not solve the problem if the firewall is Standard.

Answer Key — Question 5​

Answer: False

Explanation:

  • In Azure Firewall, the rule evaluation order is: DNAT rules first, then network rules, and lastly application rules. Network rules are evaluated before application rules, not the other way around.
  • This order is counterintuitive because, in traditional layer 7 firewalls, application rules usually have precedence. In Azure Firewall, the logic is different: if a network rule allows traffic, it does not reach application rule evaluation.
  • The practical consequence of this misconception is relevant: an administrator who creates a permissive network rule believing that application rules will refine it will be exposed to uninspected traffic, as the network rule will be evaluated and satisfied before application rules are considered.