Tag: Azure Security

azure, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026October 10, 2026

Implement and configure Azure Firewall (SC-500 Exam Prep)

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

Requirement	Appropriate choice
Small environment with basic firewall requirements	Basic
Standard centralized network and application filtering	Standard
Threat intelligence alert and deny mode	Standard or Premium
IDPS	Premium
TLS inspection	Premium
Advanced URL filtering	Premium
Web categories	Standard or Premium

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.

Feature	Azure Firewall	Network security group
Scope	Centralized network security service	Subnet or network interface
Inspection	Layer 3–Layer 7, depending on rule type	Primarily Layer 3–Layer 4
FQDN filtering	Supported	Not a general equivalent
Centralized policy	Supported	Distributed across subnets and interfaces
Threat intelligence	Supported	Not built in as a comparable firewall feature
Application rules	Supported	Not supported
DNAT	Supported	Not supported
Typical purpose	Centralized inspection and egress/inbound control	Basic segmentation and traffic filtering

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:

DNAT rules
Network rules
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:

Rule collection group	Default priority
Default DNAT	100
Default Network	200
Default Application	300

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:

Threat intelligence filtering is evaluated.
DNAT rules are processed for applicable inbound traffic.
Network rules are evaluated.
Application rules are evaluated.
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:

Identify the required traffic.
Create narrowly scoped allow rules.
Avoid broad source and destination ranges.
Deny unnecessary traffic.
Monitor denied traffic.
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:

Assign a public IP address to the firewall.
Create a DNAT rule.
Specify the public destination port.
Specify the private translated destination address.
Specify the translated destination port.
Ensure the backend application is reachable.
Restrict source addresses where possible.
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

azure, Microsoft Certification, SC-500, security October 10, 2026

Evaluate effective security rules by using Azure Network Watcher diagnostics (SC-500 Exam Prep)

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
      --> Evaluate effective security rules by using Azure Network Watcher diagnostics

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.

Overview

Azure Network Watcher provides diagnostic tools that help security engineers determine why network traffic is allowed or denied in Azure. For the SC-500 exam, an important capability is evaluating the effective security rules applied to a virtual machine’s network interface and using diagnostic tools to identify the rule responsible for a connectivity decision.

These capabilities are especially useful when a workload cannot connect to another resource, a management connection such as SSH or RDP fails, or an application unexpectedly has access to a network destination.

Azure Network Watcher can evaluate network security group rules and, where applicable, administrative network rules configured through Azure Virtual Network Manager. It can also help distinguish a security-rule problem from a routing, application, or service-availability problem.

What Are Effective Security Rules?

An effective security rule is the combined set of security rules that actually applies to a network interface.

The effective rules can include:

Rules from an NSG associated with the subnet.
Rules from an NSG associated with the network interface.
Default NSG security rules.
Applicable administrative rules configured through Azure Virtual Network Manager.
Both inbound and outbound rules.

The effective rules view is therefore different from looking at only one NSG in isolation. A rule configured on the subnet-level NSG may affect a virtual machine even if the network interface itself has a different NSG.

Example

A virtual machine might have:

A subnet-level NSG allowing TCP port 443.
A network-interface-level NSG denying TCP port 443.
A default outbound rule allowing Internet traffic.

Looking at only the subnet-level NSG would not provide a complete picture. The effective security rules view helps you determine which rules are applied to the selected network interface.

Why Effective Security Rules Matter

Effective security rules are useful for both troubleshooting and security governance.

Troubleshooting

You can use effective security rules to investigate:

Failed SSH or RDP connections.
Blocked application traffic.
Unexpected inbound exposure.
Unexpected outbound Internet access.
Communication failures between virtual machines.
Connectivity problems involving Azure Bastion.
Conflicting rules at the subnet and network-interface levels.

Security auditing

Security teams can compare the effective rules applied to network interfaces against an approved security baseline. This can help identify:

Unintended open ports.
Overly broad source or destination ranges.
Unexpected administrative rules.
Missing deny rules.
Differences between the intended and actual security configuration.

Azure Network Watcher also allows effective security rules to be downloaded as a CSV file, which can support documentation, review, and compliance activities.

Azure Network Watcher Diagnostic Tools

Several Network Watcher capabilities work together when evaluating security rules.

1. IP Flow Verify

IP Flow Verify determines whether a specific packet is allowed or denied by the security rules applied to a virtual machine.

You specify the characteristics of the traffic, including:

Direction: inbound or outbound.
Protocol: TCP or UDP.
Local IP address.
Local port.
Remote IP address.
Remote port.

The tool returns:

Whether access is allowed or denied.
The security rule responsible for the decision.
The NSG containing the rule, when applicable.

For example, you can test whether a source IP address is allowed to connect to a virtual machine over TCP port 3389. If the traffic is denied, IP Flow Verify can identify the rule causing the denial.

Important limitation

IP Flow Verify tests TCP and UDP traffic. It does not test ICMP traffic. To evaluate ICMP-related rules, use NSG diagnostics instead. IP Flow Verify also focuses on rules applied to a virtual machine’s network interface and is not the appropriate tool for testing rules applied to virtual machine scale sets.

Example scenario

A user cannot connect to a VM using RDP.

You can run IP Flow Verify with:

Direction: Inbound.
Protocol: TCP.
Local IP: The VM’s private IP address.
Local port: 3389.
Remote IP: The user’s source IP address.
Remote port: The client’s source port.

If the result is:

Access denied by DenyAllInBound

you know that the traffic is being blocked by the default inbound deny rule because no higher-priority rule allows the connection.

2. Effective Security Rules

The Effective security rules feature displays the aggregated inbound and outbound rules applied to a network interface.

It helps answer questions such as:

Which NSG rules apply to this VM?
Is the rule associated with the subnet or network interface?
Is an administrative rule affecting the traffic?
Which source and destination prefixes are associated with a rule?
Is the traffic allowed by a custom rule or a default rule?

In the Azure portal, effective security rules are grouped into inbound and outbound sections. You can select an individual rule to view additional details, including associated address prefixes.

Azure portal navigation

A typical portal workflow is:

Open the affected virtual machine.
Select Networking or Network settings.
Select the virtual machine’s network interface.
Select Effective security rules.
Review the inbound and outbound rules.
Expand or select rules to inspect their details.

If the virtual machine has multiple network interfaces, select the specific interface involved in the traffic.

Azure CLI

You can retrieve effective NSG information for a network interface by using:

			
az network nic list-effective-nsg \
  --resource-group <resource-group> \
  --name <nic-name>

Azure PowerShell

The equivalent PowerShell command is:

			
Get-AzEffectiveNetworkSecurityGroup `
  -NetworkInterfaceName "<nic-name>" `
  -ResourceGroupName "<resource-group>"

These commands provide the combined view of the rules applied to the network interface, including subnet-level rules, network-interface-level rules, and default rules.

3. NSG Diagnostics

NSG diagnostics checks whether traffic is allowed or denied by the security and administrative rules applied to a virtual machine.

It is useful when you need to evaluate traffic characteristics that may not be covered by IP Flow Verify, including ICMP traffic.

NSG diagnostics can help identify:

The rule allowing the traffic.
The rule denying the traffic.
Whether the decision comes from a custom rule.
Whether the decision comes from a default rule.
Whether the issue is related to inbound or outbound filtering.

Microsoft’s troubleshooting guidance demonstrates using NSG diagnostics to investigate a connection failure involving Azure Bastion and a virtual machine.

4. Connection Troubleshoot

Connection troubleshoot evaluates connectivity between a source and destination. It is broader than simply checking an individual NSG rule.

It can help identify:

Whether the destination is reachable.
Whether a security rule allows or denies the traffic.
Whether a route exists.
The next hop used for the traffic.
Whether the destination VM is running or listening.
Whether the problem is related to routing rather than security filtering.

You can test connectivity from a virtual machine to:

Another virtual machine.
An IP address.
A URI.
An FQDN.
An on-premises destination, depending on the network configuration.

For example, if a VM cannot connect to another VM over TCP port 3389, Connection troubleshoot can show that the traffic is allowed by the NSG but that no valid route exists. This prevents you from incorrectly changing security rules when the actual problem is routing.

Azure CLI example

			
az network watcher test-connectivity \
  --resource-group <resource-group> \
  --source-resource <source-vm> \
  --dest-address <destination-address> \
  --protocol TCP \
  --dest-port 443

		

Connection troubleshoot can also be used with a destination IP address:

			
az network watcher test-connectivity \
  --resource-group <resource-group> \
  --source-resource <source-vm> \
  --dest-address 10.10.10.10 \
  --protocol TCP \
  --dest-port 3389

		

5. Next Hop

Although Next hop does not directly evaluate NSG rules, it is valuable when diagnosing connectivity problems.

Next hop determines how Azure routes traffic from a virtual machine to a specified destination. It reports information such as:

Next-hop type.
Next-hop IP address.
Route table information.

Possible next-hop types include:

Virtual network.
Internet.
Virtual network gateway.
Virtual appliance.
None.

If a security rule allows traffic but the next hop is None, the problem may be a missing route rather than an NSG denial.

How Azure Evaluates NSG Rules

Understanding NSG evaluation is essential when interpreting Network Watcher results.

Inbound traffic

For inbound traffic, Azure evaluates the rules associated with the subnet and network interface.

The effective result depends on the applicable rules and their priorities. A matching rule with a higher priority takes precedence over a matching rule with a lower priority.

Outbound traffic

Outbound traffic is evaluated against outbound rules associated with the network interface and subnet.

A VM may be able to receive traffic from a source but still be unable to initiate outbound traffic if an outbound rule denies it.

Default rules

NSGs include default rules such as:

Allow virtual network inbound.
Allow Azure Load Balancer inbound.
Deny all inbound.
Allow virtual network outbound.
Allow Internet outbound.
Deny all outbound.

Custom rules with priorities from 100 through 4096 are evaluated before the default rules. If no custom rule matches, a default rule may determine the result.

Example

Suppose a VM receives an inbound TCP connection on port 80:

A custom rule allows TCP 80 from a specific source with priority 200.
A default inbound deny rule has lower precedence.

The custom allow rule wins because it matches the traffic and is evaluated before the default deny rule.

If no custom allow rule matches, the default inbound deny rule blocks the traffic.

Effective Rules Versus Configured Rules

The distinction between configured and effective rules is a common exam concept.

Concept	Description
Configured rules	Rules defined in a particular NSG
Effective rules	Combined rules actually applied to a network interface
Subnet-level NSG	Applies to resources within the subnet
NIC-level NSG	Applies to the specific network interface
Default rules	Built-in rules used when no higher-priority custom rule determines the result
Administrative rules	Rules applied through Azure Virtual Network Manager

When troubleshooting, do not inspect only the NSG that appears most obvious. Always inspect the effective rules for the affected network interface.

Recommended Troubleshooting Workflow

Use the following process when a VM or application cannot communicate.

Step 1: Define the exact traffic

Record:

Source VM or source IP.
Destination VM, IP, URI, or FQDN.
Direction.
Protocol.
Destination port.
Source port, if relevant.
Expected result.

A vague test such as “the server cannot connect” is less useful than:

VM-A cannot connect to VM-B over TCP port 443.

Step 2: Run IP Flow Verify

Use IP Flow Verify to determine whether the packet is allowed or denied.

If the result is Access denied, record:

The rule name.
The NSG name.
The direction.
The traffic parameters.

Step 3: Review effective security rules

Inspect the effective inbound or outbound rules on the affected network interface.

Look for:

A custom deny rule.
A missing allow rule.
An unexpected subnet-level rule.
A network-interface-level rule.
A default deny rule.
An administrative rule.

Step 4: Check rule priority

If multiple rules could match the traffic, compare their priorities.

Remember:

Lower numerical priority values are evaluated first.
A rule with priority 100 is evaluated before a rule with priority 500.
A broad deny rule with a higher priority can override a more specific allow rule with a lower priority.

Step 5: Check routing

If the security rules allow the traffic, use:

Next hop to inspect routing.
Connection troubleshoot to test the complete path.

Check for:

Missing routes.
Incorrect user-defined routes.
An unexpected virtual appliance.
Incorrect peering or gateway configuration.
Asymmetric routing.
A destination that is not running.

Step 6: Check the destination service

If the traffic is allowed and the route is correct, verify that:

The destination VM is running.
The application is listening on the expected port.
The operating system firewall allows the traffic.
The service is bound to the correct IP address.
The destination application is healthy.

Network Watcher can identify Azure network filtering and routing issues, but it does not replace application-level troubleshooting.

Step 7: Re-test after changes

After modifying an NSG rule or route:

Run the same diagnostic test again.
Confirm that the decision changed as expected.
Verify that the new rule did not create unintended exposure.
Document the reason for the change.

Common Troubleshooting Scenarios

Scenario 1: RDP is blocked

A user cannot connect to a VM over TCP port 3389.

Possible causes include:

No inbound allow rule for the user’s source IP.
A higher-priority deny rule.
The default DenyAllInBound rule.
An NSG associated with the subnet.
An NSG associated with the NIC.
The VM’s operating system firewall.
RDP not running on the VM.

Use IP Flow Verify first to determine whether Azure NSG rules are blocking the connection.

Scenario 2: Internet access is blocked

A VM cannot access an external website over TCP port 443.

Possible causes include:

An outbound NSG deny rule.
A missing route.
A firewall or virtual appliance.
DNS resolution failure.
The destination website being unavailable.

Use IP Flow Verify for outbound filtering, then use Connection troubleshoot and Next hop to evaluate routing and reachability.

Scenario 3: Traffic is unexpectedly allowed

A VM is accessible from a source that should be blocked.

Review:

Effective inbound rules.
Broad source prefixes such as *.
Rules allowing VirtualNetwork.
Rules allowing Internet.
Administrative rules.
Rule priorities.
NSGs applied at both subnet and NIC levels.

Do not assume that the absence of a custom allow rule means traffic is blocked. Default rules may allow certain traffic.

Scenario 4: Azure Bastion cannot connect to a VM

Azure Bastion requires appropriate connectivity to the target VM. A misconfigured NSG can block the connection.

Review the effective inbound rules on the target VM’s network interface and confirm that the required traffic from the Bastion subnet is allowed. NSG diagnostics can help identify the blocking rule.

Security Best Practices

Use least-privilege rules

Avoid broad rules such as:

Any source to Any destination.
Any protocol.
Any port.
Any Internet source.

Instead, restrict rules by:

Source IP or service tag.
Destination IP or subnet.
Protocol.
Destination port.
Business requirement.

Use explicit rule names

Use descriptive names such as:

Allow-AppSubnet-To-Database-1433
Deny-Internet-To-Management
Allow-BastionSubnet-To-VM-RDP

Clear names make Network Watcher results easier to interpret.

Review effective rules regularly

A subnet-level or NIC-level NSG change may alter the effective security posture of a VM. Periodically review effective rules for sensitive workloads.

Treat default rules as part of the security model

Do not review only custom rules. Default rules can determine whether traffic is allowed or denied.

Use diagnostics before changing rules

Do not immediately create a new allow rule when connectivity fails. First determine:

Whether the traffic is actually denied by an NSG.
Which rule caused the decision.
Whether routing or the destination service is the real problem.

Avoid unnecessary public exposure

If a management connection is required, prefer controlled access methods such as Azure Bastion, private connectivity, or restricted source ranges rather than exposing management ports broadly to the Internet.

Export and document results

Use the effective rules export capability to support:

Security reviews.
Change management.
Compliance evidence.
Troubleshooting records.
Baseline comparisons.

Important Exam Distinctions

IP Flow Verify versus Effective Security Rules

IP Flow Verify answers: “Is this specific packet allowed or denied, and which rule caused the result?”
Effective security rules answers: “What combined rules are applied to this network interface?”

IP Flow Verify versus Connection Troubleshoot

IP Flow Verify focuses on security-rule evaluation.
Connection troubleshoot evaluates the broader connection path, including reachability and routing.

NSG diagnostics versus Next hop

NSG diagnostics evaluates security filtering.
Next hop evaluates routing.

Network Watcher versus the operating system firewall

Network Watcher can identify Azure-level filtering and routing problems. It does not automatically prove that the guest operating system firewall or application is configured correctly.

Configured NSG versus effective NSG

A configured NSG is only one source of rules. Effective rules represent the aggregate configuration that applies to the network interface.

Practice Exam Questions

Question 1

A security engineer must determine whether a specific TCP connection from an external IP address to a virtual machine is allowed or denied by Azure network security rules. Which Network Watcher feature should the engineer use?

A. Next hop
B. Connection troubleshoot
C. IP Flow Verify
D. Traffic Analytics

Answer: C

Explanation: IP Flow Verify evaluates a specific traffic flow using the direction, protocol, local and remote IP addresses, and local and remote ports. It returns whether access is allowed or denied and identifies the applicable security rule.

Question 2

A virtual machine has one NSG associated with its subnet and another NSG associated with its network interface. The security engineer wants to view the complete set of inbound and outbound rules applied to the VM. What should the engineer use?

A. Effective security rules
B. Azure Monitor metrics
C. Next hop
D. Connection monitor

Answer: A

Explanation: Effective security rules display the aggregated rules from the subnet-level NSG, network-interface-level NSG, default rules, and applicable administrative rules.

Question 3

A VM cannot connect to another VM over TCP port 443. IP Flow Verify reports that the traffic is allowed. Which tool should the engineer use next to determine whether the traffic is being routed correctly?

A. Azure Policy
B. Microsoft Defender for Cloud
C. NSG diagnostics
D. Next hop

Answer: D

Explanation: Next hop identifies the route and next-hop type used for traffic to a destination. If the security rules allow the traffic, the next step is to investigate routing.

Question 4

A security engineer runs IP Flow Verify for an inbound TCP connection to port 3389. The result is Access denied by DenyAllInBound. What does this indicate?

A. The VM is powered off.
B. No higher-priority rule allowed the inbound traffic.
C. The destination route is missing.
D. The operating system firewall blocked the connection.

Answer: B

Explanation: DenyAllInBound is a default inbound NSG rule. The result indicates that no applicable custom allow rule matched the traffic before the default deny rule was reached.

Question 5

Which traffic type cannot be tested by IP Flow Verify?

A. ICMP
B. TCP
C. UDP
D. TCP over IPv4

Answer: A

Explanation: IP Flow Verify tests TCP and UDP traffic. It does not test ICMP traffic. NSG diagnostics can be used when ICMP rule evaluation is required.

Question 6

A VM’s effective security rules show that outbound traffic is allowed, but Connection troubleshoot reports that the destination is unreachable and the next-hop type is None. What is the most likely issue?

A. A higher-priority outbound NSG deny rule
B. An invalid DNS record only
C. A missing or incorrect route
D. A missing inbound NSG rule on the destination

Answer: C

Explanation: A next-hop type of None indicates that Azure does not have a valid route to the destination. The issue is routing rather than the outbound NSG decision.

Question 7

A security engineer wants to identify whether an NSG rule associated with the subnet or the network interface is blocking access to a VM. Which approach is most appropriate?

A. Review only the subnet-level NSG.
B. Review only the NIC-level NSG.
C. Review the VM’s public IP configuration.
D. Run IP Flow Verify and inspect the effective security rules.

Answer: D

Explanation: The effective rules view combines the rules applied from both the subnet and network interface. IP Flow Verify can then identify the rule responsible for a specific traffic decision.

Question 8

Which statement correctly describes Azure Network Watcher Connection troubleshoot?

A. It only lists the NSGs associated with a VM.
B. It tests connectivity and can provide information about filtering and routing.
C. It automatically changes a denied NSG rule to allow traffic.
D. It replaces the guest operating system firewall.

Answer: B

Explanation: Connection troubleshoot evaluates the broader connection path. It can identify reachability problems, security-rule decisions, and routing issues, but it does not replace the guest firewall or automatically correct configuration.

Question 9

A custom inbound NSG rule allows TCP port 22 from a trusted administrator IP address with priority 200. Another custom rule denies all inbound TCP traffic with priority 100. What is the result for an SSH connection from the trusted IP address?

A. The allow rule wins because it is more specific.
B. Both rules are evaluated and traffic is allowed.
C. The deny rule wins because it has the higher evaluation priority.
D. The default inbound rule determines the result.

Answer: C

Explanation: Lower numerical priority values are evaluated first. The deny rule with priority 100 is evaluated before the allow rule with priority 200 and therefore blocks the connection.

Question 10

A VM can connect to a destination according to IP Flow Verify, but the application still fails to communicate. Which action should be performed next?

A. Use Connection troubleshoot and verify the route, destination service, and application listener.
B. Delete all NSGs from the VM.
C. Add an allow rule for all Internet traffic.
D. Disable the VM’s operating system firewall permanently.

Answer: A

Explanation: If IP Flow Verify allows the traffic, the problem may involve routing, service availability, the application listener, DNS, or the operating system firewall. Connection troubleshoot and destination-side checks are more appropriate than broadly weakening security controls.

Summary

For the SC-500 exam, remember the following:

Effective security rules show the combined rules applied to a network interface.
Rules can come from subnet-level NSGs, NIC-level NSGs, default rules, and applicable administrative rules.
IP Flow Verify evaluates a specific TCP or UDP flow and identifies the rule allowing or denying it.
NSG diagnostics can evaluate security rules and is useful for scenarios such as ICMP traffic.
Connection troubleshoot evaluates the broader connection path.
Next hop helps identify routing problems.
A denied connection is not always caused by an NSG; routing, the operating system firewall, and the destination application must also be considered.
Lower numerical NSG priorities are evaluated first.
Always inspect effective rules rather than reviewing only one NSG in isolation.
Use diagnostics before modifying security rules to avoid unnecessary or overly broad access.

Go to the SC-500 Exam Prep Hub main page

azure, Microsoft Certification, SC-500, security October 10, 2026

Implement platform-level security configurations in Azure SQL (SC-500 Exam Prep)

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 databases
      --> Implement platform-level security configurations in Azure SQL

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

The SC-500 exam expects you to understand how to secure Azure SQL Database and Azure SQL Managed Instance at the platform level.

Platform-level security focuses on controls that protect the database service and its connections, including:

Authentication
Authorization
Network isolation
Encryption in transit
Encryption at rest
Customer-managed keys
Dynamic data masking
Row-level security
Microsoft Defender for SQL
Auditing and monitoring

These controls should be implemented using a defense-in-depth approach. No single control protects every layer of a database workload.

1. Understand the Azure SQL Security Model

Azure SQL security can be viewed in several layers:

Security layer	Primary purpose	Examples
Identity and authentication	Establish who or what is connecting	Microsoft Entra ID, SQL authentication, managed identities
Authorization	Determine what the identity can do	Azure RBAC, database roles, permissions
Network security	Control where connections originate	Private endpoints, virtual network rules, firewall rules
Encryption in transit	Protect data while moving between systems	TLS
Encryption at rest	Protect stored database files and backups	Transparent Data Encryption
Encryption in use	Protect especially sensitive values while being processed	Always Encrypted
Data visibility	Limit what users can see	Dynamic data masking, row-level security
Monitoring and detection	Identify suspicious or unauthorized activity	Auditing, Microsoft Defender for SQL

Azure SQL Database is a platform as a service offering. Microsoft manages many underlying platform responsibilities, such as patching, backups, and infrastructure maintenance, but customers remain responsible for configuring access, network exposure, data protection, and monitoring.

2. Configure Microsoft Entra Authentication

What Is Microsoft Entra Authentication?

Microsoft Entra authentication allows users and applications to connect to Azure SQL using identities managed by Microsoft Entra ID.

Supported identities can include:

