This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for application platform services
      --> Implement and configure Azure Web Application Firewall

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

Web applications are frequently exposed to the public internet and therefore represent an attractive target for attackers. Even when an application is well designed and securely coded, vulnerabilities can exist in application frameworks, third-party components, APIs, or configuration.

Azure Web Application Firewall (WAF) provides a centralized layer of protection for web applications against common web-based attacks and vulnerabilities. Rather than requiring every application to independently implement defenses against common HTTP attacks, WAF can inspect incoming web requests and apply security rules before the traffic reaches the application.

Azure WAF can be integrated with several Azure application-delivery services, including:

• Azure Application Gateway
• Azure Front Door
• Azure Application Gateway for Containers
• Azure CDN in supported scenarios

For SC-500, the most important distinction is understanding when to use WAF, how WAF policies and rules work, how to configure WAF in Detection versus Prevention mode, and how WAF complements—not replaces—other security controls.

1. What Is Azure Web Application Firewall?

Azure Web Application Firewall is a specialized firewall designed to inspect HTTP/HTTPS application traffic.

Traditional network security controls primarily focus on network traffic, IP addresses, ports, protocols, and network boundaries. WAF operates at a higher level by examining characteristics of web requests.

For example, a WAF can identify patterns associated with:

• SQL injection
• Cross-site scripting (XSS)
• Command injection
• Local file inclusion
• Protocol anomalies
• Malicious bots
• Other common web application exploits

This allows WAF to provide a security layer between internet clients and the application.

Simplified architecture

                 Internet
                    |
                    v
          +-------------------+
          | Azure Front Door   |
          |       + WAF        |
          +-------------------+
                    |
                    v
             Azure Web App
             / App Service

Or for a regional architecture:

                 Internet
                    |
                    v
        +------------------------+
        | Application Gateway    |
        |       + WAF             |
        +------------------------+
                    |
                    v
             Azure Web App
             / App Service

The WAF examines incoming requests and determines whether they should be allowed, blocked, logged, redirected, or otherwise processed according to the configured policy.

Azure describes WAF as centralized protection against common exploits and vulnerabilities, including SQL injection and cross-site scripting.

2. WAF Is Not the Same as a Network Firewall

A common SC-500 exam trap is confusing a Web Application Firewall with a traditional network firewall.

WAF is therefore not a replacement for Azure Firewall, NSGs, authentication, or secure application development.

Instead, these controls can work together as layers of defense.

3. Where Can Azure WAF Be Deployed?

Azure WAF is available with several Azure application-delivery services.

The two most important for SC-500 are:

Azure Front Door + WAF

Azure Front Door provides a globally distributed application-delivery layer. WAF operates at Microsoft’s global edge locations, allowing malicious requests to be filtered before they travel toward the application origin.

This is particularly useful for:

• Global applications
• Internet-facing applications
• Globally distributed users
• Applications requiring edge-based protection
• Applications that benefit from Front Door’s routing and acceleration capabilities

Microsoft describes Front Door WAF as a global, centralized solution that inspects incoming requests at the network edge.

Application Gateway + WAF

Application Gateway is a regional application-delivery service that can provide Layer 7 load balancing and WAF capabilities.

It is particularly useful when the application architecture requires:

• Regional application delivery
• Integration with an Azure virtual network
• Application Gateway routing capabilities
• TLS termination
• WAF inspection close to the application

Microsoft’s current guidance distinguishes the two primarily by scope: Application Gateway WAF is regional, while Front Door WAF operates globally at the edge.

4. Front Door WAF vs. Application Gateway WAF

This is an important architectural distinction.

A globally distributed application may use Front Door WAF as the first security layer.

An organization may also combine Front Door and Application Gateway when additional regional routing, inspection, or application-specific controls are required.

Microsoft’s architecture guidance explicitly describes scenarios where Front Door and Application Gateway can be combined for additional layers of protection.

5. WAF Policies

