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 storage, databases, and networking (25–30%)
   --> Implement security for Azure network services
      --> Implement and configure Azure 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

Azure Firewall is used to centrally inspect and control network traffic entering, leaving, and moving between Azure networks. The exam focus includes deploying Azure Firewall, configuring firewall policies and rules, routing traffic through the firewall, enabling threat protection, and selecting the appropriate firewall SKU.

What is Azure Firewall?

Azure Firewall is a fully stateful, managed network security service for Azure. It provides centralized traffic filtering and inspection without requiring the organization to deploy and maintain firewall virtual machines.

Azure Firewall can inspect:

• North-south traffic, such as traffic entering or leaving Azure.
• East-west traffic, such as traffic moving between Azure virtual networks or subnets.
• Layer 3 and Layer 4 traffic using network rules.
• Layer 7 application traffic using application rules.
• Inbound traffic using destination network address translation (DNAT).
• Traffic associated with known malicious IP addresses and domains through threat intelligence filtering.

Azure Firewall includes built-in high availability and automatically scales within the limits of the selected SKU and deployment architecture.

Azure Firewall deployment models

Azure Firewall can be deployed in two primary architectures.

Hub virtual network deployment

In a hub-and-spoke architecture:

• Azure Firewall is deployed in a central hub virtual network.
• Spoke virtual networks contain application workloads.
• User-defined routes direct traffic from the spokes to the firewall.
• The firewall inspects the traffic before forwarding it to the destination.

A common design is:

Spoke VNet A
    |
    | User-defined route
    v
Hub VNet
Azure Firewall
    |
    v
Internet, on-premises, or another VNet

This model is useful when an organization wants centralized security controls for multiple virtual networks.

Secured virtual hub deployment

Azure Firewall can also be deployed in an Azure Virtual WAN secured virtual hub.

In this model:

• Virtual WAN provides the hub networking architecture.
• Azure Firewall provides centralized inspection.
• Virtual WAN routing capabilities simplify traffic forwarding.
• Azure Firewall Manager can centrally manage policies across secured virtual hubs.

A secured virtual hub is useful for larger environments that require centralized connectivity and security across branches, virtual networks, and hybrid locations.

Azure Firewall subnet requirements

For a traditional virtual network deployment, Azure Firewall must be placed in a dedicated subnet named:

AzureFirewallSubnet

The subnet must be at least /26. The subnet should not contain other resources.

The firewall subnet should be treated as an infrastructure subnet rather than an application subnet. Workload route tables should normally be associated with workload subnets, not with the firewall subnet, unless a documented forced-tunneling design requires otherwise.

Example hub virtual network

Hub VNet: 10.0.0.0/16
AzureFirewallSubnet: 10.0.0.0/26
GatewaySubnet:        10.0.1.0/27
Management subnet:    10.0.2.0/24

The actual address ranges depend on the organization’s network plan. The important exam concepts are that the firewall requires a dedicated subnet and that the subnet must provide sufficient address space.

Azure Firewall SKUs

Azure Firewall is available in three SKUs:

• Basic
• Standard
• Premium

Azure Firewall Basic

Basic is intended for smaller environments with simpler requirements.

Important characteristics include:

• Designed for small and medium-sized businesses.
• Recommended for environments with estimated throughput up to approximately 250 Mbps.
• Fixed scale capacity.
• Threat intelligence alert mode only.
• Does not provide the complete feature set available in Standard and Premium.

Azure Firewall Standard

Standard provides:

• Stateful Layer 3–Layer 7 filtering.
• Network and application rules.
• Threat intelligence filtering.
• Threat intelligence alert and deny mode.
• Web categories.
• FQDN filtering.
• Centralized firewall policy management.

Azure Firewall Premium

Premium provides the advanced capabilities of Standard plus features such as:

• Intrusion detection and prevention system (IDPS).
• TLS inspection.
• URL filtering.
• Additional advanced threat protection capabilities.

Premium should be selected when the organization needs deeper inspection of encrypted traffic or advanced signature-based threat detection.

SKU selection summary

The exact available features and limitations should always be checked against the current SKU comparison because Azure Firewall capabilities can change.

Azure Firewall versus network security groups

Azure Firewall and network security groups (NSGs) provide different types of protection.