Individual users
Microsoft Entra groups
Service principals
Managed identities
Applications using Microsoft Entra access tokens

Microsoft Entra authentication provides centralized identity management and can integrate with capabilities such as multifactor authentication, Conditional Access, and identity lifecycle management.

Configure a Microsoft Entra Administrator

Before Microsoft Entra identities can be used to administer an Azure SQL logical server, configure a Microsoft Entra administrator for the server.

The Microsoft Entra administrator can be:

A Microsoft Entra user
A Microsoft Entra group

Using a group is often preferable for operational continuity because membership can be managed without changing the SQL server’s configured administrator whenever an individual administrator changes roles.

The Microsoft Entra administrator is configured at the logical-server level. After the administrator is configured, that identity can connect and create database users or assign appropriate database permissions.

Create Microsoft Entra Database Users

A Microsoft Entra user or group can be created inside an Azure SQL database using T-SQL similar to:

			
CREATE USER [Finance Analysts]
FROM EXTERNAL PROVIDER;

The user can then be added to an appropriate database role or granted specific permissions.

For example:

			
ALTER ROLE db_datareader
ADD MEMBER [Finance Analysts];

However, built-in roles such as db_datareader may grant more access than necessary. A more secure design is to create custom database roles and grant only the required permissions.

Microsoft Entra-Only Authentication

Microsoft Entra-only authentication disables SQL authentication for the logical server or supported Azure SQL resource.

This can reduce the risks associated with:

SQL usernames and passwords
Password reuse
Password theft
Password storage in connection strings
Credential rotation
Brute-force password attacks

Before enabling Microsoft Entra-only authentication, verify that all applications, scripts, tools, and integration services support Microsoft Entra authentication.

An application that still depends on a SQL login and password may stop connecting after SQL authentication is disabled.

3. Use Managed Identities for Applications

Managed identities are recommended for Azure-hosted applications that need to connect to Azure SQL.

A managed identity allows an Azure resource to authenticate without storing a password, client secret, or connection-string credential in application code.

Common examples include:

Azure App Service
Azure Functions
Azure Virtual Machines
Azure Kubernetes Service
Azure Logic Apps
Azure Automation
Other Azure services that support managed identities

Typical Configuration Process

Enable a system-assigned or user-assigned managed identity on the application.
Configure a Microsoft Entra administrator for the SQL logical server.
Connect to the target database as an appropriate administrator.
Create a database user for the managed identity.
Grant the identity only the required database permissions.
Configure the application to request and use a Microsoft Entra access token.

Example:

			
CREATE USER [my-function-app]
FROM EXTERNAL PROVIDER;

Then grant only the permissions required by the application.

System-Assigned versus User-Assigned Managed Identity

Type	Characteristics
System-assigned	Tied to the lifecycle of one Azure resource
User-assigned	Separate Azure resource that can be assigned to multiple supported resources

A system-assigned identity is useful when the identity should exist only as long as the application exists.

A user-assigned identity is useful when several applications need to share the same identity or when the identity lifecycle should be independent of a particular application.

4. Understand SQL Authentication

SQL authentication uses a SQL login and password rather than Microsoft Entra credentials.

It may still be required for:

Legacy applications
Cross-platform applications that do not support Microsoft Entra authentication
Migration scenarios
Certain administrative or automation tools

If SQL authentication must be used:

Use strong, unique passwords.
Store secrets in a secure secret-management service.
Avoid embedding credentials in source code.
Rotate passwords regularly.
Restrict the login’s permissions.
Monitor failed authentication attempts.
Avoid using highly privileged accounts for application connections.

SQL authentication should not be confused with Azure RBAC. Azure RBAC controls Azure resource management operations, while SQL authentication and database permissions control access inside the database.

5. Configure Network Isolation

Network security controls determine which clients can reach Azure SQL.

The primary options include:

Public endpoint with firewall rules
Virtual network rules
Private endpoints
Disabling public network access

Public Endpoint and Firewall Rules

Azure SQL Database can expose a public endpoint protected by firewall rules.

Firewall rules can be configured at:

Server level
Database level

Server-level firewall rules

A server-level firewall rule applies to all databases on the logical server.

This is useful when the same trusted source must access multiple databases.

Database-level firewall rules

A database-level firewall rule applies only to a specific database.

This provides more granular control when different databases require different network access rules.

By default, connections are rejected unless an applicable firewall rule allows them. The most secure configuration is to permit only the required IP addresses or ranges and avoid broad rules.

“Allow Azure Services and Resources to Access This Server”

This setting allows connections from Azure services and resources, including resources that may not belong to the same subscription.

Although convenient, it can create broader network exposure than intended.

Use it only when required and understand that it is not equivalent to allowing only one specific application or subnet.

Private Endpoints

A private endpoint assigns a private IP address from an Azure virtual network to the Azure SQL resource.

With a private endpoint:

Traffic can remain on private Azure networking.
The database is accessed through a private IP address.
Public internet exposure can be reduced.
Private DNS configuration is required for reliable name resolution.
Network access can be controlled using virtual network and subnet security controls.

For a strongly isolated design, configure a private endpoint and disable public network access when the workload does not require public connectivity.

Important Exam Distinction

A private endpoint does not automatically guarantee that every client uses it.

You must also consider:

DNS resolution
Routing
Network security rules
Whether public network access remains enabled
Whether clients can reach the private endpoint’s virtual network

6. Protect Data in Transit with TLS

Azure SQL encrypts connections in transit using Transport Layer Security.

Encryption in transit protects data as it travels between:

Applications and Azure SQL
Administrative tools and Azure SQL
Integration services and Azure SQL

TLS helps reduce the risk of:

Network eavesdropping
Credential interception
Data interception
Man-in-the-middle attacks

Client connection strings should require encryption and should not blindly trust the server certificate.

For example, application drivers should be configured to:

Encrypt the connection
Validate the server certificate
Avoid insecure certificate-trust settings

Azure SQL services enforce encrypted connections in transit.

7. Enable Transparent Data Encryption

What Is Transparent Data Encryption?

Transparent Data Encryption, or TDE, encrypts data at rest.

TDE protects:

Database files
Transaction log files
Backup files

TDE is transparent to applications. Applications do not normally need to change their SQL statements or data-access code to use TDE.

New Azure SQL databases are encrypted by default. You should still verify the configuration and understand whether the organization requires customer-managed keys instead of Microsoft-managed keys.

TDE and Customer-Managed Keys

By default, Azure SQL uses Microsoft-managed encryption keys.

For regulated workloads or organizations requiring greater control, configure a customer-managed key in Azure Key Vault.

Customer-managed keys can provide control over:

Key rotation
Key access
Key revocation
Key auditing
Key lifecycle management

The customer-managed key protects or wraps the database encryption key. It does not mean that every database operation directly uses the Key Vault key.

Requirements for Customer-Managed TDE

A typical implementation includes:

Create or select an Azure Key Vault.
Configure appropriate network and access controls for the vault.
Create or import a key.
Grant the Azure SQL server identity access to the key.
Configure the customer-managed key for the logical server or supported database.
Monitor key usage and expiration.
Plan for key rotation and recovery.

If the SQL service cannot access the configured key, database availability or encryption operations may be affected. Key lifecycle management is therefore a critical operational responsibility.

TDE versus Always Encrypted

Feature	TDE	Always Encrypted
Protects data at rest	Yes	Yes
Protects data in transit	Through TLS	Through TLS
Protects data from database administrators	Generally no	Yes, for protected columns
Requires application changes	Usually no	Often yes
Protects selected columns while in use	No	Yes

TDE protects the database storage layer. Always Encrypted is designed for highly sensitive columns where the database engine should not have access to plaintext values.

8. Understand Dynamic Data Masking

Dynamic Data Masking, or DDM, limits the exposure of sensitive values to users who do not have permission to view the underlying data.

Examples of sensitive values include:

Credit card numbers
Telephone numbers
Email addresses
Social Security numbers
Personal identifiers

A masked value may appear similar to:

XXXX-XXXX-XXXX-1234

The exact masking format depends on the configured masking function.

Important Characteristics

Dynamic data masking:

Does not encrypt the underlying data.
Does not modify the stored value.
Is applied when data is returned to a user.
Helps reduce accidental exposure.
Is configured at the database level.
Is not a replacement for database permissions.

Privileged users or users with sufficient permissions may still be able to view the unmasked data.

When to Use Dynamic Data Masking

Use DDM when:

Support personnel need limited access to production data.
Developers need to troubleshoot applications without seeing sensitive values.
Analysts need to see data structure but not full identifiers.
A database contains sensitive information that should be obscured for some users.

Do not rely on DDM as the only protection for confidential data. Combine it with least-privilege permissions, encryption, auditing, and appropriate application security.

9. Implement Row-Level Security

Row-Level Security, or RLS, restricts which rows a user can access.

RLS is especially useful for:

Multitenant applications
Regional data separation
Department-level access
Customer-specific data
Business-unit restrictions

For example, a sales representative may be allowed to see only rows belonging to their assigned region.

How RLS Works

RLS uses a security predicate that determines whether a row can be accessed.

A common design is:

Identify the current user or application identity.
Compare that identity with a column in the table.
Allow or deny access to each row based on the result.

RLS can restrict:

Reading rows
Inserting rows
Updating rows
Deleting rows

Example Concept

A table might contain:

			
CustomerId
CustomerName
TenantId

A security predicate can ensure that a user only sees rows where TenantId matches the tenant associated with the current session.

RLS versus Dynamic Data Masking

Requirement	Correct feature
Hide part of a value	Dynamic Data Masking
Prevent users from seeing other tenants’ rows	Row-Level Security
Encrypt database files at rest	Transparent Data Encryption
Encrypt selected columns so database administrators cannot view plaintext	Always Encrypted
Restrict who can connect to the database	Firewall or private endpoint
Detect suspicious SQL activity	Microsoft Defender for SQL

RLS controls which rows are visible. It does not encrypt the data and should not be treated as an encryption mechanism.

10. Configure Microsoft Defender for SQL

Microsoft Defender for SQL provides threat detection and security assessment capabilities for Azure SQL workloads.

It can help identify suspicious activity such as:

SQL injection attempts
Unusual access patterns
Potential data exfiltration
Brute-force activity
Suspicious database behavior
Potential exploitation attempts

Defender for SQL can also provide vulnerability assessment and security recommendations. Alerts can be investigated through Microsoft Defender for Cloud.

Defender for SQL versus Auditing

These features serve different purposes:

Feature	Main purpose
Auditing	Records database activity for investigation, compliance, and analysis
Defender for SQL	Detects suspicious activity and generates security alerts
Vulnerability assessment	Identifies potential database weaknesses
Dynamic Data Masking	Obscures sensitive values from certain users
TDE	Encrypts data at rest

Defender for SQL does not replace firewall rules, identity controls, encryption, or database permissions.

11. Configure SQL Auditing

SQL auditing records database events and sends them to a selected destination.

Supported destinations can include:

Azure Storage
Azure Monitor Logs
Event Hubs

Auditing can help with:

Regulatory compliance
Security investigations
Tracking privileged activity
Investigating failed access attempts
Identifying unusual database operations
Establishing an activity history

Audit logs should be protected from unauthorized modification and retained according to the organization’s compliance and investigation requirements.

Recommended Auditing Practices

Enable auditing for production databases.
Send logs to a centralized destination.
Restrict access to audit logs.
Configure retention appropriate to business and regulatory requirements.
Monitor failed logins and privileged operations.
Correlate audit events with identity and network logs.
Use Microsoft Sentinel or other monitoring workflows when centralized investigation is required.

12. Apply Least Privilege

Least privilege means granting users and applications only the permissions they require.

Apply least privilege at multiple levels:

Azure resource level

Use Azure RBAC to control who can:

Create SQL servers
Modify networking
Change firewall rules
Configure auditing
Configure Defender for SQL
Change encryption settings

Database level

Use database roles and permissions to control who can:

Read tables
Insert data
Update data
Delete data
Execute stored procedures
Alter database objects

Data level

Use:

Row-Level Security
Dynamic Data Masking
Column-level permissions
Views
Stored procedures

Avoid granting broad roles such as db_owner to application identities unless absolutely necessary.

13. Platform-Level Security Implementation Example

Suppose a company hosts a financial application in Azure SQL Database.

The application requirements are:

The application runs in Azure App Service.
Only the application and administrators should reach the database.
Developers must not see full customer payment information.
Database activity must be audited.
The organization requires control over encryption keys.

A suitable design would be:

Enable a managed identity on the App Service.
Create a Microsoft Entra database user for the identity.
Grant only the required database permissions.
Configure a private endpoint for Azure SQL.
Disable public network access if public connectivity is unnecessary.
Configure private DNS so the application resolves the SQL server privately.
Verify TLS encryption for all connections.
Enable TDE and configure a customer-managed key in Azure Key Vault.
Apply dynamic data masking to selected sensitive columns.
Use RLS if users must see only records associated with their tenant or business unit.
Enable SQL auditing and send logs to Azure Monitor Logs or Azure Storage.
Enable Microsoft Defender for SQL for threat detection and vulnerability assessment.
Use Azure Policy to enforce required security configurations where supported.

This design combines identity, network isolation, encryption, data protection, and monitoring rather than relying on one security feature.

14. Common Exam Traps

Trap 1: Confusing Azure RBAC with database permissions

Azure RBAC controls Azure resource management. It does not automatically grant permission to query tables.

Trap 2: Assuming TDE protects plaintext from administrators

TDE protects data at rest. It does not prevent an authorized database administrator from querying plaintext data.

Trap 3: Confusing DDM with encryption

Dynamic Data Masking hides returned values from some users. It does not encrypt the stored data.

Trap 4: Confusing RLS with DDM

RLS restricts rows. DDM obscures values.

Trap 5: Assuming a private endpoint automatically disables public access

A private endpoint provides private connectivity, but public network access may remain enabled unless explicitly disabled.

Trap 6: Assuming Microsoft Entra authentication automatically grants database access

The identity must also exist in the database and have appropriate permissions.

Trap 7: Granting Storage-style roles to SQL users

Azure SQL database access is not granted by assigning unrelated Azure Storage roles. Use appropriate Azure RBAC roles for management operations and SQL permissions for database operations.

Trap 8: Disabling SQL authentication without checking dependencies

Legacy applications may stop working if they depend on SQL logins and passwords.

Trap 9: Assuming auditing detects and blocks attacks

Auditing records activity. Microsoft Defender for SQL provides threat detection and alerts. Neither replaces preventive access controls.

Trap 10: Assuming customer-managed keys eliminate all security responsibilities

Customer-managed keys increase control, but the organization must manage key permissions, rotation, availability, and recovery.

15. Security Checklist

Use the following checklist when implementing platform-level security for Azure SQL:

Configure a Microsoft Entra administrator.
Prefer Microsoft Entra authentication over SQL authentication.
Use managed identities for Azure-hosted applications.
Disable SQL authentication when all dependencies support Microsoft Entra authentication.
Assign database permissions using least privilege.
Use private endpoints for workloads requiring private connectivity.
Disable public network access when it is not required.
Restrict firewall rules to necessary sources.
Require encrypted connections.
Verify certificate validation in client applications.
Confirm that TDE is enabled.
Use customer-managed keys when required by compliance or organizational policy.
Protect encryption keys in Azure Key Vault.
Use Always Encrypted for especially sensitive columns.
Use Dynamic Data Masking to reduce accidental data exposure.
Use Row-Level Security for tenant- or row-specific restrictions.
Enable SQL auditing.
Enable Microsoft Defender for SQL.
Review vulnerability assessment recommendations.
Monitor privileged activity and failed authentication attempts.
Use Azure Policy to enforce security baselines.
Test application connectivity after security changes.

Practice Exam Questions

Question 1

An Azure App Service must connect to an Azure SQL database. The security team does not want database passwords or client secrets stored in application settings.

What should you implement?

A. A SQL login with a complex password
B. A public database endpoint with an IP firewall rule
C. A managed identity with a Microsoft Entra database user
D. A database-level firewall rule

Correct answer: C

Explanation: A managed identity allows the App Service to authenticate through Microsoft Entra ID without storing a password or client secret. The identity must also be created as a database user and granted the required permissions.

Question 2

A company wants to ensure that employees can connect to Azure SQL only from a private Azure virtual network. The database must not be reachable through its public endpoint.

Which configuration best meets the requirement?

A. Enable a private endpoint and disable public network access
B. Add the company’s public IP address to the server firewall
C. Enable the “Allow Azure services and resources to access this server” setting
D. Enable SQL authentication and require strong passwords

Correct answer: A

Explanation: A private endpoint provides private connectivity through a virtual network. Disabling public network access ensures that clients cannot continue using the public endpoint. DNS and routing must also be configured correctly.

Question 3

A database contains customer credit card information. Developers need to troubleshoot queries but must not see the complete credit card numbers.

Which feature is most appropriate?

A. Transparent Data Encryption
B. Dynamic Data Masking
C. Private endpoint
D. Microsoft Defender for SQL

Correct answer: B

Explanation: Dynamic Data Masking obscures sensitive values returned to users who do not have permission to view the unmasked data. TDE protects data at rest, while a private endpoint controls network connectivity.

Question 4

A multitenant application stores records for many customers in the same table. Each customer must see only records belonging to its own tenant.

Which feature should be implemented?

A. Transparent Data Encryption
B. Dynamic Data Masking
C. Row-Level Security
D. SQL auditing

Correct answer: C

Explanation: Row-Level Security restricts access to individual rows based on the user, tenant, or session context. Dynamic Data Masking hides portions of values but does not prevent users from seeing rows belonging to other tenants.

Question 5

An organization requires control over the encryption keys used to protect Azure SQL databases. The keys must be rotated and audited by the organization.

What should be configured?

A. Customer-managed keys for Transparent Data Encryption in Azure Key Vault
B. Dynamic Data Masking on all database columns
C. A server-level firewall rule
D. A stored procedure that encrypts query results

Correct answer: A

Explanation: Customer-managed keys for TDE allow the organization to control key lifecycle activities such as rotation, revocation, and auditing. The keys are stored and managed in Azure Key Vault.

Question 6

An administrator assigns a user the Contributor role on an Azure SQL logical server. The user can manage the server resource but cannot query tables in a database.

Why?

A. Azure SQL does not support database permissions
B. Contributor is a management-plane role and does not automatically grant database data access
C. The user must enable public network access
D. The user must use SQL authentication instead of Microsoft Entra authentication

Correct answer: B

Explanation: Azure RBAC management roles control Azure resource operations. Database access requires an appropriate database user, role membership, or explicit SQL permission.

Question 7

A security engineer wants to record database activity for compliance investigations. The organization needs to send the events to a centralized log-analysis platform.

Which feature should be configured?

A. Dynamic Data Masking
B. Row-Level Security
C. Transparent Data Encryption
D. SQL auditing with Azure Monitor Logs

Correct answer: D

Explanation: SQL auditing records database events and can send them to Azure Monitor Logs. Auditing supports compliance, investigation, and analysis of database activity.

Question 8

A company wants to detect SQL injection attempts and unusual database access patterns.

Which service should be enabled?

A. Azure Private Link
B. Azure Key Vault
C. Microsoft Defender for SQL
D. Dynamic Data Masking

Correct answer: C

Explanation: Microsoft Defender for SQL provides threat detection for suspicious database activity, including potential SQL injection and anomalous access patterns. It complements, but does not replace, preventive security controls.

Question 9

An organization has migrated all applications to Microsoft Entra authentication. It wants to prevent applications from using SQL usernames and passwords.

Which configuration should be used?

A. Microsoft Entra-only authentication
B. Dynamic Data Masking
C. Database-level firewall rules
D. SQL auditing

Correct answer: A

Explanation: Microsoft Entra-only authentication disables SQL authentication and requires supported connections to use Microsoft Entra authentication. Applications must be tested before the setting is enabled.

Question 10

A security team wants to protect Azure SQL data stored on disk and in database backups. Applications should not require code changes.

Which feature should be used?

A. Row-Level Security
B. Transparent Data Encryption
C. Microsoft Defender for SQL
D. Microsoft Entra Conditional Access

Correct answer: B

Explanation: Transparent Data Encryption encrypts database files, transaction logs, and backups at rest without normally requiring application changes. It does not restrict which rows users can query or detect suspicious activity.

Final Summary

For the SC-500 exam, remember the following distinctions:

Microsoft Entra authentication establishes identity.
Managed identities eliminate the need to store application credentials.
Database roles and permissions control what users and applications can do inside the database.
Private endpoints provide private connectivity.
Firewall rules restrict network sources.
TLS protects data in transit.
TDE protects data at rest.
Customer-managed keys provide additional control over encryption keys.
Always Encrypted protects selected sensitive values from database administrators.
Dynamic Data Masking obscures sensitive values.
Row-Level Security restricts access to rows.
SQL auditing records database activity.
Microsoft Defender for SQL detects suspicious database activity and provides security assessment capabilities.
Azure Policy and least privilege help enforce consistent security across the environment.

The most secure Azure SQL design combines these controls according to the workload’s identity, network, data sensitivity, compliance, and monitoring requirements.

Go to the SC-500 Exam Prep Hub main page

azure, Microsoft Certification, SC-500, security October 10, 2026

Implement and manage network security groups (NSGs) and application security groups (ASGs) (SC-500 Exam Prep)

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 manage network security groups (NSGs) and application security groups (ASGs)

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.

Overview

Network security groups (NSGs) and application security groups (ASGs) are foundational Azure networking features used to control traffic within and between Azure virtual networks.

Network security groups provide traffic filtering through inbound and outbound security rules.
Application security groups allow administrators to organize virtual machines and network interfaces according to application roles rather than relying on individual IP addresses.

Together, NSGs and ASGs support defense in depth, network segmentation, least-privilege access, and easier security-rule management.

An NSG can be associated with:

A subnet
A network interface card (NIC)
Both a subnet and a NIC

When an NSG is associated with a subnet, its rules apply to the resources in that subnet. When it is associated with a NIC, its rules apply to the traffic for that network interface.

1. Understand Network Security Groups

A network security group is an Azure resource containing security rules that allow or deny network traffic.

Each rule can evaluate traffic based on:

Source
Source port
Destination
Destination port
Protocol
Direction
Priority
Action

Supported protocols include:

The action is either:

Allow
Deny

For example, an NSG rule could allow HTTPS traffic from the Internet to a web server while denying direct inbound access to the database tier.

Example security rule

Property	Example
Name	Allow-HTTPS
Direction	Inbound
Priority	100
Source	Internet
Source port	*
Destination	Web server subnet
Destination port	443
Protocol	TCP
Action	Allow

A lower priority number has higher precedence. For example, priority 100 is evaluated before priority 200.

2. NSG Default Rules

Every NSG contains default security rules. These rules cannot be deleted, but custom rules can override them by using a higher priority.

Common default inbound rules include:

Allow traffic from the VirtualNetwork service tag
Allow traffic from the AzureLoadBalancer service tag
Deny all other inbound traffic

Common default outbound rules include:

Allow traffic to the VirtualNetwork service tag
Allow traffic to the Internet
Deny all other outbound traffic

The default rules are evaluated after custom rules. Therefore, a custom rule with a priority lower than the default deny rule can allow traffic that would otherwise be denied.

Important exam point

NSGs are not automatically “deny all” in every direction. They include default rules that permit certain virtual-network and outbound Internet traffic. Security administrators should explicitly review and override these defaults when stricter controls are required.

3. Inbound and Outbound Rule Evaluation

NSGs filter both inbound and outbound traffic.

Inbound traffic

For a virtual machine with NSGs at both the subnet and NIC levels:

Azure evaluates the subnet-level NSG.
Azure evaluates the NIC-level NSG.
Traffic must be allowed by both NSGs.

Outbound traffic

For outbound traffic:

Azure evaluates the NIC-level NSG.
Azure evaluates the subnet-level NSG.
Traffic must be allowed by both NSGs.

The effective result is the combined set of applicable rules. A deny rule in either NSG can prevent traffic from flowing.

Example

Suppose:

The subnet NSG allows inbound TCP 443.
The NIC NSG denies inbound TCP 443.

The traffic is denied because both NSGs must permit the traffic.

Similarly:

The subnet NSG allows outbound TCP 1433.
The NIC NSG denies outbound TCP 1433.

The connection is denied.

4. NSG Rule Priority

Each custom NSG rule must have a unique priority number.

Lower numbers have higher priority.
Rules are evaluated in priority order.
Evaluation stops when a matching rule is found.
A later rule cannot override an earlier matching rule.

Example

Priority	Rule	Action
100	Allow TCP 443 from Internet	Allow
110	Deny all inbound traffic	Deny

HTTPS traffic is allowed because the priority 100 rule is evaluated first.

If the rules were reversed:

Priority	Rule	Action
100	Deny all inbound traffic	Deny
110	Allow TCP 443 from Internet	Allow

The HTTPS allow rule would never be reached for matching traffic.

Best practices

Reserve priority ranges for different application tiers.
Use descriptive rule names.
Avoid overlapping rules.
Place specific rules before broad rules.
Avoid using unnecessarily permissive rules such as Any for both source and destination.
Document why each rule exists.

5. Source and Destination Options

NSG rules can use several types of source and destination values.

Any

Matches all addresses.

Use this only when broad access is intentionally required.

IP addresses or CIDR ranges

You can specify:

A single IP address
Multiple IP addresses
A subnet range
Multiple CIDR ranges

Example:

10.10.1.0/24

Service tags

A service tag represents a group of IP address prefixes associated with an Azure service or category of traffic.

Examples include:

VirtualNetwork
Internet
AzureLoadBalancer
AzureCloud
Storage
AzureKeyVault

Microsoft maintains the IP prefixes represented by service tags and updates them as Azure addresses change. This avoids manually maintaining large lists of IP addresses.

Application security groups

An ASG can be used as the source or destination of an NSG rule. This allows rules to be based on application roles instead of IP addresses.

For example:

			
Source ASG: Asg-Web
Destination ASG: Asg-Database
Destination port: 1433
Protocol: TCP
Action: Allow

		

This rule allows members of the web application group to communicate with members of the database group over TCP port 1433.

6. Network Security Group Association

An NSG can be associated with a subnet, a NIC, or both.

Subnet-level association

A subnet-level NSG is useful when a common policy should apply to all resources in the subnet.

Examples:

Deny inbound Internet traffic to a private application subnet.
Allow communication from a shared management subnet.
Restrict outbound traffic from a database subnet.

NIC-level association

A NIC-level NSG is useful when a particular virtual machine requires additional controls beyond the subnet policy.

Examples:

A management server requires SSH access.
A specific application server needs an additional inbound port.
A sensitive VM requires stricter outbound restrictions.

Recommended design

Use subnet-level NSGs for broad segmentation and NIC-level NSGs for workload-specific restrictions. Avoid creating unnecessarily complicated combinations that are difficult to troubleshoot.

7. Understand Application Security Groups

An application security group is a logical grouping of network interfaces.

ASGs allow administrators to define security rules according to application architecture, such as:

Web servers
Application servers
Database servers
Management servers
Monitoring servers

Instead of creating rules based on individual IP addresses, you can create rules based on group membership.

Example application groups

			
Asg-Web
Asg-App
Asg-Database
Asg-Management

A rule could allow:

			
Asg-Web → Asg-App → TCP 8080
Asg-App → Asg-Database → TCP 1433
Asg-Management → Asg-Web → TCP 22

This design is easier to maintain when virtual machines are added, removed, or assigned new IP addresses.

ASGs are logical groupings; they do not themselves filter traffic. The filtering is performed by NSG rules that reference the ASGs.

8. ASG Constraints

Important ASG constraints include:

An ASG contains network interfaces, not entire virtual machines directly.
All NICs in an ASG must be in the same virtual network.
An ASG cannot contain NICs from different virtual networks.
If an NSG rule uses an ASG as both source and destination, the referenced ASGs must contain NICs in the same virtual network.
A NIC can belong to multiple ASGs.
An ASG does not automatically grant access; a matching NSG rule is still required.

The location and virtual-network requirements should be considered when designing application groups.

9. ASGs and Dynamic Application Membership

ASGs are especially useful when application membership changes frequently.

For example, an organization may have:

Three web servers today
Six web servers next month
Different private IP addresses after redeployment

If the web server NICs are members of Asg-Web, the NSG rule can remain unchanged as servers are added or removed.

The administrator only needs to update ASG membership.

Benefits

Reduces dependence on hard-coded IP addresses
Simplifies rule maintenance
Supports application-centric segmentation
Makes security intent easier to understand
Reduces the number of rules required
Helps maintain consistent policies during scaling

Microsoft recommends using ASGs and service tags where appropriate to reduce rule complexity.

10. Example Three-Tier Application Design

Consider a three-tier application:

			
Internet
   |
   v
Web tier
   |
   v
Application tier
   |
   v
Database tier

		

Create the following ASGs:

Asg-Web
Asg-App
Asg-Database

Then configure NSG rules such as:

Priority	Source	Destination	Port	Action
100	Internet	Asg-Web	443	Allow
110	Asg-Web	Asg-App	8080	Allow
120	Asg-App	Asg-Database	1433	Allow
130	Asg-Management	Asg-Web	22	Allow
4000	Any	Any	Any	Deny

This approach prevents direct Internet access to the application and database tiers.

The database tier does not need to allow traffic from the entire virtual network. It only needs to allow traffic from the application tier on the required port.

11. Service Tags Versus ASGs

Service tags and ASGs solve different problems.

Feature	Service tags	Application security groups
Represents	Azure service IP ranges or traffic categories	Application network interfaces
Example	`Storage`, `Internet`, `AzureLoadBalancer`	`Asg-Web`, `Asg-Database`
Main purpose	Simplify access to Azure services	Simplify application segmentation
Managed by	Microsoft-managed IP prefix updates	Customer-managed membership
Common use	Allow traffic from Azure Storage	Allow web servers to access database servers

Use service tags when the source or destination is an Azure service or well-defined traffic category. Use ASGs when the source or destination is a group of application workloads.

12. Augmented Security Rules

Augmented security rules allow multiple values to be specified in a single rule.

For example, one rule can contain:

Multiple source IP addresses
Multiple destination IP addresses
Multiple ports
Port ranges

This can reduce the number of individual rules required.

Example:

			
Source ports: *
Destination ports: 80, 443, 8080
Protocol: TCP
Action: Allow

Augmented rules should be used carefully. Combining unrelated access requirements into one rule can make the security policy harder to understand. Where possible, use service tags and ASGs to express the security intent more clearly.

13. Managing NSGs and ASGs

NSGs and ASGs can be managed through:

Azure portal
Azure PowerShell
Azure CLI
Azure Resource Manager templates
Bicep
Terraform

Typical management tasks include:

Create an NSG.
Create an ASG.
Associate the NSG with a subnet or NIC.
Add NICs to the ASG.
Create inbound and outbound rules.
Test connectivity.
Review effective security rules.
Update or remove obsolete rules.

Azure CLI examples

Create an NSG:

			
az network nsg create \
  --resource-group NetworkRG \
  --name nsg-web

Create an ASG:

			
az network asg create \
  --resource-group NetworkRG \
  --name asg-web \
  --location eastus

Create an inbound rule allowing HTTPS to the web ASG:

			
az network nsg rule create \
  --resource-group NetworkRG \
  --nsg-name nsg-web \
  --name Allow-HTTPS \
  --access Allow \
  --protocol Tcp \
  --direction Inbound \
  --priority 100 \
  --source-address-prefix Internet \
  --source-port-range "*" \
  --destination-asgs asg-web \
  --destination-port-range 443

		

The exact command syntax can vary depending on whether the rule references IP addresses, service tags, or ASGs.

14. Troubleshooting NSG Connectivity

When traffic is unexpectedly blocked, review the following:

1. Confirm the destination port

Ensure the application is actually listening on the expected port.

2. Confirm the source address

The source may be:

A private IP address
A public IP address
A load balancer
A service tag
Another application group

A rule that allows the wrong source range will not match.

3. Check both NSGs

Review:

The subnet-level NSG
The NIC-level NSG

A deny rule in either NSG can block traffic.

4. Review effective security rules

Effective security rules show the aggregated rules applied to a NIC, including rules from both the subnet and NIC NSGs.

In the Azure portal, effective rules can be viewed from the VM’s networking settings. They can also be retrieved with Azure CLI:

			
az network nic list-effective-nsg \
  --name vm-nic \
  --resource-group NetworkRG

This is one of the most important troubleshooting tools for NSG-related connectivity problems.

5. Check rule priority

A broad deny rule with a higher priority can prevent a later allow rule from being evaluated.

6. Check ASG membership

If an NSG rule references an ASG, verify that the destination or source NIC is actually a member of that ASG.

7. Check other networking controls

NSGs are not the only possible cause of blocked traffic. Also consider:

Azure Firewall
Network virtual appliances
Route tables
Private endpoints
Application Gateway
Operating-system firewalls
Application configuration
Network Watcher connection troubleshooting

15. NSGs Are Not a Replacement for Azure Firewall

NSGs provide basic network traffic filtering at the subnet and NIC levels. They are not a full network firewall solution.

NSGs generally do not provide the same capabilities as Azure Firewall, such as:

Centralized stateful inspection
Advanced threat intelligence filtering
Intrusion detection and prevention
Centralized application and network rule processing
Advanced logging and security operations integration

A common defense-in-depth architecture uses:

NSGs for subnet and workload segmentation
Azure Firewall for centralized traffic inspection
Application Gateway WAF for web application protection
Private Link for private access to PaaS services
Microsoft Defender for Cloud for security posture management

16. Best Practices

Use least privilege

Allow only the required:

Sources
Destinations
Ports
Protocols
Directions

Prefer application-based rules

Use ASGs instead of individual IP addresses when controlling communication between application tiers.

Use service tags appropriately

Use service tags to avoid maintaining changing Azure service IP ranges manually.

Avoid unrestricted access

Avoid rules that allow:

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

		

unless there is a documented and justified requirement.

Separate application tiers

Use different subnets and ASGs for:

Web
Application
Database
Management

Review effective rules

Regularly inspect effective security rules to verify that the actual applied policy matches the intended design.

Use infrastructure as code

Define NSGs, ASGs, and rules in Bicep, ARM templates, or another approved infrastructure-as-code solution to improve consistency and auditability.

Remove obsolete rules

Unused rules increase complexity and may create unintended access paths.

Document security intent

Use descriptive names and descriptions such as:

Allow-App-to-Database-SQL

rather than:

Rule1

Practice Exam Questions

Question 1

A company hosts a three-tier application in Azure. Web servers must communicate with application servers over TCP port 8080. Application servers must communicate with database servers over TCP port 1433. The company wants security rules to remain valid when virtual machines are added or their private IP addresses change.

What should you implement?

A. Create ASGs for each application tier and reference them in NSG rules.
B. Create a separate NSG for every virtual machine using static IP addresses.
C. Allow all traffic between the application subnets.
D. Use public IP addresses for all application servers.

Correct answer: A

Explanation: ASGs allow NSG rules to reference application roles instead of individual IP addresses. Membership can change without requiring the security rules to be rewritten.

Question 2

An NSG associated with a subnet allows inbound TCP port 443. An NSG associated with a VM’s NIC denies inbound TCP port 443 from the same source.

What is the result?

A. The subnet NSG takes precedence, so traffic is allowed.
B. The NIC NSG takes precedence, so traffic is denied.
C. Azure randomly selects one of the rules.
D. The traffic is allowed only if the VM has a public IP address.

Correct answer: B

Explanation: Both the subnet-level and NIC-level NSGs apply. Traffic must be allowed by both. The deny rule in the NIC-level NSG blocks the connection.

Question 3

An administrator creates an NSG rule with priority 100 that denies all inbound traffic. Another rule with priority 200 allows inbound HTTPS traffic.

What happens to inbound HTTPS traffic?

A. HTTPS is allowed because it uses a secure protocol.
B. HTTPS is allowed because the allow rule is more specific.
C. HTTPS is denied because the priority 100 rule is evaluated first.
D. Azure combines the actions and allows the traffic.

Correct answer: C

Explanation: Lower priority numbers are evaluated first. The broad deny rule at priority 100 matches the traffic, so the later allow rule is not evaluated.

Question 4

A VM cannot receive traffic from another VM in the same virtual network. The NSG associated with the destination NIC allows the traffic, but the subnet-level NSG contains a deny rule.

What should the administrator do first?

A. Assign a public IP address to the destination VM.
B. Review and modify the subnet-level NSG rule.
C. Disable the destination VM’s operating-system firewall.
D. Create an Azure Firewall policy.

Correct answer: B

Explanation: Both the subnet-level and NIC-level NSGs apply. A deny rule at the subnet level can block traffic even when the NIC-level NSG allows it.

Question 5

An organization wants to allow traffic from Azure Storage without manually maintaining a list of changing Azure IP addresses.

Which feature should be used?

A. Application security group
B. User-defined route
C. Service tag
D. Public IP prefix

Correct answer: C

Explanation: Service tags represent Microsoft-managed groups of IP address prefixes for Azure services. Microsoft updates the prefixes as service addresses change.

Question 6

A security administrator creates an ASG named Asg-Database. The administrator then creates an NSG rule allowing traffic to Asg-Database on TCP port 1433.

A database VM is not receiving the traffic.

Which issue could explain the problem?

A. The VM’s NIC is not a member of Asg-Database.
B. ASGs automatically deny all traffic.
C. ASGs can contain only public IP addresses.
D. ASGs work only with Azure Firewall.

Correct answer: A

Explanation: An NSG rule referencing an ASG applies only to network interfaces that are members of that ASG. The ASG itself does not automatically include every VM in a subnet.

Question 7

Which statement about application security groups is correct?

A. An ASG directly filters traffic without an NSG.
B. An ASG can contain NICs from multiple virtual networks.
C. An ASG is a logical grouping of network interfaces used by NSG rules.
D. An ASG replaces the need for subnet-level NSGs.

Correct answer: C

Explanation: ASGs provide logical grouping. NSG rules perform the actual allow or deny operation. NICs in an ASG must be in the same virtual network.

Question 8

A VM cannot connect to a database server. The administrator wants to see the combined inbound and outbound rules applied from the subnet and NIC NSGs.

Which feature should be used?

A. Azure Advisor
B. Effective security rules
C. Microsoft Defender Vulnerability Management
D. Azure Service Health

Correct answer: B

Explanation: Effective security rules show the aggregated rules applied to a network interface and are designed to help troubleshoot NSG-related connectivity issues.

Question 9

A company wants to allow management traffic only from a management subnet to selected application servers. The application servers are distributed across several subnets in the same virtual network.

What is the most maintainable approach?

A. Add every application server’s private IP address to a separate rule.
B. Allow management traffic from the entire virtual network to every server.
C. Create an ASG for the management servers and an ASG for the target application servers, then reference them in an NSG rule.
D. Assign public IP addresses to the management servers.

Correct answer: C

Explanation: ASGs allow security policies to be expressed according to application roles. The rule can remain stable as servers are added or their IP addresses change.

Question 10

An administrator wants to create a rule that allows TCP ports 80, 443, and 8080 from a specified source range using one NSG rule.

Which NSG capability supports this configuration?

A. Augmented security rules
B. Azure Bastion
C. Application Gateway WAF
D. Private Link

Correct answer: A

Explanation: Augmented security rules allow multiple ports, addresses, and ranges to be specified in a single rule, reducing the number of individual rules required.

Final Exam Point

NSGs and ASGs are most effective when used together: NSGs enforce traffic rules, while ASGs make those rules easier to express and maintain according to application architecture.

Go to the SC-500 Exam Prep Hub main page

azure, Microsoft Certification, SC-500, security October 10, 2026

Implement and configure network access policies by using Azure Virtual Network Manager (SC-500 Exam Prep)

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 network access policies by using Azure Virtual Network Manager

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.

Overview

Azure Virtual Network Manager is a network-management service that provides centralized control over Azure virtual networks. It can organize virtual networks into groups and apply network configurations consistently across subscriptions and management groups.

For security, Azure Virtual Network Manager provides security admin rules. These rules allow a central networking or security team to enforce organization-wide network access policies across managed virtual networks.

Security admin rules complement, rather than replace, network security groups (NSGs):

Security admin rules provide centrally managed security guardrails.
NSGs provide workload- and subnet-level traffic filtering.
Azure Firewall provides centralized, stateful traffic inspection and advanced firewall capabilities.

AVNM can also manage connectivity and routing configurations, but security admin rules are the primary feature for centrally enforcing network access policies.

1. Why Use Azure Virtual Network Manager?

Managing NSGs independently across many subscriptions can lead to:

Inconsistent security policies
Duplicate rules
Accidental exposure of high-risk ports
Difficulty enforcing organization-wide requirements
Security gaps when new virtual networks or resources are created
Conflicts between central security requirements and application-team configurations

AVNM addresses these challenges by allowing administrators to define security policies once and apply them to groups of virtual networks.

For example, an organization could centrally enforce the following policy:

Deny inbound SSH and RDP traffic from the Internet to all managed virtual networks unless an explicitly approved exception exists.

The central security team manages the security admin configuration, while application teams can continue managing their own NSGs for more specific workload requirements.

2. Understand the Main Azure Virtual Network Manager Components

Network manager instance

The network manager instance is the primary AVNM resource. It defines:

The management scope
The regions in which configurations can be deployed
The features enabled for the instance

The management scope can include:

Selected subscriptions
Management groups

The network manager only manages resources within its defined scope. A virtual network outside that scope is not affected by the manager’s configurations.

Network groups

A network group is a logical collection of virtual networks to which configurations can be applied.

Membership can be:

Static — administrators manually select virtual networks.
Dynamic — Azure Policy conditions determine which virtual networks belong to the group.

Examples of network groups include:

Production
Development
Corporate
Internet-facing
Regulated workloads
High-security workloads
Regional network groups

Dynamic membership is useful when new virtual networks should automatically receive the appropriate security policy based on tags, subscriptions, resource groups, or other policy conditions.

Configurations

AVNM supports several configuration types, including:

Connectivity configurations
Security admin configurations
Routing configurations

A security admin configuration contains rule collections, and each rule collection contains security admin rules.

Deployment

Creating or modifying a configuration does not immediately apply it to the target virtual networks. The configuration must be deployed to the relevant regions.

This commit-and-deploy model allows administrators to prepare, review, and then deploy a configuration.

3. Understand Security Admin Rules

A security admin rule is a centrally defined network security rule that applies to virtual networks in targeted network groups.

A rule can specify:

Priority
Action
Direction
Protocol
Source
Destination
Source ports
Destination ports

Security admin rules support three actions:

Allow
Always allow
Deny

The rules are applied at the virtual-network level and are evaluated before NSG rules.

4. Security Admin Rule Actions

Allow

An Allow rule permits the specified traffic to continue to NSG evaluation.

This means that an NSG can still deny the traffic.

For example:

A security admin rule allows inbound TCP 443.
The subnet NSG denies inbound TCP 443.

The traffic is ultimately denied by the NSG.

Use Allow when central governance wants to permit a category of traffic but still wants workload owners to apply additional restrictions.

Always allow

An Always allow rule allows the traffic and prevents subsequent NSG rules from denying it.

Use this action only when central governance must guarantee that a particular flow is permitted.

For example, an organization might use an Always allow rule for a required management or monitoring flow.

Because Always allow bypasses subsequent NSG evaluation for the matching traffic, it should be used carefully.

Deny

A Deny rule blocks the traffic immediately.

NSG rules are not evaluated for traffic that matches the security admin deny rule.

This is useful for centrally blocking:

Internet-based SSH
Internet-based RDP
Known high-risk ports
Unauthorized network segments
Traffic to sensitive workloads

The difference between the three actions is important for the exam:

Action	Result
Allow	Permits traffic to continue to NSG evaluation
Always allow	Permits traffic and prevents NSGs from denying it
Deny	Blocks traffic immediately before NSG evaluation

5. Security Admin Rule Priority

Security admin rules use priorities from 1 through 4,096.

Lower numbers have higher priority.
A rule with priority 10 is evaluated before a rule with priority 100.
A matching higher-priority rule can prevent a lower-priority rule from being evaluated.

Example

Suppose an organization has these rules:

Priority	Target group	Traffic	Action
10	Approved-Admin-Networks	Inbound TCP 22	Allow
100	All-Managed-Networks	Inbound TCP 22 from Internet	Deny

The approved administration networks receive the higher-priority allow rule. Other managed networks are subject to the deny rule.

However, if the priority 10 rule uses Allow, the traffic still proceeds to NSG evaluation. If the rule must bypass a conflicting NSG deny rule, the administrator would need to use Always allow, assuming that action is appropriate for the requirement.

6. Security Admin Rules Versus NSGs

Security admin rules and NSGs have different scopes and purposes.

Characteristic	Security admin rules	NSGs
Main audience	Central network/security administrators	Application and workload teams
Applied to	Managed virtual networks	Subnets and network interfaces
Scope	Organization-wide or group-wide	Workload- or subnet-specific
Actions	Allow, Always allow, Deny	Allow, Deny
Evaluation	Before NSGs	After security admin rules
Central enforcement	Yes	Usually managed at workload level
Can block traffic before NSG evaluation?	Yes, with Deny	No
Can bypass NSG denial?	Yes, with Always allow	No

A security admin rule does not eliminate the need for NSGs. A common design is:

AVNM enforces organization-wide security requirements.
NSGs enforce application-specific access.
Azure Firewall provides centralized inspection where required.

7. Example: Centrally Blocking High-Risk Ports

An organization wants to prevent Internet-based access to:

TCP 22 — SSH
TCP 3389 — RDP

The security team creates a network group containing all managed virtual networks.

A security admin configuration contains rules such as:

Priority	Direction	Source	Destination	Port	Action
100	Inbound	Internet	Any	22	Deny
110	Inbound	Internet	Any	3389	Deny

After deployment, the rules apply to resources in the targeted virtual networks.

This approach is more reliable than asking every application team to create and maintain equivalent NSG deny rules independently.

8. Example: Allowing Approved Exceptions

Suppose an organization blocks inbound SSH from the Internet but has a small set of approved administration networks.

Create two network groups:

All-Networks
Approved-Admin-Networks

Then create security admin rules:

Priority	Network group	Source	Destination	Port	Action
10	Approved-Admin-Networks	Approved admin range	Any	22	Allow
100	All-Networks	Internet	Any	22	Deny

The more specific exception is evaluated first because it has the lower priority.

If the approved traffic must not be blocked by a workload NSG, use Always allow instead of Allow, subject to the organization’s security design.

The important principle is that exceptions should be narrowly scoped and have a higher priority than the broad deny rule.

9. Create a Network Manager Instance

The general implementation process is:

Create an Azure Virtual Network Manager instance.
Define its management scope.
Enable the Security admin feature.
Create network groups.
Add virtual networks to the groups.
Create a security admin configuration.
Add rule collections and rules.
Associate rule collections with network groups.
Deploy the configuration to the required regions.
Verify the resulting policy and connectivity.