A WAF policy defines how Azure WAF protects an application.

A policy can contain:

1. Managed rules
2. Custom rules

These rules determine what traffic is considered suspicious or malicious and what action should be taken.

Conceptually:

                 WAF Policy
                     |
          +----------+----------+
          |                     |
     Managed Rules        Custom Rules
          |                     |
    Known attack         Organization-
    signatures           specific logic

A policy can then be associated with the appropriate application-delivery resource.

For example:

WAF Policy
    |
    +---- Managed rules
    |
    +---- Custom rules
    |
    +---- WAF mode
    |
    +---- Exclusions
    |
    +---- Logging/monitoring

Azure WAF policies support both Azure-managed rule sets and administrator-created custom rules.

6. Managed Rules

Managed rules are preconfigured security rules maintained by Microsoft.

They provide protection against known attack patterns without requiring administrators to manually create every rule.

Managed rules can detect common attacks such as:

• SQL injection
• Cross-site scripting
• Command injection
• File inclusion
• Protocol violations
• Other common web vulnerabilities

Azure’s WAF managed rule sets are based on established web-application security rule sets and are updated over time as threat patterns evolve.

Why managed rules are valuable

Without managed rules, an organization would need to:

• Identify attack signatures
• Develop rules
• Test them
• Update them as threats evolve
• Maintain them over time

Managed rules reduce this administrative burden.

Important exam concept

A WAF policy without an appropriate managed rule set does not automatically provide the same protection against common web exploits.

For example, Microsoft specifically notes that a Front Door WAF policy with no managed rule set assigned does not provide managed-rule inspection for those attack signatures.

7. OWASP and Default Rule Sets

Azure WAF managed rules use industry-standard web application attack detection techniques.

The rule sets are designed to detect common web application attacks and vulnerabilities.

Depending on the Azure WAF platform and supported version, you may encounter terminology such as:

• CRS — Core Rule Set
• DRS — Default Rule Set
• Bot Manager rule set
• HTTP DDoS rule set

The exact available rule sets and versions vary by WAF platform and evolve over time, so administrators should use currently supported rule-set versions rather than relying on an obsolete version.

Microsoft’s current managed-rule support policy states that Azure WAF maintains a defined set of supported rule-set releases and periodically introduces newer releases containing updated signatures and protections.

Exam takeaway

Know the difference between:

Managed rule

Microsoft-provided protection against known attack patterns.

and

Custom rule

Administrator-defined logic for an organization’s specific security requirements.

8. Custom WAF Rules

Managed rules are broad and reusable, but organizations frequently need application-specific security policies.

That’s where custom rules are useful.

Examples include:

• Block traffic from specific IP addresses
• Allow traffic only from specific IP ranges
• Block traffic from specific countries or regions
• Restrict access based on request characteristics
• Apply rate limits
• Block requests matching specific patterns

A custom rule consists of concepts such as:

• Priority
• Rule type
• Match conditions
• Action

Azure Front Door WAF currently supports both match rules and rate-limit rules as custom rule types.

9. IP Allow and Block Rules

A custom WAF rule can use IP addresses or IP ranges as conditions.

For example, suppose an organization wants to block a known malicious address:

Client IP
    |
    v
203.0.113.50
    |
    v
WAF custom rule
    |
    +---- Match = Yes
             |
             v
           BLOCK

Alternatively, an organization could create an allow rule for trusted source networks.

Examples:

• Corporate headquarters
• Partner networks
• Known application integration systems
• Administrative networks

However, IP allow lists should be used carefully.

An allow rule can have a significant impact because it may permit traffic to bypass lower-priority rules depending on the platform and configuration.

10. Geo-Filtering

WAF can also use geographic information to control access.

For example:

“Block requests originating from countries where the organization does not operate.”

This can be useful when an application is intended for a limited geographic market.

Example:

Allowed:
United States
Canada
United Kingdom
Blocked:
Other geographic locations