NSGs should still be used for subnet and network-interface-level segmentation. Azure Firewall should be used when centralized inspection, application filtering, threat intelligence, or DNAT is required.

These services are complementary rather than mutually exclusive.

Azure Firewall rule types

Azure Firewall policies organize rules into three main categories:

1. DNAT rules
2. Network rules
3. Application rules

DNAT rules

DNAT rules control inbound traffic arriving through a firewall public IP address.

A DNAT rule translates a public destination IP address and port into a private destination IP address and port.

For example:

Internet client
    |
    | Firewall public IP: 203.0.113.10:443
    v
Azure Firewall DNAT
    |
    | Translated destination: 10.2.1.10:443
    v
Internal web server

DNAT rules are useful when publishing an internal application through a firewall public IP address.

A DNAT rule normally specifies:

• Source address.
• Destination firewall public IP.
• Destination port.
• Protocol.
• Translated destination address.
• Translated destination port.

DNAT should be used carefully because it creates an inbound access path into the network. The organization should restrict source addresses whenever possible and ensure that the destination application has its own authentication and authorization controls.

Network rules

Network rules operate at the network and transport layers.

They can filter traffic based on:

• Source IP address.
• Destination IP address.
• Source IP group.
• Destination IP group.
• Protocol.
• Destination port.
• Fully qualified domain name, where supported with the appropriate DNS configuration.

Typical examples include:

• Allowing TCP traffic from an application subnet to a database server on port 1433.
• Allowing UDP DNS traffic to an approved DNS server.
• Allowing HTTPS traffic to a specific destination IP.
• Blocking traffic between two application segments.

Network rules are appropriate when the requirement is based on IP addresses, ports, or protocols rather than the content or URL of an application request.

Application rules

Application rules operate at Layer 7 and can filter outbound or east-west traffic based on application-level information.

They can use:

• HTTP.
• HTTPS.
• Fully qualified domain names.
• URLs.
• Web categories, depending on the SKU and configuration.

For example, an application rule can allow a workload to access:

https://api.contoso.com

while denying access to other internet destinations.

Application rules are useful for controlling web traffic based on the destination hostname rather than only on destination IP addresses.

Firewall policy structure

An Azure Firewall Policy is a top-level resource containing firewall security and operational settings.

The policy hierarchy is:

Firewall Policy
    |
    +-- Rule collection group
            |
            +-- Rule collection
                    |
                    +-- Individual rules

Rule collection groups

Rule collection groups are the first level processed by the firewall. They have priorities that determine their processing order.

The default rule collection groups are:

Custom rule collection groups can be created with custom priorities. When custom groups are used to define processing logic, the organization should plan the priority order carefully and avoid creating confusing overlaps between default and custom groups.

Rule collections

A rule collection belongs to a rule collection group and contains rules of the same type.

Each rule collection has:

• A collection type.
• A priority.
• An action, such as allow or deny.

The action applies to the rules in the collection.

Individual rules

Individual rules define the actual traffic conditions, such as:

• Source.
• Destination.
• Protocol.
• Port.
• FQDN.
• URL.
• Web category.

Rules within a collection are evaluated in a top-down manner. If no rule allows the traffic, the traffic is denied by default.

Rule processing order

Azure Firewall processes traffic according to the firewall policy hierarchy.

At a high level:

1. Threat intelligence filtering is evaluated.
2. DNAT rules are processed for applicable inbound traffic.
3. Network rules are evaluated.
4. Application rules are evaluated.
5. Traffic that is not allowed is denied by default.

Threat intelligence rules are processed before NAT, network, and application rules.

The exact processing behavior can vary based on traffic type and rule configuration, so administrators should avoid relying only on the apparent order of rules in the portal. They should understand the rule collection group priorities and test the resulting behavior.

Default deny behavior

Azure Firewall uses a default-deny approach.

If traffic does not match an applicable allow rule, it is denied.

This supports a least-privilege network design:

1. Identify the required traffic.
2. Create narrowly scoped allow rules.
3. Avoid broad source and destination ranges.
4. Deny unnecessary traffic.
5. Monitor denied traffic.
6. Add exceptions only when justified.

A common mistake is to create a broad allow rule such as:

Source: Any
Destination: Any
Protocol: Any
Port: Any
Action: Allow

