Technical Lab: Configure detection or prevention mode
Questions
Question 1 — Multiple Choice
An administrator needs to evaluate the impact of new rules on an Azure Application Gateway with WAF before deploying them to production. The environment is receiving real traffic and any improper blocking would impact users. Which WAF operation mode meets this requirement and what is the expected behavior?
A) Prevention mode, as it logs and blocks only traffic that violates rules, without affecting the rest
B) Detection mode, as it monitors traffic and logs violations without blocking any requests
C) Detection mode, as it blocks suspicious requests and generates alerts for later review
D) Prevention mode, as it forwards suspicious traffic to quarantine without interrupting the main flow
Question 2 — Technical Scenario
A team configured an Azure Front Door with WAF Policy and associated the policy to a production endpoint. After deployment, the security team reports that SQL Injection attacks are being detected in the logs, but none of them are being blocked. The snippet below represents the current policy configuration:
{
"policySettings": {
"enabledState": "Enabled",
"mode": "Detection",
"redirectUrl": null,
"customBlockResponseStatusCode": 403
}
}
What is the direct cause of the observed behavior?
A) The customBlockResponseStatusCode property is configured incorrectly; the correct value would be 200
B) The WAF policy is in Detection mode, which logs violations but does not execute blocking actions
C) The policy is not correctly associated with the endpoint; the redirectUrl field needs to be filled
D) Azure Front Door WAF does not support SQL Injection detection without manual addition of custom rules
Question 3 — True or False
When a WAF Policy associated with an Azure Application Gateway is changed from Detection mode to Prevention mode, all requests that previously only generated logs are blocked immediately, without requiring gateway restart or reconfiguration of existing rules.
Question 4 — Multiple Choice
Consider two environments with WAF configured as follows:
| Environment | Resource | Mode | Managed Rules |
|---|---|---|---|
| Prod | Application Gateway | Prevention | OWASP 3.2 active |
| Staging | Application Gateway | Detection | OWASP 3.2 active |
A request with Cross-Site Scripting (XSS) payload is sent to both environments simultaneously. What is the expected behavior?
A) Both environments block the request, as the OWASP 3.2 rules are identical
B) The Prod environment blocks and returns 403 error; the Staging environment logs the violation and forwards the request normally
C) The Staging environment blocks the request locally and waits for manual approval before forwarding
D) Both log the violation, but only the Prod environment sends an alert to Microsoft Defender for Cloud
Question 5 — Technical Scenario
An organization migrated their WAF from Detection mode to Prevention mode on an Azure Application Gateway. Two days after the change, the support team reports that a legacy partner system is receiving 403 errors when trying to consume an API protected by the gateway. The partner system was not changed. The WAF logs show the following pattern:
RuleId: 942100
Action: Blocked
Message: SQL Injection Attack Detected via libinjection
RequestUri: /api/parceiro/consulta
What is the most appropriate approach to resolve the issue without compromising the security posture of other endpoints?
A) Revert the WAF to Detection mode across the entire policy to restore partner functionality
B) Create a rule exclusion for RuleId 942100 applied specifically to the /api/parceiro/consulta path, preserving protection on other endpoints
C) Completely disable the OWASP rule set on the Application Gateway and replace with custom rules
D) Change the customBlockResponseStatusCode to 200 in the WAF policy so the partner doesn't receive blocking errors
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Detection mode is designed exactly for evaluation scenarios in environments with real traffic. It inspects all requests, logs violations in diagnostic logs and Log Analytics, but does not execute any blocking actions. This allows the administrator to analyze false positives before activating Prevention mode.
Alternative A reverses the behavior of modes: Prevention is the one that blocks, not Detection. Alternatives C and D describe behaviors that don't exist in Azure WAF implementation: Detection never blocks, and Prevention has no quarantine mechanism with parallel forwarding. Choosing Prevention in this scenario would cause immediate blocks in production, including potential false positives.
Answer Key — Question 2
Answer: B
The "mode": "Detection" field in the WAF Policy configuration is the direct determinant of behavior. Regardless of which rules are active or how other fields are configured, a policy in Detection mode never executes blocking actions: it only evaluates traffic and logs rule matches.
Alternative A is a plausible distractor, but the 403 status code is valid and doesn't interfere with operation mode. Alternative C is incorrect because redirectUrl is optional and relevant only for custom redirects, not for blocking functionality. Alternative D is false: SQL Injection is covered by the default managed rule set (DRS/OWASP) without needing custom rules.
Answer Key — Question 3
Answer: True
The transition between Detection and Prevention modes in an Application Gateway WAF Policy is a configuration change that takes effect immediately, without gateway restart. The managed rules were already active and evaluating traffic in Detection mode; when changing to Prevention, the execution mechanism starts applying blocking action (Block) for the same matches that previously only generated logs.
This behavior reinforces the importance of analyzing logs thoroughly during the Detection period before promoting to Prevention, as false positives that were invisible to end users become 403 errors immediately after the change.
Answer Key — Question 4
Answer: B
The WAF operation mode is the only factor that differentiates the behavior of the two environments in this scenario, since the rules are identical. In Prevention, the violation results in blocking with error response (typically 403) before the request reaches the backend. In Detection, the same violation is logged, but the request is forwarded normally to the backend.
Alternative A is the most common mistake: many assume that identical rules produce identical behaviors, ignoring that the mode determines the action executed. Alternative C describes a manual approval flow that doesn't exist in Azure WAF. Alternative D confuses Defender for Cloud integration with intrinsic mode behavior, which doesn't interfere with external notifications.
Answer Key — Question 5
Answer: B
The correct solution for a false positive on a specific path is to create a targeted rule exclusion, which removes evaluation of RuleId 942100 only for requests matching the /api/parceiro/consulta path. This surgical approach preserves active protection for all other endpoints and rules.
Alternative A solves the symptom by reverting the entire security posture of the environment, which is technically incorrect in production. Alternative C is disproportionate and eliminates managed protection for all endpoints unnecessarily. Alternative D is an important misconception: changing the response code to 200 doesn't disable blocking; the request would still be blocked by WAF, just returning a different HTTP status to the client, which doesn't solve the partner's functional problem.