Geo-filtering should not be treated as a complete security boundary because geographic identification is based on the source IP and associated geographic information.

It is best viewed as one additional layer of defense.

Azure Front Door WAF supports geographic-based access control through custom rules.

11. Rate Limiting

A web application can be overwhelmed by excessive numbers of requests even when the requests themselves are not obviously malicious.

A WAF can use rate-limit rules to control request rates.

For example:

Client
   |
   | 1,000 requests/minute
   v
WAF
   |
   +---- Rate exceeds threshold
              |
              v
          Apply action

Rate limiting can be useful for:

• Login endpoints
• Public APIs
• Search endpoints
• Expensive application operations
• Protection against automated abuse

Rate limiting is especially useful as part of a layered defense against abusive or automated traffic.

Azure Front Door WAF supports rate-limit custom rules.

12. WAF Detection Mode vs. Prevention Mode

One of the most important SC-500 concepts is the difference between Detection and Prevention mode.

Detection mode

In Detection mode:

• WAF evaluates requests.
• Matching rules are logged.
• WAF does not actively block the request solely because of the WAF match.

This mode is useful when initially deploying WAF.

For example:

Internet
   |
   v
WAF - Detection
   |
   +---- Suspicious request
   |
   +---- Log
   |
   v
Application

This allows administrators to determine whether legitimate application requests are being incorrectly identified.

Prevention mode

In Prevention mode:

• WAF evaluates requests.
• Matching rules can take enforcement actions.
• Malicious or disallowed requests can be blocked.

Conceptually:

Internet
   |
   v
WAF - Prevention
   |
   +---- Legitimate ----> Application
   |
   +---- Malicious -----> BLOCK

Microsoft documents Detection as monitoring/logging behavior and Prevention as enforcement behavior.

Recommended deployment approach

A practical approach is:

1. Configure WAF.
2. Enable managed rules.
3. Start in Detection mode.
4. Monitor WAF logs.
5. Identify false positives.
6. Tune exclusions/rules.
7. Move to Prevention mode.
8. Continue monitoring.

This reduces the risk of unexpectedly blocking legitimate application traffic.

13. WAF Actions

Depending on the WAF platform and rule, possible actions include:

• Allow
• Block
• Log
• Redirect
• Anomaly score, where supported

The exact available actions vary by rule set and WAF platform.

For example:

Block

The request is rejected.

Log

The request is recorded for analysis.

Allow

The request is permitted and lower-priority rules may not continue to block it, depending on the WAF platform/rule processing behavior.

Redirect

The request is redirected to a configured destination where supported.

Anomaly score

With supported rule sets, individual rule matches contribute to an overall anomaly score rather than necessarily causing an immediate block.

Azure documents these WAF actions and their processing behavior for Front Door WAF.

14. Understanding Anomaly Scoring

Anomaly scoring is an important concept when working with current WAF rule sets.

Instead of treating every individual rule match as an immediate block, supported rule sets can assign severity values to matches.

For example:

The scores can be accumulated for a request.

For supported DRS/CRS versions, if the resulting anomaly score reaches the blocking threshold while WAF is operating in Prevention mode, the request can be blocked.

This approach helps distinguish between:

• One highly serious match
• Several lower-severity matches

Microsoft’s current documentation describes anomaly scoring behavior for supported DRS/CRS rule sets.

Exam point

Do not assume:

“Every WAF rule match immediately blocks the request.”

That is not necessarily how current anomaly-scoring rule sets operate.

15. WAF Rule Priority

Rules are processed according to priority.

Generally:

Lower priority number = higher processing priority.

For example:

The exact behavior after a rule matches depends on the rule type and WAF platform.

Azure Front Door documentation states that custom rules are processed before managed rules, and that rules are evaluated according to their priority.

Exam trap

Do not confuse:

Priority 1

with

Priority 100

Priority 1 is evaluated first.

16. WAF Exclusions

Sometimes a legitimate application request looks suspicious to a generic WAF rule.