Such a rule defeats much of the value of centralized firewall filtering and should be avoided unless there is a carefully documented reason.

Threat intelligence filtering

Azure Firewall can use Microsoft threat intelligence feeds to identify traffic associated with known malicious:

• IP addresses.
• Fully qualified domain names.
• URLs.

Threat intelligence can operate in different modes:

• Off.
• Alert only.
• Alert and deny.

In alert-only mode, the firewall generates alerts but does not block the matching traffic.

In alert and deny mode, the firewall blocks matching traffic and generates alerts.

Basic supports alert mode only, while Standard and Premium support alert and deny mode. Threat intelligence rules are evaluated before NAT, network, and application rules.

Threat intelligence allowlist

False positives can occur. Azure Firewall supports an allowlist for approved IP addresses or ranges.

The allowlist should be managed carefully. Adding an address to the allowlist bypasses threat intelligence filtering for that address, so entries should be:

• Justified.
• Documented.
• Reviewed periodically.
• Removed when no longer required.

DNS proxy and FQDN filtering

FQDN-based filtering depends on reliable DNS resolution.

Azure Firewall can provide DNS proxy functionality so that clients use the firewall for DNS resolution. This helps ensure that the firewall and the client use consistent DNS answers when evaluating FQDN-based rules.

DNS proxy is especially important when:

• Network rules use FQDNs.
• Application rules depend on hostname resolution.
• Private DNS zones are used.
• DNS responses differ between clients and the firewall.
• The organization uses custom DNS servers.

Without a consistent DNS design, a rule may appear correct but fail because the client or firewall resolves the destination differently.

Azure Firewall can also use:

• FQDN tags for commonly required Azure and Microsoft services.
• Service tags in network rules.
• FQDN filtering in network rules when the required DNS proxy configuration is enabled.

Managed tags reduce the need to manually maintain changing Microsoft service IP ranges.

Routing traffic through Azure Firewall

Creating a firewall does not automatically cause all workload traffic to pass through it.

The organization must configure routing.

User-defined routes

In a hub-and-spoke architecture, a route table can direct traffic from a spoke subnet to the firewall’s private IP address.

For example:

Address prefix: 0.0.0.0/0
Next hop type: Virtual appliance
Next hop IP: Azure Firewall private IP

This route directs internet-bound traffic through the firewall.

Additional routes may be required for:

• Traffic between spoke virtual networks.
• Traffic to on-premises networks.
• Traffic to other regions.
• Traffic to private endpoints.
• Forced-tunneling scenarios.

Important routing considerations

When configuring routes:

• Avoid routing loops.
• Ensure return traffic has a valid path.
• Verify that peering settings support the intended architecture.
• Confirm that the firewall can reach the destination.
• Avoid associating workload routes with the firewall subnet unless required by the design.
• Test both directions of communication.

A firewall rule cannot permit traffic that never reaches the firewall. Conversely, routing traffic through the firewall does not guarantee that the firewall will allow it.

Both routing and firewall policy must be correct.

Inbound traffic and DNAT

To publish an internal service through Azure Firewall:

1. Assign a public IP address to the firewall.
2. Create a DNAT rule.
3. Specify the public destination port.
4. Specify the private translated destination address.
5. Specify the translated destination port.
6. Ensure the backend application is reachable.
7. Restrict source addresses where possible.
8. Monitor the resulting traffic.

Example:

Public firewall IP: 203.0.113.20
Public port:        443
Private server IP:  10.2.1.20
Private port:       443
Protocol:           TCP

The firewall translates traffic destined for 203.0.113.20:443 to 10.2.1.20:443.

The backend server should not be considered secure merely because it is behind DNAT. It should still use:

• Host-based firewall rules.
• NSGs.
• Secure configuration.
• Application authentication.
• TLS.
• Patching.
• Monitoring.

Outbound traffic and SNAT

Azure Firewall can perform source network address translation (SNAT) for outbound traffic.

This allows internal workloads to access external destinations through the firewall’s public IP address.

High-volume outbound workloads can exhaust available SNAT ports. To address this, organizations can consider:

• Additional firewall public IP addresses.
• Azure NAT Gateway integration, where supported by the deployment architecture.
• NAT Gateway V2 for appropriate zone-redundant designs.