The manager’s scope should be designed carefully. A manager scoped to a management group can govern virtual networks across multiple subscriptions within that scope.

10. Configure Network Group Membership

Static membership

With static membership, an administrator manually adds virtual networks to a network group.

This provides precise control but requires ongoing maintenance.

Use static membership when:

The number of virtual networks is small.
Membership changes are infrequent.
The organization needs explicit approval for every member.

Dynamic membership

With dynamic membership, Azure Policy determines which virtual networks belong to the group.

For example, a policy could include virtual networks that:

Have a specific tag
Belong to a particular subscription
Exist in a particular resource group
Match a defined naming convention

Dynamic membership is useful in large environments because new qualifying virtual networks can be added automatically.

However, membership updates and configuration application are not necessarily instantaneous. Administrators should account for deployment and policy-evaluation delays.

11. Create a Security Admin Configuration

A security admin configuration contains one or more rule collections.

A rule collection generally defines:

A collection name
A set of security admin rules
The network groups to which the collection applies

A rule should be designed around a clearly stated security requirement.

For example:

Block inbound RDP from the Internet to all production virtual networks.

The corresponding rule could specify:

Direction: Inbound
Protocol: TCP
Source: Internet
Destination: Any
Destination port: 3389
Action: Deny
Priority: 100

The configuration is then associated with the appropriate production network group and deployed to the required regions.

12. Deployment and Eventual Consistency

AVNM configurations do not take effect merely because they have been created.

Administrators must deploy the configuration to the regions containing the target virtual networks.

There may also be a delay when:

A configuration is first deployed
A network group’s membership changes
New resources are added to a managed virtual network
A security admin rule is modified

Microsoft describes this as an eventual consistency model. A newly created resource may not receive the security admin rules immediately.

Exam consideration

If a rule appears not to be working immediately:

Confirm that the configuration was deployed.
Confirm that the deployment targeted the correct region.
Confirm that the virtual network belongs to the expected network group.
Allow time for membership and configuration propagation.
Verify whether the resource or subnet is exempt from security admin rules.

13. Important Exceptions and Limitations

Security admin rules do not apply universally.

Private endpoints in managed virtual networks

Security admin rules do not apply to private endpoints that fall under the scope of a managed virtual network.

Service-specific subnets

Certain service subnets are exempt because the services require specific network behavior.

Examples include subnets used by:

Azure Application Gateway
Azure Bastion
Azure Firewall
Azure Route Server
Azure VPN Gateway
Azure Virtual WAN
Azure ExpressRoute Gateway

Azure SQL Managed Instance and Azure Databricks

By default, security admin rules are not applied to virtual networks containing certain services, including:

Azure SQL Managed Instance
Azure Databricks

These services can have network intent policies that conflict with security admin rules.

For supported scenarios, administrators can configure the security configuration to apply Allow rules only to such virtual networks. This does not mean that Deny rules are applied; the setting is specifically intended to avoid conflicts with service-required network policies.

14. Network Groups as Sources and Destinations

AVNM can use network groups to define the source and destination of security admin rules.

For example:

			
Source: Web-Networks
Destination: Database-Networks
Protocol: TCP
Destination port: 1433
Action: Allow

		

This expresses the intended relationship between groups of virtual networks rather than relying only on individual IP addresses.

However, the use of network groups as source and destination in security admin rules is identified in Microsoft documentation as a public-preview capability. Preview features may have limitations and should not automatically be assumed to be suitable for production workloads.

15. AVNM and Connectivity Configurations

Although this topic focuses on network access policies, AVNM also supports connectivity configurations.

Connectivity configurations can establish:

Hub-and-spoke connectivity
Mesh connectivity
Regional mesh connectivity
Global mesh connectivity

Security admin rules and connectivity configurations solve different problems:

Connectivity configurations determine how virtual networks connect.
Security admin configurations determine which traffic is permitted or denied.

A network can be connected but still have traffic blocked by security admin rules or NSGs.

AVNM’s configurations are additive in some scenarios, and multiple connectivity configurations can exist in a region. However, only one security admin configuration can be deployed to a region for a given network manager instance; multiple security rule collections can be placed within that configuration.

16. AVNM and Azure Firewall

Azure Virtual Network Manager security admin rules are not a replacement for Azure Firewall.

Use security admin rules for:

Organization-wide allow or deny policies
Blocking high-risk ports
Enforcing network segmentation
Applying consistent guardrails across many virtual networks
Preventing workload NSGs from bypassing central deny rules

Use Azure Firewall for:

Stateful traffic inspection
Centralized network and application rules
Threat intelligence filtering
Centralized logging
Advanced firewall policy management
Traffic inspection between network segments

A defense-in-depth design may use AVNM security admin rules, NSGs, Azure Firewall, private endpoints, and application-layer controls together.

17. Best Practices

Define a clear management scope

Use a management group or carefully selected subscriptions that contain the virtual networks requiring centralized governance.

Separate central and workload responsibilities

Central security teams should manage organization-wide guardrails. Application teams should manage workload-specific NSGs.

Use deny-by-default principles

Block unnecessary traffic and permit only the flows required by the business or application.

Use specific priorities

Reserve priority ranges for:

Emergency blocks
Approved exceptions
Standard organization-wide denies
General allow rules

Use network groups strategically

Group virtual networks by meaningful characteristics such as:

Environment
Business unit
Data sensitivity
Regulatory requirements
Internet exposure
Application role

Use dynamic membership where appropriate

Dynamic membership reduces manual administration but requires careful Azure Policy design and awareness of propagation delays.

Test exceptions

Verify that approved exceptions work without unintentionally allowing broader access.

Avoid unnecessary Always allow rules

Always allow bypasses NSG denial for matching traffic. Use it only when central governance must guarantee the flow.

Document exclusions

Record why certain service subnets or virtual networks are exempt from security admin rules.

Verify after deployment

Confirm:

The configuration is deployed
The deployment succeeded
The expected network groups contain the correct virtual networks
The rules have the intended priorities
Connectivity behaves as designed

Practice Exam Questions

Question 1

A company wants to centrally block inbound RDP traffic from the Internet across all production virtual networks. Individual application teams currently manage their own NSGs.

Which solution best meets the requirement?

A. Create a security admin Deny rule in Azure Virtual Network Manager and apply it to a production network group.
B. Create a separate NSG on every VM and configure an RDP deny rule.
C. Configure Azure DNS to block RDP traffic.
D. Add a route for TCP port 3389 to each subnet.

Correct answer: A

Explanation: Security admin rules provide centralized enforcement across managed virtual networks. A Deny rule blocks matching traffic before NSG evaluation.

Question 2

A security administrator creates an AVNM security admin rule with the action Allow for inbound TCP port 443. A subnet-level NSG denies the same traffic.

What happens?

A. The security admin Allow rule always overrides the NSG.
B. The traffic is allowed because security admin rules bypass NSGs.
C. The traffic is denied by the NSG.
D. The traffic is routed through Azure Firewall automatically.

Correct answer: C

Explanation: An Allow security admin rule permits traffic to continue to NSG evaluation. The NSG can still deny the traffic.

Question 3

An organization needs to guarantee that approved monitoring traffic is not blocked by workload-level NSGs.

Which security admin action should be considered?

A. Allow
B. Deny
C. Audit
D. Always allow

Correct answer: D

Explanation: Always allow permits the matching traffic and prevents subsequent NSG rules from denying it. It should be used carefully because it bypasses NSG denial for that flow.

Question 4

Which priority has the highest precedence in an Azure Virtual Network Manager security admin configuration?

A. 4,096
B. 2,000
C. 100
D. 10

Correct answer: D

Explanation: Lower priority numbers are evaluated first. Priority 10 has higher precedence than priorities 100, 2,000, and 4,096.

Question 5

An organization wants new virtual networks with the tag Environment=Production to automatically receive a centralized security policy.

What should the administrator use?

A. Static network group membership
B. Dynamic network group membership based on Azure Policy
C. A public IP prefix
D. An NSG attached to one production VM

Correct answer: B

Explanation: Dynamic network group membership uses policy-based conditions to determine which virtual networks belong to a group.

Question 6

An administrator creates a security admin configuration but traffic is still permitted through a virtual network that should be protected.

What should be checked first?

A. Whether the configuration was deployed to the correct region
B. Whether the VM has a larger SKU
C. Whether the virtual network has a DNS server
D. Whether the VM has an availability set

Correct answer: A

Explanation: AVNM configurations do not take effect until they are deployed to the relevant regions. Incorrect or missing deployment is a common cause of unexpected behavior.

Question 7

Which statement correctly describes the relationship between security admin rules and NSGs?

A. NSGs are evaluated before security admin rules.
B. Security admin rules and NSGs cannot be used together.
C. Security admin rules are evaluated before NSGs.
D. Security admin rules apply only to public IP addresses.

Correct answer: C

Explanation: Security admin rules provide centralized network-level enforcement and are evaluated before NSG rules.

Question 8

A virtual network contains Azure SQL Managed Instance. The administrator notices that the expected security admin Deny rules are not being applied.

What is the most likely explanation?

A. SQL Managed Instance supports only public IP addresses.
B. Security admin rules are never applied to production networks.
C. NSGs automatically disable AVNM.
D. Certain service network intent requirements can cause security admin rules to be skipped by default.

Correct answer: D

Explanation: Azure SQL Managed Instance and certain other services have network intent policies that can conflict with security admin rules. Such virtual networks may be exempt by default, with supported Allow-rules-only behavior available for applicable scenarios.

Question 9

A company wants to centrally deny Internet-based SSH traffic but permit SSH from an approved administration network. Which design is most appropriate?

A. Create a lower-priority allow exception for the approved network and a broader higher-numbered deny rule for all managed networks.
B. Create only an allow rule for the Internet.
C. Create a deny rule for the approved administration network.
D. Remove all NSGs from the virtual networks.

Correct answer: A

Explanation: The approved exception should have a lower priority number than the broad deny rule. If the exception must bypass NSG denial, the administrator should evaluate whether Always allow is appropriate.

Question 10

Which statement about Azure Virtual Network Manager security admin rules is correct?

A. They replace Azure Firewall for stateful traffic inspection.
B. They directly modify the operating-system firewall on each VM.
C. They can enforce centralized network policies across virtual networks in targeted network groups.
D. They apply automatically to every virtual network in every Azure tenant.

Correct answer: C

Explanation: AVNM applies centralized security admin rules to virtual networks in network groups within the manager’s defined scope. It does not replace Azure Firewall, modify guest operating-system firewalls, or automatically govern resources outside its scope.

Go to the SC-500 Exam Prep Hub main page

azure, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Configure security for an Azure Virtual WAN (SC-500 Exam Prep)

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
      --> Configure security for an Azure Virtual WAN

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.

Overview

Azure Virtual WAN is a Microsoft-managed networking service that provides centralized connectivity between Azure virtual networks, branch offices, remote users, and other connected environments. It combines networking, routing, VPN, ExpressRoute, and security capabilities through a unified operational model.

For the SC-500 exam, the important security concept is that Azure Virtual WAN should not be viewed only as a connectivity service. It can also provide a centralized inspection and enforcement point for traffic flowing between:

Azure virtual networks
On-premises branch offices
Remote users
Other Virtual WAN hubs
The internet
Azure platform services and private resources

A common secure design is to use a secured virtual hub, Azure Firewall, Firewall Manager, and Virtual WAN routing capabilities to ensure that traffic is inspected before reaching protected destinations.

What Is Azure Virtual WAN?

Azure Virtual WAN consists of several major components:

Virtual WAN resource

The Virtual WAN resource is the top-level container for one or more virtual hubs. It provides a centralized management and configuration boundary.

Virtual hub

A virtual hub is a Microsoft-managed network infrastructure component deployed in an Azure region. It provides connectivity and routing services for connected networks and gateways.

A virtual hub can contain or provide access to:

Site-to-site VPN gateways
Point-to-site user VPN gateways
ExpressRoute gateways
The Virtual WAN hub router
Azure Firewall
Supported network virtual appliances
Connections to Azure virtual networks
Connections to branch sites

Unlike a customer-managed hub VNet, a Virtual WAN hub is operated by Microsoft. You do not directly deploy or manage the underlying hub virtual network in the same way that you manage a normal Azure VNet.

Virtual network connections

Azure VNets connect to a Virtual WAN hub through virtual network connections. These connections allow workloads in the VNets to communicate with other connected networks according to the hub’s routing configuration.

VPN and ExpressRoute connections

Branch offices and on-premises networks can connect to Virtual WAN through:

Site-to-site VPN
ExpressRoute
Point-to-site user VPN

The connection type depends on the organization’s requirements for connectivity, performance, availability, and authentication.

Basic and Standard Virtual WAN

Azure Virtual WAN is available in two primary types:

Capability	Basic Virtual WAN	Standard Virtual WAN
Site-to-site VPN	Supported	Supported
ExpressRoute	Not supported	Supported
Point-to-site user VPN	Not supported	Supported
Inter-hub transit	Not supported	Supported
VNet-to-VNet transit	Not supported	Supported
Azure Firewall	Not supported	Supported
Network virtual appliances in Virtual WAN	Not supported	Supported

For most enterprise security scenarios, Standard Virtual WAN is required because secured hubs, Azure Firewall, advanced transit, and additional gateway capabilities depend on Standard functionality.

A Basic Virtual WAN can be upgraded to Standard, but it cannot be downgraded from Standard back to Basic.

What Is a Secured Virtual Hub?

A secured virtual hub is an Azure Virtual WAN hub with an integrated Azure Firewall.

Azure Firewall provides centralized traffic inspection and policy enforcement for traffic moving through the Virtual WAN environment. A secured hub can inspect traffic destined for:

Private IP addresses
Azure virtual networks
Other connected networks
The internet
Azure platform services, depending on the routing and security design

Azure Firewall can inspect traffic between different network locations, including:

North-south traffic: traffic between on-premises networks and Azure
East-west traffic: traffic between Azure networks or workloads
Internet-bound traffic: traffic from Azure workloads to the internet

This approach centralizes security enforcement rather than requiring every workload or spoke network to independently deploy a firewall.

Why use a secured virtual hub?

A secured virtual hub can provide:

Centralized traffic inspection
Consistent firewall policies
Reduced need for manually configured routes
Centralized security management across multiple hubs
Protection for Azure and branch connectivity
A more consistent Zero Trust architecture
Easier enforcement of organization-wide security requirements

For example, an organization might connect several regional VNets and branch offices to Virtual WAN. Instead of deploying and maintaining separate firewalls in every location, the organization can use Azure Firewall in secured hubs and apply consistent policies.

Azure Firewall Manager

Azure Firewall Manager provides centralized management for firewall policies and secured virtual hubs.

It can be used to:

Create secured virtual hubs
Manage Azure Firewall policies
Apply consistent security rules across multiple hubs
Configure routing-related security settings
Manage security for multiple regions
Separate centralized security administration from individual workload administration

Firewall Manager is particularly useful when an organization has multiple Virtual WAN hubs in different Azure regions.

For example:

A global company has hubs in North America, Europe, and Asia.
Each hub connects regional VNets and branch offices.
Security administrators manage common firewall policies centrally.
Regional teams manage their workloads without independently designing the entire network security architecture.

Firewall Manager supports centralized rule management across secured hubs.

Routing Intent

One of the most important security features in Azure Virtual WAN is routing intent.

Routing intent allows you to define how traffic should be routed through a security solution, such as Azure Firewall or a supported network virtual appliance.

Common routing intent patterns include:

Internet traffic inspection

Internet-bound traffic from connected VNets or branches is routed through the security solution before reaching the internet.

This helps enforce policies such as:

Blocking malicious destinations
Restricting outbound access
Inspecting internet-bound traffic
Applying centralized filtering
Logging traffic for investigation

Private traffic inspection

Private traffic between connected networks is routed through the security solution.

For example:

VNet A communicates with VNet B.
A branch office communicates with an Azure workload.
One regional hub communicates with another regional hub.

Routing intent can be used to steer this private traffic through the firewall for inspection.

Why routing intent matters

Without centralized routing, administrators may need to create and maintain multiple user-defined routes. Incorrect or incomplete routes can allow traffic to bypass inspection.

Routing intent helps simplify this process by automatically steering specified traffic categories through the security solution. The Virtual WAN architecture is designed to reduce the need for manually maintained routing configurations.

Traffic Flow Through a Secured Virtual Hub

A simplified secure traffic flow might look like this:

			
Branch Office
     |
     | Site-to-site VPN or ExpressRoute
     |
Virtual WAN Hub
     |
Azure Firewall
     |
     +--------------------+
     |                    |
Private Azure VNet     Internet

		

For traffic between two Azure VNets:

			
VNet A
  |
  | Virtual WAN connection
  |
Virtual WAN Hub
  |
Azure Firewall
  |
Virtual WAN Hub
  |
  | Virtual WAN connection
  |
VNet B

		

The exact traffic path depends on the hub configuration, routing intent, firewall policy, connection settings, and whether the traffic is classified as private or internet-bound.

The important exam concept is:

A connection to Virtual WAN does not automatically mean that all traffic is inspected by Azure Firewall. The routing and security configuration must direct the traffic through the security solution.

Azure Firewall Policy in a Secured Virtual Hub

Azure Firewall policies define the traffic that is allowed, denied, or inspected.

Depending on the Azure Firewall tier and configuration, policies can include:

Network rules
Application rules
NAT rules
Threat intelligence filtering
DNS-related security controls
TLS inspection capabilities, where supported and configured
IDPS capabilities with Azure Firewall Premium

Network rules

Network rules control traffic based on characteristics such as:

Source address
Destination address
Protocol
Destination port

Examples include:

Allow TCP 443 from a corporate network to an application subnet
Deny TCP 22 from untrusted networks
Allow DNS traffic to an approved DNS service
Block traffic to a known prohibited network range

Application rules

Application rules can control supported application-layer traffic, such as HTTP and HTTPS, based on:

Fully qualified domain names
Web categories
Application characteristics

For example, an organization might allow servers to access only approved software repositories.

NAT rules

NAT rules can publish selected internal services through a public IP address. NAT should be configured carefully because it can expose internal resources to external traffic.

Security considerations include:

Restricting source addresses
Limiting exposed ports
Avoiding unnecessary public exposure
Applying least privilege
Monitoring inbound connections
Using private connectivity whenever possible

Virtual WAN Network Virtual Appliances

Azure Virtual WAN can also support supported network virtual appliances, depending on the Virtual WAN type and deployment architecture.

A network virtual appliance might provide specialized capabilities such as:

Third-party firewall functionality
Intrusion prevention
Secure web gateway features
Specialized network inspection
Vendor-specific security controls

However, an NVA is not automatically equivalent to Azure Firewall. Before selecting an NVA, verify:

Supported Virtual WAN integration
Routing behavior
High availability
Scaling model
Inspection capabilities
Logging and monitoring
TLS inspection support
Compatibility with required traffic patterns
Whether the appliance supports the organization’s security requirements

Microsoft documentation specifically notes that NVAs deployed in a Virtual WAN hub can have different capabilities from Azure Firewall.

Virtual WAN Hub Address Space

When creating a Virtual WAN hub, you must specify a hub address space.

Important considerations include:

The minimum hub address space is /24.
Microsoft recommends using /23 or larger when future growth is expected.
If Azure Firewall is used in the Virtual WAN hub, a minimum /22 address space is required to provide sufficient IP address capacity for firewall scaling.
The hub address space cannot be changed after the hub is created.
The hub address space must not overlap with connected VNets, on-premises networks, or other Virtual WAN hub address spaces.

The address space is used internally by the hub and its services, including the hub router, VPN gateways, ExpressRoute, Azure Firewall, and supported NVAs.

Exam warning

Do not select a hub address range that overlaps with:

An on-premises network
A connected VNet
Another Virtual WAN hub
A future planned network

Address-space overlap can cause routing conflicts and connectivity failures.

Virtual WAN Connectivity Security

Site-to-site VPN

Site-to-site VPN provides encrypted connectivity between an on-premises VPN device and a Virtual WAN hub.

The on-premises device generally requires:

An externally reachable public IP address
IPsec/IKE compatibility
Correct VPN configuration
Matching authentication and encryption settings
Appropriate routing configuration

Virtual WAN supports IPsec/IKE VPN connectivity, including IKEv1 and IKEv2 scenarios.

Security best practices include:

Use strong pre-shared keys or supported authentication methods.
Store sensitive VPN secrets securely.
Rotate credentials according to organizational policy.
Avoid exposing management interfaces on the public internet.
Monitor VPN connection status and gateway logs.
Use redundant connections for critical sites.
Validate learned and advertised routes.

Point-to-site user VPN

Point-to-site VPN allows individual users to connect to a Virtual WAN hub.

Authentication can be integrated with Microsoft Entra ID. This enables centralized identity-based access and can support organizational authentication requirements.

Security controls may include:

Microsoft Entra authentication
Multifactor authentication
Conditional Access
Group-based authorization
Device compliance requirements
Restricted user access
Short-lived or controlled access
Monitoring of user VPN activity

The key distinction is that site-to-site VPN connects networks, while point-to-site VPN connects individual users or devices.

ExpressRoute

ExpressRoute provides private connectivity between on-premises infrastructure and Azure.

ExpressRoute traffic does not traverse the public internet in the same way as ordinary internet-based connectivity. Virtual WAN can provide transit connectivity and routing between connected networks.

Security considerations include:

Controlling which routes are advertised
Avoiding unintended transit
Applying private traffic inspection where required
Monitoring route propagation
Using encryption requirements appropriate to the organization
Understanding that private connectivity does not automatically eliminate the need for authorization and inspection

Route Tables and Route Propagation

Virtual WAN uses hub routing and route tables to determine how traffic is forwarded between connected networks.

A route table can define:

Which routes a connection learns
Which routes are propagated to a connection
Which networks can communicate
Whether a connection receives default routes
Whether traffic is directed toward a firewall or NVA

Route association

A connection is associated with a Virtual WAN route table. The association determines which route table is used for forwarding decisions.

Route propagation

Route propagation determines which routes are advertised to a connection.

For example, a connection might receive routes for:

Other VNets
Branch networks
Other Virtual WAN hubs
The internet default route
Specific private address ranges

Security importance

Route propagation can affect whether traffic:

Reaches a protected network
Can communicate with another spoke
Is routed through a firewall
Can access the internet
Can bypass an inspection point

A secure configuration should advertise only the routes that are necessary.

Internet Security and the Default Route

The default route is:

0.0.0.0/0

When internet security is enabled and routing is configured to send internet traffic through a firewall or NVA, the default route can be advertised to connected VNets.

This causes internet-bound traffic from those VNets to use the centralized security solution.

However, administrators must understand the operational impact:

Internet access may be blocked unless firewall rules allow it.
DNS resolution may be affected by routing and firewall policies.
Application dependencies may fail if required endpoints are not allowed.
The firewall must be configured to permit legitimate outbound traffic.
Route propagation must be validated after changes.

The security objective is to prevent workloads from bypassing the organization’s inspection and filtering controls.

Private Traffic Inspection

Private traffic inspection is used when traffic between private networks must pass through a security solution.

Examples include:

VNet-to-VNet communication
Branch-to-VNet communication
Hub-to-hub communication
Traffic between application tiers
Traffic between production and shared services

Private traffic inspection is especially important in Zero Trust architectures because private IP addressing alone does not prove that traffic is trustworthy.

A workload in one VNet should not automatically be trusted merely because it is connected to the same Virtual WAN environment.

Security policies should consider:

Source network
Destination network
Application role
Protocol
Port
Identity and workload context
Required business relationship
Logging and monitoring requirements

Branch-to-Branch and Hub-to-Hub Connectivity

Virtual WAN can provide transit connectivity between connected branch sites and hubs.

This can simplify global network architecture, but it also creates security considerations.

For example, if branch-to-branch traffic is enabled, one branch may be able to communicate with another branch through Virtual WAN. This may be useful, but it could also create an unintended trust relationship.

Before enabling branch-to-branch connectivity, determine:

Which branches should communicate
Whether branch traffic must be inspected
Whether segmentation is required
Whether the firewall can inspect the traffic
Whether route propagation exposes unnecessary networks
Whether the connectivity requirement is temporary or permanent

The principle is:

Enable only the transit connectivity that is required by the business and security architecture.

Azure Virtual WAN and Zero Trust

A Zero Trust design assumes that no network location is inherently trusted.

For Virtual WAN, this means:

Do not trust traffic solely because it originates from a connected VNet.
Do not assume private traffic is safe.
Inspect traffic where required.
Use least-privilege routing.
Restrict internet access.
Authenticate remote users.
Apply consistent firewall policies.
Monitor traffic and configuration changes.
Segment workloads and branches.
Avoid unnecessary route propagation.

A secured Virtual WAN hub can support Zero Trust by centralizing inspection and reducing opportunities for traffic to bypass security controls.

Logging and Monitoring

Virtual WAN and related resources can produce resource logs that can be sent to:

Log Analytics workspaces
Event Hubs
Storage accounts

Logging can support:

Security investigations
VPN troubleshooting
Route analysis
Firewall monitoring
Compliance evidence
Detection of configuration changes
Investigation of unexpected connectivity

Resource logs are not necessarily enabled automatically. The organization must configure diagnostic settings and select the appropriate destination.

A recommended design is to send security-relevant logs to a centralized Log Analytics workspace and integrate them with Microsoft Sentinel when broader security analytics and incident response are required.

Monitor these areas

Monitor:

Virtual hub health
Hub router status
VPN connection state
ExpressRoute connectivity
Learned routes
Advertised routes
Firewall health
Firewall rule hits
Denied connections
Unexpected internet access
Configuration changes
Resource deployment failures

Hub Router Status

A Virtual WAN hub router can have statuses such as:

Provisioned
Provisioning
Failed
None

A Failed status may indicate a problem during router instantiation.

A None status may occur when the router was not provisioned, including scenarios involving Basic Virtual WAN or older hub deployments.

The hub router is important because it provides the routing infrastructure for transit connectivity. If the router is not functioning correctly, connected networks may experience routing or connectivity problems.

Security Best Practices

1. Use Standard Virtual WAN for enterprise security scenarios

Standard Virtual WAN supports the capabilities generally required for secured hubs, advanced transit, ExpressRoute, point-to-site VPN, Azure Firewall, and supported NVAs.

2. Use secured virtual hubs for centralized inspection

Deploy Azure Firewall in the Virtual WAN hub when traffic from multiple networks must be inspected consistently.

3. Use Firewall Manager for centralized policy management

Use centralized firewall policies to reduce inconsistent regional configurations.

4. Configure routing intent deliberately

Ensure private and internet-bound traffic is routed through the appropriate security solution.

5. Avoid overlapping address spaces

Plan hub, VNet, branch, and on-premises address spaces before deployment.

6. Use least-privilege route propagation

Advertise only the routes that each connection needs.

7. Do not assume connected networks are trusted

Apply inspection and access controls based on the required communication paths.

8. Protect VPN credentials

Store VPN secrets securely and rotate them according to policy.

9. Monitor logs centrally

Enable diagnostic settings and send relevant logs to a centralized monitoring destination.

10. Validate changes before production deployment

Test:

Route propagation
Firewall inspection
VPN connectivity
Internet access
Private network access
DNS resolution
Failover behavior
Logging and alerting

Common Exam Traps

Trap 1: “A VNet connected to Virtual WAN automatically uses Azure Firewall.”

Not necessarily. Traffic must be routed through the firewall using the appropriate security and routing configuration.

Trap 2: “Basic Virtual WAN supports Azure Firewall.”

Basic Virtual WAN does not support Azure Firewall. Standard Virtual WAN is required.

Trap 3: “A private connection is automatically secure.”

Private connectivity reduces exposure to the public internet, but it does not replace authorization, segmentation, inspection, or monitoring.

Trap 4: “Routing intent is only for internet traffic.”

Routing intent can be used for internet-bound traffic and private traffic inspection.

Trap 5: “The Virtual WAN hub address space can be changed later.”

The hub address space cannot be modified after the hub is created.

Trap 6: “An NVA and Azure Firewall always have identical capabilities.”

They do not. Validate the NVA’s supported features and Virtual WAN integration.

Trap 7: “Enabling branch-to-branch connectivity is always desirable.”

It can create additional trust paths and should be enabled only when required.

Practice Exam Questions

Question 1

An organization has several Azure VNets and branch offices connected through Azure Virtual WAN. The security team requires all internet-bound traffic from the VNets to pass through a centralized Azure Firewall.

What should the organization configure?

A. A network security group on every subnet
B. Routing intent that directs internet traffic through Azure Firewall
C. A point-to-site VPN connection for every workload
D. A separate public IP address for every VNet

Correct answer: B

Explanation: Routing intent can direct internet-bound traffic through Azure Firewall in a secured virtual hub. NSGs do not provide centralized internet traffic inspection across Virtual WAN.

Question 2

Which Virtual WAN type is required for an architecture that uses Azure Firewall, ExpressRoute, and inter-hub transit?

A. Basic Virtual WAN
B. Standard Virtual WAN
C. Basic virtual hub with a route table
D. Any Virtual WAN type

Correct answer: B

Explanation: Standard Virtual WAN supports Azure Firewall, ExpressRoute, inter-hub transit, point-to-site VPN, and other advanced capabilities. Basic Virtual WAN is limited primarily to site-to-site VPN connectivity.

Question 3

A company wants to centrally manage Azure Firewall policies across secured Virtual WAN hubs deployed in multiple regions.

Which service should it use?

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

Correct answer: C

Explanation: Azure Firewall Manager provides centralized management of firewall policies and secured virtual hubs across regions.

Question 4

An administrator is creating a Virtual WAN hub that will use Azure Firewall. Which address-space decision is appropriate?

A. Use an address space that overlaps with the largest connected VNet
B. Use a minimum /30 address space
C. Use a minimum /22 address space for a hub with Azure Firewall
D. Use the same address space as the on-premises network

Correct answer: C

Explanation: A Virtual WAN hub using Azure Firewall requires a minimum /22 address space to provide sufficient capacity for firewall scaling. The address space must also avoid overlap with connected networks.

Question 5

An organization wants to inspect traffic between two Azure VNets connected to the same Virtual WAN environment.

Which capability is most relevant?

A. Private traffic inspection through routing intent
B. Azure Storage firewall rules
C. Point-to-site VPN authentication
D. Azure Resource Locks

Correct answer: A

Explanation: Private traffic inspection allows traffic between connected private networks to be directed through a firewall or supported NVA.

Question 6

A security engineer enables branch-to-branch connectivity in Virtual WAN. What is the primary security concern?

A. Branches will no longer be able to use VPN
B. Branch-to-branch connectivity may create unintended trust paths
C. Azure Firewall will be automatically deleted
D. ExpressRoute will be converted to a public connection

Correct answer: B

Explanation: Branch-to-branch connectivity can allow one branch to communicate with another. It should be enabled only when required and should be evaluated against segmentation and inspection requirements.

Question 7

Which statement about the Virtual WAN hub address space is correct?

A. It can be changed at any time after hub deployment
B. It must overlap with the connected VNets
C. It cannot overlap with connected or on-premises address spaces
D. It is used only for point-to-site VPN clients

Correct answer: C

Explanation: The hub address space cannot be changed after creation and must not overlap with other Virtual WAN hubs, connected VNets, or on-premises networks.

Question 8

A company wants to connect individual employees to a Virtual WAN hub and authenticate them using Microsoft Entra ID.

Which connectivity option should it use?

A. Site-to-site VPN
B. Point-to-site user VPN
C. ExpressRoute Direct
D. VNet peering

Correct answer: B

Explanation: Point-to-site user VPN connects individual users or devices and can be configured with Microsoft Entra ID authentication.

Question 9

An administrator configures routing intent but users report that internet access is failing from a connected VNet. What should the administrator check first?

A. Whether the firewall policy allows the required outbound traffic
B. Whether every VM has a public IP address
C. Whether the VNet has a storage account
D. Whether Azure Bastion is deployed

Correct answer: A

Explanation: Routing internet traffic through Azure Firewall does not automatically allow it. The firewall policy must permit the required destinations, protocols, and ports.

Question 10

A security team needs to investigate unexpected VPN disconnects and routing changes in Virtual WAN.

What should it configure?

A. Azure Resource Locks only
B. Diagnostic settings that send Virtual WAN resource logs to a monitoring destination
C. A public IP address on every connected subnet
D. A separate Virtual WAN for every VPN connection

Correct answer: B

Explanation: Virtual WAN and related resources can produce resource logs that can be sent to Log Analytics, Event Hubs, or a storage account. These logs support troubleshooting, auditing, and security investigations.

Key Takeaways

For the SC-500 exam, remember these core points:

Standard Virtual WAN is required for advanced enterprise capabilities.
A secured virtual hub integrates Azure Firewall with a Virtual WAN hub.
Azure Firewall Manager centralizes firewall policy management.
Routing intent directs private or internet-bound traffic through a security solution.
Connected networks are not automatically trusted.
Plan Virtual WAN hub address spaces carefully because they cannot be changed after creation.
Avoid address-space overlap.
Use least-privilege route propagation.
Secure site-to-site and point-to-site connectivity.
Monitor Virtual WAN resource logs, routes, gateways, and firewall activity.
Validate that traffic actually passes through the intended inspection point.

Go to the SC-500 Exam Prep Hub main page

Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Exam Prep Hub for SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads

Welcome to the SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads Exam Prep Hub!

Welcome to the one-stop hub with information for preparing for the SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads certification exam. The content for this exam helps prepare you to be “a security engineer who protects organizational systems and data across cloud and hybrid environments by implementing comprehensive security controls that proactively help prevent unauthorized access and mitigate risks. Your role spans multiple security domains, including identity, network, application, data, and compute. You also help ensure that platforms, data, identities, and infrastructure used by AI workloads are securely implemented and monitored.”.
Upon successful completion of the exam, you earn the Microsoft Certified: Cloud and AI Security Engineer Associate certification.

This hub provides information directly here (topic-by-topic as outlined in the official study guide), links to a number of external resources, tips for preparing for the exam, practice tests, and section questions to help you prepare. Bookmark this page and use it as a guide to ensure that you are fully covering all relevant topics for the SC-500 exam and making use of as many of the resources available as possible.

**Audience profile (from Microsoft’s site)**

As a candidate for this Microsoft Certification, you’re a security engineer who protects organizational systems and data across cloud and hybrid environments by implementing comprehensive security controls that proactively help prevent unauthorized access and mitigate risks. Your role spans multiple security domains, including identity, network, application, data, and compute. You also help ensure that platforms, data, identities, and infrastructure used by AI workloads are securely implemented and monitored.

In this role, your responsibilities include:
- Securing access to resources by using Microsoft Entra ID and Azure Key Vault.
- Enforcing security and regulatory compliance.
- Securing storage, databases, and networking.
- Securing compute.
- Securing AI solutions.
- Managing and monitoring security posture.

You work closely with architects, administrators, engineers, analysts, and developers responsible for Azure, Microsoft 365, identity and access, information protection, security operations, DevOps, application development, database platforms, and networks.

For this exam, you should have practical experience in administration of Azure and hybrid environments, including compute, network, and storage. You need strong familiarity with Microsoft Entra ID and familiarity with Microsoft 365 administration.

Skills at a glance

Manage identity, access, and governance (20–25%)
Secure storage, databases, and networking (25–30%)
Secure compute (20–25%)
Manage and monitor security posture (20–25%)

Topic-by-Topic Exam Content

[click a topic link to access the content and practice questions for that topic]

Manage identity, access, and governance (20–25%)

Secure access to resources by using Microsoft Entra ID

Secure secrets and keys by using Azure Key Vault

Implement governance to enforce security and regulatory compliance

Secure storage, databases, and networking (25–30%)

Implement security for storage accounts

Implement security for databases

Implement security for Azure network services

Secure compute (20–25%)

Implement security for AI

Implement security for servers and virtual machines (VMs)

Implement security for application platform services

Manage and monitor security posture (20–25%)

Manage security posture by using Defender for Cloud

Implement activity and event collection in Microsoft Sentinel

Implement Microsoft Security Copilot

SC-500 Practice Exams

SC-500 Practice Exam #1 (30 questions)

SC-500 Practice Exam #2 (30 questions)

SC-500 Practice Exam #3 (30 questions)

SC-500 Practice Exam #4 (30 questions)

Important SC-500 Resources

Link to the free, comprehensive, self-paced course on Microsoft Learn:

Implement end‑to‑end security controls for cloud and AI workloads

This course has 12 learning paths.

Link to the certification page:

Link to the “Microsoft Certified: Cloud and AI Security Engineer Associate” certification page.

Link to the study guide:

Link to the Study Guide for SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads.

A few highly rated SC-500 related courses on Udemy:

YouTube Video Series

Good luck to you passing the SC-500 Exam!
However, the more preparation you have, the less luck you will need. 🙂

Visit this post to see the list of all the certification preparation hubs available on The Data Community.

Microsoft Certification, SC-500, security October 10, 2026

Implement resource locks (SC-500 Exam Prep)

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:
Manage identity, access, and governance (20–25%)
   --> Implement governance to enforce security and regulatory compliance
      --> Implement resource locks

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 resource locks are an important governance mechanism for protecting critical Azure resources from accidental or unauthorized deletion or modification.

For the SC-500 exam, you should understand:

What Azure resource locks are
The two types of locks
Where locks can be applied
How locks are inherited
How locks interact with Azure RBAC
The difference between control-plane and data-plane operations
When to use CanNotDelete versus ReadOnly
How to create and manage locks
Important limitations and operational considerations

Resource locks are especially useful for protecting critical infrastructure such as production resource groups, databases, storage accounts, networking components, and other resources that should not be accidentally removed or modified.

1. What Are Azure Resource Locks?

An Azure resource lock is a management control that prevents users from accidentally deleting or modifying Azure resources.

Locks can be applied at several scopes, including:

Subscription
Resource group
Individual resource

When a lock is applied to a parent scope, resources contained within that scope can inherit the lock.

Resource locks are implemented through Azure Resource Manager and are sometimes referred to as management locks.

The key purpose of a resource lock is:

Protect important Azure resources from accidental deletion or modification, even when the user otherwise has sufficient permissions to perform the operation.

This makes resource locks different from ordinary Azure RBAC permissions.

2. Resource Locks vs. Azure RBAC

This distinction is extremely important for the SC-500 exam.

Azure RBAC determines what actions a user, group, service principal, or managed identity is authorized to perform.

A resource lock imposes an additional restriction on operations against the locked resource.

For example, suppose a user has the Owner role on a resource group.

Normally, the user has sufficient permissions to delete resources in that resource group.

If the resource group has a CanNotDelete lock, however, the user cannot delete the locked resource until the lock is removed.

Therefore:

A resource lock can restrict an operation even when the user has sufficient RBAC permissions to perform that operation.

This is one of the most important concepts to remember.

Simple comparison

Capability	Azure RBAC	Resource Lock
Determines who has permissions	Yes	No
Grants permissions	Yes	No
Restricts deletion	Indirectly, through permissions	Yes
Restricts modification	Through permissions	Yes, with `ReadOnly`
Applies to all users/roles at the locked scope	No	Yes
Protects against accidental deletion	Indirectly	Specifically designed for this
Replaces RBAC	No	No

Resource locks and RBAC are therefore complementary, not competing, security controls.

3. The Two Primary Resource Lock Types

Azure provides two primary management lock levels:

CanNotDelete
ReadOnly

The names used in the Azure portal are:

Delete
Read-only

The underlying Azure Resource Manager lock levels are:

CanNotDelete
ReadOnly

Understanding exactly what each does is essential for the exam.

4. CanNotDelete Lock

A CanNotDelete lock prevents the locked resource from being deleted.

Authorized users can still:

Read the resource
Modify the resource

They simply cannot delete it while the lock remains in place.

Example

Suppose a production SQL database has a CanNotDelete lock.

An administrator can still change supported configuration settings.

However, an attempt to delete the database will fail because the resource is locked.

Think of it as:

“You can change it, but you cannot delete it.”

This is generally the less restrictive of the two lock types.

5. ReadOnly Lock

A ReadOnly lock is more restrictive.

It prevents users from:

Modifying the resource
Deleting the resource

Users can still read the resource.

Think of it as:

“You can look at it, but you cannot change or delete it.”

A ReadOnly lock is conceptually similar to restricting authorized users to read-only access for control-plane operations.

However, there are important nuances involving data-plane operations, discussed later.

6. CanNotDelete vs. ReadOnly

This comparison should be memorized for the exam.

Lock Type	Read	Modify	Delete
No lock	Yes	Yes*	Yes*
`CanNotDelete`	Yes	Yes	No
`ReadOnly`	Yes	No	No

* Subject to the user’s normal RBAC permissions and other governance controls.

Easy memory trick

CanNotDelete:

Change it, but don’t delete it.

ReadOnly:

Read it, but don’t change or delete it.

7. Where Can Resource Locks Be Applied?

Resource locks can be applied at several scopes.

Subscription

A lock can be applied to an entire Azure subscription.

This can protect resources throughout the subscription.

However, a subscription-level lock can have a very broad impact and should therefore be used carefully.

Resource Group

A lock can be applied to a resource group.

This is a common approach for protecting a collection of related production resources.

For example:

			
Production Resource Group
│
├── Web App
├── Application Gateway
├── SQL Database
├── Storage Account
└── Key Vault

		

A CanNotDelete lock on the resource group can protect the resources from deletion.

Individual Resource

A lock can also be applied directly to a specific resource.

For example:

			
Production Resource Group
│
├── Web App
├── SQL Database ← CanNotDelete
├── Storage Account
└── Key Vault

		

Only the targeted resource is protected by the lock, subject to lock inheritance and scope rules.

This can be preferable when only a particularly critical resource needs protection.

8. Lock Inheritance

Locks can be inherited from a parent scope.

For example:

			
Subscription
     │
     └── Resource Group
             │
             ├── VM
             ├── Storage Account
             └── SQL Database

		

If a lock is applied to the resource group, the resources contained within that resource group inherit the lock.

This also means that resources added to the resource group later can inherit the applicable lock.

Exam scenario

Suppose:

Resource group ProductionRG has a CanNotDelete lock.
A new storage account is created in ProductionRG.

The storage account inherits the applicable lock.

The protection isn’t limited only to resources that existed when the lock was originally created.

9. The Most Restrictive Lock Takes Precedence

Multiple locks can exist within an inheritance hierarchy.

When multiple locks apply, the most restrictive lock takes precedence.

For example:

			
Resource Group
   CanNotDelete
        ↓
Storage Account
   ReadOnly

		

The storage account is effectively protected by the more restrictive ReadOnly behavior.

Therefore, when evaluating a scenario, don’t look only at a resource’s direct lock.

Consider:

The resource’s own lock
The parent resource group’s lock
The subscription-level lock
Which applicable lock is most restrictive

10. Resource Locks Are Control-Plane Controls

One of the most important technical details for the SC-500 exam is that resource locks apply to Azure Resource Manager control-plane operations.

They do not universally protect data-plane operations.

Control plane

The control plane manages Azure resources themselves.

Examples include operations such as:

Creating resources
Deleting resources
Updating resource configuration
Changing resource properties

These operations generally go through Azure Resource Manager.

Data plane

The data plane operates on the data contained within a resource.

Examples include:

Reading blob data
Writing blob data
Reading database records
Modifying database records

A resource lock does not automatically prevent all data-plane operations.

11. Example: Storage Account Lock

Consider a storage account containing:

			
Storage Account
│
├── Blob Container
│     ├── File A
│     └── File B
│
├── Queue
└── Table

		

You apply a CanNotDelete lock to the storage account.

The lock protects the storage account resource against deletion.

However, it does not automatically prevent someone with appropriate data-plane permissions from deleting Blob File A.

Why?

Because:

The lock protects Azure Resource Manager control-plane operations; it isn’t a general-purpose data protection mechanism.

This is a very common exam trap.

12. Resource Locks Do Not Replace Data Protection

Suppose an organization wants to protect important data stored in Azure Storage.

A resource lock can help prevent someone from deleting the storage account itself.

But it should not be treated as a replacement for:

Data access controls
Microsoft Entra authentication
Azure RBAC
Storage authorization
Backup
Soft delete
Versioning
Immutable storage where appropriate
Data-plane security controls

The lock protects the resource management operation.

Other controls protect the data.

13. Why Use CanNotDelete?

CanNotDelete is useful when:

Administrators need to continue modifying the resource
The resource must not be accidentally deleted
Normal operational management must continue
A production resource is business-critical

Example

A company has a production database that needs regular configuration updates.

The organization wants administrators to continue making approved changes but wants to prevent accidental deletion.

A CanNotDelete lock is appropriate.

The administrator can modify the resource but cannot delete it.

14. Why Use ReadOnly?

ReadOnly is appropriate when the resource should not be changed through the Azure Resource Manager control plane.

Examples might include:

A highly stable production resource
A critical networking component during a controlled period
A resource that should be temporarily frozen
A resource where configuration changes must be prevented

However, ReadOnly should be used carefully.

It is significantly more restrictive than CanNotDelete.

15. ReadOnly Can Break Operations

A common mistake is to assume that a ReadOnly lock is harmless because it only prevents direct modifications.

Some Azure operations that appear to be read or indirectly related to a resource can require control-plane write operations.

Consequently, applying ReadOnly can interfere with normal service functionality.

For example, some service operations may need to update configuration, create child resources, or perform other control-plane operations.

Therefore:

Use ReadOnly only when you understand the operational consequences for the service.

This is an important real-world security principle and can appear in scenario-based exam questions.

16. Resource Locks and Resource Groups

Resource-group-level locks require particular attention.

Suppose:

			
ProductionRG
│
├── VM
├── Storage Account
├── Key Vault
└── SQL Server

		

You apply:

CanNotDelete

to ProductionRG.

The resources inherit the protection.

An attempt to delete the resource group is blocked because deleting the resource group would require deleting its contained resources.

Importantly, the deletion operation doesn’t simply delete everything that isn’t individually locked while leaving locked resources behind.

The lock blocks the overall deletion operation.

17. Resource Locks and Resource Group Deletion

Consider:

			
ProductionRG
│
├── Resource A
├── Resource B
└── Resource C

		

If the resource group has a CanNotDelete lock, attempting to delete ProductionRG is blocked.

This is true even if some individual resources don’t have their own locks.

The parent-level lock protects the scope and its resources.

Exam takeaway

If a scenario says:

“Prevent the resource group and all resources within it from being accidentally deleted.”

A CanNotDelete lock at the resource-group level is a strong candidate.

18. Resource Locks and RBAC Assignments

A particularly important operational consideration is that a CanNotDelete lock can also prevent deletion of Azure RBAC role assignments associated with the locked resource or scope.

This is another reason resource locks should be planned carefully.

A lock isn’t simply a protection mechanism for the resource itself; it can affect related control-plane operations.