For example, an application may legitimately submit data containing a string that resembles SQL syntax.

The WAF could interpret the request as SQL injection.

Blocking it would create a false positive.

Instead of disabling WAF protection entirely, an administrator can use an exclusion to omit a specific request attribute from evaluation.

This is generally preferable to broadly disabling protection.

Conceptually:

Managed WAF Rule
       |
       v
Potential false positive
       |
       v
   Exclusion
       |
       v
Only the necessary attribute
is excluded

Azure WAF supports exclusion lists to prevent selected request attributes from being evaluated while allowing the remainder of the request to continue through WAF processing.

Best practice

Use the narrowest possible exclusion.

Avoid creating an overly broad exclusion merely because an application generates false positives.

17. Bot Protection

Automated bots can create significant security and operational problems.

Examples include bots that:

• Scrape content
• Scan applications
• Search for vulnerabilities
• Attempt credential attacks
• Generate excessive traffic
• Consume application resources

Azure WAF supports bot protection capabilities on supported platforms.

For example, Azure Front Door Premium supports a Bot Manager rule set that classifies automated traffic and can distinguish categories such as known good, known bad, and unknown bots.

Application Gateway WAF also supports managed bot protection capabilities for supported configurations.

18. WAF and DDoS Protection

WAF and DDoS protection address related but different threats.

WAF

Primarily protects against application-layer attacks such as:

• SQL injection
• XSS
• Malicious HTTP requests
• Application-layer abuse

DDoS Protection

Primarily addresses attacks designed to overwhelm network resources through large volumes of traffic.

For internet-facing web applications, using multiple layers can provide stronger protection.

A conceptual architecture is:

                Internet
                   |
                   v
            DDoS Protection
                   |
                   v
          Front Door + WAF
                   |
                   v
             Web Application

Microsoft recommends using DDoS protection and WAF together for web workloads where appropriate.

Exam takeaway

If a question asks:

“Which service protects against SQL injection?”

Think WAF.

If it asks:

“Which service protects against large-scale volumetric network attacks?”

Think DDoS protection.

19. WAF Does Not Replace Authentication

Another important distinction is that WAF does not determine whether a user is authorized to use an application.

For example:

User
 |
 v
Authentication
 |
 v
WAF
 |
 v
Application
 |
 v
Authorization

Depending on the architecture, WAF and authentication can occur at different layers.

WAF determines whether the request itself appears acceptable from a web-security perspective.

Authentication determines who the caller is.

Authorization determines what the caller is allowed to do.

Therefore, a secure application should not rely on WAF as a replacement for:

• Microsoft Entra ID
• Application authentication
• Authorization
• Azure RBAC
• Managed identities

20. WAF and Azure App Service

For an Azure App Service workload, WAF is often placed in front of the application rather than installed directly inside the App Service application.

A common architecture is:

Internet
    |
    v
Azure Front Door
    |
    +-- WAF
    |
    v
Azure App Service

Or:

Internet
    |
    v
Application Gateway
    |
    +-- WAF
    |
    v
Azure App Service

This architecture provides a centralized inspection layer before traffic reaches the application.

WAF therefore complements other App Service security controls such as:

• HTTPS-only
• Microsoft Entra authentication
• Access restrictions
• Private endpoints
• Managed identities
• TLS configuration
• Key Vault integration

21. Securing the App Service Origin

Deploying WAF in front of an App Service does not automatically mean that attackers cannot bypass the WAF.

For example:

              Internet
              /      \
             /        \
            v          v
        WAF          App Service
         |               ^
         |_______________|

If the App Service remains directly accessible through another public endpoint, an attacker may attempt to bypass the WAF.

A stronger architecture attempts to ensure that application traffic reaches the origin through the intended security path.

For highly restricted architectures, organizations can use techniques such as:

• Private endpoints
• Restricted public access
• Network controls
• Origin restrictions
• Appropriate Front Door/Application Gateway configuration