NAT Gateway should not be combined with secured virtual hub firewalls in architectures where that combination is unsupported. SNAT capacity should be planned based on the number of concurrent outbound connections and the behavior of the workloads.

Forced tunneling

Forced tunneling routes internet-bound traffic through an on-premises security appliance or another centralized inspection path instead of allowing the firewall to send it directly to the internet.

Forced tunneling may be required when:

• Corporate security appliances must inspect internet traffic.
• Internet access must originate from on-premises.
• Regulatory requirements require centralized egress.
• The organization uses a hybrid security architecture.

Azure Firewall forced tunneling uses a management network interface and a dedicated:

AzureFirewallManagementSubnet

This separates firewall management traffic from customer traffic.

Forced tunneling must be designed carefully because incorrect routes can interrupt firewall management or create routing loops.

TLS inspection

Azure Firewall Premium supports TLS inspection.

TLS inspection allows the firewall to decrypt, inspect, and re-encrypt supported encrypted traffic so that security controls can evaluate traffic that would otherwise remain encrypted.

TLS inspection requires:

• Azure Firewall Premium.
• Appropriate certificate configuration.
• Certificate storage and management, commonly using Azure Key Vault.
• Correct client trust configuration.
• Careful handling of applications that use certificate pinning or do not support interception.

TLS inspection should be used only where justified because it introduces additional complexity and can affect privacy, compatibility, and performance.

Private connectivity alone does not make encrypted inspection unnecessary. If the security requirement is to inspect HTTPS content, TLS inspection or an equivalent application-layer control may be required.

IDPS in Azure Firewall Premium

Azure Firewall Premium includes a signature-based intrusion detection and prevention system.

IDPS can identify suspicious or malicious network activity using Microsoft-managed signatures.

Organizations can:

• Detect known attack patterns.
• Block high-confidence threats.
• Tune signature behavior.
• Investigate alerts.
• Reduce false positives.
• Monitor attack attempts against workloads.

IDPS is particularly useful when the organization needs more than basic IP, port, protocol, and hostname filtering.

Web categories and URL filtering

Azure Firewall Standard and Premium support web category filtering.

Web categories allow administrators to control access to groups of websites, such as:

• Gambling.
• Social networking.
• Malware.
• Adult content.
• Streaming media.
• Newly registered domains.

Premium provides additional URL filtering capabilities.

Web categories can reduce administrative effort compared with maintaining large lists of individual domains. However, category-based filtering should be combined with threat intelligence, application rules, and an acceptable-use policy.

Azure Firewall Manager

Azure Firewall Manager provides centralized management for Azure Firewall policies.

It can be used to:

• Create and manage firewall policies.
• Apply common rules to multiple firewalls.
• Manage firewalls across subscriptions.
• Manage firewalls in virtual networks.
• Manage firewalls in secured virtual hubs.
• Establish policy inheritance.

A parent policy can contain common organizational rules, while child policies can add environment-specific rules.

For example:

Parent policy
    |
    +-- Block known malicious destinations
    +-- Require threat intelligence
    +-- Allow approved DNS
    |
    +-- Child policy: Production
    |       +-- Production-specific rules
    |
    +-- Child policy: Development
            +-- Development-specific rules

Policy inheritance can improve consistency, but administrators must understand how parent and child settings interact before deploying changes to production.

Monitoring Azure Firewall

Azure Firewall should be monitored continuously.

Useful monitoring sources include:

• Azure Monitor metrics.
• Diagnostic settings.
• Log Analytics.
• Resource logs.
• Azure Activity Log.
• Firewall Policy Analytics.
• Microsoft Defender for Cloud.
• Microsoft Sentinel.

Important events to monitor include:

• Allowed traffic.
• Denied traffic.
• DNAT traffic.
• Threat intelligence detections.
• IDPS alerts.
• Policy changes.
• Firewall configuration changes.
• Backend connectivity failures.
• Unexpected outbound destinations.
• SNAT port exhaustion.
• Firewall health and capacity.

Diagnostic logs should be sent to an appropriate Log Analytics workspace when centralized investigation and correlation are required.

Azure Policy and governance

Azure Policy can help enforce organizational requirements for Azure Firewall.

Examples include policies that:

• Require threat intelligence to be enabled.
• Require multi-Availability Zone deployment.
• Require Firewall Policy Analytics.
• Restrict firewall configurations.
• Require encrypted traffic.
• Identify virtual networks that should have Azure Firewall deployed.
• Encourage migration from classic rules to Firewall Policy.

Azure Policy can use effects such as:

• Audit.
• Deny.
• DeployIfNotExists.
• Modify.

A policy should be tested in audit mode before using deny in production, especially when existing deployments may not comply with the new requirement.

Security best practices

Use a centralized policy

Use Firewall Policy rather than maintaining inconsistent classic rules across individual firewalls.

Apply least privilege

Allow only the required:

• Sources.
• Destinations.
• Ports.
• Protocols.
• FQDNs.
• URLs.

Enable threat intelligence

Use alert and deny mode when supported and appropriate.

Use Premium when advanced inspection is required

Choose Premium when the organization needs:

• IDPS.
• TLS inspection.
• Advanced URL filtering.

Enable DNS proxy for relevant FQDN filtering

Ensure that the firewall and clients use a consistent DNS resolution path.

Use NSGs in addition to Azure Firewall

NSGs provide local segmentation and defense in depth.

Secure management access

Limit who can:

• Create firewalls.
• Modify policies.
• Add public IP addresses.
• Change DNAT rules.
• Approve network changes.
• Configure threat intelligence exceptions.

Use Microsoft Entra ID, Azure RBAC, privileged identity management, and just-in-time administrative access where appropriate.

Protect firewall configuration

Use:

• Azure Policy.
• Resource locks.
• Infrastructure as code.
• Change control.
• Activity logs.
• Policy versioning.
• Backup and recovery procedures.

Avoid unnecessary public exposure

Do not publish internal services through DNAT unless there is a documented business requirement. When inbound publication is necessary, restrict source addresses and secure the backend service.

Common troubleshooting scenarios

Traffic is not reaching the firewall

Check:

• The workload subnet’s route table.
• The next-hop IP address.
• Virtual network peering.
• Effective routes.
• Return routing.
• Network security groups.
• Whether the traffic type is supported by the intended route.

Traffic reaches the firewall but is denied

Check:

• Rule collection group priority.
• Rule collection priority.
• Source and destination values.
• Protocol and port.
• FQDN resolution.
• Threat intelligence mode.
• Whether the rule is in the correct rule collection type.
• Whether a deny rule is evaluated first.

FQDN rules do not work

Check:

• DNS proxy configuration.
• DNS server settings.
• DNS forwarding.
• Firewall DNS resolution.
• Whether the application uses the expected hostname.
• Whether the destination is resolved to changing IP addresses.

DNAT does not work

Check:

• Firewall public IP address.
• DNAT rule.
• Translated destination address.
• Translated port.
• Backend service availability.
• NSG rules.
• Operating system firewall.
• Load balancer configuration.
• Return routing.

Clients cannot access the internet

Check:

• Default route.
• Firewall application or network rules.
• DNS resolution.
• SNAT configuration.
• Firewall public IP availability.
• Threat intelligence detections.
• NAT port exhaustion.
• Forced-tunneling routes.

Firewall management becomes unavailable

Check:

• Forced-tunneling configuration.
• Management subnet.
• Management route.
• Network security rules.
• Firewall subnet changes.
• User-defined routes applied to infrastructure subnets.

Common exam traps

• Azure Firewall is stateful; NSGs are not a replacement for centralized firewall inspection.
• Creating Azure Firewall does not automatically route traffic through it.
• A route to the firewall does not automatically allow traffic.
• A firewall rule does not help if routing bypasses the firewall.
• DNAT is used for inbound destination translation.
• SNAT is used for outbound source translation.
• Application rules are Layer 7 rules.
• Network rules are primarily Layer 3 and Layer 4 rules.
• Threat intelligence is processed before NAT, network, and application rules.
• Basic supports threat intelligence alert mode only.
• Premium is required for IDPS and TLS inspection.
• FQDN filtering depends on correct DNS behavior.
• The firewall subnet must be dedicated and named AzureFirewallSubnet.
• A private connection does not eliminate the need for TLS or application authentication.
• Azure Firewall and NSGs are complementary controls.
• Firewall Policy provides centralized organization of rule collection groups, rule collections, and rules.
• Azure Firewall Manager can manage policies across multiple firewalls and secured virtual hubs.
• Public DNAT exposure must be secured separately from the firewall configuration.

