Category: security

Configure database auditing for Azure SQL Database and Azure SQL Managed Instance (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
      --> Configure database auditing for Azure SQL Database and Azure SQL Managed Instance


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

Database auditing records database activity so that organizations can investigate security incidents, identify unauthorized access, support compliance requirements, and understand how data is being used.

For the SC-500 exam, database auditing primarily involves configuring and managing auditing for:

  • Azure SQL Database
  • Azure SQL Managed Instance
  • SQL databases hosted in Azure
  • Microsoft Entra authentication and database activity
  • Audit destinations and retention
  • Audit logs and monitoring

Auditing is different from authentication and authorization:

  • Authentication determines who or what is connecting.
  • Authorization determines what the principal is allowed to do.
  • Auditing records what happened, who performed the action, when it occurred, and other relevant details.

A user might be correctly authenticated and authorized to read a table, but auditing can record that the user actually performed the read operation.


Why Database Auditing Is Important

Database auditing supports several security and governance objectives.

Detecting suspicious activity

Audit records can help identify:

  • Repeated failed login attempts
  • Access to sensitive tables
  • Unexpected changes to database objects
  • Changes to permissions or roles
  • Unusual administrative activity
  • Attempts to access data outside normal business patterns

Supporting compliance

Many regulatory and organizational standards require organizations to maintain evidence of access to sensitive data. Audit logs can help demonstrate:

  • Who accessed data
  • Which operations were performed
  • When the operations occurred
  • Whether privileged users changed security settings
  • Whether sensitive data was accessed or modified

Investigating security incidents

When an incident occurs, audit logs can help security teams reconstruct events and determine:

  • Which account was used
  • Which database was accessed
  • Which commands were executed
  • Whether data was read, changed, or deleted
  • Whether permissions were modified
  • The approximate time sequence of activity

Establishing accountability

Auditing helps associate database activity with a user, application, service principal, or managed identity. This is especially important when multiple applications or administrators access the same database.


Azure SQL Auditing

Azure SQL auditing tracks database events and writes audit records to a configured destination.

Auditing can be configured at different scopes, depending on the service:

  • Azure SQL logical server
  • Individual Azure SQL Database
  • Azure SQL Managed Instance
  • SQL databases hosted by the managed instance

The exact configuration experience and available settings can vary between Azure SQL Database and Azure SQL Managed Instance.

For Azure SQL Database, auditing can generally be configured at the server or database level. A database-level configuration can provide more specific control for an individual database.

For Azure SQL Managed Instance, auditing is configured for the managed instance and can capture activity across the databases hosted by that instance.


Azure SQL Database Auditing

Azure SQL Database auditing records database events for databases hosted on an Azure SQL logical server.

Auditing can be enabled through the Azure portal, Azure PowerShell, Azure CLI, REST APIs, or infrastructure-as-code tools.

At a high level, configuring auditing involves:

  1. Selecting the SQL server or database.
  2. Opening the auditing configuration.
  3. Enabling auditing.
  4. Selecting an audit destination.
  5. Configuring retention and related settings.
  6. Saving the configuration.
  7. Reviewing the generated audit records.

Auditing can be configured at the server level so that databases inherit the server’s auditing configuration. A database-level configuration can be used when a particular database requires different auditing behavior.


Azure SQL Managed Instance Auditing

Azure SQL Managed Instance provides auditing for database activity across the managed instance.

Because a managed instance can host multiple databases, auditing at the managed-instance level is useful when an organization wants consistent auditing across its database environment.

Auditing can help record activity such as:

  • Database connections
  • Queries and stored procedure execution
  • Data access
  • Data changes
  • Permission changes
  • Schema changes
  • Security-related operations

The audit configuration should be reviewed carefully to ensure that the selected events meet the organization’s security and compliance requirements without generating unnecessary volumes of data.


Audit Destinations

Azure SQL auditing supports several destinations. The appropriate destination depends on the organization’s retention, analysis, and monitoring requirements.

Azure Storage

Audit logs can be written to an Azure Storage account.

Azure Storage is useful when an organization needs:

  • Long-term retention
  • Centralized storage
  • Low-cost archival
  • Integration with other data-processing tools
  • Storage-based compliance evidence

When using Azure Storage, consider:

  • Storage account security
  • Access control
  • Network restrictions
  • Encryption
  • Retention policies
  • Immutability requirements
  • Lifecycle management

Audit logs should not be stored in a location where unauthorized users can modify or delete them.

For stronger protection, organizations can use storage security features such as restricted access, role-based access control, and immutable storage where appropriate.


Log Analytics Workspace

Audit logs can be sent to a Log Analytics workspace.

This destination is useful when security teams need to:

  • Query audit records
  • Correlate database events with other Azure activity
  • Build dashboards
  • Create alerts
  • Investigate incidents
  • Use Microsoft Sentinel for security monitoring

Log Analytics is often the most useful destination for operational security monitoring because audit data can be queried using Kusto Query Language.

For example, security teams might use audit data to investigate:

  • Access to sensitive databases
  • Changes to database permissions
  • Unusual administrative activity
  • Repeated failed connections
  • Unexpected data modification

Event Hubs

Audit logs can also be sent to Azure Event Hubs.

Event Hubs is useful when audit data must be streamed to another system, such as:

  • A security information and event management platform
  • A security analytics platform
  • A custom monitoring application
  • A third-party compliance or monitoring solution

Event Hubs is designed for high-throughput event ingestion and streaming rather than long-term log storage by itself.


Choosing a Destination

RequirementSuitable destination
Long-term archivalAzure Storage
Interactive investigation and queriesLog Analytics workspace
Streaming audit data to another systemEvent Hubs
Security analytics and alertingLog Analytics and Microsoft Sentinel
Compliance retentionAzure Storage, often with additional retention controls

An organization may use more than one destination when it needs both operational monitoring and long-term retention.


Types of Activity That Can Be Audited

The exact audit events available depend on the Azure SQL service and configuration, but auditing can capture several important categories of activity.

Authentication and connection activity

Examples include:

  • Successful database connections
  • Failed connection attempts
  • Authentication-related events
  • Connection information

These events can help identify brute-force attempts, misconfigured applications, or unexpected access.

Data access

Examples include:

  • Reading data
  • Selecting data from sensitive tables
  • Executing stored procedures
  • Accessing specific database objects

Data-access auditing is particularly important for databases containing:

  • Personally identifiable information
  • Financial information
  • Healthcare information
  • Customer records
  • Confidential business data

Data changes

Examples include:

  • Insert operations
  • Update operations
  • Delete operations
  • Bulk data changes

Auditing data changes can help determine whether records were modified or removed.

Schema changes

Examples include:

  • Creating tables
  • Altering tables
  • Dropping tables
  • Creating or modifying stored procedures
  • Changing database objects

Schema auditing is useful because unauthorized schema changes can create security vulnerabilities or affect application behavior.

Permission and role changes

Examples include:

  • Granting permissions
  • Revoking permissions
  • Adding users to database roles
  • Removing users from database roles
  • Changing ownership or security-related settings

These events are important for detecting privilege escalation.

Administrative activity

Examples include:

  • Changes to auditing configuration
  • Changes to database settings
  • Changes to security configuration
  • Administrative commands

Administrative auditing helps establish accountability for privileged operations.


Auditing Versus Microsoft Defender for SQL

Azure SQL auditing and Microsoft Defender for SQL serve related but different purposes.

Azure SQL auditing

Auditing primarily records database activity for:

  • Investigation
  • Compliance
  • Accountability
  • Historical analysis
  • Security monitoring

It answers questions such as:

What activity occurred in the database?

Microsoft Defender for SQL

Microsoft Defender for SQL provides additional security capabilities, such as:

  • Threat detection
  • Security alerts
  • Vulnerability assessment
  • Security recommendations
  • Identification of suspicious database activity

It answers questions such as:

Does this activity appear suspicious or represent a security risk?

Auditing and Defender for SQL can be used together. Auditing provides detailed activity records, while Defender for SQL can identify and alert on potentially malicious behavior.


Auditing and Microsoft Sentinel

Audit logs can be integrated with Microsoft Sentinel to support centralized security monitoring.

A typical workflow is:

  1. Enable auditing on Azure SQL Database or Azure SQL Managed Instance.
  2. Send audit logs to a Log Analytics workspace.
  3. Connect the workspace to Microsoft Sentinel.
  4. Create queries and analytics rules.
  5. Configure alerts and incidents.
  6. Investigate related activity across Azure and other environments.

For example, Microsoft Sentinel could correlate:

  • A suspicious Microsoft Entra sign-in
  • A database permission change
  • Access to a sensitive table
  • Activity from an unusual IP address
  • A subsequent data export

This correlation provides more context than reviewing database logs alone.


Retention and Log Management

Audit logs should be retained according to:

  • Regulatory requirements
  • Organizational policies
  • Incident-response requirements
  • Legal and contractual obligations
  • Storage costs
  • Data sensitivity

Retention should be long enough to support investigations and compliance audits.

Important considerations include:

  • How long logs are retained
  • Whether logs can be deleted by ordinary administrators
  • Whether logs are protected from modification
  • Whether access to logs is itself audited
  • Whether archived logs can be searched or restored
  • Whether retention policies apply consistently across databases

Audit logs may contain sensitive information, so they should be protected using appropriate access controls and encryption.


Securing Audit Logs

Audit logs are security evidence and should be protected as carefully as the database itself.

Restrict access

Only authorized personnel should be able to read, export, or delete audit logs.

Use least-privilege access through Microsoft Entra ID and Azure RBAC where supported.

Protect against deletion or modification

Consider:

  • Storage immutability
  • Resource locks where appropriate
  • Restricted administrative access
  • Separate security or compliance ownership
  • Monitoring of changes to audit configuration

A log that can be easily deleted by the person being investigated provides limited forensic value.

Encrypt audit data

Audit data should be protected using encryption at rest and secure transport.

Azure services generally provide encryption at rest, but organizations must still configure access and key-management controls appropriately.

Monitor auditing configuration

Security teams should monitor changes to:

  • Whether auditing is enabled
  • Audit destinations
  • Retention settings
  • Audit policies
  • Database-level overrides
  • Permissions to audit destinations

An attacker who disables auditing may be attempting to conceal activity.


Configuring Auditing in the Azure Portal

The following is a conceptual configuration process. The exact portal labels may vary as Azure services evolve.

Azure SQL Database

  1. Open the Azure portal.
  2. Navigate to the Azure SQL logical server or database.
  3. Select Auditing under the security-related settings.
  4. Enable auditing.
  5. Choose one or more supported destinations.
  6. Configure the destination details.
  7. Configure retention or related settings.
  8. Save the configuration.
  9. Generate or perform test activity.
  10. Verify that audit records are being delivered.

When configuring auditing at the server level, review whether individual databases inherit the configuration or override it.

Azure SQL Managed Instance

  1. Open the Azure portal.
  2. Navigate to the managed instance.
  3. Select the auditing configuration.
  4. Enable auditing.
  5. Select the destination.
  6. Configure retention and related settings.
  7. Save the configuration.
  8. Verify that activity from the managed instance’s databases is being recorded.

Common Exam Considerations

Server-level versus database-level configuration

A server-level auditing configuration can provide centralized coverage, while a database-level configuration can provide more specific control.

When troubleshooting, determine whether:

  • Auditing is enabled at the server level
  • The database has its own auditing configuration
  • A database-level setting overrides the inherited configuration
  • The selected destination is correctly configured

Auditing does not grant access

Enabling auditing does not allow a user to connect to a database or read data.

Authentication and authorization must still be configured separately.

Auditing does not block activity

Auditing records activity. It does not, by itself, prevent a user from executing a query or changing data.

To prevent activity, use controls such as:

  • Microsoft Entra authentication
  • Azure RBAC
  • Database roles and permissions
  • Network access controls
  • Microsoft Defender for SQL
  • Azure Policy
  • Microsoft Purview or other data-governance controls

Auditing is not the same as diagnostic logging

Diagnostic settings are used to route platform logs and metrics to destinations such as Log Analytics, Storage, or Event Hubs.

Azure SQL auditing is a database-specific auditing capability. Diagnostic settings may be involved in routing or collecting related logs, but they do not replace the need to configure database auditing appropriately.

Do not collect more data than necessary

Auditing should be designed to meet security and compliance objectives while controlling:

  • Storage costs
  • Query volume
  • Log noise
  • Sensitive information exposure
  • Operational overhead

A useful audit policy focuses on meaningful events and protects the resulting records.


Best Practices

  1. Enable auditing for production databases.
  2. Use Log Analytics when interactive investigation and alerting are required.
  3. Use Azure Storage for long-term retention and archival.
  4. Send relevant audit data to Microsoft Sentinel for centralized security monitoring.
  5. Protect audit destinations with least-privilege access.
  6. Use retention policies that meet regulatory and organizational requirements.
  7. Protect logs against unauthorized deletion or modification.
  8. Monitor changes to auditing configuration.
  9. Review audit records regularly.
  10. Correlate audit activity with identity, network, and application logs.
  11. Use Microsoft Defender for SQL for threat detection in addition to auditing.
  12. Test auditing after configuration changes.
  13. Document which events are audited and why.
  14. Avoid relying on auditing as a substitute for authorization.
  15. Ensure that audit logs themselves are treated as sensitive data.

Practice Exam Questions

Question 1

An organization needs to record activity performed against an Azure SQL Database so that security analysts can investigate suspicious queries and create alerts. Which destination is the most appropriate?

A. Azure Key Vault
B. Azure Storage only
C. Log Analytics workspace
D. Azure Resource Graph

Correct answer: C

Explanation: A Log Analytics workspace is designed for querying and analyzing log data. It can also be used with Microsoft Sentinel to create alerts and investigate security incidents. Azure Storage is better suited to archival and long-term retention.


Question 2

A company must retain Azure SQL audit records for several years at a relatively low cost. The records must also be protected from unauthorized modification. Which approach is most appropriate?

A. Store the records only in the SQL database being audited
B. Send the records to Azure Storage and configure appropriate retention and immutability controls
C. Send the records only to Azure Event Hubs without any downstream storage
D. Disable auditing after exporting the records once per year

Correct answer: B

Explanation: Azure Storage is appropriate for long-term retention. Additional controls, such as retention policies and immutable storage, can help protect audit records from deletion or modification.


Question 3

Which statement best describes the purpose of Azure SQL auditing?

A. It records database activity for investigation, accountability, and compliance
B. It automatically grants users permission to access database objects
C. It replaces Microsoft Entra authentication
D. It prevents all unauthorized queries from executing

Correct answer: A

Explanation: Auditing records activity that occurs in the database. It does not grant permissions, replace authentication, or automatically block queries.


Question 4

An administrator enables auditing for an Azure SQL Database but users still cannot connect to the database. What is the most likely explanation?

A. Auditing can only be enabled after all users are assigned the Owner role
B. Auditing automatically blocks connections until Microsoft Sentinel is configured
C. Auditing records activity but does not provide authentication or authorization
D. Auditing requires Azure Storage to be configured before any user can connect

Correct answer: C

Explanation: Authentication and authorization are separate from auditing. A user must still have a valid authentication method and sufficient database permissions.


Question 5

A security team wants to correlate Azure SQL activity with Microsoft Entra sign-ins, virtual machine alerts, and other cloud security events. Which solution is most appropriate?

A. Azure Files
B. Microsoft Sentinel connected to a Log Analytics workspace
C. Azure DNS
D. Azure Resource Manager locks only

Correct answer: B

Explanation: Microsoft Sentinel can use Log Analytics data to correlate database audit events with identity, infrastructure, and other security events.


Question 6

An organization wants to investigate whether a privileged administrator changed database permissions. Which type of audit activity is most relevant?

A. Permission and role changes
B. Storage account replication events
C. Virtual network route changes only
D. Azure billing events only

Correct answer: A

Explanation: Permission and role changes can reveal privilege escalation or unauthorized changes to database access.


Question 7

A company configures auditing at the Azure SQL logical server level. One database has different auditing requirements and must use a separate configuration. What should the administrator investigate?

A. Whether the database can override or use a database-level auditing configuration
B. Whether auditing can only be configured at the subscription level
C. Whether the database must be moved to Azure Cosmos DB
D. Whether auditing requires a dedicated virtual machine

Correct answer: A

Explanation: Azure SQL Database auditing can be configured at the server or database level. The administrator should determine whether the database-level configuration provides the required override or separate behavior.


Question 8

Which statement correctly compares Azure SQL auditing and Microsoft Defender for SQL?

A. Auditing blocks threats, while Defender for SQL only stores logs
B. Auditing and Defender for SQL are identical features
C. Auditing records database activity, while Defender for SQL provides additional threat detection and security recommendations
D. Defender for SQL is required before auditing can be enabled

Correct answer: C

Explanation: Auditing provides activity records for investigation and compliance. Microsoft Defender for SQL adds security capabilities such as threat detection, alerts, and vulnerability-related recommendations.


Question 9

An organization sends Azure SQL audit records to Event Hubs. What is the primary reason for selecting Event Hubs?

A. To stream audit events to another monitoring or security system
B. To replace database authentication
C. To provide database table-level permissions
D. To encrypt database columns automatically

Correct answer: A

Explanation: Event Hubs is designed for high-throughput event ingestion and streaming. It can forward audit events to downstream monitoring or security systems.


Question 10

A security team notices that audit records are missing after an administrator changed the auditing configuration. Which action should be performed first?

A. Delete the database and recreate it
B. Disable Microsoft Entra authentication
C. Confirm that auditing is still enabled and verify the configured destination and delivery settings
D. Assign the Security Reader role to every database user

Correct answer: C

Explanation: The first troubleshooting step is to verify the auditing configuration, including whether auditing remains enabled and whether the destination is correctly configured. The team should also verify that the destination is receiving records and that no configuration change disabled or redirected auditing.


Final Exam Point

The key exam distinction is that auditing records database activity, while authentication, authorization, network controls, and threat-detection services determine whether activity should be allowed or considered suspicious.


Go to the SC-500 Exam Prep Hub main page

Configure Defender for Databases protection across Azure database services (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
      --> Configure Defender for Databases protection across Azure database services


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

Microsoft Defender for Databases is a set of security capabilities within Microsoft Defender for Cloud that helps protect database services from vulnerabilities, suspicious activity, and potential attacks.

The service combines database security monitoring with vulnerability assessment and security recommendations. It is designed to help security teams identify weaknesses, detect threats, investigate alerts, and improve the security posture of database workloads.

For the SC-500 exam, important concepts include:

  • Enabling Defender for Databases
  • Understanding the database-specific protection plans
  • Protecting Azure SQL databases and managed instances
  • Protecting SQL Server running on machines
  • Protecting open-source relational databases
  • Protecting Azure Cosmos DB
  • Using vulnerability assessment
  • Understanding advanced threat protection
  • Reviewing security alerts and recommendations
  • Monitoring coverage across subscriptions and resources

Microsoft Defender for Databases is managed through Microsoft Defender for Cloud.


What Defender for Databases Protects

The Defender for Databases plan contains four primary offerings:

  1. Microsoft Defender for Azure SQL Databases
  2. Microsoft Defender for SQL Servers on Machines
  3. Microsoft Defender for Open-Source Relational Databases
  4. Microsoft Defender for Azure Cosmos DB

Each offering targets different database platforms and has different capabilities. The plans are priced separately, and enabling the overall Databases plan activates the supported database protection offerings for the selected environment.


Microsoft Defender for Azure SQL Databases

Microsoft Defender for Azure SQL Databases protects supported Azure SQL workloads, including:

  • Azure SQL Database
  • Azure SQL elastic pools
  • Azure SQL Managed Instance
  • Azure Synapse Analytics dedicated SQL pools
  • Supported SQL Server workloads running on Azure virtual machines
  • Supported SQL Server workloads enabled through Azure Arc

The service helps identify database vulnerabilities and detect anomalous activity that may indicate an attack.

Examples of suspicious activity include:

  • Potential SQL injection
  • Unusual database access patterns
  • Abnormally high numbers of failed sign-in attempts
  • Brute-force attempts
  • Access from an unusual location
  • Access by an unfamiliar principal
  • Activity associated with a potentially compromised application or computer

Defender for Azure SQL Databases provides security alerts with details about the suspicious activity and guidance for investigation or mitigation.


Microsoft Defender for SQL Servers on Machines

Microsoft Defender for SQL Servers on Machines protects SQL Server installations running on:

  • Azure virtual machines
  • On-premises servers
  • Azure Arc-enabled servers
  • Other supported cloud environments, including AWS and Google Cloud

This offering is useful for hybrid and multicloud environments because it extends SQL security monitoring beyond Azure-native database services.

It provides two major capabilities:

  • Vulnerability assessment
  • Advanced threat protection

The service can identify potential SQL injection, unusual access locations, unfamiliar principals, suspicious applications, and brute-force activity. It can also provide security recommendations and detailed alerts.


Microsoft Defender for Open-Source Relational Databases

This offering provides protection for supported open-source database services, including:

  • Azure Database for PostgreSQL
  • Azure Database for MySQL
  • Supported Amazon RDS database engines, such as PostgreSQL, MySQL, MariaDB, and Aurora variants

Capabilities can include:

  • Threat detection
  • Suspicious activity alerts
  • Sensitive data discovery
  • Security posture recommendations
  • Identification of database configuration weaknesses

The exact capabilities depend on the database engine, deployment environment, and supported Defender features. Defender for Databases is not a single identical feature set across every database platform.


Microsoft Defender for Azure Cosmos DB

Microsoft Defender for Azure Cosmos DB provides protection for Azure Cosmos DB workloads.

Its primary purpose is to detect suspicious database activity and provide security alerts that can help organizations respond to potential threats.

Cosmos DB protection should be considered separately from SQL-specific protection because Cosmos DB is a NoSQL database service and does not use the same SQL vulnerability assessment and threat-detection model as Azure SQL.


Main Defender for Databases Capabilities

Vulnerability Assessment

Vulnerability assessment evaluates database configurations and security settings to identify potential weaknesses.

For supported Azure SQL services, vulnerability assessment can identify issues such as:

  • Excessive permissions
  • Insecure database configurations
  • Weak security settings
  • Unprotected sensitive data
  • Database-level security problems
  • Server-level security problems
  • Deviations from recommended security practices

The results include findings and remediation guidance.

Vulnerability assessment is intended to help organizations proactively improve security rather than waiting for an attack to occur.

Vulnerability assessment is not penetration testing

Vulnerability assessment generally evaluates configurations and known security conditions. It should not be confused with:

  • A full penetration test
  • A simulated attack
  • A replacement for secure application development
  • A replacement for access control
  • A guarantee that the database is free from vulnerabilities

It is one component of a broader database security program.


Vulnerability Assessment for Azure SQL

SQL vulnerability assessment is supported for:

  • Azure SQL Database
  • Azure SQL Managed Instance
  • Azure Synapse Analytics

The scanner uses a collection of security rules to identify vulnerabilities and deviations from recommended practices.

For supported configurations, scans are lightweight, read-only, and do not make changes to the database. Vulnerability assessment scans for SQL servers on machines occur approximately every 12 hours.

Vulnerability assessment findings

A finding typically provides:

  • The security issue
  • The affected resource
  • The severity or risk context
  • Evidence supporting the finding
  • Recommended remediation steps

Security teams can review findings through Defender for Cloud and use them to prioritize remediation.

Baselines

A baseline can be used when a finding is acceptable for a particular environment.

For example, an organization may intentionally allow a configuration because of a documented application dependency. Establishing a baseline prevents the same accepted condition from being repeatedly treated as a new failure.

Baselines should be used carefully. They should not be used to hide unresolved vulnerabilities without documented justification, ownership, and periodic review.

Express and classic configuration

SQL vulnerability assessment supports different configuration models.

Express configuration uses Microsoft-managed storage for scan results and simplifies deployment.

Classic configuration uses a customer-managed storage account and provides additional configuration control.

The available configuration model depends on the database service and current service support. Express configuration is the recommended simplified approach for supported services.


Advanced Threat Protection

Advanced threat protection continuously monitors database activity for patterns that may indicate malicious or suspicious behavior.

Examples include:

  • SQL injection attempts
  • Brute-force login activity
  • Unusual query patterns
  • Access from unfamiliar locations
  • Access by unfamiliar users or applications
  • Suspicious database activity associated with compromised systems
  • Unusual data-access behavior

Advanced threat protection is focused on detecting potentially harmful activity, whereas vulnerability assessment focuses on identifying security weaknesses and misconfigurations.

Vulnerability assessment versus threat protection

CapabilityPrimary purpose
Vulnerability assessmentIdentify weaknesses and configuration problems
Advanced threat protectionDetect suspicious or potentially malicious activity
Security recommendationsExplain how to improve security posture
Security alertsNotify responders about possible threats
Microsoft Sentinel integrationCorrelate and investigate security events across systems

Both vulnerability assessment and threat protection should be enabled when supported and appropriate for the workload.


Enabling Defender for Databases

Prerequisites

Before enabling Defender for Databases, ensure that:

  • Microsoft Defender for Cloud is available for the Azure subscription.
  • You have sufficient permissions to modify Defender for Cloud settings.
  • The relevant database resources are supported.
  • Any required agents, extensions, managed identities, or workspace dependencies are configured.
  • The organization understands the cost implications of the selected plans.

For hybrid or multicloud database protection, the relevant AWS accounts, Google Cloud projects, or non-Azure machines must be connected to Defender for Cloud as required.


Enable the Databases Plan

A typical portal-based process is:

  1. Sign in to the Azure portal.
  2. Open Microsoft Defender for Cloud.
  3. Select Environment settings.
  4. Select the relevant Azure subscription or connected cloud environment.
  5. Open the Defender plans page.
  6. Locate the Databases plan.
  7. Turn the plan on.
  8. Review and configure the individual database offerings.
  9. Save the configuration.
  10. Verify protection coverage.

Enabling the Databases plan activates the supported database protection offerings for the selected environment.


Configuring Specific Database Plans

After enabling the Databases plan, review the individual offerings.

Defender for Azure SQL Databases

Use this plan for supported Azure SQL Database, Azure SQL Managed Instance, and related SQL workloads.

Verify:

  • The correct subscription is selected.
  • Supported SQL resources are covered.
  • Threat protection is enabled.
  • Vulnerability assessment is configured.
  • Alerts are being generated and delivered as expected.

Defender for SQL Servers on Machines

Use this plan for SQL Server running on Azure virtual machines, on-premises machines, or other supported connected environments.

Verify:

  • The machines are connected to Azure through the appropriate mechanism.
  • SQL Server discovery is working.
  • Required extensions or agents are healthy.
  • Vulnerability assessment is enabled.
  • The Log Analytics workspace is configured where required.

Defender for Open-Source Relational Databases

Use this plan for supported PostgreSQL and MySQL database services.

Review the supported database engines and deployment types before enabling the plan. Do not assume that every open-source database service has identical monitoring or assessment capabilities.

Defender for Azure Cosmos DB

Use this plan for supported Azure Cosmos DB resources.

Review the protection coverage and available alerts for the specific Cosmos DB configuration.


Monitoring Protection Coverage

Defender for Cloud provides coverage information that helps administrators determine which subscriptions and resources are protected.

Coverage reviews should identify:

  • Subscriptions with the Databases plan enabled
  • Database services that are protected
  • Resources that are not covered
  • Unsupported database types
  • Resources with configuration problems
  • Workloads that require separate plan activation
  • Hybrid or multicloud environments that are not connected

Coverage should be reviewed regularly because new databases may be created after the initial security configuration.

For supported resources, enabling the relevant plan at the subscription level can protect existing resources and future supported resources created in that subscription.


Security Alerts

Defender for Databases generates alerts when activity appears suspicious or potentially harmful.

An alert may contain:

  • The affected database or server
  • The time of the activity
  • The type of suspicious behavior
  • The source or principal involved
  • Relevant evidence
  • Severity information
  • Recommended investigation or mitigation steps

Examples of alerts include:

  • Possible SQL injection
  • Brute-force database access
  • Access from an unusual location
  • Access by an unfamiliar principal
  • Suspicious query patterns
  • Activity associated with a potentially compromised application

Security alerts should be investigated rather than automatically assumed to be confirmed attacks. Some alerts may represent legitimate but unusual administrative or application activity.


Integrating with Microsoft Sentinel

Microsoft Sentinel can provide centralized investigation and correlation for Defender for Databases alerts.

A typical integration can correlate database alerts with:

  • Microsoft Entra sign-in events
  • Privileged Identity Management activity
  • Azure Activity Log events
  • Virtual machine alerts
  • Network security events
  • Application logs
  • Endpoint security events
  • Other database activity

For example, a suspicious database access alert may become more serious when it occurs shortly after:

  • A risky sign-in
  • A privilege escalation
  • A new service principal credential
  • A change to a firewall rule
  • A compromised virtual machine alert

Defender for Databases alerts can include options for continuing investigations through Microsoft Sentinel.


Roles and Permissions

Managing Defender for Databases requires appropriate Azure permissions.

The permissions needed depend on the task, such as:

  • Viewing Defender for Cloud recommendations
  • Viewing security alerts
  • Enabling Defender plans
  • Configuring vulnerability assessment
  • Viewing scan results
  • Managing storage for scan results
  • Accessing Log Analytics data
  • Managing connected machines

The ability to manage Azure resources does not necessarily mean that a user can read all database data. Similarly, the ability to view database security alerts does not automatically grant access to the underlying database.

Use least privilege when assigning administrative and monitoring roles.


Important Security Distinctions

Defender for Databases does not replace access control

Defender for Databases detects threats and vulnerabilities. It does not replace:

  • Microsoft Entra authentication
  • Database users and roles
  • Azure RBAC
  • Network security controls
  • Private endpoints
  • Firewall rules
  • Encryption
  • Application security
  • Secure coding practices

A database can have Defender protection enabled and still be insecure if users have excessive permissions or the database is exposed unnecessarily.

Defender for Databases does not guarantee prevention

Threat protection may detect suspicious activity and generate alerts, but detection is not the same as prevention.

Organizations must define response procedures, which may include:

  • Blocking a user or application
  • Revoking credentials
  • Disabling a compromised identity
  • Restricting network access
  • Isolating a virtual machine
  • Changing database permissions
  • Investigating related resources

Not every database service has identical capabilities

The term “Defender for Databases” covers multiple database protection offerings. Features differ by:

  • Database engine
  • Azure service
  • Deployment model
  • Region
  • Supported plan
  • Configuration model

Always verify the capabilities for the specific database platform being protected.


Best Practices

  1. Enable the appropriate Defender database plan for each supported database platform.
  2. Review coverage regularly across subscriptions and connected environments.
  3. Enable vulnerability assessment where supported.
  4. Review and remediate high-severity findings.
  5. Use baselines only for documented and approved exceptions.
  6. Monitor security alerts continuously.
  7. Integrate alerts with Microsoft Sentinel when centralized investigation is required.
  8. Correlate database alerts with identity, network, and endpoint events.
  9. Protect Log Analytics workspaces and scan-result storage with least privilege.
  10. Review the cost of each database protection plan.
  11. Confirm that hybrid and multicloud database resources are properly connected.
  12. Do not assume that enabling Defender automatically fixes vulnerabilities.
  13. Continue using strong authentication, authorization, encryption, and network controls.
  14. Test alert routing and incident-response procedures.
  15. Review new database resources to ensure they are included in protection coverage.

Common SC-500 Exam Traps

  • Vulnerability assessment identifies weaknesses; it does not primarily detect active attacks.
  • Advanced threat protection detects suspicious activity; it does not replace database permissions.
  • Defender for Databases is a collection of database-specific offerings, not one identical feature set.
  • Azure SQL Database and SQL Server on machines use different protection configurations.
  • Azure Cosmos DB requires its own Defender for Cosmos DB offering.
  • Enabling the Databases plan does not eliminate the need to review coverage.
  • A security recommendation is not the same as a security alert.
  • A vulnerability finding is not automatically proof that an attack is occurring.
  • A baseline should represent an approved exception, not an ignored security issue.
  • Microsoft Sentinel is used for centralized correlation and investigation, not as a prerequisite for every Defender database feature.

Practice Exam Questions

Question 1

An organization wants to identify insecure database configurations and excessive permissions in its Azure SQL databases. Which Defender for Databases capability should it use?

A. Vulnerability assessment
B. Advanced threat protection
C. Microsoft Entra Conditional Access
D. Azure Firewall

Correct answer: A

Explanation: Vulnerability assessment evaluates database configurations and security settings to identify potential weaknesses, such as excessive permissions and insecure configurations.


Question 2

A security analyst receives an alert indicating that a database was accessed from an unfamiliar location and that the activity may be suspicious. Which capability most likely generated the alert?

A. Azure Policy
B. Vulnerability assessment
C. Azure Backup
D. Advanced threat protection

Correct answer: D

Explanation: Advanced threat protection continuously monitors database activity for anomalous or potentially harmful behavior, including access from unusual locations.


Question 3

A company has Azure SQL Database, Azure SQL Managed Instance, and Azure Cosmos DB resources. Which approach provides the most appropriate protection coverage?

A. Enable only Defender for Azure SQL Databases
B. Enable the Databases plan and configure the relevant database-specific offerings
C. Enable Defender for Servers only
D. Configure Azure SQL auditing and assume all database services are protected

Correct answer: B

Explanation: Defender for Databases includes separate offerings for Azure SQL, SQL Servers on Machines, open-source relational databases, and Azure Cosmos DB. The relevant offerings must be enabled and reviewed for the database types in use.


Question 4

An organization runs SQL Server on an Azure virtual machine and on an on-premises server connected through Azure Arc. Which Defender offering is designed for these workloads?

A. Defender for Azure Cosmos DB
B. Defender for Open-Source Relational Databases
C. Defender for SQL Servers on Machines
D. Defender for Azure SQL Databases only

Correct answer: C

Explanation: Defender for SQL Servers on Machines protects supported SQL Server installations running on Azure virtual machines, on-premises servers, and other connected environments.


Question 5

A database administrator establishes a vulnerability assessment baseline for a finding that is an approved exception in the organization’s environment. What is the purpose of the baseline?

A. To permanently disable all vulnerability assessment scans
B. To treat the accepted condition as a passing result in later assessments
C. To grant the database administrator unrestricted database access
D. To convert the finding into a security alert

Correct answer: B

Explanation: A baseline records an accepted security state or finding so that it is not repeatedly reported as a failure. Baselines should be documented and reviewed periodically.


Question 6

A security team wants to correlate a suspicious database access alert with a risky Microsoft Entra sign-in and a virtual machine compromise alert. Which service is most appropriate?

A. Microsoft Sentinel
B. Azure Storage Explorer
C. Azure Resource Graph only
D. Azure Cost Management

Correct answer: A

Explanation: Microsoft Sentinel can correlate database alerts with identity, endpoint, network, and other security events to support centralized investigation.


Question 7

Which statement best describes the relationship between vulnerability assessment and advanced threat protection?

A. Vulnerability assessment detects active attacks, while advanced threat protection only checks configuration
B. Both capabilities perform exactly the same function
C. Advanced threat protection replaces the need for database permissions
D. Vulnerability assessment identifies weaknesses, while advanced threat protection detects suspicious activity

Correct answer: D

Explanation: Vulnerability assessment focuses on security weaknesses and configuration issues. Advanced threat protection monitors activity for suspicious or potentially malicious behavior.


Question 8

An organization enables Defender for Databases but discovers that several newly created database resources are not protected. What should the administrator do first?

A. Disable all database services
B. Replace Microsoft Entra authentication with SQL authentication
C. Review Defender for Cloud coverage and confirm that the relevant database plan supports those resources
D. Delete and recreate the subscription

Correct answer: C

Explanation: The administrator should review coverage, supported resource types, subscription settings, and the relevant database-specific plan. Not every database service is covered by the same offering.


Question 9

Which statement about Defender for Databases is accurate?

A. It replaces database authentication and authorization
B. It guarantees that all database attacks will be prevented
C. It provides database security capabilities such as vulnerability assessment and threat detection
D. It automatically encrypts every database column

Correct answer: C

Explanation: Defender for Databases helps identify vulnerabilities and suspicious activity. It does not replace authentication, authorization, encryption, or other security controls.


Question 10

A security team wants to protect PostgreSQL and MySQL database services in Azure. Which Defender offering should it investigate?

A. Defender for Open-Source Relational Databases
B. Defender for SQL Servers on Machines only
C. Defender for Azure Cosmos DB
D. Defender for Containers

Correct answer: A

Explanation: Defender for Open-Source Relational Databases is designed to provide protection for supported PostgreSQL and MySQL database services, along with supported related environments.


Go to the SC-500 Exam Prep Hub main page

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:

  • TCP
  • UDP
  • Any

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

PropertyExample
NameAllow-HTTPS
DirectionInbound
Priority100
SourceInternet
Source port*
DestinationWeb server subnet
Destination port443
ProtocolTCP
ActionAllow

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:

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

Outbound traffic

For outbound traffic:

  1. Azure evaluates the NIC-level NSG.
  2. Azure evaluates the subnet-level NSG.
  3. 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

PriorityRuleAction
100Allow TCP 443 from InternetAllow
110Deny all inbound trafficDeny

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

If the rules were reversed:

PriorityRuleAction
100Deny all inbound trafficDeny
110Allow TCP 443 from InternetAllow

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:

PrioritySourceDestinationPortAction
100InternetAsg-Web443Allow
110Asg-WebAsg-App8080Allow
120Asg-AppAsg-Database1433Allow
130Asg-ManagementAsg-Web22Allow
4000AnyAnyAnyDeny

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.

FeatureService tagsApplication security groups
RepresentsAzure service IP ranges or traffic categoriesApplication network interfaces
ExampleStorage, Internet, AzureLoadBalancerAsg-Web, Asg-Database
Main purposeSimplify access to Azure servicesSimplify application segmentation
Managed byMicrosoft-managed IP prefix updatesCustomer-managed membership
Common useAllow traffic from Azure StorageAllow 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:

  1. Create an NSG.
  2. Create an ASG.
  3. Associate the NSG with a subnet or NIC.
  4. Add NICs to the ASG.
  5. Create inbound and outbound rules.
  6. Test connectivity.
  7. Review effective security rules.
  8. 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

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:

  1. Allow
  2. Always allow
  3. 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:

ActionResult
AllowPermits traffic to continue to NSG evaluation
Always allowPermits traffic and prevents NSGs from denying it
DenyBlocks 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:

PriorityTarget groupTrafficAction
10Approved-Admin-NetworksInbound TCP 22Allow
100All-Managed-NetworksInbound TCP 22 from InternetDeny

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.

CharacteristicSecurity admin rulesNSGs
Main audienceCentral network/security administratorsApplication and workload teams
Applied toManaged virtual networksSubnets and network interfaces
ScopeOrganization-wide or group-wideWorkload- or subnet-specific
ActionsAllow, Always allow, DenyAllow, Deny
EvaluationBefore NSGsAfter security admin rules
Central enforcementYesUsually managed at workload level
Can block traffic before NSG evaluation?Yes, with DenyNo
Can bypass NSG denial?Yes, with Always allowNo

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

  1. AVNM enforces organization-wide security requirements.
  2. NSGs enforce application-specific access.
  3. 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:

PriorityDirectionSourceDestinationPortAction
100InboundInternetAny22Deny
110InboundInternetAny3389Deny

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:

PriorityNetwork groupSourceDestinationPortAction
10Approved-Admin-NetworksApproved admin rangeAny22Allow
100All-NetworksInternetAny22Deny

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:

  1. Create an Azure Virtual Network Manager instance.
  2. Define its management scope.
  3. Enable the Security admin feature.
  4. Create network groups.
  5. Add virtual networks to the groups.
  6. Create a security admin configuration.
  7. Add rule collections and rules.
  8. Associate rule collections with network groups.
  9. Deploy the configuration to the required regions.
  10. 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:

  1. Confirm that the configuration was deployed.
  2. Confirm that the deployment targeted the correct region.
  3. Confirm that the virtual network belongs to the expected network group.
  4. Allow time for membership and configuration propagation.
  5. 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

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:

CapabilityBasic Virtual WANStandard Virtual WAN
Site-to-site VPNSupportedSupported
ExpressRouteNot supportedSupported
Point-to-site user VPNNot supportedSupported
Inter-hub transitNot supportedSupported
VNet-to-VNet transitNot supportedSupported
Azure FirewallNot supportedSupported
Network virtual appliances in Virtual WANNot supportedSupported

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

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.

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

CapabilityAzure RBACResource Lock
Determines who has permissionsYesNo
Grants permissionsYesNo
Restricts deletionIndirectly, through permissionsYes
Restricts modificationThrough permissionsYes, with ReadOnly
Applies to all users/roles at the locked scopeNoYes
Protects against accidental deletionIndirectlySpecifically designed for this
Replaces RBACNoNo

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:

  1. CanNotDelete
  2. 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 TypeReadModifyDelete
No lockYesYes*Yes*
CanNotDeleteYesYesNo
ReadOnlyYesNoNo

* 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:

  1. The resource’s own lock
  2. The parent resource group’s lock
  3. The subscription-level lock
  4. 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/*

or

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:

  1. Open the resource or resource group.
  2. Select Locks.
  3. Select Add.
  4. Enter a lock name.
  5. Select the lock type:
    • Delete
    • Read-only
  6. Optionally provide notes.
  7. Create the lock.

The portal terminology maps to the Azure Resource Manager lock levels:

PortalARM Lock Level
DeleteCanNotDelete
Read-onlyReadOnly

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.

Tags

Provide metadata for:

  • Organization
  • Cost management
  • Ownership
  • Environment classification
  • Automation

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

RequirementRecommended Approach
Prevent resource deletionCanNotDelete
Prevent resource modification and deletionReadOnly
Allow normal configuration changes but prevent deletionCanNotDelete
Protect an entire resource groupLock the resource group
Protect a single critical resourceLock the resource
Protect resources across a subscriptionSubscription-level lock, used carefully
Prevent insecure configurationsAzure Policy
Control who can manage resourcesAzure RBAC
Protect data from data-plane deletionData-plane security/data protection controls
Protect against accidental resource deletionResource lock
Allow users to read but not modify the resourceReadOnly

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:

  1. Prevent developers from deploying resources that violate required security configurations.
  2. 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:

  1. Resource locks protect Azure resources from accidental deletion or modification.
  2. Locks can be applied at the subscription, resource group, or resource scope.
  3. The two primary lock types are CanNotDelete and ReadOnly.
  4. CanNotDelete allows reading and modification but prevents deletion.
  5. ReadOnly allows reading but prevents modification and deletion.
  6. Resource locks can restrict operations even when the user has sufficient RBAC permissions.
  7. Locks applied at a parent scope can be inherited by child resources.
  8. When multiple locks apply, the most restrictive lock takes precedence.
  9. Resource locks primarily affect control-plane operations.
  10. A resource lock does not automatically protect data-plane data such as blobs or database records.
  11. Resource locks do not replace Azure RBAC.
  12. Resource locks do not replace Azure Policy.
  13. Use Azure Policy to govern resource configurations and use resource locks to protect resources from deletion or modification.
  14. Use CanNotDelete when administrators must continue modifying the resource.
  15. Use ReadOnly when both modification and deletion must be prevented.
  16. Apply locks carefully because they can interfere with automated Azure service operations.
  17. In particular, locks can affect services such as Azure Backup and other services that need to modify or delete resources.
  18. A resource-group-level lock can prevent deletion of the entire resource group and its contents.
  19. Managing locks requires appropriate authorization to manage Azure management locks.
  20. 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

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:

  1. Security principal
  2. Role definition
  3. 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:

  1. Management group
  2. Subscription
  3. Resource group
  4. 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 roleGeneral purpose
OwnerFull access, including ability to assign Azure RBAC roles
ContributorManage Azure resources, but cannot assign Azure RBAC roles
ReaderView Azure resources without making changes
User Access AdministratorManage user access to Azure resources
Role Based Access Control AdministratorManage Azure RBAC role assignments
Virtual Machine ContributorManage virtual machines
Network ContributorManage networking resources
Storage Account ContributorManage storage account resources
Key Vault ReaderRead Key Vault metadata
Storage Blob Data ReaderRead 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:

RoleManage resourcesAssign Azure RBAC roles
ReaderNoNo
ContributorYesNo
OwnerYesYes
User Access AdministratorAccess-management focusedYes

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:

RequirementLikely approach
View Azure resourcesReader
Manage Azure resources without managing RBACContributor or a more specialized role
Full resource management plus RBAC managementOwner
Manage Azure RBAC assignmentsRole Based Access Control Administrator or User Access Administrator, depending on requirements
Manage only a particular workload typeSpecialized built-in role
Application needs blob read accessStorage Blob Data Reader or another appropriate data-plane role
Access should apply only to one resourceResource-level scope
Access should apply to resources in one resource groupResource-group scope
Access should span an entire subscriptionSubscription scope
Access should span multiple subscriptionsManagement-group scope
Built-in role is too broad or doesn’t meet requirementsConsider a custom role
Need to prevent insecure configurationsAzure Policy
Need to protect against accidental deletionResource lock
Need temporary privileged accessConsider PIM

27. Key Takeaways

For the SC-500 exam, remember these principles:

  1. Azure RBAC controls access to Azure resources.
  2. A role assignment consists of a principal, role definition, and scope.
  3. Built-in roles provide predefined permissions for common scenarios.
  4. Owner provides full resource management and can assign Azure RBAC roles.
  5. Contributor can manage resources but cannot assign Azure RBAC roles.
  6. Reader provides read-only resource access.
  7. User Access Administrator and Role Based Access Control Administrator are designed for access-management scenarios.
  8. Azure RBAC scopes are management group, subscription, resource group, and resource.
  9. Permissions assigned at a parent scope are inherited by child resources.
  10. Follow least privilege by selecting the narrowest appropriate role and scope.
  11. Assign roles to groups when practical.
  12. Distinguish control-plane permissions from data-plane permissions.
  13. Use a specialized built-in role when it provides the required permissions more precisely than Contributor or Owner.
  14. Consider custom roles only when built-in roles cannot meet the requirement appropriately.
  15. Use PIM to reduce standing privileged access.
  16. 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

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 roleMicrosoft Entra custom role
Primary purposeManage Azure resourcesManage Microsoft Entra resources
Authorization systemAzure RBACMicrosoft Entra RBAC
Examples of resourcesVMs, storage, networking, databasesUsers, groups, applications, enterprise applications
Permission modelAzure resource-provider operationsMicrosoft Entra resource actions
Assignment scopesAzure management-group, subscription, resource-group/resource scopesDirectory or supported resource-specific scopes
Created/managed throughAzure portal, CLI, PowerShell, REST APIMicrosoft Entra admin center, Microsoft Graph PowerShell/API
Can permissions be mixed?NoNo

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:

  1. Identify the exact required operations.
  2. Review existing built-in roles.
  3. Determine whether an existing built-in role is sufficient.
  4. Create a custom role only if necessary.
  5. Limit its permissions.
  6. Limit its assignable scopes.
  7. 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

CharacteristicAzure Custom RoleMicrosoft Entra Custom Role
Authorization systemAzure RBACMicrosoft Entra RBAC
Primary targetAzure resourcesMicrosoft Entra resources/capabilities
Permission formatAzure resource-provider operationsMicrosoft Entra resource actions
Control-plane/data-plane distinctionYes, including Actions/DataActions where supportedDifferent Microsoft Entra permission model
Typical resourcesVM, Storage, SQL, NetworkUsers, groups, applications, enterprise applications
Azure management-group scopeYesNo
Azure subscription scopeYesNo
Azure resource-group scopeYesNo
Microsoft Entra directory scopeNoYes
App registration resource scopeNoSupported
Creation toolsAzure portal, CLI, PowerShell, RESTEntra admin center, Graph PowerShell, Graph API
Typical creation privilegeAzure authorization permission such as roleDefinitions/writePrivileged Role Administrator
Permissions interchangeable?NoNo

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:

  1. Azure custom roles are part of Azure RBAC.
  2. Microsoft Entra custom roles are part of Microsoft Entra RBAC.
  3. The two permission models are separate.
  4. Azure custom roles manage Azure resources.
  5. Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities.
  6. A role definition describes permissions.
  7. A role assignment grants a role to a principal at a scope.
  8. Azure custom roles can contain Actions, NotActions, DataActions, and NotDataActions.
  9. Actions generally represent control-plane operations.
  10. DataActions represent data-plane operations where supported.
  11. NotActions is not an explicit deny mechanism.
  12. Azure custom-role AssignableScopes controls where the role can be assigned.
  13. The role assignment’s scope determines where the assigned permissions apply.
  14. Built-in roles should generally be used when they meet the requirement.
  15. Custom roles are appropriate when built-in roles cannot provide the required level of precision.
  16. Avoid unnecessary wildcard permissions.
  17. Evaluate effective permissions across all role assignments, not just one role.
  18. Privileged role-management permissions require particular caution.
  19. PIM can help reduce standing privileged access.
  20. 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

Evaluate and remediate overprivileged access assignments by using Azure role-based access control (RBAC) (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
      --> Evaluate and remediate overprivileged access assignments by using Azure role-based access control (RBAC)


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 who can access Azure resources, what they can do, and at what scope they can perform those actions.

One of the most important security responsibilities of an Azure administrator or security engineer is to ensure that users, groups, service principals, managed identities, and other security principals have only the permissions they actually need.

Over time, Azure environments can accumulate excessive permissions because:

  • Employees change jobs or responsibilities.
  • Temporary administrative access becomes permanent.
  • Users receive multiple role assignments through different groups.
  • Broad roles such as Owner or Contributor are assigned for convenience.
  • Roles are assigned at subscription or management-group scope when a resource-group or resource scope would be sufficient.
  • Group memberships change without corresponding changes to Azure access.
  • Service principals and managed identities retain permissions after an application changes.
  • Administrators assign a powerful built-in role when a narrower role would work.
  • Inherited role assignments are overlooked.

The SC-500 exam expects you to understand how to identify excessive Azure RBAC permissions, determine why the permissions exist, reduce them to the minimum required level, and periodically review access to prevent privilege accumulation.


1. Understand the Azure RBAC Access Model

Azure RBAC can be understood through three fundamental components:

Security principal + Role definition + Scope = Role assignment

Security principal

The security principal is the identity receiving the permissions.

Examples include:

  • User
  • Security group
  • Service principal
  • Managed identity
  • Workload identity

Azure RBAC can assign roles to these types of principals.

Role definition

A role definition specifies what actions the principal is allowed to perform.

Examples include:

  • Reader
  • Contributor
  • Owner
  • Storage Blob Data Reader
  • Virtual Machine Contributor
  • Custom roles

Scope

Scope specifies where the permissions apply.

Azure RBAC supports a hierarchy of scopes:

  1. Management group
  2. Subscription
  3. Resource group
  4. Individual resource

Permissions assigned at a parent scope are inherited by child scopes.

For example:

Management Group
|
+-- Subscription
|
+-- Resource Group
|
+-- Storage Account
|
+-- Virtual Machine

If a user receives Contributor at the subscription level, that access can apply to resources throughout the subscription.

If the same user receives Contributor only at a particular resource group, the permissions are limited to that resource group’s resources.

Therefore, scope is one of the most important factors when evaluating excessive access.


2. What Is Overprivileged Access?

A principal is overprivileged when it has more permissions or broader scope than necessary to perform its job.

Consider this example:

A developer only needs to restart virtual machines in the Development resource group.

The developer has:

Contributor at the subscription level

This is potentially excessive because Contributor provides broad management permissions across many resource types and the assignment applies to the entire subscription.

A better solution might be:

Virtual Machine Contributor at the Development resource-group scope

This reduces both:

  • The number of operations the developer can perform.
  • The number of resources on which those operations can be performed.

This follows the principle of least privilege: provide the minimum permissions necessary to perform the required task.


3. Why Overprivileged Assignments Are a Security Risk

Excessive Azure RBAC permissions increase the potential impact of a compromised identity.

For example, suppose a compromised account has:

Owner at subscription scope

The attacker could potentially manage resources and access assignments throughout the subscription.

Compare that with:

Virtual Machine Contributor at one resource group

The potential blast radius is significantly smaller.

The principle is:

The broader the role and the broader the scope, the greater the potential impact of credential compromise.

This is why Azure RBAC best practices recommend avoiding broad roles at broad scopes when narrower permissions can satisfy the business requirement.


4. Built-In Roles Should Usually Be the Starting Point

Azure provides many built-in roles for common administrative scenarios.

Examples include:

RoleGeneral purpose
ReaderView resources without managing them
ContributorManage Azure resources but cannot normally assign Azure RBAC roles
OwnerFull resource-management access, including managing Azure RBAC access
User Access AdministratorManage user access to Azure resources
Role Based Access Control AdministratorManage Azure role assignments with fewer permissions than User Access Administrator
Virtual Machine ContributorManage virtual machines
Storage Account ContributorManage storage accounts
Network ContributorManage networking resources

The goal isn’t simply to find a role that works.

The goal is to find the role that provides the required permissions with the least unnecessary privilege.

For example:

If someone only needs to view resources, use Reader rather than Contributor.

If someone needs to manage virtual machines but not storage accounts, use an appropriately scoped VM-management role rather than Contributor across the subscription.


5. Evaluate the Role and the Scope

When investigating an RBAC assignment, evaluate two separate questions.

Question 1: What can the principal do?

Examine the assigned role.

For example:

Owner
Contributor
Virtual Machine Contributor
Reader
Custom Role

Question 2: Where can the principal do it?

Examine the assignment scope.

For example:

Management group
Subscription
Resource group
Specific resource

You should evaluate both dimensions.

Consider:

RoleScopePotential concern
ReaderResourceLow
ReaderSubscriptionMay be appropriate
ContributorResourceDepends on requirement
ContributorResource groupPotentially broad
ContributorSubscriptionFrequently requires scrutiny
OwnerResourceHighly privileged
OwnerSubscriptionHighly privileged
User Access AdministratorSubscriptionHighly privileged

The correct question is not:

“Is Contributor dangerous?”

Instead ask:

“Does this principal need Contributor at this scope?”


6. Understand Inherited Permissions

A common RBAC troubleshooting mistake is attempting to remove a role assignment from a child resource when the assignment was actually created at a parent scope.

For example:

Subscription
|
+-- Contributor assigned to Alice
|
+-- Resource Group A
|
+-- VM

Alice sees Contributor access to the VM, but the assignment may not exist directly on the VM.

It is inherited from the subscription.

If you try to remove the assignment at the VM level, you cannot simply remove the inherited assignment there.

You must locate and modify or remove the assignment at the scope where it was actually created.

Exam tip

When you see:

“The user has access to a resource, but no role assignment appears directly on the resource.”

Think:

Inherited RBAC assignment.

Then investigate the parent scopes.


7. Use the Azure Portal to Evaluate Access

A common way to investigate Azure RBAC assignments is through Access control (IAM).

At the appropriate scope:

  1. Open the subscription, resource group, or resource.
  2. Select Access control (IAM).
  3. Select Role assignments.
  4. Review the principals.
  5. Review their roles.
  6. Review the assignment scope.
  7. Determine whether the assignment is direct or inherited.
  8. Identify unnecessary or excessive permissions.
  9. Remove or replace excessive assignments.

The important point is to investigate all effective access, rather than looking only at direct assignments.


8. Evaluate Effective Access, Not Just Individual Assignments

A user can have multiple role assignments.

For example:

Alice
├── Reader → Subscription
├── Contributor → Resource Group A
└── VM Contributor → VM01

Looking at only one assignment may not reveal the user’s actual level of access.

You need to consider:

  • Direct assignments
  • Group-based assignments
  • Inherited assignments
  • Multiple role assignments
  • Different scopes
  • Privileged roles
  • Service principals and managed identities where applicable

This is particularly important because a user may appear to have a relatively narrow direct assignment while receiving significantly broader permissions through group membership.


9. Look for High-Risk Roles

Certain Azure roles deserve particular scrutiny because they can provide highly privileged capabilities.

Owner

Owner provides full management access to the resource and includes the ability to manage Azure RBAC access.

An unnecessary Owner assignment should generally be removed or replaced with a less privileged role.

User Access Administrator

User Access Administrator is specifically designed to manage access to Azure resources.

Because it can manage role assignments, it is itself a highly privileged role.

Role Based Access Control Administrator

The Role Based Access Control Administrator role is designed for role-assignment management and has fewer permissions than User Access Administrator, making it useful when the requirement is specifically to delegate RBAC administration.

Contributor

Contributor cannot normally assign Azure RBAC roles, but it can perform broad resource-management operations.

Therefore:

Contributor is less privileged than Owner, but it can still be significantly overprivileged.

Do not assume that an assignment is acceptable merely because the principal isn’t an Owner.


10. Reduce Excessive Scope

One of the easiest ways to reduce excessive access is to narrow the scope.

For example:

Before

Contributor
Subscription

After

Virtual Machine Contributor
Development Resource Group

The second assignment reduces both:

  • Permissions
  • Scope

This is much closer to least privilege.

Azure recommends using narrower scopes, such as a resource group or resource, when a broader management-group or subscription scope isn’t required.


11. Remove Unnecessary Role Assignments

If a principal no longer requires access, the correct remediation is generally to remove the role assignment.

For example:

A contractor completed a project six months ago but still has Contributor access to the production subscription.

The appropriate action is to remove the unnecessary assignment.

Removing an Azure RBAC role assignment removes that access from the specified scope, assuming the assignment is not being inherited from another scope or otherwise recreated by an automated process.

Important distinction

Do not simply disable an account and assume the RBAC assignment has been cleaned up.

When an identity is deleted, stale role assignments can remain and should be removed as part of access hygiene.


12. Replace Broad Roles With Narrower Roles

Sometimes an assignment should not be removed completely because the user still needs access.

Instead, replace the excessive role with a narrower role.

Example:

Requirement

A support engineer needs to:

  • View Azure resources.
  • Restart virtual machines.

The engineer does not need to:

  • Modify storage accounts.
  • Modify networking.
  • Create role assignments.
  • Delete unrelated resources.

Poor assignment

Contributor
Subscription

Better assignment

Use a VM-specific role at the appropriate resource-group or resource scope.

This follows the principle:

Don’t remove required access—right-size it.


13. Use Custom Roles When Built-In Roles Are Too Broad

Sometimes no built-in role provides exactly the permissions required.

In that case, a custom Azure RBAC role can provide a more precise set of permissions.

For example, suppose an operations team needs to:

  • Start virtual machines.
  • Stop virtual machines.
  • Restart virtual machines.

But they should not be able to:

  • Delete virtual machines.
  • Modify networking.
  • Modify storage.
  • Assign roles.

If an appropriate built-in role is too broad, a custom role can be designed around the required operations.

The objective is not:

“Create a custom role because custom roles are more secure.”

Instead:

Create a custom role when a built-in role cannot provide the required least-privilege access.

Azure guidance recommends starting with built-in roles and creating custom roles only when there is a clear need.


14. Review Role Permissions Carefully

A custom role can contain permissions such as:

  • Actions
  • NotActions
  • DataActions
  • NotDataActions

These distinctions are important.

Actions

Control-plane management operations.

Examples include operations to:

  • Create resources
  • Update resources
  • Delete resources
  • Read resource configuration

DataActions

Data-plane operations.

These control access to data within supported Azure resources.

For example, management-plane access to a storage account is different from permission to read blob data.

Therefore:

Do not assume that having management permissions automatically means having data-plane permissions, or vice versa.


15. Be Careful With Wildcards

Custom roles can use wildcard permissions.

For example:

Microsoft.Storage/*

This can be convenient, but it may grant more permissions than intended and may encompass additional operations as the platform evolves.

For least privilege, explicitly identify the operations that are actually required whenever practical.

Azure RBAC guidance recommends avoiding wildcard permissions in custom roles unless they are genuinely justified.


16. Understand That NotActions Is Not an Explicit Deny

A frequent exam trap involves NotActions.

Suppose a role contains:

Actions:
Microsoft.Compute/*
NotActions:
Microsoft.Compute/virtualMachines/delete

NotActions removes specified operations from the role’s Actions set.

It does not create a universal deny rule.

If another role assignment grants the principal the ability to delete virtual machines, the NotActions entry in this particular role does not necessarily prevent that other assignment from granting the permission.

Therefore:

NotActions is an exclusion from a role definition, not a deny mechanism across Azure RBAC.


17. Investigate Group-Based Access

Group-based RBAC is a recommended way to manage access because it simplifies administration.

However, groups can also create hidden privilege accumulation.

For example:

User
|
+-- Member of Developers
| |
| +-- Contributor → Subscription
|
+-- Member of Operations
|
+-- Reader → Management Group

The user’s effective access comes from both groups.

When investigating excessive access, determine:

  • Which groups grant Azure roles?
  • Which groups is the user a member of?
  • Are nested groups involved?
  • Is the user receiving duplicate or overlapping permissions?
  • Is the user still supposed to be in those groups?

The best remediation may be to remove the user from an unnecessary group, rather than individually changing every RBAC assignment.


18. Review Service Principals and Managed Identities

Overprivileged access isn’t limited to human users.

Applications and workloads can also receive Azure RBAC assignments.

Examples:

  • Service principals
  • Managed identities
  • Workload identities

These identities should receive only the permissions necessary for the application to function.

For example:

An application only needs to read secrets from a specific Key Vault.

Giving its managed identity Owner access to the subscription would be extremely excessive.

Instead, assign an appropriate Key Vault role at the narrowest practical scope.

This reduces the potential blast radius if the workload or its credentials are compromised.


19. Use Privileged Identity Management (PIM)

For privileged access, Microsoft Entra Privileged Identity Management (PIM) can help reduce standing administrative privileges.

Instead of keeping highly privileged access permanently active, eligible users can activate privileged roles when needed, subject to organizational controls such as:

  • Approval
  • Multifactor authentication
  • Time limits
  • Justification
  • Notifications
  • Access reviews

PIM also supports reviews of Azure resource roles, helping organizations identify stale privileged assignments.

Exam concept

If the scenario says:

“Administrators need privileged access only occasionally.”

Think:

PIM / eligible access rather than permanent standing access.


20. Perform Regular Access Reviews

RBAC isn’t a “set it and forget it” security control.

Access should be reviewed regularly.

Ask:

  • Does the user still need the role?
  • Does the user still have the correct job responsibilities?
  • Is the scope still appropriate?
  • Is the role more powerful than necessary?
  • Is the assignment permanent when it could be temporary?
  • Is access coming through a group?
  • Is the identity still active?
  • Is the service principal or managed identity still required?

Access reviews can be used to review privileged Azure resource roles and Microsoft Entra roles through PIM. Recurring reviews can help identify stale access over time.


21. Understand the Difference Between Evaluation and Remediation

The exam topic contains two important activities:

Evaluate

Determine whether access is excessive.

Examples:

  • User has Owner but only needs Reader.
  • Contributor is assigned at subscription scope but only one resource group is required.
  • User retains access after changing departments.
  • Service principal has permissions unrelated to its application.
  • A privileged role is permanently assigned even though it is only occasionally required.

Remediate

Take action to reduce the risk.

Examples:

  • Remove the role assignment.
  • Remove unnecessary group membership.
  • Replace Contributor with a narrower role.
  • Reduce subscription scope to resource-group scope.
  • Replace Owner with a job-specific role.
  • Create a custom least-privilege role.
  • Convert standing privileged access to eligible PIM access where appropriate.

22. A Practical RBAC Remediation Process

A useful process for SC-500 is:

Step 1 — Identify the principal

Determine whether the assignment belongs to:

  • User
  • Group
  • Service principal
  • Managed identity
  • Workload identity

Step 2 — Identify all effective assignments

Look for:

  • Direct assignments
  • Group-based assignments
  • Inherited assignments
  • Multiple assignments

Step 3 — Identify the assigned roles

Determine whether the principal has:

  • Reader
  • Contributor
  • Owner
  • User Access Administrator
  • RBAC Administrator
  • Specialized built-in role
  • Custom role

Step 4 — Determine the actual business requirement

Ask:

What does this identity actually need to do?

Avoid designing permissions based on what the user currently happens to have.

Step 5 — Evaluate scope

Determine whether the role is assigned at:

  • Management group
  • Subscription
  • Resource group
  • Resource

Step 6 — Reduce the role

Choose the least powerful role that satisfies the requirement.

Step 7 — Reduce the scope

Choose the smallest practical scope.

Step 8 — Consider PIM

If privileged access is occasional, consider eligible/JIT-style privileged access rather than permanent access.

Step 9 — Remediate

Remove, replace, or modify the unnecessary assignment.

Step 10 — Review regularly

Schedule periodic access reviews, particularly for privileged roles.


23. A Simple Least-Privilege Decision Framework

When an exam question presents an excessive RBAC assignment, work through these questions:

Question 1

Does the principal still need access?

If No → remove the assignment.

Question 2

Does the principal need the entire role?

If No → replace it with a narrower role or custom role.

Question 3

Does the principal need access to everything within the current scope?

If No → reduce the scope.

Question 4

Does the principal need permanent privileged access?

If No → consider PIM.

Question 5

Is the access coming from a group?

If Yes → evaluate whether group membership should be removed rather than changing an individual assignment.

This framework is highly useful for scenario-based SC-500 questions.


24. Common Exam Traps

Trap 1: “Contributor is safe because it isn’t Owner.”

Incorrect.

Contributor can still provide broad management permissions.


Trap 2: “The user needs access to one VM, so give Contributor at the subscription.”

Incorrect.

Use a narrower role and narrower scope.


Trap 3: “The role isn’t assigned directly to the resource, so the user doesn’t have access.”

Incorrect.

The role may be inherited from a parent scope.


Trap 4: “NotActions denies the operation everywhere.”

Incorrect.

NotActions excludes operations from that role definition; it isn’t a universal deny.


Trap 5: “PIM automatically fixes excessive permissions.”

Not necessarily.

PIM can reduce standing privileged access, but you still need to evaluate whether the underlying role and scope are appropriate.


Trap 6: “Custom roles are always better.”

Incorrect.

Start with built-in roles. Use custom roles when built-in roles don’t provide the required least-privilege combination.


Trap 7: “Remove the user’s direct role assignment and the problem is solved.”

Not necessarily.

The user may receive the same or greater permissions through:

  • Group membership
  • Inheritance
  • Another role assignment

Trap 8: “A role assignment at a resource is always the most important thing to examine.”

Not necessarily.

You must evaluate the complete effective-access picture.


25. Key Concepts to Remember

For the SC-500 exam, remember these relationships:

RequirementPreferred approach
User no longer needs accessRemove role assignment
User needs less powerful permissionsReplace with narrower role
User needs access to fewer resourcesReduce scope
Built-in role is too broadConsider custom role
Privileged access is occasionalConsider PIM
Access comes through unnecessary groupRemove group membership
Assignment appears unexpectedlyCheck inherited/group-based access
Application has excessive permissionsRight-size service principal/managed identity
Need regular confirmation of privileged accessAccess reviews
Need to manage role assignments with fewer privilegesRBAC Administrator
Need to manage resources but not RBAC assignmentsContributor
Need full resource access including RBACOwner

Practice Exam Questions

Question 1

A developer needs to restart virtual machines in a single resource group. The developer currently has the Contributor role assigned at the subscription scope.

What is the BEST remediation?

A. Replace Contributor with an appropriate VM-management role at the resource-group scope.

B. Replace Contributor with Owner at the resource-group scope.

C. Keep Contributor because Contributor cannot assign RBAC roles.

D. Replace Contributor with User Access Administrator at the subscription scope.

Answer: A

Explanation

The developer needs VM-management capabilities only within one resource group. The best solution is to use a narrower VM-specific role and assign it at the resource-group scope.

Contributor at subscription scope provides considerably broader access than necessary.

This addresses both dimensions of least privilege:

  • Reduce the permissions
  • Reduce the scope

Question 2

A security engineer discovers that a user can modify resources in a resource group even though no Contributor assignment appears directly on the resource group.

What should the engineer investigate FIRST?

A. Whether the resource has a resource lock.

B. Whether Azure Policy is granting Contributor permissions.

C. Whether the user has an inherited role assignment from a parent scope.

D. Whether the user has a Microsoft Entra application role.

Answer: C

Explanation

Azure RBAC assignments are inherited from parent scopes.

The user may have Contributor assigned at the subscription or management-group level.

Azure Policy does not grant Azure RBAC permissions, and a resource lock does not grant access.


Question 3

An organization discovers that an employee has Owner access to an Azure subscription but only needs to manage virtual machines in one production resource group.

Which remediation best follows the principle of least privilege?

A. Change Owner to Contributor at the subscription scope.

B. Replace Owner with an appropriate VM-management role at the production resource-group scope.

C. Keep Owner but enable MFA.

D. Replace Owner with User Access Administrator at the subscription scope.

Answer: B

Explanation

The employee needs VM management in one resource group—not complete subscription administration.

The best remediation is therefore to:

  1. Reduce the role.
  2. Reduce the scope.

MFA is valuable but does not correct excessive authorization.


Question 4

An administrator wants to prevent a custom Azure RBAC role from allowing deletion of virtual machines while allowing the other operations included in a broader action set.

Which role-definition property is designed to exclude specific operations from the role’s Actions?

A. DataActions

B. AssignableScopes

C. NotDataActions

D. NotActions

Answer: D

Explanation

NotActions excludes specified control-plane operations from the role’s Actions.

NotDataActions applies to data-plane permissions.

However, remember that NotActions is not a universal deny. Another role assignment could potentially grant the excluded permission.


Question 5

A service principal used by an application has Contributor access to an entire subscription. The application only needs to read data from one Azure service.

What should the security engineer do?

A. Change Contributor to Owner at the subscription scope.

B. Remove the excessive assignment and grant the application only the required data-access role at the narrowest appropriate scope.

C. Keep Contributor because service principals are not subject to least-privilege requirements.

D. Assign User Access Administrator to the service principal.

Answer: B

Explanation

Service principals and managed identities must also follow least-privilege principles.

The application should receive only the permissions it requires and only at the necessary scope.

Giving an application Contributor at subscription scope creates an unnecessarily large blast radius if the application or its credentials are compromised.


Question 6

A company has 20 administrators who occasionally need highly privileged Azure access. Security policy requires that privileged permissions not remain permanently active.

Which solution is MOST appropriate?

A. Use Microsoft Entra Privileged Identity Management to provide eligible, controlled privileged access.

B. Assign Owner permanently but require users to change their passwords monthly.

C. Assign Contributor permanently and use Azure Policy to remove the role.

D. Create a resource lock on the subscription.

Answer: A

Explanation

PIM is designed to reduce standing privileged access and can support controlled, time-bound activation of privileged Azure resource roles.

The other choices do not solve the underlying problem of permanently assigned privileged permissions.


Question 7

A user receives the following Azure RBAC assignments:

  • Reader at the subscription level
  • Contributor at Resource Group A
  • Owner at Resource Group B

Security policy states that the user should only manage virtual machines in Resource Group A.

What is the BEST remediation?

A. Remove Reader and keep Owner.

B. Change Owner to Contributor but leave all other assignments unchanged.

C. Remove all Azure access and recreate the account.

D. Remove unnecessary assignments and provide an appropriately scoped VM-management role for Resource Group A.

Answer: D

Explanation

The user’s requirement is limited to VM management in Resource Group A.

The correct solution is to eliminate unnecessary access and provide the smallest role and scope that satisfy the requirement.

In particular, the Owner assignment on Resource Group B is clearly outside the stated requirement.


Question 8

A custom Azure RBAC role contains:

Actions:
Microsoft.Storage/*
NotActions:
Microsoft.Storage/storageAccounts/delete

What does NotActions accomplish?

A. It creates an explicit deny that prevents the user from deleting storage accounts through any Azure RBAC assignment.

B. It prevents the user from accessing storage-account data.

C. It excludes the specified delete operation from the permissions granted by this role definition.

D. It restricts where the role can be assigned.

Answer: C

Explanation

NotActions subtracts specified control-plane operations from the role’s Actions.

It does not create an explicit deny across all role assignments.

AssignableScopes controls where a custom role can be assigned, while DataActions concerns data-plane operations.


Question 9

A user no longer requires Contributor access to a subscription. The security engineer attempts to remove the Contributor assignment from a resource group but Azure indicates that the assignment is inherited.

What should the engineer do?

A. Create a resource lock on the resource group.

B. Delete the resource group.

C. Assign Reader to the user before removing Contributor.

D. Locate the original role assignment at the parent scope and remove or modify it there.

Answer: D

Explanation

Inherited Azure RBAC assignments must be addressed at the scope where the assignment was created.

If Contributor was assigned at the subscription level, removing it from an individual resource group isn’t the correct remediation.


Question 10

A security team performs a quarterly review and discovers several users with privileged Azure resource roles that were granted months ago. The organization wants resource owners to determine whether those users still require the access.

Which capability is BEST suited to this requirement?

A. Azure resource locks

B. Microsoft Entra access reviews through Privileged Identity Management

C. Azure Policy with a deny effect

D. Azure Storage firewall rules

Answer: B

Explanation

Access reviews integrated with Privileged Identity Management can be used to periodically review privileged Azure resource roles and determine whether users should retain access.

This directly addresses stale privileged access.

Resource locks protect resources from deletion or modification; they do not evaluate whether users still need RBAC permissions.

Azure Policy is useful for enforcing resource configurations, not for periodically certifying whether individual users still need privileged access.


Final Exam Takeaways

When you encounter an SC-500 question about overprivileged Azure RBAC access, think:

Evaluate the identity → evaluate the role → evaluate the scope → evaluate inherited/group access → determine the actual requirement → reduce role → reduce scope → remove unnecessary access → use PIM/access reviews for privileged access.

The most important principle is:

Least privilege = the minimum permissions at the minimum necessary scope for the minimum necessary period.

Also remember these high-value exam distinctions:

  • Owner → full resource access, including RBAC access management.
  • Contributor → broad resource management, but not normally Azure RBAC role assignment.
  • Reader → read-only management-plane access.
  • RBAC Administrator → role-assignment management with fewer permissions than User Access Administrator.
  • Role assignment = principal + role definition + scope.
  • Parent-scope assignments are inherited.
  • Narrow the role AND narrow the scope when remediating excessive access.
  • Custom roles are useful when built-in roles are too broad for the requirement.
  • NotActions is not a universal deny.
  • DataActions concern data-plane operations.
  • PIM helps reduce standing privileged access.
  • Access reviews help identify and remediate stale privileged assignments.
  • Groups, service principals, and managed identities must also be evaluated for excessive access.
  • The objective isn’t simply to remove permissions—it is to right-size access to what the principal actually needs.

Go to the SC-500 Exam Prep Hub main page