Microsoft’s architecture guidance recommends locking down origins appropriately when Front Door and Application Gateway are used together.

22. Monitoring WAF

WAF protection is not a “configure it once and forget it” control.

Administrators should monitor:

• Blocked requests
• Detected requests
• Rule IDs
• Source IPs
• Request patterns
• False positives
• Attack trends
• Rate-limit violations
• Bot activity

WAF integrates with Azure monitoring capabilities, including Azure Monitor and Azure Monitor Logs for supported configurations.

A typical operational process is:

Configure WAF
     |
     v
Monitor logs
     |
     v
Investigate matches
     |
     v
Identify false positives
     |
     v
Tune rules/exclusions
     |
     v
Continue monitoring

23. A Practical WAF Deployment Strategy

A security engineer could use the following process.

Step 1 — Identify the application entry point

Determine whether the application is:

• Globally distributed
• Regional
• Internet-facing
• Internal
• Hosted in App Service
• Hosted behind Application Gateway
• Hosted behind Front Door

Step 2 — Select the application-delivery platform

Consider:

• Front Door + WAF for globally distributed applications.
• Application Gateway + WAF for regional/VNet-centric application delivery.
• A combined architecture when additional layers are justified.

Step 3 — Create the WAF policy

Configure:

• Managed rules
• Custom rules
• Rule priorities
• Exclusions
• Bot protection where applicable
• Rate limiting where appropriate

Step 4 — Start with Detection

Monitor WAF behavior before aggressively blocking legitimate application traffic.

Step 5 — Tune

Investigate false positives.

Use narrowly scoped exclusions rather than disabling broad rule sets.

Step 6 — Enable Prevention

Once the policy has been validated, move to Prevention mode when appropriate.

Step 7 — Monitor continuously

Review:

• WAF logs
• Security alerts
• Application behavior
• Blocked traffic
• False positives
• Emerging attack patterns

24. Example Scenario

Scenario

A company hosts an e-commerce application in Azure App Service.

The application is publicly accessible and receives customers from North America and Europe.

Security requirements include:

• Protection from SQL injection
• Protection from XSS
• Blocking known malicious bots
• Rate limiting for login requests
• Centralized security policies
• Global application delivery
• Minimal application-code changes

Recommended architecture

                       Internet
                          |
                          v
                 Azure Front Door
                          |
                     WAF Policy
                   /     |      \
                  /      |       \
          Managed     Custom    Bot
           Rules       Rules   Protection
             |           |         |
             +-----------+---------+
                          |
                          v
                    Azure App Service

Why?

Azure Front Door provides global edge delivery and WAF can inspect incoming requests before they reach the application.

Managed rules provide protection against common web exploits.

Custom rules can address application-specific requirements such as rate limiting.

Bot protection can address malicious automated traffic.

The application itself can continue using its own authentication and authorization mechanisms.

25. Common WAF Mistakes

Mistake 1: Enabling WAF but not enabling appropriate managed rules

A WAF policy must actually contain rules that provide the intended protection.

Better: Verify that appropriate managed rules are assigned.

Mistake 2: Assuming Detection mode blocks attacks

Detection mode primarily monitors and logs matches.

Better: Use Detection for initial validation and tuning, then use Prevention when appropriate.

Mistake 3: Immediately disabling a managed rule after a false positive

This can reduce protection unnecessarily.

Better: Investigate the false positive and use a narrowly scoped exclusion when appropriate.

Mistake 4: Treating WAF as authentication

WAF does not replace identity and authorization controls.

Better: Use WAF alongside Microsoft Entra ID and appropriate application authorization.

Mistake 5: Assuming WAF provides complete DDoS protection

WAF and DDoS protection address different attack types.

Better: Use layered protection.

Mistake 6: Forgetting origin security

Putting WAF in front of an application does not automatically eliminate every alternate path to the origin.

Better: Secure the origin and prevent unintended bypass paths.