Practice Exam Questions

Question 1

An organization has three spoke virtual networks and wants all internet-bound traffic from the spokes to be centrally inspected.

What should the organization configure?

A. A service endpoint on each spoke subnet
B. A user-defined route from each spoke subnet to the Azure Firewall private IP address
C. A public IP address on each virtual machine
D. A network security group allowing outbound internet traffic

Answer: B

Explanation: Azure Firewall does not automatically receive all workload traffic. User-defined routes can direct traffic from spoke subnets to the firewall’s private IP address for inspection.

Question 2

A company needs to inspect encrypted HTTPS traffic and detect malicious network patterns using signature-based detection.

Which Azure Firewall SKU should it select?

A. Basic
B. Standard
C. Basic with threat intelligence enabled
D. Premium

Answer: D

Explanation: Azure Firewall Premium provides advanced capabilities including TLS inspection and IDPS. Basic and Standard do not provide the complete set of Premium inspection features.

Question 3

A security administrator wants to allow an application subnet to access only api.contoso.com over HTTPS.

Which rule type is most appropriate?

A. Application rule
B. DNAT rule
C. Network security group rule only
D. Resource lock

Answer: A

Explanation: Application rules operate at Layer 7 and can filter HTTP and HTTPS traffic using fully qualified domain names.

Question 4

An administrator creates an allow rule for outbound traffic, but the traffic never reaches Azure Firewall.

What is the most likely cause?

A. Routing does not direct the traffic through the firewall
B. The firewall policy contains an application rule
C. Threat intelligence is enabled
D. The firewall is stateful

Answer: A

Explanation: Firewall rules apply only to traffic that reaches the firewall. A route table or other routing configuration must direct the workload traffic to the firewall.

Question 5

A company wants to publish an internal web server through an Azure Firewall public IP address.

Which configuration should be used?

A. DNAT rule
B. Application rule
C. Service endpoint
D. Private DNS zone only

Answer: A

Explanation: DNAT rules translate traffic arriving at a firewall public IP address to a private destination address and port.

Question 6

An organization wants Azure Firewall to block traffic to known malicious IP addresses and domains rather than only generate alerts.

Which configuration is required?

A. Threat intelligence disabled
B. Threat intelligence alert-only mode
C. A network security group on the firewall subnet
D. Threat intelligence alert and deny mode on Standard or Premium

Answer: D

Explanation: Alert and deny mode blocks traffic associated with known malicious destinations. Basic supports alert mode only, while Standard and Premium support alert and deny mode.

Question 7

A firewall application rule uses an FQDN, but traffic is not consistently filtered because the firewall and clients receive different DNS responses.

What should the administrator investigate?

A. DNS proxy and DNS forwarding configuration
B. DNAT port translation
C. Resource locks
D. The firewall’s public IP prefix

Answer: A

Explanation: FQDN filtering depends on consistent DNS resolution. DNS proxy can help ensure that the firewall and clients use consistent DNS answers.

Question 8

Which rule type should be used to allow TCP traffic from an application subnet to a database server on port 1433?

A. Application rule
B. DNAT rule
C. Network rule
D. Threat intelligence rule

Answer: C

Explanation: Network rules filter traffic using network and transport information such as source, destination, protocol, and port.

Question 9

An organization needs to manage firewall policies across multiple subscriptions and secured virtual hubs.

Which service should it use?

A. Azure Bastion
B. Azure Private DNS
C. Azure Network Watcher
D. Azure Firewall Manager

Answer: D

Explanation: Azure Firewall Manager provides centralized management of Azure Firewall policies across supported firewall deployments, including virtual network firewalls and secured virtual hubs.

Question 10

A company wants to require that all Azure Firewall policies have threat intelligence enabled.

Which service is best suited to enforce this requirement consistently?

A. Azure Policy
B. Azure Load Balancer
C. Azure VPN Gateway
D. Azure Private Link

Answer: A

Explanation: Azure Policy can audit or deny noncompliant Azure Firewall configurations and can be used to enforce organizational security standards such as enabling threat intelligence.

Go to the SC-500 Exam Prep Hub main page