Skip to main content

Technical Lab: Create and implement Azure Firewall Manager policies

Questions​

Question 1 — Multiple Choice​

An organization maintains a parent Firewall Policy called policy-global with network and application rules that apply to all environments. A development team creates a child policy called policy-dev that inherits from policy-global. The engineer responsible for the development team wants to add a rule in policy-dev that allows traffic that policy-global explicitly denies. What is the expected behavior?

A) The allow rule in policy-dev prevails over the deny rule in policy-global because child policies have precedence over parent policies.

B) Parent policy rules are evaluated before child policy rules; therefore, the deny rule in policy-global will block traffic before the allow rule in policy-dev is reached.

C) Azure Firewall Manager detects the conflict and automatically disables the conflicting rule in the child policy until the inconsistency is manually resolved.

D) The allow rule in policy-dev is evaluated first because child policies are more specific and Azure Firewall prioritizes specificity over inheritance.

Question 2 — Technical Scenario​

A company uses Azure Firewall Manager to manage firewalls in a hub-and-spoke topology. The administrator needs to block access to a category of malicious URLs across all managed firewalls, but also allow specific exceptions for a set of domains that are incorrectly classified. The base policy already contains application rules for general traffic.

policy-base (parent)
  └── Application rule: block-malicious
        Target: Web categories = Malicious
        Action: Deny

policy-regional (child of policy-base)
  └── Application rule: allow-exception
        Target: legitimate-partner.com
        Action: Allow

What is the resulting behavior for requests to the domain legitimate-partner.com?

A) The domain will be allowed because the allow rule in the child policy is evaluated before inherited rules from the parent policy.

B) The domain will be blocked because parent policy rules are evaluated first and the block-malicious rule matches the traffic before the child policy exception is reached.

C) The behavior depends on the numerical priority assigned to the rule collections; without seeing the priority numbers, it's not possible to determine the result.

D) The domain will be allowed because allow rules always take precedence over deny rules when both match the same destination, regardless of the policy source.

Question 3 — Multiple Choice​

When creating a Firewall Policy in Azure Firewall Manager, an engineer needs to decide between using Rule Collections organized in Rule Collection Groups and understand how priority between them affects evaluation. Which statement correctly describes the evaluation hierarchy within a single Firewall Policy?

A) Rules are evaluated in order: rule type (DNAT, network, application) first, and within each type, by Rule Collection Group priority and then by Rule Collection priority.

B) Rules are evaluated exclusively by numerical priority assigned to each individual rule, without considering grouping in Rule Collections or Rule Collection Groups.

C) Rule Collection Groups are evaluated by priority, but within each group all Rule Collections are evaluated simultaneously, and the most restrictive action prevails.

D) Rule Collections are evaluated by global priority across all groups, without hierarchy between Rule Collection Groups and individual Rule Collections.

Question 4 — Technical Scenario​

An administrator creates a Firewall Policy Premium associated with an Azure Firewall Premium and enables TLS inspection. For the inspection to work, he configures an intermediate CA certificate stored in Azure Key Vault. After configuration, he verifies that HTTPS connections to some destinations continue without inspection, while others are inspected normally.

What is the most likely cause for this selective behavior?

A) Azure Firewall only inspects TLS connections when the destination is explicitly listed in an application rule with TLS inspection option enabled in the rule collection.

B) Some destinations are in the TLS inspection bypass list configured in the policy, which allows excluding specific categories or FQDNs from inspection without disabling it globally.

C) TLS inspection silently fails for destinations using certificate pinning, and Azure Firewall treats them as allowed traffic without inspection to avoid false blocks.

D) The intermediate CA certificate was not distributed to all clients; destinations whose clients don't trust the intermediate certificate have their connections ignored by the inspection mechanism.

Question 5 — True or False​

