Troubleshooting Lab: Map requirements to features and capabilities of Azure Firewall
Diagnostic Scenarios
Scenario 1 — Root Cause
A security team deployed Azure Firewall Premium in a centralized connectivity hub. The firewall is configured with a hierarchical firewall policy: a parent policy defined by the corporate security team and a child policy managed by the application team.
The environment has the following elements:
- Parent policy with network rules blocking traffic between spokes by default
- Child policy with an application rule allowing
*.storage.azure.comon port 443 - IDPS enabled in Alert and Deny mode
- A user-defined route (UDR) in the spoke pointing the next hop to the firewall's private IP
- Threat Intelligence configured in Alert Only mode
Developers report that HTTPS calls to minhaconta.blob.core.windows.net are being blocked, even after creating the application rule in the child policy. The firewall logs show:
Action: Deny
Rule Collection: Default Deny
Rule: DeniedByDefault
Target FQDN: minhaconta.blob.core.windows.net
Protocol: HTTPS:443
Source: 10.1.2.5
The network team confirms that the UDR is correctly applied and that traffic is reaching the firewall. The Azure subscription has 12 other firewalls in production, all with Standard SKU.
What is the root cause of the observed blocking?
A) IDPS in Alert and Deny mode is intercepting and blocking TLS traffic before the application rule is evaluated.
B) The application rule in the child policy is being overridden by the parent policy, because network rules in the parent policy take precedence over application rules in the child policy.
C) The application rule uses *.storage.azure.com, but the target FQDN belongs to the core.windows.net domain, so the pattern doesn't match the actual destination.
D) Threat Intelligence in Alert Only mode doesn't block traffic, but logs a false positive that appears in the log as Deny.
Scenario 2 — Action Decision
The root cause has been identified: a company's Azure Firewall Standard needs to inspect outbound traffic from virtual machines to the internet, but the security team requires that the firewall decode and inspect the content of TLS sessions to detect malware in HTTPS downloads.
The operational context is as follows:
- The current firewall is Standard SKU, deployed 18 months ago in production
- No maintenance window is available in the next 72 hours
- The environment uses a classic firewall policy, without hierarchy
- The security team formally approved the requirement and registered the ticket
- A valid intermediate CA certificate is available in Azure Key Vault
What is the correct action to take at this time?
A) Enable TLS inspection directly in the current firewall policy, pointing to the certificate in Key Vault, without changing the SKU.
B) Upgrade the firewall to Premium SKU and enable TLS inspection in the policy, taking advantage of the opportunity window before the 72 hours.
C) Document the requirement as pending and wait for the next maintenance window to perform the upgrade to Premium and configure TLS inspection.
D) Create a second firewall with Premium SKU in parallel, gradually migrate traffic and enable TLS inspection on the new resource without affecting the current environment.
Scenario 3 — Root Cause
An organization uses Azure Firewall to control outbound traffic from a workload subnet to the internet. The firewall is configured with the following rules:
Network rule (priority 100):
Name: Allow-DNS
Source: 10.2.0.0/16
Destination: 8.8.8.8
Port: 53/UDP
Action: Allow
Application rule (priority 200):
Name: Allow-Updates
Source: 10.2.0.0/16
Target FQDNs: windowsupdate.microsoft.com, update.microsoft.com
Protocol: HTTPS:443
Action: Allow
Servers in subnet 10.2.1.0/24 cannot download Windows updates. The operations team verifies that DNS resolution is working correctly: nslookup windowsupdate.microsoft.com returns valid IPs from the VMs. Ping to 8.8.8.8 also works. Azure Monitor shows the firewall is healthy and processing traffic normally. The workload subnet has no NSG applied.
Firewall log:
Action: Deny
Rule: DeniedByDefault
Source IP: 10.2.1.15
Destination IP: 13.107.4.52
Destination Port: 443
Protocol: TCP
What is the root cause of the blocking?
A) The Allow-DNS network rule is consuming all UDP processing of the firewall, causing delay in processing application rules for TCP.
B) Application rules require the firewall's DNS proxy to be used for FQDN resolution. Since VMs are using 8.8.8.8 directly via network rule, the firewall cannot associate the destination IP with the allowed FQDN.
C) The absence of NSG on the subnet prevents TCP:443 traffic from being routed correctly to the firewall.
D) Priority 200 of the application rule is numerically higher than 100 of the network rule, causing the network rule to always be evaluated first and block HTTPS traffic.
Scenario 4 — Diagnostic Sequence
An administrator receives the following complaint: applications in one spoke cannot reach an internal endpoint in another spoke, even though a network rule in Azure Firewall explicitly allows traffic between the two prefixes.
The available investigation steps are:
- Check Azure Firewall logs to see if traffic is reaching the firewall and which rule is being applied
- Confirm if the UDR in the source spoke has the next hop pointed to the firewall's private IP
- Verify if there's a more specific route in the effective routes of the source VM's NIC that bypasses the firewall
- Confirm if the destination prefix of the other spoke is included in the scope of the allowed network rule
- Verify if return traffic from the destination spoke also goes through the firewall or returns via direct path
Which investigation sequence follows the correct logic of progressive diagnosis?
A) 1 → 2 → 4 → 3 → 5
B) 2 → 3 → 1 → 4 → 5
C) 4 → 1 → 2 → 3 → 5
D) 3 → 2 → 4 → 1 → 5
Answer Key and Explanations
Answer Key — Scenario 1
Answer: C
The application rule was created with the pattern *.storage.azure.com, but the actual destination FQDN is minhaconta.blob.core.windows.net. These are distinct domains: blob.core.windows.net is the public endpoint of Azure Blob Storage, not a subdomain of storage.azure.com. The wildcard pattern *.storage.azure.com covers FQDNs like minhaconta.storage.azure.com, which is the endpoint for Azure Data Lake Storage Gen1 or resources exposed via Private Link with custom DNS, not the default Blob Storage endpoint. The log confirms this by showing that the denial comes from the default rule, indicating that no allow rule matched the destination.
The information about the 12 other firewalls with Standard SKU is irrelevant and was included to distract. IDPS and Threat Intelligence are also distractors: IDPS in Alert and Deny mode would block after the rule is matched, not before an attempt to match, and Threat Intelligence in Alert Only mode never blocks traffic by definition.
The most dangerous distractor is alternative B. It confuses policy hierarchy with the evaluation order between rule types. Network rules in the parent policy take precedence over network rules in the child policy, but application rules and network rules are distinct types. Acting on this distractor would lead the administrator to modify the parent policy without solving the real problem, potentially introducing unnecessarily broad permissions.
Answer Key — Scenario 2
Answer: C
TLS inspection is an exclusive feature of Azure Firewall Premium. The current firewall is Standard SKU and doesn't support this capability, regardless of certificates available in Key Vault. Alternative A is technically impossible: there's no option to enable TLS inspection on a Standard firewall.
Alternative B represents the technically correct action, but ignores a critical restriction from the scenario: no maintenance window is available in the next 72 hours. A SKU upgrade in production without a maintenance window can cause traffic interruption and violates change management practices. Acting on alternative B would be the most dangerous decision in the set.
Alternative D is a valid approach in environments that require zero downtime, but the scenario doesn't describe this restriction as motivating, and creating a second firewall without a maintenance window is also not authorized by the context.
Alternative C is the correct action given the set of restrictions: the requirement is approved and documented, but execution must occur during the next maintenance window, respecting the change process. Security and availability must be balanced, not treated unilaterally.
Answer Key — Scenario 3
Answer: B
Azure Firewall uses its own internal DNS proxy to resolve FQDNs in application rules. When an application rule specifies an FQDN as destination, the firewall needs to resolve that FQDN to IPs at the moment traffic arrives, in order to compare the packet's destination IP with the IPs that the FQDN resolves to. If the VM is using an external DNS server directly (8.8.8.8 via network rule), the firewall has no visibility about which FQDN that destination IP represents. The result is that the TCP:443 packet arrives at the firewall with destination 13.107.4.52, without matching any application rule, and falls to the default deny rule.
The log confirms exactly this behavior: the packet is denied by DeniedByDefault with destination as a pure IP, without an associated FQDN in the evaluation.
DNS resolution working on the VMs is the irrelevant information in the scenario. The fact that nslookup returns correct results only means that VMs can resolve names, not that the firewall has this mapping in its DNS proxy for rule evaluation purposes.
The most dangerous distractor is alternative D, which reverses priority logic. Lower numbers represent higher priority in Azure Firewall: priority 100 is evaluated before 200. Acting on this alternative would lead to reordering rules without effect on the real problem.
Answer Key — Scenario 4
Answer: B
The correct sequence is 2 → 3 → 1 → 4 → 5, as it follows the logic of validating the data plane before analyzing logs and then before validating the rule configuration itself.
Step 2 confirms if traffic is being directed to the firewall via UDR. Without this, any investigation in firewall logs would be inconclusive, as traffic may simply never be reaching there. Step 3 verifies if there's a more specific route that bypasses the UDR, which is a common problem in environments with direct peering between spokes or routes learned via BGP. Only after confirming that traffic is reaching the firewall does it make sense to check logs (step 1) to know which rule is being applied. With this information, step 4 verifies if the destination prefix is covered by the rule. Step 5, about the return path, is the most advanced and only makes sense after all previous ones, as routing asymmetry can cause timeouts without appearing in the firewall's outbound logs.
Alternative A starts with logs before confirming traffic reaches the firewall, which can lead to a false conclusion that the rule is correct while traffic simply doesn't go through the firewall. Alternative C starts with the rule, ignoring that the problem might be in routing. Alternative D starts with the more specific route, skipping validation of the primary UDR, which inverts the natural order of diagnostic priority.
Troubleshooting Tree: Azure Firewall
Color legend:
| Color | Node type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Medium blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start with the root node that describes the observed symptom and answer each question based on what you can verify directly in the environment: firewall logs, effective route tables, policy configuration, and operational mode of features like IDPS and Threat Intelligence. Each branch eliminates a class of causes and deepens the diagnosis until reaching an identified cause in red or a corrective action in green. Don't skip levels: the order of questions reflects the logical dependency between hypotheses.