Troubleshooting Lab: Associate a WAF Policy
Diagnostic Scenarios
Scenario 1 — Root Cause
A platform team deployed an Azure Front Door Premium with three endpoints configured to distribute traffic between applications from different business units. A WAF Policy in Prevention mode was created with managed rules from the Microsoft_DefaultRuleSet 2.1 ruleset and associated with the Front Door profile.
After deployment, the security team confirms that the app-financeiro.contoso.com endpoint is being properly protected by the WAF. However, the QA team reports that simulated attack attempts against app-rh.contoso.com and app-operacoes.contoso.com are not being blocked, and the WAF logs show no traffic records for these two endpoints.
The responsible architect verifies the configuration and finds the following state in the portal:
WAF Policy: WafPolicy-FrontDoor-Prod
Mode: Prevention
Associated Resources:
- Endpoint: app-financeiro.contoso.com (Enabled)
- Endpoint: app-rh.contoso.com (Not configured)
- Endpoint: app-operacoes.contoso.com (Not configured)
Managed Rules:
Microsoft_DefaultRuleSet 2.1: Enabled
Custom Rules: None
The architect also mentions that the three endpoints were created in the same Front Door Premium profile and that the WAF policy was configured before the creation of the HR and operations endpoints. The Front Door SKU is Premium, which is required for WAF association. The subscription has sufficient quota for additional WAF policies.
What is the root cause of the problem?
A) The Azure Front Door WAF policy applies protection only to the first endpoint configured in the profile, requiring the creation of separate policies for each additional endpoint.
B) The endpoints app-rh.contoso.com and app-operacoes.contoso.com were not associated with the WAF policy after their creation, so traffic destined to them is not inspected.
C) The WAF policy was created before the HR and operations endpoints, which prevents retroactive association with endpoints created later in the same profile.
D) The Front Door Premium SKU supports only one WAF policy association per profile, requiring the three endpoints to share three distinct policies instead of a single one.
Scenario 2 — Root Cause
A network engineer received the task of associating an existing WAF Policy to a Application Gateway v2 that was recently provisioned in a new subscription. The WAF policy, called WafPolicy-AppGW-Corp, was created six months ago in the original production subscription and is being reused for the new environment.
The engineer tries to associate the policy to the Application Gateway through the portal and receives the following error:
Error: The WAF policy 'WafPolicy-AppGW-Corp' cannot be associated with the
Application Gateway 'AppGW-NewSub-East'. Ensure the policy and the gateway
are in the same region and subscription.
Code: WafPolicyAssociationFailed
Target: /subscriptions/NEW-SUB-ID/resourceGroups/rg-appgw/providers/
Microsoft.Network/applicationGateways/AppGW-NewSub-East
The engineer verifies that the Application Gateway is in the East US region and was provisioned with WAF_v2 SKU. The WafPolicy-AppGW-Corp policy was originally created in the West Europe region and is in the original production subscription. The new subscription is in the same Microsoft Entra ID tenant. The engineer confirms having Network Contributor permission in both subscriptions.
What is the root cause of the problem?
A) The Network Contributor role doesn't have sufficient permission to associate WAF policies between subscriptions, requiring the Security Admin role in the source subscription.
B) The WAF policy WafPolicy-AppGW-Corp is in a different subscription and region from the target Application Gateway, and WAF policies for Application Gateway cannot be associated across subscriptions or regions.
C) The WAF policy was created six months ago and expired the validity period for new associations, requiring recreation of the policy in the new subscription.
D) The WAF_v2 SKU of the Application Gateway requires that the WAF policy be created with the Regional type, but the original policy was created as Global type, incompatible with the association.
Scenario 3 — Action Decision
The security team of a company identified that an Application Gateway v2 in production is operating with a WAF Policy associated at Gateway level that was created two years ago and uses the OWASP CRS 3.0 ruleset. An audit determined that the policy should be updated to OWASP CRS 3.2 and that two of the five gateway listeners need distinct exclusion configurations that cannot be implemented in a single Gateway-level policy.
The cause was confirmed: the current architecture doesn't support granularity requirements per listener with a single Gateway-level policy. The solution requires creating individual policies associated at Listener level for the two listeners that need specific exclusions, keeping the Gateway policy for the others.
The environment is in active production with 99.9% SLA. The team has a maintenance window available in 72 hours. No configuration changes in production are allowed outside approved windows, per internal policy.
What is the correct action to take at this moment?
A) Create the two Listener-level policies with OWASP CRS 3.2 and the necessary exclusions, associate them to the corresponding listeners, and update the Gateway policy now, taking advantage that the maintenance window is close and the impact is minimal.
B) Update the existing Gateway policy from CRS 3.0 to CRS 3.2 immediately, without changing the association structure, and wait for the maintenance window to create and associate the Listener-level policies.
C) Prepare the two new Listener-level policies with OWASP CRS 3.2 and the necessary exclusions, update the Gateway policy to CRS 3.2, and execute all associations during the maintenance window in 72 hours.
D) Create the two Listener-level policies in Detection mode, associate them to the listeners now outside the maintenance window to validate the exclusions with real traffic, and migrate to Prevention during the maintenance window.
Scenario 4 — Collateral Impact
An administrator identified that an Azure Front Door Premium was using a WAF Policy shared among five endpoints from different applications. To meet a security isolation requirement, the administrator created individual WAF policies for each endpoint and associated them correctly, then disassociated the shared policy from all five endpoints.
The immediate result was confirmed: each endpoint now uses its dedicated policy, and the WAF logs show that traffic is being inspected correctly by each individual policy.
What secondary consequence can this action cause?
A) Disassociating the shared policy from the five endpoints causes automatic deletion of the original WAF policy, removing the log history associated with it.
B) The five new individual WAF policies generate five times greater log data volume in the linked Log Analytics Workspace, potentially impacting log ingestion and retention costs depending on the workspace configuration.
C) Azure Front Door Premium endpoints without an associated WAF policy during the interval between disassociation and association of the new policy are temporarily without inspection, exposing traffic during that period.
D) Creating five individual WAF policies instead of one shared policy exceeds the WAF policy limit per subscription in Azure Front Door Premium, causing silent failure in the policies created last.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The root cause is that the endpoints app-rh.contoso.com and app-operacoes.contoso.com simply were not associated with the WAF policy. In Azure Front Door Premium, the association between a WAF Policy and an endpoint is explicit and individual. Creating an endpoint in the profile doesn't generate automatic association with existing WAF policies, regardless of how many other endpoints in the same profile are already associated.
The definitive clue is in the configuration output provided in the scenario: the two endpoints appear with Not configured status in the associated resources section of the policy. There's no possible ambiguity: the policy exists, the SKU is compatible, and the endpoints exist in the profile. The absence of log records for these endpoints confirms that traffic is not being inspected.
The irrelevant information is the mention of additional WAF policy quota in the subscription. This detail could suggest that the solution requires creating new policies, but the problem is just association, not the amount of available policies.
The main reasoning error of the distractors is assuming technical limitations that don't exist: A invents a "first endpoint only" restriction, C invents a sequential creation restriction, and D invents a one policy per profile restriction. The most dangerous distractor is D, because it would lead the engineer to create unnecessary additional policies, increasing operational complexity and cost, without solving the real problem which is just a missing association.
Answer Key — Scenario 2
Answer: B
The root cause is a fundamental scope restriction of WAF policies for Application Gateway: they are regional resources and must be in the same region and same subscription as the Application Gateway they will be associated with. The error returned by the portal confirms this textually. The WafPolicy-AppGW-Corp policy is in the West Europe region and in the original subscription, while the Application Gateway is in the East US region and in a different subscription.
The most objective clue is the error block itself, which explicitly states: "Ensure the policy and the gateway are in the same region and subscription." No interpretation is needed, the system already identified and described the cause.
The irrelevant information is the mention of the same Microsoft Entra ID tenant. Sharing a tenant doesn't create any compatibility bridge between resources in different subscriptions for WAF Policy association purposes. The tenant is irrelevant for this type of resource scope restriction.
The most dangerous distractor is A, because the Network Contributor role and its permissions are a natural diagnostic vector when there's association failure between resources in different subscriptions. A less experienced engineer could request permission elevation, attempts with broader roles like Owner, and open support tickets about permissions before realizing that the problem is geographic and subscription scope, not authorization.
Answer Key — Scenario 3
Answer: C
The correct action is to prepare all policies and updates in advance and execute all changes during the maintenance window in 72 hours. This respects the critical constraint of the scenario: no configuration changes in production outside approved windows.
Alternative A directly violates the internal policy by executing changes outside the window, even arguing that the impact is minimal. In environments with 99.9% SLA, minimal impact justification doesn't replace compliance with approved processes. Alternative B performs only part of the work outside the window, which also violates internal policy and leaves the environment in an inconsistent intermediate state, with CRS 3.2 in the Gateway policy but without the Listener policies created.
Alternative D is technically interesting as a validation approach, but also violates internal policy by performing associations outside the window, even though in Detection mode. Detection mode doesn't exempt the action from the production change restriction.
The critical point that differentiates C from the others is that preparing policies without associating them doesn't constitute a production change: resources can be created in parallel without impact. Executing the associations and updating the Gateway policy is what should occur in the window. This distinction between preparation and activation is fundamental in environments with formal change control.
Answer Key — Scenario 4
Answer: C
The real collateral impact is the exposure window generated by the interval between disassociation of the shared policy and completion of individual policy associations. In Azure Front Door Premium, an endpoint without an associated WAF policy receives traffic without inspection. If the disassociation of the shared policy and association of individual policies aren't atomic or simultaneous operations, there's a period when one or more endpoints are unprotected.
Alternative A is false: disassociating a WAF policy from resources doesn't cause its deletion. WAF policies are independent resources that persist even without active associations.
Alternative B is technically plausible as a cost concern in environments with high traffic volume, but it's not a direct and immediate consequence of the described action. Additionally, the scenario confirms that traffic was already being logged by the shared policy, so the volume of events in Log Analytics wouldn't increase proportionally to the number of policies, it would just be distributed among them.
Alternative D invents a limitation that doesn't exist for this scenario. The WAF policy limit per subscription in Azure is high enough that five policies wouldn't represent a quota risk in a single Front Door, and the product doesn't cause silent failure in policies created beyond an arbitrary number.
The practical consequence of this scenario is that WAF policy migration operations should be planned to minimize or eliminate the disassociation interval, ideally associating the new policies before removing the existing policy, when the architecture allows temporary overlap.
Troubleshooting Tree: Associate a WAF Policy
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (tree root) |
| Medium blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
| To use this tree for a real problem, start at the root node by identifying whether the problem manifests as an error during association attempt or as traffic reaching the resource without WAF inspection. These two initial paths separate compatibility and resource scope issues from association coverage problems. Follow each question by answering only with what is directly verifiable in the portal or diagnostic logs, without assuming the cause, until you reach an identified cause node with the corresponding action. |