Mistake 7: Ignoring logs

A WAF that is never monitored may miss both attacks and false positives.

Better: Integrate WAF logging with Azure monitoring and establish an operational review process.

26. Azure WAF Decision Matrix

27. Key SC-500 Exam Concepts

When preparing for SC-500, remember these distinctions:

WAF

Protects web applications against common web attacks.

Managed rules

Microsoft-maintained rules for known attack patterns.

Custom rules

Administrator-defined conditions and actions.

Detection

Monitor and log WAF matches without enforcement.

Prevention

Enforce WAF actions, including blocking matched traffic.

Exclusions

Prevent specific request elements from being evaluated by selected WAF rules.

Rate limiting

Controls excessive request rates.

Bot protection

Helps identify and control malicious automated traffic.

Front Door WAF

Global, edge-based application protection.

Application Gateway WAF

Regional application-delivery and WAF capability.

DDoS protection

Addresses DDoS threats and complements WAF.

Authentication

Determines who the caller is; WAF does not replace it.

28. Final Takeaways

Azure Web Application Firewall is an important component of a defense-in-depth strategy for internet-facing web applications.

The most important concepts to remember are:

1. WAF protects web applications at the application layer.
2. Azure Front Door WAF operates globally at the edge.
3. Application Gateway WAF provides regional application-delivery protection.
4. Managed rules provide Microsoft-maintained protection against common attacks.
5. Custom rules address organization-specific requirements.
6. Detection mode monitors and logs; Prevention mode enforces.
7. Exclusions should be narrowly scoped to address false positives.
8. Rate limiting can help control excessive requests.
9. Bot protection can help identify malicious automated traffic.
10. WAF complements, rather than replaces, authentication, network security, and DDoS protection.
11. Securing the application origin is important so attackers cannot simply bypass the WAF.
12. WAF policies should be continuously monitored and tuned.

For SC-500, many questions are likely to test whether you can identify which security layer solves a particular problem, rather than simply knowing what WAF is.

Practice Exam Questions

Question 1

A company hosts a globally distributed customer-facing web application. Security architects want malicious HTTP requests to be inspected as close to the users as possible before traffic reaches the application’s origins.

Which solution should you recommend?

A. Azure Network Security Group

B. Azure Front Door with Azure Web Application Firewall

C. Azure Bastion

D. Azure Private DNS

Answer: B

Explanation

Azure Front Door provides global application delivery, and its WAF capability inspects incoming requests at Microsoft’s global edge locations. This allows web-application attacks to be filtered before they reach the origin.

An NSG operates at the network layer, Azure Bastion provides secure administrative access to VMs, and Private DNS provides name resolution.

Question 2

An organization has just deployed an Azure WAF policy containing managed rules. The security team wants to observe potential attacks and identify false positives before the WAF begins blocking legitimate customer requests.

Which WAF mode should they use initially?

A. Prevention

B. Disabled

C. Redirect

D. Detection

Answer: D

Explanation

Detection mode allows the organization to monitor and log WAF rule matches without taking enforcement action based on those matches. This makes it useful for initial deployment, testing, and tuning.

Prevention mode is appropriate when the organization is ready for enforcement.

Question 3

An organization’s Azure App Service receives legitimate API requests containing data that occasionally triggers a false positive in a managed WAF rule. The security team wants to preserve the managed rule while preventing the specific legitimate request attribute from triggering the rule.

What should the security team use?

A. Replace WAF with an NSG

B. Disable the entire managed rule set

C. Disable WAF

D. A WAF exclusion

Answer: D

Explanation

A WAF exclusion allows specific request attributes to be omitted from WAF evaluation while retaining the broader protection provided by the managed rule set.

Disabling the entire rule set or WAF would unnecessarily reduce security.

Question 4

A security engineer must protect a regional web application hosted in Azure. The application requires Layer 7 routing and is integrated into an Azure virtual network. The organization also wants WAF protection.

