AZ-500 Practice Question: Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel
Your company deploys a new Azure application gateway with WAF policy in prevention mode. After deployment, users report that legitimate traffic is being blocked. You need to identify which WAF rules are causing the blocks without affecting the security posture. What should you do?
⚠ Common exam trap
Many candidates think disabling the WAF or creating an allow-all rule is a quick fix, but the correct approach is to use detection mode to diagnose false positives without compromising security.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Change the WAF policy mode to detection.
Switching the WAF policy mode from prevention to detection allows the application gateway to log WAF rule matches without blocking legitimate traffic. This enables you to review the logs and identify which specific rules are causing false positives, while still maintaining visibility into threats. Once identified, you can fine-tune the rules or create exceptions without disrupting the security posture.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable the WAF policy temporarily.
Why it's wrong here
Disabling the WAF policy on the Application Gateway turns off the web application firewall entirely, exposing the gateway to OWASP Top 10 attacks while you troubleshoot. It also generates no WAF evaluation data, so you won't discover which managed rule or signature is responsible for the blocked traffic. This is a risky operational change, not a targeted diagnostic.
- ✗
Create a custom rule to allow all traffic.
Why it's wrong here
Creating a custom rule with an 'Allow' action that matches all traffic (for example, a high-priority rule with a wildcard condition) makes the WAF skip inspection and forward the request directly, bypassing both managed rule sets and any other custom rules. Because the request is no longer evaluated by the firewall, you will not see the managed rule ID or match details in the logs, so the root cause remains hidden while your security control is effectively disabled.
- ✗
Set the WAF policy to custom rules only.
Why it's wrong here
Setting the WAF policy to custom rules only disables the managed rule sets, so OWASP CRS rules are not evaluated at all. If the problem is a false positive from a built-in managed rule, no match will be recorded and you lose the ability to identify the exact rule ID; this also removes baseline protection rather than capturing diagnostic data about the blocking event.
- ✓
Change the WAF policy mode to detection.
Why this is correct
Changing the WAF policy mode to detection makes the gateway evaluate every managed and custom rule and log all matches to the WAF diagnostic logs, but it stops enforcing blocking actions. You can then correlate the rejected requests with the exact rule ID and request details in Log Analytics, confirming whether this is a false positive. Once you've identified the offending rule, you can add exclusions or tune rule actions and switch the policy back to prevention mode.
Go deeper
Related to this question
About these practice questions
Courseiva writes every AZ-500 question from scratch — 617 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-500 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-500 exam.