Troubleshooting Lab: Azure Firewall SKU Selection
Diagnostic Scenarios
Scenario 1 — Root Cause
A security team reports that the Azure Firewall deployed in the hub VNet is not filtering traffic based on URL categories, such as blocking gambling or social media sites. The firewall is responding normally to application and network rules, and logs are being sent correctly to the Log Analytics Workspace. The team mentions that the resource was provisioned three weeks ago using an existing ARM template in the organization, originally created for a development environment. The public IP address is configured as static and the firewall policy is correctly associated.
The security manager states that URL category filtering was approved in the solution design and is documented in the project.
What is the root cause of the problem?
A) The firewall policy is associated with the wrong resource and needs to be relinked to the correct VNet.
B) The deployed SKU is Standard, which does not support URL category filtering, a feature exclusive to the Premium SKU.
C) The Log Analytics Workspace is not configured to receive URL category logs, preventing rule processing.
D) The static public IP address prevents encrypted traffic inspection required for URL categorization.
Scenario 2 — Action Decision
A financial services company operates an Azure environment with Azure Firewall Standard in production, protecting critical payment processing workloads. After a security incident investigated by the response team, it was identified that the attack vector exploited encrypted TLS traffic that passed uninspected through the firewall. The root cause was formally documented: the Standard SKU does not perform TLS inspection.
The production environment handles 40,000 transactions per hour. Any disruption must be communicated to the regulator with a minimum 72-hour advance notice. The team has an approved maintenance window in 5 days. An identical staging environment is available.
What is the correct action to take at this time?
A) Upgrade the SKU directly on the production firewall resource, taking advantage that Azure allows in-place upgrade without downtime.
B) Provision an Azure Firewall Premium in the staging environment, validate the configuration with active TLS inspection, and plan migration for the approved maintenance window.
C) Configure a TLS inspection policy on the current Standard instance to mitigate risk immediately while migration is planned.
D) Immediately replace the production firewall with Premium SKU, as the regulatory risk of operating with the known vulnerability exceeds the disruption risk.
Scenario 3 — Root Cause
A network architect receives a call reporting that Azure Firewall is rejecting outbound connections to a corporate SaaS service that uses a domain with a self-signed certificate. The firewall is configured with an application rule allowing the service FQDN on port 443. The rule existed before the problem started and was not changed. Logs show the following entry:
Action: Deny
Rule Collection: App-RC-SaaS
Rule: Allow-SaaS-Portal
Protocol: HTTPS
TargetFqdns: saas-portal.contoso-partner.com
ThreatIntelMode: Alert
The team reports that the SaaS service certificate was renewed by the vendor the previous week. Other FQDNs in the same application rule work normally. The infrastructure team mentions there was a firewall policy update two days before the incident.
What is the root cause of the problem?
A) The firewall policy update accidentally removed the application rule that allowed the affected FQDN.
B) The firewall is on Premium SKU with active TLS inspection and is rejecting the SaaS service's self-signed certificate during TLS handshake.
C) The ThreatIntel mode configured as Alert is actively blocking the SaaS service destination IP by reputation.
D) The application rule does not cover the correct protocol and should be reconfigured to include HTTP in addition to HTTPS.
Scenario 4 — Diagnostic Sequence
A customer reports that after migrating from Azure Firewall Standard to Premium, some internal applications stopped working correctly. The observed symptom is that HTTPS connections to certain internal backends are terminated with certificate errors on the client. The team suspects that TLS inspection introduced in the new SKU is the source of the problem, but has not yet confirmed it.
The following investigation steps are available:
- P: Verify if the Intermediate CA configured in the firewall is trusted by affected clients
- Q: Review firewall logs to identify which connections are being blocked or terminated
- R: Confirm if the firewall policy has TLS inspection enabled and which application rules are in scope
- S: Verify if affected backends have valid certificates issued by a trusted public or private CA
- T: Compare behavior between affected and unaffected clients to isolate the determining variable
What is the correct investigation sequence?
A) R, Q, T, S, P
B) Q, R, S, P, T
C) T, R, Q, P, S
D) P, S, R, Q, T
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
URL category filtering is an exclusive feature of Azure Firewall Premium. The Standard SKU supports FQDN filtering, network and application rules, but does not perform URL categorization based on enriched threat intelligence. The critical detail in the statement is that the ARM template was originally intended for a development environment, where typically the Standard SKU is used for cost reasons. The fact that the firewall is responding normally to other rules confirms that the resource is operational, which rules out general configuration failures.
The information about the Log Analytics Workspace is irrelevant for this diagnosis: logs working correctly indicate adequate connectivity and diagnostic configuration, but have no relation to the SKU's ability to process URL categories. The static public IP address also has no relation to categorization functionality.
The most dangerous distractor is alternative C, as it directs the diagnosis to the observability layer when the problem is at the product capability layer. Acting on this hypothesis would lead to hours of workspace investigation without results.
Answer Key — Scenario 2
Answer: B
The scenario imposes two critical restrictions that eliminate the other alternatives: the requirement for regulatory notification with 72 hours advance notice and the existence of an approved maintenance window in 5 days. Any action that affects production before the window violates the regulatory restriction.
Alternative A is technically incorrect: Azure Firewall does not support in-place upgrade between Standard and Premium SKUs. A new resource would need to be provisioned. Alternative C is technically impossible: the Standard SKU does not support TLS inspection regardless of the configured policy. Alternative D deliberately ignores the regulatory restriction documented in the scenario.
The correct action is to use the staging environment to validate the new configuration with TLS inspection, identify potential impacts on applications, and execute the migration in the approved window with adequate communication to the regulator.
Answer Key — Scenario 3
Answer: B
The displayed log shows a denial on a rule that was previously working, affecting only a specific FQDN whose certificate was renewed. When Azure Firewall Premium operates with active TLS inspection, it performs a transparent TLS proxy: it terminates the client connection, inspects the content, and opens a new connection to the backend. If the backend certificate is not trusted by the CA chain configured in the firewall, the connection is blocked.
The determining detail is the combination of two simultaneous events: certificate renewal by the vendor and firewall operation on Premium SKU. The renewal may have introduced a self-signed certificate or one issued by a CA not configured as trusted in the firewall.
The information about the policy update two days earlier is purposely irrelevant: other FQDNs in the same rule work normally, which eliminates the hypothesis of accidental rule change. The ThreatIntel mode configured as Alert does not block traffic, only logs alerts, making alternative C incorrect. Alternative D is implausible because the rule already existed and correctly covered HTTPS before the problem.
Answer Key — Scenario 4
Answer: A
The correct sequence is R, Q, T, S, P, which follows the logic of progressive diagnosis from most comprehensive to most specific.
The first step is to confirm if TLS inspection is actually enabled in the policy and which rules are in scope (R), because without this it is not possible to state that TLS inspection is the cause. Next, logs reveal which specific connections are being affected and for what stated reason (Q). With connections identified, compare behavior between affected and unaffected clients to isolate the determining variable (T), such as TLS client version or accepted certificate chain. Then, verify the validity and trust chain of certificates from affected backends (S). Finally, confirm if the firewall's intermediate CA is in the client trust list (P), which is the most likely cause of certificate error on the client when TLS inspection is active.
Sequence B starts with logs before confirming if TLS inspection is even active, which can lead to log analysis without context. Sequence D starts with the most specific step before establishing general context, inverting the logic of progressive elimination.
Troubleshooting Tree: Azure Firewall SKU Selection
Color Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom, investigation entry point |
| Blue | Diagnostic question, decision based on what was observed |
| Red | Identified cause, confirmed problem origin |
| Green | Recommended action or applicable resolution |
| Orange | Validation or intermediate verification before acting |
To use this tree when facing a real problem, start with the root node identifying that the firewall is not executing an expected functionality. The first branch determines the current SKU, as many capability failures have direct origin in SKU choice. From there, follow the diagnostic questions responding only with what was observed or verified, without skipping steps. Each path ends with a named cause and a specific action, avoiding corrections applied without confirmed diagnosis.