A Firewall Policy of type Standard can be converted to type Premium directly in the Azure portal, allowing enabling features like TLS inspection and IDPS on existing firewalls without needing to recreate the policy or associated firewall.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Explanation:

  • In the Azure Firewall Manager inheritance model, parent policy rules are always evaluated before child policy rules. This ensures that central administrators maintain effective control over base policies. A child policy can add rules, but cannot bypass or override decisions already made by the parent policy.
  • Alternative A reverses the hierarchy: child policy specificity does not grant evaluation precedence. The order is determined by position in the inheritance tree, not by rule scope.
  • Alternative C describes non-existent behavior: Firewall Manager does not automatically detect conflicts or disable conflicting rules. The configuration is accepted, but the evaluation result may surprise those who don't understand the evaluation order.
  • The practical consequence of choosing A or D would be assuming that local teams can create exceptions to corporate policies, which invalidates the centralized governance model of Firewall Manager.

Answer Key — Question 2​

Answer: B

Explanation:

  • The evaluation order between parent and child policy is deterministic: parent policy rules are evaluated first. The block-malicious rule in policy-base matches traffic to legitimate-partner.com (if classified as malicious by the web category), and the Deny action is applied before the allow-exception rule in policy-regional is considered.
  • Alternative A is the most common error on this topic: assuming that the child policy, being more specific or more recent, has precedence over the parent. This directly contradicts the Firewall Manager inheritance model.
  • Alternative C would be true if both rules were in the same policy, where numerical priority of collections would determine evaluation. But in parent/child policies, inheritance hierarchy supersedes numerical priority.
  • Alternative D describes non-existent behavior: Azure Firewall does not have "allow beats deny" logic based on action alone; the first matching rule ends evaluation.

Answer Key — Question 3​

Answer: A

Explanation:

  • Within a single Firewall Policy, evaluation follows a two-level hierarchy: first, rule type (DNAT before network, network before application); then, within each type, rules are evaluated by Rule Collection Group priority (lower number = higher priority) and, within each group, by Rule Collection priority.
  • Alternative B denies the grouping structure, which is central to Firewall Manager design for organization and policy delegation. Ignoring groups would make managing complex policies with multiple teams unfeasible.
  • Alternative C introduces the concept of simultaneous evaluation with most restrictive action, which doesn't exist in Azure Firewall: the first matching rule ends evaluation; there's no comparison of actions between multiple matches.
  • Alternative D denies the hierarchy between groups and collections, which would make the Rule Collection Group concept irrelevant, contradicting the purpose of this structure in the product.

Answer Key — Question 4​

Answer: B

Explanation:

  • Azure Firewall Manager allows configuring a TLS inspection bypass list within the Firewall Policy Premium. This list specifies FQDNs, web categories, or IP ranges that should be excluded from TLS inspection, even when inspection is globally enabled. This is used for destinations like financial services, healthcare, or partners that don't accept man-in-the-middle, without needing to disable inspection for all traffic.
  • Alternative A describes incorrect behavior: TLS inspection in Azure Firewall Premium is applied to traffic that matches application rules allowing the traffic; it doesn't require a per-rule option to be activated.
  • Alternative C describes behavior that Azure Firewall doesn't implement: there's no automatic certificate pinning detection logic with fallback to allow without inspection. Connections with certificate pinning may fail if the intermediate certificate is inserted.
  • Alternative D describes a legitimate cause of TLS failure from the client perspective, but wouldn't explain why the firewall inspects some connections and selectively ignores others; this symptom is characteristic of configured bypass.

Answer Key — Question 5​

Answer: False

Explanation:

  • It's not possible to convert a Standard Firewall Policy to Premium directly. Standard and Premium policies are distinct types and immutable after creation. To use Premium features (TLS inspection, IDPS, Web Categories), you must create a new Firewall Policy of Premium type and associate it with an Azure Firewall Premium.
  • This limitation has relevant operational impact on migrations: both the policy and firewall need to be Premium type for exclusive features to work. A Premium policy associated with a Standard firewall, or vice versa, doesn't enable Premium features.
  • The common misconception is extrapolating the behavior of other Azure resources that support in-place upgrade (like Public IP SKUs or VPN Gateway) to Firewall Policies, where this operation doesn't exist.