Therefore, before applying a lock, administrators should understand what operations are required to manage the resource and its associated configuration.

19. Resource Locks and Azure Backup

Resource locks can also affect Azure Backup operations.

For example, a CanNotDelete lock on a resource group created by Azure Backup can prevent the service from deleting old restore points.

This can cause backup-related operational problems because the service may be unable to perform its normal cleanup.

Exam lesson

Don’t assume:

“A resource lock can always be safely applied to any resource group.”

Instead, consider:

What services manage resources in the scope?
Do those services need to delete resources?
Do they need to modify resources?
Will the lock interfere with lifecycle operations?

Security controls must be designed with service dependencies in mind.

20. Resource Locks and Azure Machine Learning

Another example of an operational consequence involves Azure Machine Learning.

A CanNotDelete lock on a resource group containing an Azure Machine Learning workspace can interfere with autoscaling of compute clusters.

The service may need to remove unused nodes, and the lock can prevent the required deletion operations.

This can result in unused compute resources remaining active.

The broader lesson is:

A lock can protect resources but can also interfere with automated service operations that require deletion or modification.

21. Resource Locks and Deployment History

A CanNotDelete lock on a resource group or subscription can also affect automatic cleanup of Azure Resource Manager deployment history.

Azure Resource Manager can automatically remove older deployment records.

If the applicable scope has a CanNotDelete lock, the deployment history cannot be automatically deleted in the normal way.

This can eventually cause deployment problems if deployment history reaches its limit.

Therefore, locks can have consequences beyond the obvious “prevent resource deletion” behavior.

22. Who Can Create or Delete Resource Locks?

Resource locks are themselves Azure resources and require appropriate authorization.

Permissions to create or delete management locks are associated with actions such as:

Microsoft.Authorization/*

Microsoft.Authorization/locks/*

Roles such as Owner and User Access Administrator have the required permissions in the relevant contexts.

Specialized roles may also provide the necessary permissions.

Important distinction

Having permission to modify a resource does not necessarily mean that you can remove a resource lock.

Lock management requires appropriate authorization to manage locks.

This helps prevent a normal resource administrator from simply bypassing the protection.

23. Removing a Resource Lock

A resource lock must be removed before a protected operation can be performed when the lock blocks that operation.

For example:

			
CanNotDelete Lock
       ↓
Delete resource
       ↓
Operation blocked
       ↓
Authorized administrator removes lock
       ↓
Delete resource

		

The ability to remove the lock itself requires appropriate permissions.

This creates an additional administrative boundary around highly sensitive resources.

24. Creating Resource Locks in the Azure Portal

A resource lock can be configured through the Azure portal.

For a resource or resource group, the general process is:

Open the resource or resource group.
Select Locks.
Select Add.
Enter a lock name.
Select the lock type:
- Delete
- Read-only
Optionally provide notes.
Create the lock.

The portal terminology maps to the Azure Resource Manager lock levels:

Portal	ARM Lock Level
Delete	`CanNotDelete`
Read-only	`ReadOnly`

25. Creating Locks with Azure CLI

Resource locks can also be managed through Azure CLI.

For example, a CanNotDelete lock on a resource can be created with a command conceptually similar to:

			
az resource lock create \
  --lock-type CanNotDelete \
  --name ProductionLock \
  --resource-group ProductionRG \
  --resource MyStorageAccount \
  --resource-type Microsoft.Storage/storageAccounts

		

A read-only lock can similarly be created by specifying:

--lock-type ReadOnly

The important exam concept isn’t memorizing every CLI parameter.

Instead, understand that Azure CLI supports both:

CanNotDelete
ReadOnly

and can apply them at appropriate scopes.

26. Creating Locks with Azure PowerShell

Azure PowerShell also supports resource locks.

For example:

			
New-AzResourceLock `
    -LockName ProductionLock `
    -LockLevel CanNotDelete `
    -ResourceGroupName ProductionRG

You can use PowerShell commands such as:

New-AzResourceLock
Get-AzResourceLock
Remove-AzResourceLock

to manage locks.

Again, for SC-500, understanding the purpose and behavior is generally more important than memorizing every command parameter.

27. Resource Locks with ARM Templates and Bicep

Resource locks can also be deployed programmatically using infrastructure as code.

The resource type is:

Microsoft.Authorization/locks

For example, a Bicep resource can conceptually specify:

			
resource createRgLock 'Microsoft.Authorization/locks@2016-09-01' = {
  name: 'productionLock'
  properties: {
    level: 'CanNotDelete'
    notes: 'Protect production resources from accidental deletion.'
  }
}

		

This allows resource-lock configuration to become part of a repeatable infrastructure deployment process.

However, teams should carefully consider lifecycle management.

For example, if the same deployment is responsible for creating the lock and later modifying or deleting the protected resource, the deployment process must have the necessary permissions and be designed to account for the lock.

28. Resource Locks and Infrastructure as Code

Resource locks can be useful as part of a defense-in-depth strategy.

For example:

			
Infrastructure as Code
        ↓
Azure Policy
        ↓
RBAC
        ↓
Resource Lock
        ↓
Protected Resource

		

Each control addresses a different concern.

Infrastructure as code

Provides repeatable and controlled deployments.

Azure Policy

Enforces organizational configuration requirements.

RBAC

Controls who can perform actions.

Resource locks

Prevent deletion or modification at the locked scope.

No single control should be treated as a complete security solution.

29. Resource Locks Are Not a Replacement for Azure Policy

Resource locks and Azure Policy solve different problems.

Resource lock

Protects a specific scope from deletion or modification.

Azure Policy

Evaluates resources against organizational rules and can audit or enforce compliance.

For example:

Requirement:

All storage accounts must use approved network configurations.

Azure Policy is appropriate because the requirement needs to be evaluated across resources.

Requirement:

Prevent accidental deletion of this production storage account.

A resource lock is appropriate.

Easy distinction

Policy asks: “Does this resource meet the required configuration?”

Lock asks: “Can this resource be deleted or modified?”

30. Resource Locks and Tags

Tags and resource locks serve very different purposes.

Locks

Restrict control-plane operations.

A tag such as:

Environment = Production

doesn’t protect a resource from deletion.

A CanNotDelete lock does.

31. Resource Locks and Resource Health

Resource locks also shouldn’t be confused with resource health or monitoring capabilities.

A lock doesn’t:

Detect attacks
Detect malware
Monitor availability
Encrypt data
Back up data
Detect vulnerabilities
Replace security monitoring

Its purpose is much narrower:

Prevent specified management operations against a resource or scope.

32. Choosing the Correct Lock

A useful decision framework is:

Requirement 1

“Administrators must be able to modify the resource, but nobody should be able to delete it.”

Use: CanNotDelete

Requirement 2

“The resource should not be modified or deleted.”

Use: ReadOnly

Requirement 3

“Only this one resource must be protected.”

Apply the lock directly to the resource.

Requirement 4

“All resources in this resource group should be protected from deletion.”

Apply a CanNotDelete lock to the resource group.

Requirement 5

“Prevent resources from being deployed with insecure configurations.”

Consider Azure Policy rather than a resource lock.

Requirement 6

“Protect blob data from unauthorized deletion.”

Don’t rely solely on a resource lock.

Use appropriate data-plane controls and data-protection features.

33. Common Resource Lock Exam Traps

Trap 1: “Owner can always delete the resource.”

Not necessarily.

A resource lock can prevent deletion even when the user has sufficient RBAC permissions.

Trap 2: “`CanNotDelete` prevents modifications.”

Incorrect.

CanNotDelete permits authorized users to modify the resource.

It prevents deletion.

Trap 3: “`ReadOnly` only prevents deletion.”

Incorrect.

ReadOnly prevents both modification and deletion through applicable control-plane operations.

Trap 4: “A storage account lock prevents users from deleting blobs.”

Not necessarily.

Resource locks apply to control-plane operations and aren’t a universal data-plane protection mechanism.

Trap 5: “A resource-group lock protects only the resource group.”

Not exactly.

Locks applied at a parent scope can be inherited by resources within that scope.

Trap 6: “Locks are inherited upward.”

Incorrect.

Inheritance flows downward from a parent scope to child resources.

Trap 7: “Resource locks replace RBAC.”

Incorrect.

RBAC controls authorization.

Locks impose additional management restrictions.

Trap 8: “ReadOnly is always better because it provides stronger security.”

Not necessarily.

ReadOnly can interfere with legitimate service operations.

The appropriate lock depends on the required operational behavior.

Trap 9: “Resource locks protect against every kind of deletion.”

Incorrect.

The lock applies to Azure Resource Manager control-plane operations. Data-plane operations can behave differently.

Trap 10: “A resource lock automatically protects backups.”

Incorrect.

Locks can actually interfere with Azure Backup lifecycle operations if the backup service needs to delete or modify resources.

34. Best Practices for Resource Locks

1. Use CanNotDelete for critical resources that still require routine administration

This provides protection against accidental deletion without preventing normal configuration changes.

2. Use ReadOnly sparingly

ReadOnly is highly restrictive and can interfere with service operations.

3. Apply locks at the narrowest practical scope

Don’t automatically lock an entire subscription when protecting one resource is sufficient.

4. Document locks

Use meaningful lock names and notes explaining why the lock exists.

5. Consider service dependencies

Before locking a resource group, determine whether Azure services need to create, modify, or delete resources within it.

6. Don’t use locks as a substitute for data protection

Combine locks with appropriate:

RBAC
Data-plane authorization
Backup
Soft delete
Versioning
Immutability
Monitoring

7. Combine locks with Azure Policy

Use Policy for configuration governance and locks for resource protection.

8. Review locks periodically

An outdated lock can become an operational problem.

9. Establish a controlled lock-removal process

Because removing a lock can enable destructive operations, lock removal should be appropriately governed.

10. Use infrastructure as code when appropriate

For environments where locks are part of the intended architecture, consider managing them consistently through deployment automation.

35. Resource Locks: Quick Reference

Requirement	Recommended Approach
Prevent resource deletion	`CanNotDelete`
Prevent resource modification and deletion	`ReadOnly`
Allow normal configuration changes but prevent deletion	`CanNotDelete`
Protect an entire resource group	Lock the resource group
Protect a single critical resource	Lock the resource
Protect resources across a subscription	Subscription-level lock, used carefully
Prevent insecure configurations	Azure Policy
Control who can manage resources	Azure RBAC
Protect data from data-plane deletion	Data-plane security/data protection controls
Protect against accidental resource deletion	Resource lock
Allow users to read but not modify the resource	`ReadOnly`

36. SC-500 Exam Review

Before taking the exam, make sure you can answer the following questions.

What is a resource lock?

A management control that prevents deletion or modification of Azure resources at a specified scope.

What are the two lock types?

CanNotDelete
ReadOnly

What does CanNotDelete do?

Allows authorized users to read and modify the resource but prevents deletion.

What does ReadOnly do?

Allows reading but prevents modification and deletion through applicable control-plane operations.

Does a resource lock override RBAC permissions?

A lock can restrict operations even when a user otherwise has sufficient RBAC permissions.

Where can locks be applied?

At subscription, resource group, or resource scope.

Are locks inherited?

Yes. Locks applied at a parent scope can be inherited by child resources.

Which lock takes precedence if multiple locks apply?

The most restrictive applicable lock.

Do locks protect data-plane operations?

No. Resource locks primarily apply to Azure Resource Manager control-plane operations.

Does CanNotDelete allow modifications?

Yes.

Does ReadOnly prevent deletion?

Yes.

Should ReadOnly be used everywhere?

No. It can interfere with legitimate service operations.

Do locks replace Azure Policy?

No.

Do locks replace RBAC?

No.

Do locks replace backup and data-protection controls?

No.

Practice Exam Questions

Question 1

A company has a production Azure SQL database that must remain available for administrators to modify its configuration. However, the company wants to prevent the database from being accidentally deleted.

Which resource lock should you apply?

A. ReadOnly

B. CanNotDelete

C. Audit

D. Deny

Correct Answer: B

Explanation

A CanNotDelete lock allows authorized users to read and modify the resource while preventing deletion.

A ReadOnly lock would also prevent configuration modifications, making it too restrictive for this scenario.

Question 2

An administrator has the Owner role on an Azure resource group. The resource group has a CanNotDelete management lock.

The administrator attempts to delete the resource group.

What happens?

A. The resource group is deleted because Owner always overrides locks

B. The administrator is prompted to provide a second MFA credential

C. The deletion succeeds, but the resources inside the resource group remain

D. The deletion is blocked by the resource lock

Correct Answer: D

Explanation

A management lock can restrict operations even when the user has sufficient RBAC permissions.

The CanNotDelete lock prevents deletion of the locked scope.

An Owner role does not automatically bypass a resource lock.

Question 3

A security engineer wants to protect a critical production resource from both accidental modification and accidental deletion through Azure Resource Manager.

Which lock should be used?

A. ReadOnly

B. CanNotDelete

C. AuditIfNotExists

D. Deny

Correct Answer: A

Explanation

A ReadOnly lock prevents both modification and deletion of the resource through applicable control-plane operations while allowing it to be read.

CanNotDelete would still allow authorized users to modify the resource.

Question 4

An organization applies a CanNotDelete lock to a resource group containing several production resources.

What is the expected effect?

A. Only the resource group name becomes read-only

B. Users can no longer read any resources in the resource group

C. Resources within the resource group inherit the applicable deletion protection

D. Azure Policy is automatically assigned to every resource

Correct Answer: C

Explanation

Resource locks applied to a parent scope can be inherited by child resources.

A CanNotDelete lock on a resource group therefore protects resources within that scope from applicable deletion operations.

It doesn’t prevent reading, and it doesn’t automatically create an Azure Policy assignment.

Question 5

A security administrator applies a CanNotDelete lock to an Azure Storage account. A user with appropriate data-plane permissions subsequently deletes a blob stored in the account.

Why can this occur?

A. CanNotDelete locks only work for virtual machines

B. The lock protects Azure Resource Manager control-plane operations, not all data-plane operations

C. Storage accounts cannot have resource locks

D. Blob deletion always bypasses Azure RBAC

Correct Answer: B

Explanation

Resource locks primarily protect control-plane operations.

Blob operations are data-plane operations and are governed by data-plane authorization and data-protection mechanisms.

Therefore, a resource lock should not be considered a universal mechanism for protecting data stored inside the resource.

Question 6

A company has a resource group containing resources managed by Azure Backup. An administrator wants to apply a CanNotDelete lock to the resource group.

What should the administrator consider before applying the lock?

A. The lock automatically increases backup storage capacity

B. The lock converts all backup data to immutable storage

C. The lock has no effect on Azure Backup

D. The lock can interfere with backup lifecycle operations that require deletion of resources such as old restore points

Correct Answer: D

Explanation

A CanNotDelete lock can prevent Azure Backup from performing required cleanup operations.

Therefore, resource locks must be evaluated for operational side effects before being applied to resource groups managed by Azure services.

Question 7

A company has a CanNotDelete lock on a resource group. Administrators can still modify resources within the group, but they cannot delete them.

The security team now wants to prevent configuration changes as well.

What should they do?

A. Replace the lock with a ReadOnly lock

B. Add an Azure tag

C. Change the RBAC role to Reader for every resource

D. Enable Microsoft Sentinel

Correct Answer: A

Explanation

A ReadOnly lock prevents both modification and deletion through applicable control-plane operations.

A CanNotDelete lock only prevents deletion.

Question 8

A security engineer is designing governance controls for an Azure environment.

The organization has two requirements:

Prevent developers from deploying resources that violate required security configurations.
Prevent accidental deletion of a critical production database.

Which combination should the engineer consider?

A. Resource lock for both requirements

B. Microsoft Sentinel for both requirements

C. Azure Policy for the first requirement and a resource lock for the second

D. RBAC alone for both requirements

Correct Answer: C

Explanation

Azure Policy is appropriate for evaluating and enforcing resource configuration requirements.

A resource lock is appropriate for protecting a critical resource against deletion.

The two controls address different governance problems and can be used together.

Question 9

A resource has a CanNotDelete lock directly applied to it. Its parent resource group has a ReadOnly lock.

Which lock behavior applies to the resource?

A. CanNotDelete because the resource-level lock always overrides the parent

B. No lock because multiple locks cancel each other

C. ReadOnly because the most restrictive applicable lock takes precedence

D. The resource becomes unlocked because only subscription locks are inherited

Correct Answer: C

Explanation

Locks can be inherited from parent scopes, and when multiple locks apply, the most restrictive lock takes precedence.

ReadOnly is more restrictive than CanNotDelete because it prevents both modification and deletion.

Question 10

A security team wants to protect an Azure resource from accidental deletion. The team also wants administrators to be able to perform normal configuration changes.

Which solution best meets the requirement?

A. Apply a ReadOnly lock

B. Apply a CanNotDelete lock

C. Assign the Reader role to administrators

D. Apply an Azure Policy with a Deny effect to the resource

Correct Answer: B

Explanation

A CanNotDelete lock is specifically designed for this scenario.

It prevents deletion while allowing authorized users to modify the resource.

A ReadOnly lock would prevent the required configuration changes. The Reader role would also prevent administrators from making those changes. Azure Policy with Deny is primarily intended for enforcing configuration rules rather than simply protecting a particular resource from deletion.

Final SC-500 Takeaways

The most important concepts to remember for Implement resource locks are:

Resource locks protect Azure resources from accidental deletion or modification.
Locks can be applied at the subscription, resource group, or resource scope.
The two primary lock types are CanNotDelete and ReadOnly.
CanNotDelete allows reading and modification but prevents deletion.
ReadOnly allows reading but prevents modification and deletion.
Resource locks can restrict operations even when the user has sufficient RBAC permissions.
Locks applied at a parent scope can be inherited by child resources.
When multiple locks apply, the most restrictive lock takes precedence.
Resource locks primarily affect control-plane operations.
A resource lock does not automatically protect data-plane data such as blobs or database records.
Resource locks do not replace Azure RBAC.
Resource locks do not replace Azure Policy.
Use Azure Policy to govern resource configurations and use resource locks to protect resources from deletion or modification.
Use CanNotDelete when administrators must continue modifying the resource.
Use ReadOnly when both modification and deletion must be prevented.
Apply locks carefully because they can interfere with automated Azure service operations.
In particular, locks can affect services such as Azure Backup and other services that need to modify or delete resources.
A resource-group-level lock can prevent deletion of the entire resource group and its contents.
Managing locks requires appropriate authorization to manage Azure management locks.
Resource locks are one component of a broader defense-in-depth governance strategy.

The key exam rule to remember

CanNotDelete = Read + Modify, but NO Delete

ReadOnly = Read, but NO Modify and NO Delete

And perhaps the most important conceptual distinction:

Azure Policy governs what configurations are allowed; RBAC controls who is authorized to perform actions; resource locks prevent specified management operations on protected scopes.

Go to the SC-500 Exam Prep Hub main page

azure, Microsoft Certification, SC-500, security October 10, 2026

Manage Azure built-in role assignments (SC-500 Exam Prep)

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:
Manage identity, access, and governance (20–25%)
   --> Implement governance to enforce security and regulatory compliance
      --> Manage Azure built-in role assignments

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.

Overview

Azure role-based access control (Azure RBAC) is the authorization system used to control access to Azure resources. It answers three fundamental questions:

Who can access a resource?
What can they do?
Where can they do it?

For the SC-500 exam, understanding how to select and manage Azure built-in roles is especially important because effective security depends on assigning the minimum permissions at the narrowest practical scope.

Azure provides many predefined, or built-in, roles for common administrative and workload scenarios. Examples include Reader, Contributor, Owner, Storage Blob Data Reader, Virtual Machine Contributor, Key Vault Secrets User, and many others.

A role assignment connects a security principal to a role at a particular scope.

The basic model is:

Security principal + Role definition + Scope = Role assignment

1. What Is Azure RBAC?

Azure RBAC provides fine-grained authorization for Azure resources.

For example, an organization might want:

Developers to manage resources in a development resource group.
Database administrators to manage Azure SQL resources.
Security administrators to manage security-related configurations.
Auditors to view resources but not modify them.
An application to read data from a specific storage account.
A managed identity to access secrets in a particular Key Vault.

Rather than giving everyone unrestricted access to an entire subscription, Azure RBAC allows permissions to be assigned according to job responsibilities.

This supports the principle of least privilege.

The three core components

Every Azure RBAC role assignment involves:

Security principal
Role definition
Scope

Security principal

The security principal is the identity receiving the permissions.

It can be:

User
Group
Service principal
Managed identity

Using groups instead of assigning roles individually to many users is generally preferred because it simplifies administration and makes access easier to review.

Role definition

The role definition specifies the permissions granted.

For example:

Reader allows viewing resources.
Contributor allows managing resources but does not allow assigning Azure RBAC roles.
Owner provides full resource management access and can assign Azure RBAC roles.

Scope

Scope determines where the permissions apply.

Azure supports four primary scope levels:

Management group
Subscription
Resource group
Individual resource

Permissions assigned at a parent scope are inherited by child scopes.

2. Role Definitions vs. Role Assignments

This distinction is frequently tested.

Role definition

A role definition describes what permissions a role contains.

For example, a role definition might specify that a principal can:

Read virtual machines
Start and stop virtual machines
Restart virtual machines

A role definition is essentially the permission set.

Role assignment

A role assignment applies that role to a particular principal at a particular scope.

For example:

Assign the Virtual Machine Contributor role to the VM-Admins group at the Production-RG resource-group scope.

The role is the Virtual Machine Contributor role definition.

The group is the security principal.

The resource group is the scope.

Together, they form the role assignment.

Exam tip

Think:

Role definition = What can be done?

Role assignment = Who can do it and where?

3. What Are Azure Built-in Roles?

Azure built-in roles are predefined role definitions provided by Microsoft.

They are designed for common administrative and workload scenarios.

Azure has built-in roles covering areas such as:

General resource management
Compute
Networking
Storage
Databases
Containers
AI and machine learning
Security
Monitoring
Identity
Management and governance
Hybrid and multicloud environments

Built-in roles should generally be considered before creating custom roles.

Examples include:

Built-in role	General purpose
Owner	Full access, including ability to assign Azure RBAC roles
Contributor	Manage Azure resources, but cannot assign Azure RBAC roles
Reader	View Azure resources without making changes
User Access Administrator	Manage user access to Azure resources
Role Based Access Control Administrator	Manage Azure RBAC role assignments
Virtual Machine Contributor	Manage virtual machines
Network Contributor	Manage networking resources
Storage Account Contributor	Manage storage account resources
Key Vault Reader	Read Key Vault metadata
Storage Blob Data Reader	Read blob data

The exact permissions of a role should always be evaluated rather than relying solely on the role’s name.

4. Owner vs. Contributor vs. Reader

These three roles are particularly important.

Owner

The Owner role grants full access to manage resources, including the ability to assign Azure RBAC roles.

This makes Owner a highly privileged role.

For example:

A user with Owner at the subscription scope can manage resources throughout that subscription and can grant Azure RBAC access to other principals.

Because of its power, the number of Owner assignments should be minimized.

Contributor

The Contributor role grants broad resource-management permissions.

A Contributor can generally create and manage resources but cannot assign Azure RBAC roles.

This distinction is extremely important.

For example:

A user who needs to create, modify, and delete virtual machines but should not be able to grant other users access may be a candidate for Contributor or a more narrowly scoped compute-specific role.

Common exam trap

Contributor ≠ Owner

Contributor does not have the permission to manage Azure RBAC role assignments.

Reader

The Reader role provides read-only access to Azure resources.

A Reader can inspect resources and their configurations but cannot modify them.

For example:

A security auditor needs to inspect the configuration of resources throughout a subscription but should not be able to make changes.

Reader may be appropriate, subject to whether additional permissions are needed for the specific data or security information being examined.

5. User Access Administrator

The User Access Administrator role is designed to manage access to Azure resources.

It can assign Azure RBAC roles.

This is different from Contributor.

Consider the following:

Role	Manage resources	Assign Azure RBAC roles
Reader	No	No
Contributor	Yes	No
Owner	Yes	Yes
User Access Administrator	Access-management focused	Yes

Therefore, if a user needs to manage access but doesn’t need broad resource-management permissions, User Access Administrator can be more appropriate than Owner.

6. Role Based Access Control Administrator

The Role Based Access Control Administrator role is another important role for the SC-500 exam.

It is designed specifically for managing user access to Azure resources through Azure RBAC.

It can:

Create role assignments
Delete role assignments
Manage Azure RBAC access

It provides a more focused access-management capability than Owner.

Microsoft specifically describes Role Based Access Control Administrator as a role designed for delegating role-assignment management.

Why this matters

Suppose an organization has a team responsible for administering Azure RBAC assignments.

Giving that team Owner permissions would provide much more power than necessary.

A security-conscious design could instead use Role Based Access Control Administrator, with an appropriately limited scope.

This better supports least privilege.

7. Built-in Roles Are Not the Same as Microsoft Entra Roles

Another important distinction is between:

Azure RBAC roles

and

Microsoft Entra roles

Azure RBAC controls access to Azure resources.

Microsoft Entra roles control administrative access to Microsoft Entra resources and directory functionality.

For example:

Azure RBAC can control who can manage an Azure Storage account.
Microsoft Entra roles can control directory administration activities.

Do not automatically assume that an Azure RBAC role controls Microsoft Entra directory administration.

They are related security concepts but are different authorization systems.

8. Understanding Scope

Scope is one of the most important concepts when assigning built-in roles.

The four Azure RBAC scopes are:

1. Management group

The broadest common scope.

Permissions can apply to subscriptions and resources contained within the management group hierarchy.

2. Subscription

Permissions apply throughout the subscription.

3. Resource group

Permissions apply to resources contained within that resource group.

4. Resource

Permissions apply to a specific resource.

The hierarchy is:

Management group → Subscription → Resource group → Resource

A role assignment at a parent scope is inherited by child scopes.

9. Why Scope Matters for Least Privilege

Consider an application that needs to read blobs from one storage account.

There are several possible ways to assign permissions.

Poor design

Assign a broad storage-related role at the subscription level.

The application may receive access to far more resources than necessary.

Better design

Assign the appropriate data-access role at the storage-account or even more narrowly applicable scope, when supported.

The principle is:

Use the smallest scope that satisfies the requirement.

Microsoft recommends limiting both the role and scope because doing so reduces the resources that could be affected if a security principal is compromised.

10. Role Inheritance

Suppose you assign:

Reader → Subscription A

The assignment is inherited by resources and resource groups beneath that subscription.

Similarly:

Contributor → Resource Group A

is inherited by resources inside Resource Group A.

This means that you don’t have to create individual role assignments for every resource.

However, inheritance can also create unexpected access if administrators aren’t careful.

Exam scenario

A user unexpectedly has Contributor access to a virtual machine.

You discover that the user does not have a Contributor assignment directly on the VM.

The user might have inherited Contributor permissions from:

The resource group
The subscription
A management group

Always investigate inherited assignments when troubleshooting access.

11. Choosing the Appropriate Built-in Role

A good process is:

Step 1: Identify the principal

Who needs access?

User?
Group?
Service principal?
Managed identity?

Step 2: Determine what the principal needs to do

For example:

View resources
Manage virtual machines
Manage networking
Read blob data
Manage Azure RBAC
Manage all resources

Step 3: Select the least-privileged suitable role

Prefer an appropriate built-in role over a broader role.

For example:

If someone only needs to read resources, don’t assign Contributor.

Step 4: Determine the narrowest practical scope

Ask:

What is the smallest scope at which this role can satisfy the requirement?

Step 5: Assign the role

The role can be assigned through:

Azure portal
Azure CLI
Azure PowerShell
Azure SDKs
REST APIs

12. Example: Developer Access

Suppose developers need to manage resources in a development resource group.

A possible design is:

Principal: Developers group

Role: Contributor

Scope: Development resource group

This gives developers broad resource-management capabilities within that resource group while avoiding unnecessary access to the rest of the subscription.

However, if developers only need to manage a particular resource type, a more narrowly scoped built-in role may be preferable.

13. Example: Security Auditor

Suppose a security auditor needs to inspect Azure resources but should not modify them.

A possible assignment is:

Principal: Security Auditors group

Role: Reader

Scope: Appropriate subscription or resource group

The scope should be limited to the resources the auditors actually need to review.

If they require specialized security information or data-plane access, additional permissions may be necessary.

14. Example: Application Access to Storage

Suppose an application uses a managed identity and needs to read blob data from one storage account.

A common mistake would be to grant a broad management role such as Contributor.

That is excessive because the application doesn’t need to manage the storage account.

Instead, consider a data-plane role such as:

Storage Blob Data Reader

at the narrowest suitable scope.

This illustrates an important security principle:

Management-plane access and data-plane access are different.

A role that lets someone manage a storage account does not necessarily mean they should be granted unrestricted access to the data stored within it.

15. Control Plane vs. Data Plane

Azure permissions can involve two broad areas.

Control plane

The control plane concerns management of Azure resources.

Examples include:

Creating a storage account
Changing resource configuration
Creating a virtual machine
Deleting a resource

Azure RBAC Actions and NotActions primarily describe control-plane operations.

Data plane

The data plane concerns access to the actual data contained within a service.

Examples include:

Reading blobs
Writing blobs
Reading Key Vault secrets
Accessing database data

Azure RBAC role definitions can also contain DataActions and NotDataActions for supported services.

Exam warning

Don’t assume:

“The user can manage the resource, therefore the user can access all of its data.”

That is not necessarily true.

16. Role Definition Permissions

A role definition can contain permission categories such as:

Actions
NotActions
DataActions
NotDataActions

Actions

Control-plane operations that the role permits.

NotActions

Control-plane operations excluded from the permissions represented by Actions.

DataActions

Data-plane operations that the role permits.

NotDataActions

Data-plane operations excluded from the permissions represented by DataActions.

For exam questions, pay attention to whether the requirement involves managing a resource or accessing the data within that resource.

17. When a Built-in Role Isn’t Enough

Azure provides many built-in roles, but sometimes none provides exactly the required permissions.

For example, suppose an organization needs a role that can:

Read specific resources
Perform several specific management operations
Not perform certain administrative operations
Be assigned only within particular organizational scopes

A custom Azure role may be appropriate.

However, the general strategy should be:

Start with built-in roles and create a custom role only when the built-in roles cannot satisfy the requirement with appropriate least privilege.

18. Built-in Roles Have Broad Availability

Built-in Azure roles are designed to be reusable across Azure environments.

Built-in role definitions have an AssignableScopes value of /, meaning they are available for assignment throughout Azure’s scope hierarchy.

This differs from custom roles, whose assignable scopes can be restricted to particular management groups, subscriptions, or resource groups.

19. Who Can Assign Azure RBAC Roles?

Having the ability to manage Azure resources does not automatically mean you can assign Azure RBAC roles.

For example:

Contributor

can manage resources but cannot assign Azure RBAC roles.

Permissions needed to create role assignments include:

Microsoft.Authorization/roleAssignments/write

Permissions needed to delete role assignments include:

Microsoft.Authorization/roleAssignments/delete

Roles such as:

Owner
User Access Administrator
Role Based Access Control Administrator

can provide the appropriate role-assignment management permissions, depending on scope and configuration.

20. Assign Roles to Groups When Practical

For organizations with multiple users performing the same job function, assigning roles to Microsoft Entra groups is generally preferable to creating separate assignments for every individual.

For example:

Security-Readers group → Reader → Security subscription scope

When users join or leave the security team, group membership can be managed without repeatedly changing Azure RBAC assignments.

This can improve:

Manageability
Consistency
Auditing
Access reviews
Least-privilege governance

Azure RBAC best practices recommend assigning roles to groups rather than individual users when practical.

21. Avoid Excessive Owner Assignments

Owner is one of the most powerful Azure RBAC roles.

An Owner can:

Manage Azure resources
Assign Azure RBAC roles

Because a compromised Owner account could have substantial impact, organizations should minimize the number of permanent Owner assignments.

Microsoft’s Azure RBAC guidance recommends limiting subscription Owner assignments.

For privileged administrative access, organizations should also consider Microsoft Entra Privileged Identity Management (PIM) where appropriate.

22. Azure RBAC and PIM

Azure RBAC answers:

What permissions does this principal have?

Microsoft Entra PIM helps answer:

When and under what conditions should a person receive privileged access?

For example, instead of permanently assigning an administrator a highly privileged role, an organization can use an eligible assignment and require activation when privileged work is needed.

This reduces standing privileged access.

Exam concept

Least privilege and just-in-time privileged access complement each other.

23. Azure RBAC vs. Azure Policy

These technologies serve different purposes.

Azure RBAC

Controls:

Who can perform which actions on Azure resources?

Azure Policy

Controls:

Which resource configurations are allowed, required, or evaluated?

For example:

RBAC requirement:

Only the Network Administrators group can modify virtual networks.

Azure Policy requirement:

Storage accounts must use a specified security configuration.

Do not use Azure RBAC as a replacement for Azure Policy.

Likewise, don’t use Azure Policy as a replacement for identity authorization.

24. Azure RBAC vs. Resource Locks

Resource locks and RBAC are also different.

Azure RBAC

Controls who can perform authorized operations.

Resource locks

Protect resources against certain management operations such as deletion or modification.

For example:

RBAC determines who is authorized to manage a resource.
A CanNotDelete lock can prevent deletion even when a principal otherwise has sufficient resource-management permissions.

Therefore, security governance may use both controls together.

25. Common SC-500 Exam Traps

Trap 1: Contributor can assign roles

False.

Contributor can manage resources but cannot assign Azure RBAC roles.

Trap 2: Owner is always the best administrator role

False.

Owner provides extensive permissions and should not be used when a more narrowly privileged role is sufficient.

Trap 3: Reader can modify resources

False.

Reader is intended for read-only access.

Trap 4: A resource-level assignment automatically gives subscription-wide access

False.

The assignment applies to the specified scope and does not automatically expand upward.

Trap 5: A subscription-level assignment applies only to the subscription object

False.

Permissions assigned at subscription scope are inherited by resources beneath the subscription.

Trap 6: Azure RBAC and Microsoft Entra roles are interchangeable

False.

They govern different areas of authorization.

Trap 7: Managing a storage account means automatically having data access

False.

Management-plane and data-plane permissions are distinct.

Trap 8: Custom roles should always be used for least privilege

False.

Start with built-in roles. Create custom roles when built-in roles don’t provide the appropriate permissions.

Trap 9: Contributor is always preferable to a specialized role

False.

A specialized role may provide significantly narrower permissions.

Trap 10: Role assignment and role definition mean the same thing

False.

The role definition describes permissions; the role assignment applies those permissions to a principal at a scope.

26. Exam-Focused Decision Guide

When faced with a scenario, use this mental checklist:

Requirement	Likely approach
View Azure resources	Reader
Manage Azure resources without managing RBAC	Contributor or a more specialized role
Full resource management plus RBAC management	Owner
Manage Azure RBAC assignments	Role Based Access Control Administrator or User Access Administrator, depending on requirements
Manage only a particular workload type	Specialized built-in role
Application needs blob read access	Storage Blob Data Reader or another appropriate data-plane role
Access should apply only to one resource	Resource-level scope
Access should apply to resources in one resource group	Resource-group scope
Access should span an entire subscription	Subscription scope
Access should span multiple subscriptions	Management-group scope
Built-in role is too broad or doesn’t meet requirements	Consider a custom role
Need to prevent insecure configurations	Azure Policy
Need to protect against accidental deletion	Resource lock
Need temporary privileged access	Consider PIM

27. Key Takeaways

For the SC-500 exam, remember these principles:

Azure RBAC controls access to Azure resources.
A role assignment consists of a principal, role definition, and scope.
Built-in roles provide predefined permissions for common scenarios.
Owner provides full resource management and can assign Azure RBAC roles.
Contributor can manage resources but cannot assign Azure RBAC roles.
Reader provides read-only resource access.
User Access Administrator and Role Based Access Control Administrator are designed for access-management scenarios.
Azure RBAC scopes are management group, subscription, resource group, and resource.
Permissions assigned at a parent scope are inherited by child resources.
Follow least privilege by selecting the narrowest appropriate role and scope.
Assign roles to groups when practical.
Distinguish control-plane permissions from data-plane permissions.
Use a specialized built-in role when it provides the required permissions more precisely than Contributor or Owner.
Consider custom roles only when built-in roles cannot meet the requirement appropriately.
Use PIM to reduce standing privileged access.
Don’t confuse Azure RBAC, Microsoft Entra roles, Azure Policy, and resource locks—they solve different security problems.

Practice Exam Questions

Question 1

A company has a security operations group that needs to view Azure resources throughout a subscription. The group must not be able to create, modify, or delete resources.

Which built-in Azure RBAC role should you assign?

A. Reader

B. Contributor

C. Owner

D. User Access Administrator

Correct Answer: A. Reader

Explanation:
Reader provides read-only access to Azure resources. Contributor and Owner provide substantially more permissions, while User Access Administrator is designed primarily for managing access rather than simply viewing resources.

Question 2

A developer needs to create, modify, and delete resources in a specific resource group. The developer must not be able to grant Azure RBAC permissions to other users.

Which role is the best choice if no more specialized built-in role meets the requirement?

A. Owner at the subscription scope

B. Contributor at the resource-group scope

C. User Access Administrator at the resource-group scope

D. Reader at the resource-group scope

Correct Answer: B. Contributor at the resource-group scope

Explanation:
Contributor can manage Azure resources but cannot assign Azure RBAC roles. Assigning it at the resource-group scope limits the developer’s access to that resource group rather than unnecessarily extending it to the subscription.

Question 3

An application uses a managed identity. It needs to read blob data from one Azure Storage account but does not need to modify the storage account configuration.

Which approach best follows least privilege?

A. Assign Owner at the subscription scope

B. Assign Contributor at the storage-account scope

C. Assign Reader at the resource-group scope

D. Assign an appropriate blob-data reader role at the narrowest suitable scope

Correct Answer: D. Assign an appropriate blob-data reader role at the narrowest suitable scope

Explanation:
The application needs access to blob data, not broad resource-management permissions. A data-plane role such as Storage Blob Data Reader is more appropriate than Owner, Contributor, or a general management-plane Reader assignment.

Question 4

A security administrator is responsible for creating and removing Azure RBAC role assignments but should not receive unnecessary permissions to manage Azure resources.

Which built-in role is specifically designed for Azure RBAC assignment management?

A. Contributor

B. Reader

C. Role Based Access Control Administrator

D. Storage Account Contributor

Correct Answer: C. Role Based Access Control Administrator

Explanation:
Role Based Access Control Administrator is specifically designed for managing access to Azure resources through Azure RBAC. Contributor cannot assign Azure RBAC roles.

Question 5

A user has the Reader role assigned at the subscription scope. What happens to that user’s Reader permissions for resources within that subscription?

A. The permissions are inherited by child resource groups and resources

B. The permissions apply only to the subscription object

C. The permissions apply only to resources created after the assignment

D. The permissions automatically become Contributor on child resources

Correct Answer: A. The permissions are inherited by child resource groups and resources

Explanation:
Azure RBAC uses hierarchical scopes. Role assignments at a parent scope are inherited by child scopes. A Reader assignment at subscription scope therefore provides Reader permissions to resources beneath that subscription.

Question 6

An organization wants developers to manage only virtual machines and related operations rather than all resource types in a resource group.

Which approach best follows the principle of least privilege?

A. Assign Owner to the developers

B. Assign Contributor at the subscription scope

C. Assign Reader at the VM scope

D. Use an appropriate VM-specific built-in role at the narrowest practical scope

Correct Answer: D. Use an appropriate VM-specific built-in role at the narrowest practical scope

Explanation:
A specialized built-in role can provide more focused permissions than Contributor or Owner. The assignment should also be scoped as narrowly as practical.

Question 7

An administrator has the Contributor role on a subscription. The administrator attempts to create an Azure RBAC role assignment and receives an authorization error.

Why?

A. Contributor cannot assign Azure RBAC roles

B. Contributor cannot manage resources at subscription scope

C. Contributor is a Microsoft Entra role rather than an Azure RBAC role

D. Contributor provides only read access

Correct Answer: A. Contributor cannot assign Azure RBAC roles

Explanation:
Contributor provides broad resource-management permissions but does not include permission to assign Azure RBAC roles. Role-assignment creation requires the appropriate Microsoft.Authorization/roleAssignments/write permission.

Question 8

A company has five subscriptions under a management group. A security team needs the same read-only Azure resource access across all five subscriptions.

Which scope could provide the access without creating separate Reader assignments for every subscription?

A. Individual resource

B. Resource group

C. Management group

D. Individual virtual machine

Correct Answer: C. Management group

Explanation:
A management group is above the subscription level in the Azure hierarchy. A Reader assignment at the appropriate management-group scope can be inherited by subscriptions and resources beneath it.

Question 9

A company needs to grant a team permissions that are not adequately provided by any existing built-in role. The team needs only a specific subset of management operations.

What should the administrator consider?

A. Assign Owner instead

B. Create an appropriate custom Azure role

C. Assign Contributor and rely on Azure Policy to remove permissions

D. Assign User Access Administrator

Correct Answer: B. Create an appropriate custom Azure role

Explanation:
Built-in roles should generally be preferred, but when they cannot provide the required permissions at the appropriate level, a custom role can be created. The custom role should contain only the permissions required.

Question 10

A company wants to minimize standing privileged access for administrators who occasionally need highly privileged Azure RBAC permissions.

Which solution best addresses this requirement?

A. Assign permanent Owner access to every administrator

B. Replace all administrators with Reader assignments

C. Use Microsoft Entra Privileged Identity Management to provide eligible or just-in-time privileged access

D. Assign Contributor at the management-group scope

Correct Answer: C. Use Microsoft Entra Privileged Identity Management to provide eligible or just-in-time privileged access

Explanation:
PIM can reduce standing privileged access by allowing privileged roles to be activated when needed rather than permanently assigning highly privileged access. This complements least-privilege RBAC design.

Final Thought

An important exam habit is to ask: “What is the minimum role, for the minimum scope, that satisfies the requirement?”

Go to the SC-500 Exam Prep Hub main page

azure, Microsoft Certification, SC-500, security October 10, 2026October 10, 2026

Manage custom roles, including Azure roles and Microsoft Entra roles (SC-500 Exam Prep)

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:
Manage identity, access, and governance (20–25%)
   --> Implement governance to enforce security and regulatory compliance
      --> Manage custom roles, including Azure roles and Microsoft Entra roles

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.

Overview

Role-based access control (RBAC) is a fundamental component of cloud security. Rather than granting users unrestricted administrative privileges, RBAC allows an organization to assign only the permissions required to perform a particular job.

Azure and Microsoft Entra ID both support custom roles, but they are used for different purposes.

The distinction is critical for the SC-500 exam:

Azure custom roles control access to Azure resources.

Microsoft Entra custom roles control administrative access to Microsoft Entra resources and capabilities.

Although both systems use concepts such as role definitions, permissions, and role assignments, their permission models and scopes are different. Azure role permissions cannot simply be used in Microsoft Entra custom roles, and Microsoft Entra role permissions cannot be used in Azure custom roles.

1. What Is a Custom Role?

A custom role is a role that an organization creates when the available built-in roles do not provide the appropriate permissions.

The goal is normally to achieve least privilege.

For example, suppose an administrator needs to:

View storage accounts
Start and stop virtual machines
Read certain networking configurations

but should not be able to:

Delete resources
Assign RBAC roles
Modify unrelated resource types

A broad built-in role such as Owner or Contributor might provide excessive permissions.

A custom role can be created containing only the required permissions.

General principle

Use a built-in role when it appropriately meets the requirement. Use a custom role when the built-in roles cannot provide the required permissions with appropriate precision.

This avoids unnecessary custom-role proliferation and reduces administrative complexity.

2. Two Different Custom-Role Systems

For SC-500, keep these two systems clearly separated:

	Azure custom role	Microsoft Entra custom role
Primary purpose	Manage Azure resources	Manage Microsoft Entra resources
Authorization system	Azure RBAC	Microsoft Entra RBAC
Examples of resources	VMs, storage, networking, databases	Users, groups, applications, enterprise applications
Permission model	Azure resource-provider operations	Microsoft Entra resource actions
Assignment scopes	Azure management-group, subscription, resource-group/resource scopes	Directory or supported resource-specific scopes
Created/managed through	Azure portal, CLI, PowerShell, REST API	Microsoft Entra admin center, Microsoft Graph PowerShell/API
Can permissions be mixed?	No	No

The two systems are conceptually similar but technically separate.

3. Azure Custom Roles

Azure custom roles are part of Azure role-based access control (Azure RBAC).

They are used to manage access to Azure resources.

Examples include permissions involving:

Virtual machines
Storage accounts
Azure SQL
Virtual networks
Key Vault
Azure Kubernetes Service
Azure Container Registry
Other Azure resources

An Azure custom role is a collection of Azure resource permissions.

For example, a custom role might allow a support team to:

Read virtual machines
Restart virtual machines
Read diagnostics

while excluding:

Delete virtual machines
Modify networking
Assign RBAC roles

4. Azure Custom Role Definitions

An Azure role definition describes the permissions available in a role.

A custom role definition can contain properties such as:

Name
Description
Permissions
Assignable scopes
Role ID

The permissions section can include:

Actions
NotActions
DataActions
NotDataActions

These concepts are important for understanding how Azure custom roles are constructed.

5. Actions

Actions specify the Azure control-plane operations that the role can perform.

For example, a custom role might contain permissions that allow the principal to perform operations involving:

Reading resources
Creating resources
Updating resources
Deleting resources

The exact permissions are represented using Azure resource-provider operation names.

A permission might look conceptually like:

Microsoft.Compute/virtualMachines/read

This represents a control-plane operation involving virtual machines.

6. NotActions

NotActions specifies control-plane operations that are excluded from the permissions represented by Actions.

For example, a role could broadly allow a set of operations while excluding a particular operation.

However, be careful when interpreting NotActions.

It does not mean:

“Explicitly deny this operation under all circumstances.”

Instead, NotActions subtracts operations from the permissions granted through Actions in that role definition.

A principal might still obtain the excluded permission through another role assignment.

Exam concept

Azure RBAC permissions are additive across role assignments.

Therefore, creating a custom role with NotActions does not guarantee that the principal can never perform the excluded operation.

7. DataActions and NotDataActions

Azure also distinguishes between management-plane operations and operations against data.

`DataActions`

Specify data-plane operations that the role can perform.

Examples include permissions to:

Read blob data
Write blob data
Read other supported service data

`NotDataActions`

Exclude specified data-plane operations from the permissions granted through DataActions.

This distinction is especially important for Azure Storage.

For example:

A role that can manage a storage account does not automatically mean that the principal has permission to read the blobs stored in the account.

The custom role may need appropriate data-plane permissions.

8. Example Azure Custom Role

Imagine a help-desk team needs to support Azure virtual machines.

Requirements:

View VMs
Restart VMs
Start VMs
Stop VMs
Cannot delete VMs
Cannot modify networking
Cannot assign RBAC roles

A broad Contributor role could provide more permissions than necessary.

Instead, a custom role could be created containing only the required VM operations.

Conceptually:

Support VM Operator

Permissions:

VM read
VM start
VM stop
VM restart

Excluded:

VM delete
RBAC role assignment
unrelated resource-management operations

This is a classic least-privilege scenario.

9. Azure Custom Role AssignableScopes

One of the most important properties of an Azure custom role is:

AssignableScopes

This specifies where the custom role definition can be assigned.

A custom role can have assignable scopes at:

Management group
Subscription
Resource group

The role can subsequently be assigned at an appropriate narrower scope within those boundaries, including a resource scope where supported.

For example, a custom role could have:

/subscriptions/00000000-0000-0000-0000-000000000000

as an assignable scope.

The role would then be available for assignment within that subscription and its child scopes.

10. AssignableScopes vs. Assignment Scope

This is an important exam distinction.

AssignableScopes

Determines where the custom role definition is available to be assigned.

Role-assignment scope

Determines where the permissions actually apply to the principal.

For example:

A custom role might have an assignable scope of:

Subscription A

But the role could be assigned to a user at:

Resource Group A

The custom role is available within Subscription A, while the user’s actual permissions apply only to Resource Group A.

Exam rule

AssignableScopes limits where a custom role can be assigned; the role assignment’s scope determines where the assigned permissions apply.

11. Azure Custom Roles and Least Privilege

Custom roles can provide more precise access than broad built-in roles.

Consider three options:

Option 1 — Owner

Very broad permissions, including role assignment.

Option 2 — Contributor

Broad resource-management permissions but no RBAC role-assignment capability.

Option 3 — Custom role

Only the operations required for the user’s job.

If Option 3 satisfies the business requirement, it can provide a stronger least-privilege design.

However, custom roles should not be created simply because customization is possible.

Before creating one:

Identify the exact required operations.
Review existing built-in roles.
Determine whether an existing built-in role is sufficient.
Create a custom role only if necessary.
Limit its permissions.
Limit its assignable scopes.
Assign it at the narrowest practical scope.

12. Who Can Create an Azure Custom Role?

Creating or updating an Azure custom role requires appropriate authorization.

The key Azure permission is:

Microsoft.Authorization/roleDefinitions/write

Among the standard built-in roles, Owner and User Access Administrator include this permission.

This is different from simply assigning an existing role.

Important distinction

A person may have permission to assign an existing role without necessarily having permission to create or modify role definitions.

This distinction can appear in SC-500 scenario questions.

13. Managing Azure Custom Roles

Azure custom roles can be created and managed using:

Azure portal
Azure CLI
Azure PowerShell
Azure REST API

For example, administrators can create a custom role through the Azure portal by defining:

Role name
Description
Permissions
Assignable scopes

Custom roles are stored in the Microsoft Entra directory associated with the Azure environment and can be shared across subscriptions that trust the same directory.

14. Azure Custom Role Limits

Custom roles should be managed carefully.

Azure supports a maximum of 5,000 custom roles per Microsoft Entra tenant under the standard Azure limit.

This is another reason to avoid creating unnecessary custom roles.

A poorly governed environment could end up with:

Duplicate roles
Nearly identical roles
Roles that are no longer needed
Roles containing excessive permissions

A good role-governance process should include periodic review and cleanup.

15. Microsoft Entra Custom Roles

Microsoft Entra ID has its own RBAC system.

Microsoft Entra custom roles are used to provide customized administrative permissions for Microsoft Entra resources and capabilities.

Examples of areas that can be managed through supported Microsoft Entra permissions include:

Users
Groups
Applications
Enterprise applications
Devices
Consent-related operations

Microsoft Entra custom roles are created from a predefined set of permissions that are enabled for custom use.

16. Microsoft Entra Custom Role Permissions

Microsoft Entra custom roles use permissions expressed as Microsoft Entra resource actions.

For example, a custom role could contain permissions such as:

microsoft.directory/applications/basic/update

or:

microsoft.directory/applications/credentials/update

These permissions are different from Azure resource-provider permissions.

Critical exam distinction

Do not confuse:

Microsoft.Compute/...

with:

microsoft.directory/...

The first represents Azure resource-management permissions.

The second represents Microsoft Entra directory permissions.

17. Microsoft Entra Custom Roles Use a Defined Permission Set

You cannot simply create an arbitrary Microsoft Entra permission.

Microsoft Entra custom roles can include permissions that Microsoft makes available for custom use.

This provides granular control while keeping the permission model within supported Microsoft Entra capabilities.

For example, an organization could create a custom role allowing an application-support team to modify selected application properties without granting them broad application-administrator privileges.

18. Example: Microsoft Entra Custom Role

Suppose an organization has an application support team.

The team needs to:

Read application registrations
Update basic application properties
Update application credentials

The team should not receive broad directory administration privileges.

A custom Microsoft Entra role could be created containing only the required application-management permissions.

This is a classic least-privilege scenario.

19. Microsoft Entra Custom Role Scopes

Microsoft Entra custom roles use scopes that differ from Azure RBAC scopes.

Microsoft Entra custom roles can be assigned at:

Directory level
Supported app-registration resource scope

The exact scope options depend on the Microsoft Entra resource and permission being managed.

Exam warning

Do not automatically apply the Azure RBAC hierarchy:

Management group → subscription → resource group → resource

to Microsoft Entra custom roles.

That hierarchy belongs to Azure resource authorization.

20. Creating Microsoft Entra Custom Roles

Microsoft Entra custom roles can be created using:

Microsoft Entra admin center
Microsoft Graph PowerShell
Microsoft Graph API

In the Microsoft Entra admin center, administrators can navigate to:

Microsoft Entra ID → Roles & admins → New custom role

They then specify:

Role name
Description
Permissions

and create the role.

The role can subsequently be assigned to appropriate users or groups.

21. Microsoft Entra Custom Role Prerequisites

Creating Microsoft Entra custom roles requires appropriate privileged administration permissions.

The current prerequisites include:

Microsoft Entra ID P1 or P2
Privileged Role Administrator

when creating the role through the documented administrative interfaces.

This is an important distinction from Azure custom-role creation.

Remember

Azure custom role creation

→ Azure authorization permissions such as Microsoft.Authorization/roleDefinitions/write

Microsoft Entra custom role creation

→ Appropriate Microsoft Entra administrative permissions, such as Privileged Role Administrator

22. Microsoft Entra Custom Roles Cannot Use Azure Permissions

Suppose an administrator wants to create a Microsoft Entra custom role.

They cannot add an Azure resource-provider permission such as:

Microsoft.Compute/virtualMachines/read

to the Microsoft Entra custom role.

Likewise, an Azure custom role cannot use a Microsoft Entra permission such as:

microsoft.directory/applications/basic/update

The permission models are separate.

Exam rule

Azure RBAC permissions belong to Azure RBAC roles. Microsoft Entra permissions belong to Microsoft Entra roles.

23. Azure Roles vs. Microsoft Entra Roles

This distinction deserves special attention.

Azure role

Controls access to Azure resources.

Examples:

Virtual machines
Storage accounts
Virtual networks
Azure SQL
Key Vault

Azure roles are implemented through Azure RBAC.

Microsoft Entra role

Controls administrative access to Microsoft Entra functionality and resources.

Examples:

Users
Groups
Applications
Enterprise applications
Directory configuration

Microsoft Entra roles are implemented through Microsoft Entra RBAC.

They are separate authorization systems.

24. Application Roles Are Yet Another Concept

SC-500 questions can become confusing because there is another RBAC concept:

Application roles

Application roles are defined by an application and can be used to authorize users or applications within that application.

They are not the same as:

Azure RBAC roles
Microsoft Entra administrative roles

Therefore:

Application RBAC ≠ Azure RBAC ≠ Microsoft Entra RBAC

Microsoft explicitly distinguishes application-specific RBAC from Azure RBAC and Microsoft Entra RBAC.

25. Role Definition vs. Role Assignment

This concept applies to both Azure RBAC and Microsoft Entra RBAC, although the implementations differ.

Role definition

Defines:

What permissions does the role contain?

Role assignment

Defines:

Who receives the role and at what supported scope?

For Azure RBAC:

Principal + Azure role definition + scope = role assignment

For Microsoft Entra RBAC, a role definition containing Microsoft Entra permissions is assigned to a principal at an applicable directory/resource scope.

26. Assign Custom Roles to Groups When Practical

Custom roles can be assigned to appropriate security principals.

Depending on the authorization system and supported scenario, this can include:

Users
Groups
Service principals
Managed identities

For organizational administration, assigning permissions to groups is often preferable to individually assigning the same role to many users.

For example:

Application Support Team

→ Custom Microsoft Entra Application Support role

This simplifies:

Access management
Auditing
Access reviews
User onboarding
User offboarding

27. Combining Multiple Roles

A user can receive multiple role assignments.

Azure RBAC permissions are effectively additive.

For example, suppose a user has:

Custom VM Operator

and:

Reader

The user’s effective permissions can include permissions from both assignments.

This has an important security consequence.

Creating a custom role with fewer permissions does not necessarily restrict a user if that user already has another role that provides broader permissions.

Example

A custom role excludes:

Microsoft.Compute/virtualMachines/delete

But the same user also has Contributor.

The user could still have VM deletion capability through Contributor.

Exam lesson

Evaluate effective permissions, not just one role definition.

28. Don’t Use NotActions as a Security Deny

This is a common conceptual trap.

Suppose a custom role contains:

Actions: *

and:

NotActions: Microsoft.Compute/virtualMachines/delete

It may appear that the user is explicitly denied the ability to delete VMs.

That’s not necessarily true.

NotActions only removes that operation from the permissions granted by that role definition.

If another role assignment grants VM deletion, the user may still delete VMs.

For an actual deny mechanism, Azure has separate authorization concepts such as deny assignments in supported scenarios.

Exam takeaway

NotActions is not the same as an explicit deny rule.

29. Custom Roles and Least Privilege

The purpose of a custom role should be to make access more precise, not simply to reproduce an overly powerful built-in role under a different name.

A good custom role should:

Include only necessary permissions.
Avoid unnecessary wildcards.
Use narrow assignable scopes where appropriate.
Be assigned at the narrowest practical scope.
Be assigned only to appropriate principals.
Be reviewed periodically.
Be removed when no longer required.

30. Be Careful with Wildcards

Azure custom roles support wildcard permissions.

For example:

Microsoft.Storage/*

could provide a large collection of storage-related operations.

Similarly:

*

can provide extremely broad permissions.

Wildcards can make custom roles easier to create but can undermine least privilege.

Best practice

Use specific operations when practical rather than granting a broad wildcard.

For example, if an administrator only needs to restart virtual machines, don’t automatically give that administrator every Compute operation.

31. Privileged Custom Roles

A custom role can itself become a highly privileged role.

For example, a custom Azure role that includes:

Microsoft.Authorization/roleAssignments/write

can grant the ability to create Azure RBAC assignments.

Likewise, permissions to create or modify role definitions are privileged capabilities.

Therefore, custom-role designers must evaluate not only the number of permissions but also the sensitivity of those permissions.

A small role containing a highly privileged authorization operation can be more dangerous than a larger role containing ordinary read operations.

32. Custom Roles and Privileged Identity Management

Microsoft Entra Privileged Identity Management (PIM) can be used with supported privileged role assignments to reduce standing administrative access.

Instead of giving an administrator permanent access, an organization can use an eligible assignment and require activation when the administrator needs to perform privileged work.

Possible controls include:

Time-limited activation
Approval
Multifactor authentication
Justification
Access reviews

This supports a broader security strategy:

Least privilege + just-in-time access + strong authentication

33. A Practical Process for Creating a Custom Azure Role

Use this process:

Step 1 — Identify the business requirement

Determine exactly what the person or workload needs to accomplish.

Step 2 — Identify the resource types

Determine which Azure resources are involved.

Step 3 — Review built-in roles

Check whether an existing built-in role already satisfies the requirement.

Step 4 — Identify exact operations

Determine the required control-plane and, if applicable, data-plane operations.

Step 5 — Build the custom role

Add only the necessary permissions.

Step 6 — Define assignable scopes

Make the role available only where it needs to be used.

Step 7 — Assign the role

Assign it to the appropriate principal at the narrowest practical scope.

Step 8 — Test effective access

Verify that required operations work and unnecessary permissions are not present.

Step 9 — Review periodically

Remove obsolete roles and permissions.

34. A Practical Process for Creating a Microsoft Entra Custom Role

Use a similar but separate process:

Step 1 — Identify the Microsoft Entra administrative task

For example:

Manage selected application-registration properties.

Step 2 — Review built-in Microsoft Entra roles

Determine whether a built-in role is sufficient.

Step 3 — Identify supported custom-use permissions

Select only the required Microsoft Entra resource actions.

Step 4 — Create the custom role

Define the role name, description, and permissions.

Step 5 — Select the appropriate scope

Use a supported directory or resource-specific scope.

Step 6 — Assign the role

Assign it to the appropriate user or group.

Step 7 — Validate effective permissions

Confirm that the administrator can perform the required operations but does not have unnecessary administrative access.

35. Common SC-500 Exam Traps

Trap 1: Azure custom roles manage Microsoft Entra users

False.

Azure custom roles manage Azure resources.

Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities.

Trap 2: Microsoft Entra custom roles can contain Azure permissions

False.

The permission models are separate.

Trap 3: Contributor can create custom Azure roles

Generally false.

Contributor does not include the permission required to create or update Azure role definitions.

Trap 4: Owner is required to assign an existing Azure custom role

Not necessarily.

The relevant requirement is permission to create the role assignment. Roles such as Owner, User Access Administrator, and Role Based Access Control Administrator can provide role-assignment capabilities in appropriate scopes.

Creating the custom role definition itself is a separate privilege.

Trap 5: NotActions explicitly denies an operation

False.

It removes operations from the permissions granted by that particular role definition.

Another role assignment could still grant the operation.

Trap 6: AssignableScopes determines where the permissions apply

Not exactly.

AssignableScopes determines where the custom role is available for assignment.

The role assignment scope determines where the permissions actually apply.

Trap 7: Custom roles automatically provide least privilege

False.

A poorly designed custom role can be overly permissive.

Least privilege depends on the permissions selected, scope, and effective role assignments.

Trap 8: A custom role replaces all built-in roles

False.

Built-in roles should generally be preferred when they appropriately satisfy the requirement.

Trap 9: DataActions are the same as Actions

False.

Actions generally represent control-plane operations, while DataActions represent data-plane operations.

Trap 10: Azure RBAC, Microsoft Entra RBAC, and application RBAC are the same

False.

They are separate authorization models serving different purposes.

36. SC-500 Comparison: Azure vs. Microsoft Entra Custom Roles

Characteristic	Azure Custom Role	Microsoft Entra Custom Role
Authorization system	Azure RBAC	Microsoft Entra RBAC
Primary target	Azure resources	Microsoft Entra resources/capabilities
Permission format	Azure resource-provider operations	Microsoft Entra resource actions
Control-plane/data-plane distinction	Yes, including Actions/DataActions where supported	Different Microsoft Entra permission model
Typical resources	VM, Storage, SQL, Network	Users, groups, applications, enterprise applications
Azure management-group scope	Yes	No
Azure subscription scope	Yes	No
Azure resource-group scope	Yes	No
Microsoft Entra directory scope	No	Yes
App registration resource scope	No	Supported
Creation tools	Azure portal, CLI, PowerShell, REST	Entra admin center, Graph PowerShell, Graph API
Typical creation privilege	Azure authorization permission such as `roleDefinitions/write`	Privileged Role Administrator
Permissions interchangeable?	No	No

37. Exam Scenario Strategy

When a question asks you to design a custom role, work through these questions:

Question 1: What is being secured?

If it is:

VM
Storage
SQL
Network
Key Vault

think:

Azure RBAC

If it is:

User
Group
Application
Enterprise application
Directory administration

think:

Microsoft Entra RBAC

Question 2: Is there already a suitable built-in role?

If yes, use the built-in role unless there is a compelling reason not to.

If no, consider a custom role.

Question 3: What exact permissions are required?

Don’t simply choose broad permissions because they are convenient.

Question 4: What is the narrowest scope?

Use the smallest practical scope.

Question 5: Does the role include privileged authorization permissions?

Be particularly careful with permissions that allow:

Assigning roles
Creating roles
Modifying roles
Deleting roles
Managing other privileged security controls

38. Key Takeaways

For the SC-500 exam, remember:

Azure custom roles are part of Azure RBAC.
Microsoft Entra custom roles are part of Microsoft Entra RBAC.
The two permission models are separate.
Azure custom roles manage Azure resources.
Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities.
A role definition describes permissions.
A role assignment grants a role to a principal at a scope.
Azure custom roles can contain Actions, NotActions, DataActions, and NotDataActions.
Actions generally represent control-plane operations.
DataActions represent data-plane operations where supported.
NotActions is not an explicit deny mechanism.
Azure custom-role AssignableScopes controls where the role can be assigned.
The role assignment’s scope determines where the assigned permissions apply.
Built-in roles should generally be used when they meet the requirement.
Custom roles are appropriate when built-in roles cannot provide the required level of precision.
Avoid unnecessary wildcard permissions.
Evaluate effective permissions across all role assignments, not just one role.
Privileged role-management permissions require particular caution.
PIM can help reduce standing privileged access.
Azure RBAC ≠ Microsoft Entra RBAC ≠ application RBAC.

Practice Exam Questions

Question 1

An organization needs to create a role that allows support personnel to restart Azure virtual machines but does not allow them to delete VMs or manage networking resources. No existing built-in role provides exactly the required permissions.

What should the security engineer do?

A. Assign Owner at the resource-group scope

B. Create an Azure custom role containing only the required VM permissions

C. Assign Contributor at the VM scope

D. Create a Microsoft Entra custom role

Correct Answer: B. Create an Azure custom role containing only the required VM permissions

Explanation:
The requirement involves Azure virtual machines, so Azure RBAC is the appropriate authorization system. Because the available built-in roles do not provide the required level of precision, an Azure custom role is appropriate. The custom role should contain only the necessary VM operations.

Question 2

An administrator is creating a custom role for Azure resources. The role should be available for assignment within only one subscription.

Which property should the administrator configure?

A. NotActions

B. DataActions

C. AssignableScopes

D. Role assignment name

Correct Answer: C. AssignableScopes

Explanation:
AssignableScopes specifies the scopes where an Azure custom role definition can be assigned. It should not be confused with the scope of an individual role assignment, which determines where the permissions apply to the principal.

Question 3

A user has a custom Azure role containing NotActions that excludes deletion of virtual machines. The user also has the Contributor role at the resource-group scope.

What should the security engineer conclude?

A. The user can never delete virtual machines

B. The custom role overrides Contributor

C. Contributor becomes read-only for the user

D. The user may still be able to delete virtual machines through Contributor

Correct Answer: D. The user may still be able to delete virtual machines through Contributor

Explanation:
NotActions removes an operation from the permissions granted by that particular role definition. It does not create a universal deny. If another role assignment grants the permission, the user can still receive it through that other role.

Question 4

An organization needs to create a custom role that allows an application-support team to update selected properties of Microsoft Entra application registrations. The team should not receive broad directory-administrator permissions.

Which solution should be used?

A. Microsoft Entra custom role

B. Azure Contributor role

C. Azure custom role

D. Azure Owner role

Correct Answer: A. Microsoft Entra custom role

Explanation:
Application registrations are Microsoft Entra resources. A Microsoft Entra custom role can contain the specific supported Microsoft Entra permissions required for the application-support scenario without granting broad directory administration.

Question 5

Which statement correctly distinguishes Azure custom roles from Microsoft Entra custom roles?

A. Azure custom roles manage Microsoft Entra users, while Microsoft Entra custom roles manage virtual machines

B. Azure custom roles and Microsoft Entra custom roles use exactly the same permission model

C. Azure custom roles manage Azure resources, while Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities

D. Microsoft Entra custom roles can contain Azure resource-provider permissions

Correct Answer: C. Azure custom roles manage Azure resources, while Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities

Explanation:
Azure RBAC and Microsoft Entra RBAC are separate authorization systems. Azure custom roles are used for Azure resources, while Microsoft Entra custom roles are used for supported Microsoft Entra administration scenarios.

Question 6

An Azure custom role needs to allow a service principal to read blob data from a storage account. Which type of permission is relevant to granting access to the actual blob data?

A. NotActions

B. DataActions

C. AssignableScopes

D. RoleDefinitions/write

Correct Answer: B. DataActions

Explanation:
DataActions represent data-plane operations for supported Azure services. Reading blob data is a data-plane operation and therefore requires an appropriate data-access permission rather than merely a management-plane Action.

Question 7

A security engineer wants to create an Azure custom role. Which Azure permission is directly associated with creating or updating an Azure custom role definition?

A. Microsoft.Authorization/roleDefinitions/write

B. Microsoft.Compute/virtualMachines/read

C. Microsoft.Authorization/roleAssignments/read

D. Microsoft.Storage/storageAccounts/read

Correct Answer: A. Microsoft.Authorization/roleDefinitions/write

Explanation:
Microsoft.Authorization/roleDefinitions/write is the authorization permission associated with creating or updating Azure role definitions. This is distinct from assigning an already existing role to a principal.

Question 8

A security administrator needs to create a Microsoft Entra custom role through the Microsoft Entra administrative experience.

Which role is associated with the required administrative privilege for creating the custom role?

A. Global Reader

B. Security Reader

C. Privileged Role Administrator

D. Azure Contributor

Correct Answer: C. Privileged Role Administrator

Explanation:
Creating Microsoft Entra custom roles requires appropriate Microsoft Entra administrative privileges. The documented prerequisite includes the Privileged Role Administrator role, along with the appropriate Microsoft Entra licensing.

Question 9

An Azure administrator creates a custom role with the following design:

Read virtual machines
Start virtual machines
Stop virtual machines
Delete virtual machines

The administrator assigns the role to a support group that only needs to start and stop VMs.

What should the security engineer recommend?

A. Keep the role because custom roles should contain broad permissions

B. Replace the role with Owner

C. Add more permissions so the role is easier to reuse

D. Remove the unnecessary delete permission to better follow least privilege

Correct Answer: D. Remove the unnecessary delete permission to better follow least privilege

Explanation:
The group does not need VM deletion capability. A custom role should contain only the permissions required for the business task. Removing unnecessary privileged operations reduces the potential impact of account compromise or misuse.

Question 10

A security engineer is deciding whether to create a custom Azure role or a custom Microsoft Entra role. The requirement is to allow administrators to manage selected users and groups in Microsoft Entra ID.

Which solution is appropriate?

A. Azure custom role

B. Microsoft Entra custom role

C. Azure Storage Blob Data Reader

D. Azure Contributor

Correct Answer: B. Microsoft Entra custom role

Explanation:
The requirement concerns management of Microsoft Entra users and groups rather than Azure resources. Therefore, the appropriate authorization system is Microsoft Entra RBAC, and a Microsoft Entra custom role should be considered if an existing built-in role does not provide the required permissions.

One particularly important distinction to memorize for this section is:

Azure custom role → Azure resources → Azure RBAC

Microsoft Entra custom role → Microsoft Entra resources/administration → Microsoft Entra RBAC

And for Azure custom roles, remember the three concepts that are easy to confuse on the exam: Actions/DataActions define permissions, AssignableScopes controls where the custom role can be assigned, and the role-assignment scope controls where the granted permissions actually apply.

Go to the SC-500 Exam Prep Hub main page