Which service is the most appropriate application-delivery platform?

A. Azure Bastion

B. Azure Front Door only

C. Azure Application Gateway with WAF

D. Azure Storage

Answer: C

Explanation

Application Gateway with WAF provides regional Layer 7 application delivery, routing, and WAF capabilities and integrates with Azure virtual networking.

Front Door is particularly suited to globally distributed application delivery at the Azure edge.

Question 5

A security team wants to prevent excessive requests to an expensive login API endpoint. They want the WAF to take action when a client exceeds a configured request threshold.

Which WAF capability should they configure?

A. TLS certificate binding

B. Rate-limit custom rule

C. Managed identity

D. Azure RBAC

Answer: B

Explanation

A rate-limit custom rule can evaluate the rate of incoming requests and take the configured action when the defined threshold is exceeded.

TLS certificates protect data in transit, managed identities provide workload identity, and RBAC controls Azure resource permissions.

Question 6

A company wants to protect an internet-facing application from SQL injection and cross-site scripting attacks without writing individual detection rules for every known attack pattern.

What should the security team configure?

A. Azure-managed WAF rules

B. Azure RBAC

C. Azure Bastion

D. A network security group

Answer: A

Explanation

Azure-managed WAF rules provide preconfigured protection against common web application vulnerabilities, including SQL injection and XSS.

This is one of the primary reasons to use a managed WAF rule set.

Question 7

An organization deploys Azure Front Door with WAF in front of an Azure App Service. However, the App Service still has an unintended publicly accessible path that allows clients to reach the application without passing through the intended Front Door security layer.

What is the primary security concern?

A. The WAF cannot inspect HTTPS traffic

B. Front Door cannot route to App Service

C. Azure RBAC has been disabled

D. Attackers may bypass the WAF by accessing the origin directly

Answer: D

Explanation

A WAF protects traffic that passes through the WAF-controlled path. If the origin remains directly accessible through another path, an attacker may attempt to bypass the WAF entirely.

Securing the application origin and eliminating unintended access paths is therefore an important defense-in-depth practice.

Question 8

A company wants to block requests originating from countries where it does not conduct business. It wants to implement this restriction at the WAF layer.

Which capability should it use?

A. Azure RBAC

B. Managed identity

C. Geo-filtering/custom geographic rule

D. Azure Key Vault

Answer: C

Explanation

WAF custom rules can use geographic conditions to restrict access based on the country or region associated with a client’s IP address.

RBAC, managed identity, and Key Vault address identity and secrets-management concerns rather than geographic HTTP request filtering.

Question 9

A security team notices that several low-severity WAF rules are matching the same request. The organization is using a supported WAF rule set that uses anomaly scoring.

What is the purpose of anomaly scoring?

A. Combine the severity of rule matches to determine whether a request reaches the blocking threshold

B. Authenticate the user making the request

C. Encrypt the HTTP request

D. Assign an Azure RBAC role to the request

Answer: A

Explanation

Supported WAF rule sets can use anomaly scoring, in which rule matches contribute scores based on their severity. The cumulative score can determine whether a request should be blocked when the WAF is operating in Prevention mode.

Anomaly scoring is a WAF inspection mechanism; it does not provide authentication, encryption, or RBAC.

Question 10

A security architect is designing layered protection for a public-facing web application. The architect wants one control to detect common HTTP attacks such as SQL injection and another control specifically designed to mitigate large-scale volumetric DDoS attacks.

Which combination is most appropriate?

A. NSG + Azure RBAC

B. Key Vault + Managed Identity

C. Azure Bastion + Private DNS

D. Azure WAF + DDoS Protection

Answer: D

Explanation

Azure WAF provides application-layer protection against common web attacks such as SQL injection and XSS, while DDoS Protection addresses DDoS threats at the network/traffic level.

These controls are complementary and represent a layered security approach for internet-facing applications.

Go to the SC-500 Exam Prep Hub main page