Tag: Cloud Security

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

Implement resource locks (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
   --> Implement governance to enforce security and regulatory compliance
      --> Implement resource locks

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

Introduction

Azure resource locks are an important governance mechanism for protecting critical Azure resources from accidental or unauthorized deletion or modification.

For the SC-500 exam, you should understand:

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

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

1. What Are Azure Resource Locks?

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

Locks can be applied at several scopes, including:

Subscription
Resource group
Individual resource

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

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

The key purpose of a resource lock is:

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

This makes resource locks different from ordinary Azure RBAC permissions.

2. Resource Locks vs. Azure RBAC

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

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

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

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

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

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

Therefore:

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

This is one of the most important concepts to remember.

Simple comparison

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

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

3. The Two Primary Resource Lock Types

Azure provides two primary management lock levels:

CanNotDelete
ReadOnly

The names used in the Azure portal are:

Delete
Read-only

The underlying Azure Resource Manager lock levels are:

CanNotDelete
ReadOnly

Understanding exactly what each does is essential for the exam.

4. CanNotDelete Lock

A CanNotDelete lock prevents the locked resource from being deleted.

Authorized users can still:

Read the resource
Modify the resource

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

Example

Suppose a production SQL database has a CanNotDelete lock.

An administrator can still change supported configuration settings.

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

Think of it as:

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

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

5. ReadOnly Lock

A ReadOnly lock is more restrictive.

It prevents users from:

Modifying the resource
Deleting the resource

Users can still read the resource.

Think of it as:

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

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

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

6. CanNotDelete vs. ReadOnly

This comparison should be memorized for the exam.

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

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

Easy memory trick

CanNotDelete:

Change it, but don’t delete it.

ReadOnly:

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

7. Where Can Resource Locks Be Applied?

Resource locks can be applied at several scopes.

Subscription

A lock can be applied to an entire Azure subscription.

This can protect resources throughout the subscription.

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

Resource Group

A lock can be applied to a resource group.

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

For example:

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

		

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

Individual Resource

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

For example:

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

		

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

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

8. Lock Inheritance

Locks can be inherited from a parent scope.

For example:

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

		

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

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

Exam scenario

Suppose:

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

The storage account inherits the applicable lock.

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

9. The Most Restrictive Lock Takes Precedence

Multiple locks can exist within an inheritance hierarchy.

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

For example:

			
Resource Group
   CanNotDelete
        ↓
Storage Account
   ReadOnly

		

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

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

Consider:

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

10. Resource Locks Are Control-Plane Controls

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

They do not universally protect data-plane operations.

Control plane

The control plane manages Azure resources themselves.

Examples include operations such as:

Creating resources
Deleting resources
Updating resource configuration
Changing resource properties

These operations generally go through Azure Resource Manager.

Data plane

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

Examples include:

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

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

11. Example: Storage Account Lock

Consider a storage account containing:

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

		

You apply a CanNotDelete lock to the storage account.

The lock protects the storage account resource against deletion.

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

Why?

Because:

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

This is a very common exam trap.

12. Resource Locks Do Not Replace Data Protection

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

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

But it should not be treated as a replacement for:

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

The lock protects the resource management operation.

Other controls protect the data.

13. Why Use CanNotDelete?

CanNotDelete is useful when:

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

Example

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

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

A CanNotDelete lock is appropriate.

The administrator can modify the resource but cannot delete it.

14. Why Use ReadOnly?

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

Examples might include:

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

However, ReadOnly should be used carefully.

It is significantly more restrictive than CanNotDelete.

15. ReadOnly Can Break Operations

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

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

Consequently, applying ReadOnly can interfere with normal service functionality.

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

Therefore:

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

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

16. Resource Locks and Resource Groups

Resource-group-level locks require particular attention.

Suppose:

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

		

You apply:

CanNotDelete

to ProductionRG.

The resources inherit the protection.

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

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

The lock blocks the overall deletion operation.

17. Resource Locks and Resource Group Deletion

Consider:

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

		

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

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

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

Exam takeaway

If a scenario says:

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

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

18. Resource Locks and RBAC Assignments

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

This is another reason resource locks should be planned carefully.

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

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

19. Resource Locks and Azure Backup

Resource locks can also affect Azure Backup operations.

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

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

Exam lesson

Don’t assume:

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

Instead, consider:

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

Security controls must be designed with service dependencies in mind.

20. Resource Locks and Azure Machine Learning

Another example of an operational consequence involves Azure Machine Learning.

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

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

This can result in unused compute resources remaining active.

The broader lesson is:

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

21. Resource Locks and Deployment History

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

Azure Resource Manager can automatically remove older deployment records.

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

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

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

22. Who Can Create or Delete Resource Locks?

Resource locks are themselves Azure resources and require appropriate authorization.

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

Microsoft.Authorization/*

Microsoft.Authorization/locks/*

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

Specialized roles may also provide the necessary permissions.

Important distinction

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

Lock management requires appropriate authorization to manage locks.

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

23. Removing a Resource Lock

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

For example:

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

		

The ability to remove the lock itself requires appropriate permissions.

This creates an additional administrative boundary around highly sensitive resources.

24. Creating Resource Locks in the Azure Portal

A resource lock can be configured through the Azure portal.

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

Open the resource or resource group.
Select Locks.
Select Add.
Enter a lock name.
Select the lock type:
- Delete
- Read-only
Optionally provide notes.
Create the lock.

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

Portal	ARM Lock Level
Delete	`CanNotDelete`
Read-only	`ReadOnly`

25. Creating Locks with Azure CLI

Resource locks can also be managed through Azure CLI.

For example, a CanNotDelete lock on a resource can be created with a command conceptually similar to:

			
az resource lock create \
  --lock-type CanNotDelete \
  --name ProductionLock \
  --resource-group ProductionRG \
  --resource MyStorageAccount \
  --resource-type Microsoft.Storage/storageAccounts

		

A read-only lock can similarly be created by specifying:

--lock-type ReadOnly

The important exam concept isn’t memorizing every CLI parameter.

Instead, understand that Azure CLI supports both:

CanNotDelete
ReadOnly

and can apply them at appropriate scopes.

26. Creating Locks with Azure PowerShell

Azure PowerShell also supports resource locks.

For example:

			
New-AzResourceLock `
    -LockName ProductionLock `
    -LockLevel CanNotDelete `
    -ResourceGroupName ProductionRG

You can use PowerShell commands such as:

New-AzResourceLock
Get-AzResourceLock
Remove-AzResourceLock

to manage locks.

Again, for SC-500, understanding the purpose and behavior is generally more important than memorizing every command parameter.

27. Resource Locks with ARM Templates and Bicep

Resource locks can also be deployed programmatically using infrastructure as code.

The resource type is:

Microsoft.Authorization/locks

For example, a Bicep resource can conceptually specify:

			
resource createRgLock 'Microsoft.Authorization/locks@2016-09-01' = {
  name: 'productionLock'
  properties: {
    level: 'CanNotDelete'
    notes: 'Protect production resources from accidental deletion.'
  }
}

		

This allows resource-lock configuration to become part of a repeatable infrastructure deployment process.

However, teams should carefully consider lifecycle management.

For example, if the same deployment is responsible for creating the lock and later modifying or deleting the protected resource, the deployment process must have the necessary permissions and be designed to account for the lock.

28. Resource Locks and Infrastructure as Code

Resource locks can be useful as part of a defense-in-depth strategy.

For example:

			
Infrastructure as Code
        ↓
Azure Policy
        ↓
RBAC
        ↓
Resource Lock
        ↓
Protected Resource

		

Each control addresses a different concern.

Infrastructure as code

Provides repeatable and controlled deployments.

Azure Policy

Enforces organizational configuration requirements.

RBAC

Controls who can perform actions.

Resource locks

Prevent deletion or modification at the locked scope.

No single control should be treated as a complete security solution.

29. Resource Locks Are Not a Replacement for Azure Policy

Resource locks and Azure Policy solve different problems.

Resource lock

Protects a specific scope from deletion or modification.

Azure Policy

Evaluates resources against organizational rules and can audit or enforce compliance.

For example:

Requirement:

All storage accounts must use approved network configurations.

Azure Policy is appropriate because the requirement needs to be evaluated across resources.

Requirement:

Prevent accidental deletion of this production storage account.

A resource lock is appropriate.

Easy distinction

Policy asks: “Does this resource meet the required configuration?”

Lock asks: “Can this resource be deleted or modified?”

30. Resource Locks and Tags

Tags and resource locks serve very different purposes.

Locks

Restrict control-plane operations.

A tag such as:

Environment = Production

doesn’t protect a resource from deletion.

A CanNotDelete lock does.

31. Resource Locks and Resource Health

Resource locks also shouldn’t be confused with resource health or monitoring capabilities.

A lock doesn’t:

Detect attacks
Detect malware
Monitor availability
Encrypt data
Back up data
Detect vulnerabilities
Replace security monitoring

Its purpose is much narrower:

Prevent specified management operations against a resource or scope.

32. Choosing the Correct Lock

A useful decision framework is:

Requirement 1

“Administrators must be able to modify the resource, but nobody should be able to delete it.”

Use: CanNotDelete

Requirement 2

“The resource should not be modified or deleted.”

Use: ReadOnly

Requirement 3

“Only this one resource must be protected.”

Apply the lock directly to the resource.

Requirement 4

“All resources in this resource group should be protected from deletion.”

Apply a CanNotDelete lock to the resource group.

Requirement 5

“Prevent resources from being deployed with insecure configurations.”

Consider Azure Policy rather than a resource lock.

Requirement 6

“Protect blob data from unauthorized deletion.”

Don’t rely solely on a resource lock.

Use appropriate data-plane controls and data-protection features.

33. Common Resource Lock Exam Traps

Trap 1: “Owner can always delete the resource.”

Not necessarily.

A resource lock can prevent deletion even when the user has sufficient RBAC permissions.

Trap 2: “`CanNotDelete` prevents modifications.”

Incorrect.

CanNotDelete permits authorized users to modify the resource.

It prevents deletion.

Trap 3: “`ReadOnly` only prevents deletion.”

Incorrect.

ReadOnly prevents both modification and deletion through applicable control-plane operations.

Trap 4: “A storage account lock prevents users from deleting blobs.”

Not necessarily.

Resource locks apply to control-plane operations and aren’t a universal data-plane protection mechanism.

Trap 5: “A resource-group lock protects only the resource group.”

Not exactly.

Locks applied at a parent scope can be inherited by resources within that scope.

Trap 6: “Locks are inherited upward.”

Incorrect.

Inheritance flows downward from a parent scope to child resources.

Trap 7: “Resource locks replace RBAC.”

Incorrect.

RBAC controls authorization.

Locks impose additional management restrictions.

Trap 8: “ReadOnly is always better because it provides stronger security.”

Not necessarily.

ReadOnly can interfere with legitimate service operations.

The appropriate lock depends on the required operational behavior.

Trap 9: “Resource locks protect against every kind of deletion.”

Incorrect.

The lock applies to Azure Resource Manager control-plane operations. Data-plane operations can behave differently.

Trap 10: “A resource lock automatically protects backups.”

Incorrect.

Locks can actually interfere with Azure Backup lifecycle operations if the backup service needs to delete or modify resources.

34. Best Practices for Resource Locks

1. Use CanNotDelete for critical resources that still require routine administration

This provides protection against accidental deletion without preventing normal configuration changes.

2. Use ReadOnly sparingly

ReadOnly is highly restrictive and can interfere with service operations.

3. Apply locks at the narrowest practical scope

Don’t automatically lock an entire subscription when protecting one resource is sufficient.

4. Document locks

Use meaningful lock names and notes explaining why the lock exists.

5. Consider service dependencies

Before locking a resource group, determine whether Azure services need to create, modify, or delete resources within it.

6. Don’t use locks as a substitute for data protection

Combine locks with appropriate:

RBAC
Data-plane authorization
Backup
Soft delete
Versioning
Immutability
Monitoring

7. Combine locks with Azure Policy

Use Policy for configuration governance and locks for resource protection.

8. Review locks periodically

An outdated lock can become an operational problem.

9. Establish a controlled lock-removal process

Because removing a lock can enable destructive operations, lock removal should be appropriately governed.

10. Use infrastructure as code when appropriate

For environments where locks are part of the intended architecture, consider managing them consistently through deployment automation.

35. Resource Locks: Quick Reference

Requirement	Recommended Approach
Prevent resource deletion	`CanNotDelete`
Prevent resource modification and deletion	`ReadOnly`
Allow normal configuration changes but prevent deletion	`CanNotDelete`
Protect an entire resource group	Lock the resource group
Protect a single critical resource	Lock the resource
Protect resources across a subscription	Subscription-level lock, used carefully
Prevent insecure configurations	Azure Policy
Control who can manage resources	Azure RBAC
Protect data from data-plane deletion	Data-plane security/data protection controls
Protect against accidental resource deletion	Resource lock
Allow users to read but not modify the resource	`ReadOnly`

36. SC-500 Exam Review

Before taking the exam, make sure you can answer the following questions.

What is a resource lock?

A management control that prevents deletion or modification of Azure resources at a specified scope.

What are the two lock types?

CanNotDelete
ReadOnly

What does CanNotDelete do?

Allows authorized users to read and modify the resource but prevents deletion.

What does ReadOnly do?

Allows reading but prevents modification and deletion through applicable control-plane operations.

Does a resource lock override RBAC permissions?

A lock can restrict operations even when a user otherwise has sufficient RBAC permissions.

Where can locks be applied?

At subscription, resource group, or resource scope.

Are locks inherited?

Yes. Locks applied at a parent scope can be inherited by child resources.

Which lock takes precedence if multiple locks apply?

The most restrictive applicable lock.

Do locks protect data-plane operations?

No. Resource locks primarily apply to Azure Resource Manager control-plane operations.

Does CanNotDelete allow modifications?

Yes.

Does ReadOnly prevent deletion?

Yes.

Should ReadOnly be used everywhere?

No. It can interfere with legitimate service operations.

Do locks replace Azure Policy?

No.

Do locks replace RBAC?

No.

Do locks replace backup and data-protection controls?

No.

Practice Exam Questions

Question 1

A company has a production Azure SQL database that must remain available for administrators to modify its configuration. However, the company wants to prevent the database from being accidentally deleted.

Which resource lock should you apply?

A. ReadOnly

B. CanNotDelete

C. Audit

D. Deny

Correct Answer: B

Explanation

A CanNotDelete lock allows authorized users to read and modify the resource while preventing deletion.

A ReadOnly lock would also prevent configuration modifications, making it too restrictive for this scenario.

Question 2

An administrator has the Owner role on an Azure resource group. The resource group has a CanNotDelete management lock.

The administrator attempts to delete the resource group.

What happens?

A. The resource group is deleted because Owner always overrides locks

B. The administrator is prompted to provide a second MFA credential

C. The deletion succeeds, but the resources inside the resource group remain

D. The deletion is blocked by the resource lock

Correct Answer: D

Explanation

A management lock can restrict operations even when the user has sufficient RBAC permissions.

The CanNotDelete lock prevents deletion of the locked scope.

An Owner role does not automatically bypass a resource lock.

Question 3

A security engineer wants to protect a critical production resource from both accidental modification and accidental deletion through Azure Resource Manager.

Which lock should be used?

A. ReadOnly

B. CanNotDelete

C. AuditIfNotExists

D. Deny

Correct Answer: A

Explanation

A ReadOnly lock prevents both modification and deletion of the resource through applicable control-plane operations while allowing it to be read.

CanNotDelete would still allow authorized users to modify the resource.

Question 4

An organization applies a CanNotDelete lock to a resource group containing several production resources.

What is the expected effect?

A. Only the resource group name becomes read-only

B. Users can no longer read any resources in the resource group

C. Resources within the resource group inherit the applicable deletion protection

D. Azure Policy is automatically assigned to every resource

Correct Answer: C

Explanation

Resource locks applied to a parent scope can be inherited by child resources.

A CanNotDelete lock on a resource group therefore protects resources within that scope from applicable deletion operations.

It doesn’t prevent reading, and it doesn’t automatically create an Azure Policy assignment.

Question 5

A security administrator applies a CanNotDelete lock to an Azure Storage account. A user with appropriate data-plane permissions subsequently deletes a blob stored in the account.

Why can this occur?

A. CanNotDelete locks only work for virtual machines

B. The lock protects Azure Resource Manager control-plane operations, not all data-plane operations

C. Storage accounts cannot have resource locks

D. Blob deletion always bypasses Azure RBAC

Correct Answer: B

Explanation

Resource locks primarily protect control-plane operations.

Blob operations are data-plane operations and are governed by data-plane authorization and data-protection mechanisms.

Therefore, a resource lock should not be considered a universal mechanism for protecting data stored inside the resource.

Question 6

A company has a resource group containing resources managed by Azure Backup. An administrator wants to apply a CanNotDelete lock to the resource group.

What should the administrator consider before applying the lock?

A. The lock automatically increases backup storage capacity

B. The lock converts all backup data to immutable storage

C. The lock has no effect on Azure Backup

D. The lock can interfere with backup lifecycle operations that require deletion of resources such as old restore points

Correct Answer: D

Explanation

A CanNotDelete lock can prevent Azure Backup from performing required cleanup operations.

Therefore, resource locks must be evaluated for operational side effects before being applied to resource groups managed by Azure services.

Question 7

A company has a CanNotDelete lock on a resource group. Administrators can still modify resources within the group, but they cannot delete them.

The security team now wants to prevent configuration changes as well.

What should they do?

A. Replace the lock with a ReadOnly lock

B. Add an Azure tag

C. Change the RBAC role to Reader for every resource

D. Enable Microsoft Sentinel

Correct Answer: A

Explanation

A ReadOnly lock prevents both modification and deletion through applicable control-plane operations.

A CanNotDelete lock only prevents deletion.

Question 8

A security engineer is designing governance controls for an Azure environment.

The organization has two requirements:

Prevent developers from deploying resources that violate required security configurations.
Prevent accidental deletion of a critical production database.

Which combination should the engineer consider?

A. Resource lock for both requirements

B. Microsoft Sentinel for both requirements

C. Azure Policy for the first requirement and a resource lock for the second

D. RBAC alone for both requirements

Correct Answer: C

Explanation

Azure Policy is appropriate for evaluating and enforcing resource configuration requirements.

A resource lock is appropriate for protecting a critical resource against deletion.

The two controls address different governance problems and can be used together.

Question 9

A resource has a CanNotDelete lock directly applied to it. Its parent resource group has a ReadOnly lock.

Which lock behavior applies to the resource?

A. CanNotDelete because the resource-level lock always overrides the parent

B. No lock because multiple locks cancel each other

C. ReadOnly because the most restrictive applicable lock takes precedence

D. The resource becomes unlocked because only subscription locks are inherited

Correct Answer: C

Explanation

Locks can be inherited from parent scopes, and when multiple locks apply, the most restrictive lock takes precedence.

ReadOnly is more restrictive than CanNotDelete because it prevents both modification and deletion.

Question 10

A security team wants to protect an Azure resource from accidental deletion. The team also wants administrators to be able to perform normal configuration changes.

Which solution best meets the requirement?

A. Apply a ReadOnly lock

B. Apply a CanNotDelete lock

C. Assign the Reader role to administrators

D. Apply an Azure Policy with a Deny effect to the resource

Correct Answer: B

Explanation

A CanNotDelete lock is specifically designed for this scenario.

It prevents deletion while allowing authorized users to modify the resource.

A ReadOnly lock would prevent the required configuration changes. The Reader role would also prevent administrators from making those changes. Azure Policy with Deny is primarily intended for enforcing configuration rules rather than simply protecting a particular resource from deletion.

Final SC-500 Takeaways

The most important concepts to remember for Implement resource locks are:

Resource locks protect Azure resources from accidental deletion or modification.
Locks can be applied at the subscription, resource group, or resource scope.
The two primary lock types are CanNotDelete and ReadOnly.
CanNotDelete allows reading and modification but prevents deletion.
ReadOnly allows reading but prevents modification and deletion.
Resource locks can restrict operations even when the user has sufficient RBAC permissions.
Locks applied at a parent scope can be inherited by child resources.
When multiple locks apply, the most restrictive lock takes precedence.
Resource locks primarily affect control-plane operations.
A resource lock does not automatically protect data-plane data such as blobs or database records.
Resource locks do not replace Azure RBAC.
Resource locks do not replace Azure Policy.
Use Azure Policy to govern resource configurations and use resource locks to protect resources from deletion or modification.
Use CanNotDelete when administrators must continue modifying the resource.
Use ReadOnly when both modification and deletion must be prevented.
Apply locks carefully because they can interfere with automated Azure service operations.
In particular, locks can affect services such as Azure Backup and other services that need to modify or delete resources.
A resource-group-level lock can prevent deletion of the entire resource group and its contents.
Managing locks requires appropriate authorization to manage Azure management locks.
Resource locks are one component of a broader defense-in-depth governance strategy.

The key exam rule to remember

CanNotDelete = Read + Modify, but NO Delete

ReadOnly = Read, but NO Modify and NO Delete

And perhaps the most important conceptual distinction:

Azure Policy governs what configurations are allowed; RBAC controls who is authorized to perform actions; resource locks prevent specified management operations on protected scopes.

Go to the SC-500 Exam Prep Hub main page

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

Manage Azure built-in role assignments (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
   --> Implement governance to enforce security and regulatory compliance
      --> Manage Azure built-in role assignments

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

Overview

Azure role-based access control (Azure RBAC) is the authorization system used to control access to Azure resources. It answers three fundamental questions:

Who can access a resource?
What can they do?
Where can they do it?

For the SC-500 exam, understanding how to select and manage Azure built-in roles is especially important because effective security depends on assigning the minimum permissions at the narrowest practical scope.

Azure provides many predefined, or built-in, roles for common administrative and workload scenarios. Examples include Reader, Contributor, Owner, Storage Blob Data Reader, Virtual Machine Contributor, Key Vault Secrets User, and many others.

A role assignment connects a security principal to a role at a particular scope.

The basic model is:

Security principal + Role definition + Scope = Role assignment

1. What Is Azure RBAC?

Azure RBAC provides fine-grained authorization for Azure resources.

For example, an organization might want:

Developers to manage resources in a development resource group.
Database administrators to manage Azure SQL resources.
Security administrators to manage security-related configurations.
Auditors to view resources but not modify them.
An application to read data from a specific storage account.
A managed identity to access secrets in a particular Key Vault.

Rather than giving everyone unrestricted access to an entire subscription, Azure RBAC allows permissions to be assigned according to job responsibilities.

This supports the principle of least privilege.

The three core components

Every Azure RBAC role assignment involves:

Security principal
Role definition
Scope

Security principal

The security principal is the identity receiving the permissions.

It can be:

User
Group
Service principal
Managed identity

Using groups instead of assigning roles individually to many users is generally preferred because it simplifies administration and makes access easier to review.

Role definition

The role definition specifies the permissions granted.

For example:

Reader allows viewing resources.
Contributor allows managing resources but does not allow assigning Azure RBAC roles.
Owner provides full resource management access and can assign Azure RBAC roles.

Scope

Scope determines where the permissions apply.

Azure supports four primary scope levels:

Management group
Subscription
Resource group
Individual resource

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

2. Role Definitions vs. Role Assignments

This distinction is frequently tested.

Role definition

A role definition describes what permissions a role contains.

For example, a role definition might specify that a principal can:

Read virtual machines
Start and stop virtual machines
Restart virtual machines

A role definition is essentially the permission set.

Role assignment

A role assignment applies that role to a particular principal at a particular scope.

For example:

Assign the Virtual Machine Contributor role to the VM-Admins group at the Production-RG resource-group scope.

The role is the Virtual Machine Contributor role definition.

The group is the security principal.

The resource group is the scope.

Together, they form the role assignment.

Exam tip

Think:

Role definition = What can be done?

Role assignment = Who can do it and where?

3. What Are Azure Built-in Roles?

Azure built-in roles are predefined role definitions provided by Microsoft.

They are designed for common administrative and workload scenarios.

Azure has built-in roles covering areas such as:

General resource management
Compute
Networking
Storage
Databases
Containers
AI and machine learning
Security
Monitoring
Identity
Management and governance
Hybrid and multicloud environments

Built-in roles should generally be considered before creating custom roles.

Examples include:

Built-in role	General purpose
Owner	Full access, including ability to assign Azure RBAC roles
Contributor	Manage Azure resources, but cannot assign Azure RBAC roles
Reader	View Azure resources without making changes
User Access Administrator	Manage user access to Azure resources
Role Based Access Control Administrator	Manage Azure RBAC role assignments
Virtual Machine Contributor	Manage virtual machines
Network Contributor	Manage networking resources
Storage Account Contributor	Manage storage account resources
Key Vault Reader	Read Key Vault metadata
Storage Blob Data Reader	Read blob data

The exact permissions of a role should always be evaluated rather than relying solely on the role’s name.

4. Owner vs. Contributor vs. Reader

These three roles are particularly important.

Owner

The Owner role grants full access to manage resources, including the ability to assign Azure RBAC roles.

This makes Owner a highly privileged role.

For example:

A user with Owner at the subscription scope can manage resources throughout that subscription and can grant Azure RBAC access to other principals.

Because of its power, the number of Owner assignments should be minimized.

Contributor

The Contributor role grants broad resource-management permissions.

A Contributor can generally create and manage resources but cannot assign Azure RBAC roles.

This distinction is extremely important.

For example:

A user who needs to create, modify, and delete virtual machines but should not be able to grant other users access may be a candidate for Contributor or a more narrowly scoped compute-specific role.

Common exam trap

Contributor ≠ Owner

Contributor does not have the permission to manage Azure RBAC role assignments.

Reader

The Reader role provides read-only access to Azure resources.

A Reader can inspect resources and their configurations but cannot modify them.

For example:

A security auditor needs to inspect the configuration of resources throughout a subscription but should not be able to make changes.

Reader may be appropriate, subject to whether additional permissions are needed for the specific data or security information being examined.

5. User Access Administrator

The User Access Administrator role is designed to manage access to Azure resources.

It can assign Azure RBAC roles.

This is different from Contributor.

Consider the following:

Role	Manage resources	Assign Azure RBAC roles
Reader	No	No
Contributor	Yes	No
Owner	Yes	Yes
User Access Administrator	Access-management focused	Yes

Therefore, if a user needs to manage access but doesn’t need broad resource-management permissions, User Access Administrator can be more appropriate than Owner.

6. Role Based Access Control Administrator

The Role Based Access Control Administrator role is another important role for the SC-500 exam.

It is designed specifically for managing user access to Azure resources through Azure RBAC.

It can:

Create role assignments
Delete role assignments
Manage Azure RBAC access

It provides a more focused access-management capability than Owner.

Microsoft specifically describes Role Based Access Control Administrator as a role designed for delegating role-assignment management.

Why this matters

Suppose an organization has a team responsible for administering Azure RBAC assignments.

Giving that team Owner permissions would provide much more power than necessary.

A security-conscious design could instead use Role Based Access Control Administrator, with an appropriately limited scope.

This better supports least privilege.

7. Built-in Roles Are Not the Same as Microsoft Entra Roles

Another important distinction is between:

Azure RBAC roles

and

Microsoft Entra roles

Azure RBAC controls access to Azure resources.

Microsoft Entra roles control administrative access to Microsoft Entra resources and directory functionality.

For example:

Azure RBAC can control who can manage an Azure Storage account.
Microsoft Entra roles can control directory administration activities.

Do not automatically assume that an Azure RBAC role controls Microsoft Entra directory administration.

They are related security concepts but are different authorization systems.

8. Understanding Scope

Scope is one of the most important concepts when assigning built-in roles.

The four Azure RBAC scopes are:

1. Management group

The broadest common scope.

Permissions can apply to subscriptions and resources contained within the management group hierarchy.

2. Subscription

Permissions apply throughout the subscription.

3. Resource group

Permissions apply to resources contained within that resource group.

4. Resource

Permissions apply to a specific resource.

The hierarchy is:

Management group → Subscription → Resource group → Resource

A role assignment at a parent scope is inherited by child scopes.

9. Why Scope Matters for Least Privilege

Consider an application that needs to read blobs from one storage account.

There are several possible ways to assign permissions.

Poor design

Assign a broad storage-related role at the subscription level.

The application may receive access to far more resources than necessary.

Better design

Assign the appropriate data-access role at the storage-account or even more narrowly applicable scope, when supported.

The principle is:

Use the smallest scope that satisfies the requirement.

Microsoft recommends limiting both the role and scope because doing so reduces the resources that could be affected if a security principal is compromised.

10. Role Inheritance

Suppose you assign:

Reader → Subscription A

The assignment is inherited by resources and resource groups beneath that subscription.

Similarly:

Contributor → Resource Group A

is inherited by resources inside Resource Group A.

This means that you don’t have to create individual role assignments for every resource.

However, inheritance can also create unexpected access if administrators aren’t careful.

Exam scenario

A user unexpectedly has Contributor access to a virtual machine.

You discover that the user does not have a Contributor assignment directly on the VM.

The user might have inherited Contributor permissions from:

The resource group
The subscription
A management group

Always investigate inherited assignments when troubleshooting access.

11. Choosing the Appropriate Built-in Role

A good process is:

Step 1: Identify the principal

Who needs access?

User?
Group?
Service principal?
Managed identity?

Step 2: Determine what the principal needs to do

For example:

View resources
Manage virtual machines
Manage networking
Read blob data
Manage Azure RBAC
Manage all resources

Step 3: Select the least-privileged suitable role

Prefer an appropriate built-in role over a broader role.

For example:

If someone only needs to read resources, don’t assign Contributor.

Step 4: Determine the narrowest practical scope

Ask:

What is the smallest scope at which this role can satisfy the requirement?

Step 5: Assign the role

The role can be assigned through:

Azure portal
Azure CLI
Azure PowerShell
Azure SDKs
REST APIs

12. Example: Developer Access

Suppose developers need to manage resources in a development resource group.

A possible design is:

Principal: Developers group

Role: Contributor

Scope: Development resource group

This gives developers broad resource-management capabilities within that resource group while avoiding unnecessary access to the rest of the subscription.

However, if developers only need to manage a particular resource type, a more narrowly scoped built-in role may be preferable.

13. Example: Security Auditor

Suppose a security auditor needs to inspect Azure resources but should not modify them.

A possible assignment is:

Principal: Security Auditors group

Role: Reader

Scope: Appropriate subscription or resource group

The scope should be limited to the resources the auditors actually need to review.

If they require specialized security information or data-plane access, additional permissions may be necessary.

14. Example: Application Access to Storage

Suppose an application uses a managed identity and needs to read blob data from one storage account.

A common mistake would be to grant a broad management role such as Contributor.

That is excessive because the application doesn’t need to manage the storage account.

Instead, consider a data-plane role such as:

Storage Blob Data Reader

at the narrowest suitable scope.

This illustrates an important security principle:

Management-plane access and data-plane access are different.

A role that lets someone manage a storage account does not necessarily mean they should be granted unrestricted access to the data stored within it.

15. Control Plane vs. Data Plane

Azure permissions can involve two broad areas.

Control plane

The control plane concerns management of Azure resources.

Examples include:

Creating a storage account
Changing resource configuration
Creating a virtual machine
Deleting a resource

Azure RBAC Actions and NotActions primarily describe control-plane operations.

Data plane

The data plane concerns access to the actual data contained within a service.

Examples include:

Reading blobs
Writing blobs
Reading Key Vault secrets
Accessing database data

Azure RBAC role definitions can also contain DataActions and NotDataActions for supported services.

Exam warning

Don’t assume:

“The user can manage the resource, therefore the user can access all of its data.”

That is not necessarily true.

16. Role Definition Permissions

A role definition can contain permission categories such as:

Actions
NotActions
DataActions
NotDataActions

Actions

Control-plane operations that the role permits.

NotActions

Control-plane operations excluded from the permissions represented by Actions.

DataActions

Data-plane operations that the role permits.

NotDataActions

Data-plane operations excluded from the permissions represented by DataActions.

For exam questions, pay attention to whether the requirement involves managing a resource or accessing the data within that resource.

17. When a Built-in Role Isn’t Enough

Azure provides many built-in roles, but sometimes none provides exactly the required permissions.

For example, suppose an organization needs a role that can:

Read specific resources
Perform several specific management operations
Not perform certain administrative operations
Be assigned only within particular organizational scopes

A custom Azure role may be appropriate.

However, the general strategy should be:

Start with built-in roles and create a custom role only when the built-in roles cannot satisfy the requirement with appropriate least privilege.

18. Built-in Roles Have Broad Availability

Built-in Azure roles are designed to be reusable across Azure environments.

Built-in role definitions have an AssignableScopes value of /, meaning they are available for assignment throughout Azure’s scope hierarchy.

This differs from custom roles, whose assignable scopes can be restricted to particular management groups, subscriptions, or resource groups.

19. Who Can Assign Azure RBAC Roles?

Having the ability to manage Azure resources does not automatically mean you can assign Azure RBAC roles.

For example:

Contributor

can manage resources but cannot assign Azure RBAC roles.

Permissions needed to create role assignments include:

Microsoft.Authorization/roleAssignments/write

Permissions needed to delete role assignments include:

Microsoft.Authorization/roleAssignments/delete

Roles such as:

Owner
User Access Administrator
Role Based Access Control Administrator

can provide the appropriate role-assignment management permissions, depending on scope and configuration.

20. Assign Roles to Groups When Practical

For organizations with multiple users performing the same job function, assigning roles to Microsoft Entra groups is generally preferable to creating separate assignments for every individual.

For example:

Security-Readers group → Reader → Security subscription scope

When users join or leave the security team, group membership can be managed without repeatedly changing Azure RBAC assignments.

This can improve:

Manageability
Consistency
Auditing
Access reviews
Least-privilege governance

Azure RBAC best practices recommend assigning roles to groups rather than individual users when practical.

21. Avoid Excessive Owner Assignments

Owner is one of the most powerful Azure RBAC roles.

An Owner can:

Manage Azure resources
Assign Azure RBAC roles

Because a compromised Owner account could have substantial impact, organizations should minimize the number of permanent Owner assignments.

Microsoft’s Azure RBAC guidance recommends limiting subscription Owner assignments.

For privileged administrative access, organizations should also consider Microsoft Entra Privileged Identity Management (PIM) where appropriate.

22. Azure RBAC and PIM

Azure RBAC answers:

What permissions does this principal have?

Microsoft Entra PIM helps answer:

When and under what conditions should a person receive privileged access?

For example, instead of permanently assigning an administrator a highly privileged role, an organization can use an eligible assignment and require activation when privileged work is needed.

This reduces standing privileged access.

Exam concept

Least privilege and just-in-time privileged access complement each other.

23. Azure RBAC vs. Azure Policy

These technologies serve different purposes.

Azure RBAC

Controls:

Who can perform which actions on Azure resources?

Azure Policy

Controls:

Which resource configurations are allowed, required, or evaluated?

For example:

RBAC requirement:

Only the Network Administrators group can modify virtual networks.

Azure Policy requirement:

Storage accounts must use a specified security configuration.

Do not use Azure RBAC as a replacement for Azure Policy.

Likewise, don’t use Azure Policy as a replacement for identity authorization.

24. Azure RBAC vs. Resource Locks

Resource locks and RBAC are also different.

Azure RBAC

Controls who can perform authorized operations.

Resource locks

Protect resources against certain management operations such as deletion or modification.

For example:

RBAC determines who is authorized to manage a resource.
A CanNotDelete lock can prevent deletion even when a principal otherwise has sufficient resource-management permissions.

Therefore, security governance may use both controls together.

25. Common SC-500 Exam Traps

Trap 1: Contributor can assign roles

False.

Contributor can manage resources but cannot assign Azure RBAC roles.

Trap 2: Owner is always the best administrator role

False.

Owner provides extensive permissions and should not be used when a more narrowly privileged role is sufficient.

Trap 3: Reader can modify resources

False.

Reader is intended for read-only access.

Trap 4: A resource-level assignment automatically gives subscription-wide access

False.

The assignment applies to the specified scope and does not automatically expand upward.

Trap 5: A subscription-level assignment applies only to the subscription object

False.

Permissions assigned at subscription scope are inherited by resources beneath the subscription.

Trap 6: Azure RBAC and Microsoft Entra roles are interchangeable

False.

They govern different areas of authorization.

Trap 7: Managing a storage account means automatically having data access

False.

Management-plane and data-plane permissions are distinct.

Trap 8: Custom roles should always be used for least privilege

False.

Start with built-in roles. Create custom roles when built-in roles don’t provide the appropriate permissions.

Trap 9: Contributor is always preferable to a specialized role

False.

A specialized role may provide significantly narrower permissions.

Trap 10: Role assignment and role definition mean the same thing

False.

The role definition describes permissions; the role assignment applies those permissions to a principal at a scope.

26. Exam-Focused Decision Guide

When faced with a scenario, use this mental checklist:

Requirement	Likely approach
View Azure resources	Reader
Manage Azure resources without managing RBAC	Contributor or a more specialized role
Full resource management plus RBAC management	Owner
Manage Azure RBAC assignments	Role Based Access Control Administrator or User Access Administrator, depending on requirements
Manage only a particular workload type	Specialized built-in role
Application needs blob read access	Storage Blob Data Reader or another appropriate data-plane role
Access should apply only to one resource	Resource-level scope
Access should apply to resources in one resource group	Resource-group scope
Access should span an entire subscription	Subscription scope
Access should span multiple subscriptions	Management-group scope
Built-in role is too broad or doesn’t meet requirements	Consider a custom role
Need to prevent insecure configurations	Azure Policy
Need to protect against accidental deletion	Resource lock
Need temporary privileged access	Consider PIM

27. Key Takeaways

For the SC-500 exam, remember these principles:

Azure RBAC controls access to Azure resources.
A role assignment consists of a principal, role definition, and scope.
Built-in roles provide predefined permissions for common scenarios.
Owner provides full resource management and can assign Azure RBAC roles.
Contributor can manage resources but cannot assign Azure RBAC roles.
Reader provides read-only resource access.
User Access Administrator and Role Based Access Control Administrator are designed for access-management scenarios.
Azure RBAC scopes are management group, subscription, resource group, and resource.
Permissions assigned at a parent scope are inherited by child resources.
Follow least privilege by selecting the narrowest appropriate role and scope.
Assign roles to groups when practical.
Distinguish control-plane permissions from data-plane permissions.
Use a specialized built-in role when it provides the required permissions more precisely than Contributor or Owner.
Consider custom roles only when built-in roles cannot meet the requirement appropriately.
Use PIM to reduce standing privileged access.
Don’t confuse Azure RBAC, Microsoft Entra roles, Azure Policy, and resource locks—they solve different security problems.

Practice Exam Questions

Question 1

A company has a security operations group that needs to view Azure resources throughout a subscription. The group must not be able to create, modify, or delete resources.

Which built-in Azure RBAC role should you assign?

A. Reader

B. Contributor

C. Owner

D. User Access Administrator

Correct Answer: A. Reader

Explanation:
Reader provides read-only access to Azure resources. Contributor and Owner provide substantially more permissions, while User Access Administrator is designed primarily for managing access rather than simply viewing resources.

Question 2

A developer needs to create, modify, and delete resources in a specific resource group. The developer must not be able to grant Azure RBAC permissions to other users.

Which role is the best choice if no more specialized built-in role meets the requirement?

A. Owner at the subscription scope

B. Contributor at the resource-group scope

C. User Access Administrator at the resource-group scope

D. Reader at the resource-group scope

Correct Answer: B. Contributor at the resource-group scope

Explanation:
Contributor can manage Azure resources but cannot assign Azure RBAC roles. Assigning it at the resource-group scope limits the developer’s access to that resource group rather than unnecessarily extending it to the subscription.

Question 3

An application uses a managed identity. It needs to read blob data from one Azure Storage account but does not need to modify the storage account configuration.

Which approach best follows least privilege?

A. Assign Owner at the subscription scope

B. Assign Contributor at the storage-account scope

C. Assign Reader at the resource-group scope

D. Assign an appropriate blob-data reader role at the narrowest suitable scope

Correct Answer: D. Assign an appropriate blob-data reader role at the narrowest suitable scope

Explanation:
The application needs access to blob data, not broad resource-management permissions. A data-plane role such as Storage Blob Data Reader is more appropriate than Owner, Contributor, or a general management-plane Reader assignment.

Question 4

A security administrator is responsible for creating and removing Azure RBAC role assignments but should not receive unnecessary permissions to manage Azure resources.

Which built-in role is specifically designed for Azure RBAC assignment management?

A. Contributor

B. Reader

C. Role Based Access Control Administrator

D. Storage Account Contributor

Correct Answer: C. Role Based Access Control Administrator

Explanation:
Role Based Access Control Administrator is specifically designed for managing access to Azure resources through Azure RBAC. Contributor cannot assign Azure RBAC roles.

Question 5

A user has the Reader role assigned at the subscription scope. What happens to that user’s Reader permissions for resources within that subscription?

A. The permissions are inherited by child resource groups and resources

B. The permissions apply only to the subscription object

C. The permissions apply only to resources created after the assignment

D. The permissions automatically become Contributor on child resources

Correct Answer: A. The permissions are inherited by child resource groups and resources

Explanation:
Azure RBAC uses hierarchical scopes. Role assignments at a parent scope are inherited by child scopes. A Reader assignment at subscription scope therefore provides Reader permissions to resources beneath that subscription.

Question 6

An organization wants developers to manage only virtual machines and related operations rather than all resource types in a resource group.

Which approach best follows the principle of least privilege?

A. Assign Owner to the developers

B. Assign Contributor at the subscription scope

C. Assign Reader at the VM scope

D. Use an appropriate VM-specific built-in role at the narrowest practical scope

Correct Answer: D. Use an appropriate VM-specific built-in role at the narrowest practical scope

Explanation:
A specialized built-in role can provide more focused permissions than Contributor or Owner. The assignment should also be scoped as narrowly as practical.

Question 7

An administrator has the Contributor role on a subscription. The administrator attempts to create an Azure RBAC role assignment and receives an authorization error.

Why?

A. Contributor cannot assign Azure RBAC roles

B. Contributor cannot manage resources at subscription scope

C. Contributor is a Microsoft Entra role rather than an Azure RBAC role

D. Contributor provides only read access

Correct Answer: A. Contributor cannot assign Azure RBAC roles

Explanation:
Contributor provides broad resource-management permissions but does not include permission to assign Azure RBAC roles. Role-assignment creation requires the appropriate Microsoft.Authorization/roleAssignments/write permission.

Question 8

A company has five subscriptions under a management group. A security team needs the same read-only Azure resource access across all five subscriptions.

Which scope could provide the access without creating separate Reader assignments for every subscription?

A. Individual resource

B. Resource group

C. Management group

D. Individual virtual machine

Correct Answer: C. Management group

Explanation:
A management group is above the subscription level in the Azure hierarchy. A Reader assignment at the appropriate management-group scope can be inherited by subscriptions and resources beneath it.

Question 9

A company needs to grant a team permissions that are not adequately provided by any existing built-in role. The team needs only a specific subset of management operations.

What should the administrator consider?

A. Assign Owner instead

B. Create an appropriate custom Azure role

C. Assign Contributor and rely on Azure Policy to remove permissions

D. Assign User Access Administrator

Correct Answer: B. Create an appropriate custom Azure role

Explanation:
Built-in roles should generally be preferred, but when they cannot provide the required permissions at the appropriate level, a custom role can be created. The custom role should contain only the permissions required.

Question 10

A company wants to minimize standing privileged access for administrators who occasionally need highly privileged Azure RBAC permissions.

Which solution best addresses this requirement?

A. Assign permanent Owner access to every administrator

B. Replace all administrators with Reader assignments

C. Use Microsoft Entra Privileged Identity Management to provide eligible or just-in-time privileged access

D. Assign Contributor at the management-group scope

Correct Answer: C. Use Microsoft Entra Privileged Identity Management to provide eligible or just-in-time privileged access

Explanation:
PIM can reduce standing privileged access by allowing privileged roles to be activated when needed rather than permanently assigning highly privileged access. This complements least-privilege RBAC design.

Final Thought

An important exam habit is to ask: “What is the minimum role, for the minimum scope, that satisfies the requirement?”

Go to the SC-500 Exam Prep Hub main page

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

Manage custom roles, including Azure roles and Microsoft Entra roles (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
   --> Implement governance to enforce security and regulatory compliance
      --> Manage custom roles, including Azure roles and Microsoft Entra roles

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

Overview

Role-based access control (RBAC) is a fundamental component of cloud security. Rather than granting users unrestricted administrative privileges, RBAC allows an organization to assign only the permissions required to perform a particular job.

Azure and Microsoft Entra ID both support custom roles, but they are used for different purposes.

The distinction is critical for the SC-500 exam:

Azure custom roles control access to Azure resources.

Microsoft Entra custom roles control administrative access to Microsoft Entra resources and capabilities.

Although both systems use concepts such as role definitions, permissions, and role assignments, their permission models and scopes are different. Azure role permissions cannot simply be used in Microsoft Entra custom roles, and Microsoft Entra role permissions cannot be used in Azure custom roles.

1. What Is a Custom Role?

A custom role is a role that an organization creates when the available built-in roles do not provide the appropriate permissions.

The goal is normally to achieve least privilege.

For example, suppose an administrator needs to:

View storage accounts
Start and stop virtual machines
Read certain networking configurations

but should not be able to:

Delete resources
Assign RBAC roles
Modify unrelated resource types

A broad built-in role such as Owner or Contributor might provide excessive permissions.

A custom role can be created containing only the required permissions.

General principle

Use a built-in role when it appropriately meets the requirement. Use a custom role when the built-in roles cannot provide the required permissions with appropriate precision.

This avoids unnecessary custom-role proliferation and reduces administrative complexity.

2. Two Different Custom-Role Systems

For SC-500, keep these two systems clearly separated:

	Azure custom role	Microsoft Entra custom role
Primary purpose	Manage Azure resources	Manage Microsoft Entra resources
Authorization system	Azure RBAC	Microsoft Entra RBAC
Examples of resources	VMs, storage, networking, databases	Users, groups, applications, enterprise applications
Permission model	Azure resource-provider operations	Microsoft Entra resource actions
Assignment scopes	Azure management-group, subscription, resource-group/resource scopes	Directory or supported resource-specific scopes
Created/managed through	Azure portal, CLI, PowerShell, REST API	Microsoft Entra admin center, Microsoft Graph PowerShell/API
Can permissions be mixed?	No	No

The two systems are conceptually similar but technically separate.

3. Azure Custom Roles

Azure custom roles are part of Azure role-based access control (Azure RBAC).

They are used to manage access to Azure resources.

Examples include permissions involving:

Virtual machines
Storage accounts
Azure SQL
Virtual networks
Key Vault
Azure Kubernetes Service
Azure Container Registry
Other Azure resources

An Azure custom role is a collection of Azure resource permissions.

For example, a custom role might allow a support team to:

Read virtual machines
Restart virtual machines
Read diagnostics

while excluding:

Delete virtual machines
Modify networking
Assign RBAC roles

4. Azure Custom Role Definitions

An Azure role definition describes the permissions available in a role.

A custom role definition can contain properties such as:

Name
Description
Permissions
Assignable scopes
Role ID

The permissions section can include:

Actions
NotActions
DataActions
NotDataActions

These concepts are important for understanding how Azure custom roles are constructed.

5. Actions

Actions specify the Azure control-plane operations that the role can perform.

For example, a custom role might contain permissions that allow the principal to perform operations involving:

Reading resources
Creating resources
Updating resources
Deleting resources

The exact permissions are represented using Azure resource-provider operation names.

A permission might look conceptually like:

Microsoft.Compute/virtualMachines/read

This represents a control-plane operation involving virtual machines.

6. NotActions

NotActions specifies control-plane operations that are excluded from the permissions represented by Actions.

For example, a role could broadly allow a set of operations while excluding a particular operation.

However, be careful when interpreting NotActions.

It does not mean:

“Explicitly deny this operation under all circumstances.”

Instead, NotActions subtracts operations from the permissions granted through Actions in that role definition.

A principal might still obtain the excluded permission through another role assignment.

Exam concept

Azure RBAC permissions are additive across role assignments.

Therefore, creating a custom role with NotActions does not guarantee that the principal can never perform the excluded operation.

7. DataActions and NotDataActions

Azure also distinguishes between management-plane operations and operations against data.

`DataActions`

Specify data-plane operations that the role can perform.

Examples include permissions to:

Read blob data
Write blob data
Read other supported service data

`NotDataActions`

Exclude specified data-plane operations from the permissions granted through DataActions.

This distinction is especially important for Azure Storage.

For example:

A role that can manage a storage account does not automatically mean that the principal has permission to read the blobs stored in the account.

The custom role may need appropriate data-plane permissions.

8. Example Azure Custom Role

Imagine a help-desk team needs to support Azure virtual machines.

Requirements:

View VMs
Restart VMs
Start VMs
Stop VMs
Cannot delete VMs
Cannot modify networking
Cannot assign RBAC roles

A broad Contributor role could provide more permissions than necessary.

Instead, a custom role could be created containing only the required VM operations.

Conceptually:

Support VM Operator

Permissions:

VM read
VM start
VM stop
VM restart

Excluded:

VM delete
RBAC role assignment
unrelated resource-management operations

This is a classic least-privilege scenario.

9. Azure Custom Role AssignableScopes

One of the most important properties of an Azure custom role is:

AssignableScopes

This specifies where the custom role definition can be assigned.

A custom role can have assignable scopes at:

Management group
Subscription
Resource group

The role can subsequently be assigned at an appropriate narrower scope within those boundaries, including a resource scope where supported.

For example, a custom role could have:

/subscriptions/00000000-0000-0000-0000-000000000000

as an assignable scope.

The role would then be available for assignment within that subscription and its child scopes.

10. AssignableScopes vs. Assignment Scope

This is an important exam distinction.

AssignableScopes

Determines where the custom role definition is available to be assigned.

Role-assignment scope

Determines where the permissions actually apply to the principal.

For example:

A custom role might have an assignable scope of:

Subscription A

But the role could be assigned to a user at:

Resource Group A

The custom role is available within Subscription A, while the user’s actual permissions apply only to Resource Group A.

Exam rule

AssignableScopes limits where a custom role can be assigned; the role assignment’s scope determines where the assigned permissions apply.

11. Azure Custom Roles and Least Privilege

Custom roles can provide more precise access than broad built-in roles.

Consider three options:

Option 1 — Owner

Very broad permissions, including role assignment.

Option 2 — Contributor

Broad resource-management permissions but no RBAC role-assignment capability.

Option 3 — Custom role

Only the operations required for the user’s job.

If Option 3 satisfies the business requirement, it can provide a stronger least-privilege design.

However, custom roles should not be created simply because customization is possible.

Before creating one:

Identify the exact required operations.
Review existing built-in roles.
Determine whether an existing built-in role is sufficient.
Create a custom role only if necessary.
Limit its permissions.
Limit its assignable scopes.
Assign it at the narrowest practical scope.

12. Who Can Create an Azure Custom Role?

Creating or updating an Azure custom role requires appropriate authorization.

The key Azure permission is:

Microsoft.Authorization/roleDefinitions/write

Among the standard built-in roles, Owner and User Access Administrator include this permission.

This is different from simply assigning an existing role.

Important distinction

A person may have permission to assign an existing role without necessarily having permission to create or modify role definitions.

This distinction can appear in SC-500 scenario questions.

13. Managing Azure Custom Roles

Azure custom roles can be created and managed using:

Azure portal
Azure CLI
Azure PowerShell
Azure REST API

For example, administrators can create a custom role through the Azure portal by defining:

Role name
Description
Permissions
Assignable scopes

Custom roles are stored in the Microsoft Entra directory associated with the Azure environment and can be shared across subscriptions that trust the same directory.

14. Azure Custom Role Limits

Custom roles should be managed carefully.

Azure supports a maximum of 5,000 custom roles per Microsoft Entra tenant under the standard Azure limit.

This is another reason to avoid creating unnecessary custom roles.

A poorly governed environment could end up with:

Duplicate roles
Nearly identical roles
Roles that are no longer needed
Roles containing excessive permissions

A good role-governance process should include periodic review and cleanup.

15. Microsoft Entra Custom Roles

Microsoft Entra ID has its own RBAC system.

Microsoft Entra custom roles are used to provide customized administrative permissions for Microsoft Entra resources and capabilities.

Examples of areas that can be managed through supported Microsoft Entra permissions include:

Users
Groups
Applications
Enterprise applications
Devices
Consent-related operations

Microsoft Entra custom roles are created from a predefined set of permissions that are enabled for custom use.

16. Microsoft Entra Custom Role Permissions

Microsoft Entra custom roles use permissions expressed as Microsoft Entra resource actions.

For example, a custom role could contain permissions such as:

microsoft.directory/applications/basic/update

or:

microsoft.directory/applications/credentials/update

These permissions are different from Azure resource-provider permissions.

Critical exam distinction

Do not confuse:

Microsoft.Compute/...

with:

microsoft.directory/...

The first represents Azure resource-management permissions.

The second represents Microsoft Entra directory permissions.

17. Microsoft Entra Custom Roles Use a Defined Permission Set

You cannot simply create an arbitrary Microsoft Entra permission.

Microsoft Entra custom roles can include permissions that Microsoft makes available for custom use.

This provides granular control while keeping the permission model within supported Microsoft Entra capabilities.

For example, an organization could create a custom role allowing an application-support team to modify selected application properties without granting them broad application-administrator privileges.

18. Example: Microsoft Entra Custom Role

Suppose an organization has an application support team.

The team needs to:

Read application registrations
Update basic application properties
Update application credentials

The team should not receive broad directory administration privileges.

A custom Microsoft Entra role could be created containing only the required application-management permissions.

This is a classic least-privilege scenario.

19. Microsoft Entra Custom Role Scopes

Microsoft Entra custom roles use scopes that differ from Azure RBAC scopes.

Microsoft Entra custom roles can be assigned at:

Directory level
Supported app-registration resource scope

The exact scope options depend on the Microsoft Entra resource and permission being managed.

Exam warning

Do not automatically apply the Azure RBAC hierarchy:

Management group → subscription → resource group → resource

to Microsoft Entra custom roles.

That hierarchy belongs to Azure resource authorization.

20. Creating Microsoft Entra Custom Roles

Microsoft Entra custom roles can be created using:

Microsoft Entra admin center
Microsoft Graph PowerShell
Microsoft Graph API

In the Microsoft Entra admin center, administrators can navigate to:

Microsoft Entra ID → Roles & admins → New custom role

They then specify:

Role name
Description
Permissions

and create the role.

The role can subsequently be assigned to appropriate users or groups.

21. Microsoft Entra Custom Role Prerequisites

Creating Microsoft Entra custom roles requires appropriate privileged administration permissions.

The current prerequisites include:

Microsoft Entra ID P1 or P2
Privileged Role Administrator

when creating the role through the documented administrative interfaces.

This is an important distinction from Azure custom-role creation.

Remember

Azure custom role creation

→ Azure authorization permissions such as Microsoft.Authorization/roleDefinitions/write

Microsoft Entra custom role creation

→ Appropriate Microsoft Entra administrative permissions, such as Privileged Role Administrator

22. Microsoft Entra Custom Roles Cannot Use Azure Permissions

Suppose an administrator wants to create a Microsoft Entra custom role.

They cannot add an Azure resource-provider permission such as:

Microsoft.Compute/virtualMachines/read

to the Microsoft Entra custom role.

Likewise, an Azure custom role cannot use a Microsoft Entra permission such as:

microsoft.directory/applications/basic/update

The permission models are separate.

Exam rule

Azure RBAC permissions belong to Azure RBAC roles. Microsoft Entra permissions belong to Microsoft Entra roles.

23. Azure Roles vs. Microsoft Entra Roles

This distinction deserves special attention.

Azure role

Controls access to Azure resources.

Examples:

Virtual machines
Storage accounts
Virtual networks
Azure SQL
Key Vault

Azure roles are implemented through Azure RBAC.

Microsoft Entra role

Controls administrative access to Microsoft Entra functionality and resources.

Examples:

Users
Groups
Applications
Enterprise applications
Directory configuration

Microsoft Entra roles are implemented through Microsoft Entra RBAC.

They are separate authorization systems.

24. Application Roles Are Yet Another Concept

SC-500 questions can become confusing because there is another RBAC concept:

Application roles

Application roles are defined by an application and can be used to authorize users or applications within that application.

They are not the same as:

Azure RBAC roles
Microsoft Entra administrative roles

Therefore:

Application RBAC ≠ Azure RBAC ≠ Microsoft Entra RBAC

Microsoft explicitly distinguishes application-specific RBAC from Azure RBAC and Microsoft Entra RBAC.

25. Role Definition vs. Role Assignment

This concept applies to both Azure RBAC and Microsoft Entra RBAC, although the implementations differ.

Role definition

Defines:

What permissions does the role contain?

Role assignment

Defines:

Who receives the role and at what supported scope?

For Azure RBAC:

Principal + Azure role definition + scope = role assignment

For Microsoft Entra RBAC, a role definition containing Microsoft Entra permissions is assigned to a principal at an applicable directory/resource scope.

26. Assign Custom Roles to Groups When Practical

Custom roles can be assigned to appropriate security principals.

Depending on the authorization system and supported scenario, this can include:

Users
Groups
Service principals
Managed identities

For organizational administration, assigning permissions to groups is often preferable to individually assigning the same role to many users.

For example:

Application Support Team

→ Custom Microsoft Entra Application Support role

This simplifies:

Access management
Auditing
Access reviews
User onboarding
User offboarding

27. Combining Multiple Roles

A user can receive multiple role assignments.

Azure RBAC permissions are effectively additive.

For example, suppose a user has:

Custom VM Operator

and:

Reader

The user’s effective permissions can include permissions from both assignments.

This has an important security consequence.

Creating a custom role with fewer permissions does not necessarily restrict a user if that user already has another role that provides broader permissions.

Example

A custom role excludes:

Microsoft.Compute/virtualMachines/delete

But the same user also has Contributor.

The user could still have VM deletion capability through Contributor.

Exam lesson

Evaluate effective permissions, not just one role definition.

28. Don’t Use NotActions as a Security Deny

This is a common conceptual trap.

Suppose a custom role contains:

Actions: *

and:

NotActions: Microsoft.Compute/virtualMachines/delete

It may appear that the user is explicitly denied the ability to delete VMs.

That’s not necessarily true.

NotActions only removes that operation from the permissions granted by that role definition.

If another role assignment grants VM deletion, the user may still delete VMs.

For an actual deny mechanism, Azure has separate authorization concepts such as deny assignments in supported scenarios.

Exam takeaway

NotActions is not the same as an explicit deny rule.

29. Custom Roles and Least Privilege

The purpose of a custom role should be to make access more precise, not simply to reproduce an overly powerful built-in role under a different name.

A good custom role should:

Include only necessary permissions.
Avoid unnecessary wildcards.
Use narrow assignable scopes where appropriate.
Be assigned at the narrowest practical scope.
Be assigned only to appropriate principals.
Be reviewed periodically.
Be removed when no longer required.

30. Be Careful with Wildcards

Azure custom roles support wildcard permissions.

For example:

Microsoft.Storage/*

could provide a large collection of storage-related operations.

Similarly:

*

can provide extremely broad permissions.

Wildcards can make custom roles easier to create but can undermine least privilege.

Best practice

Use specific operations when practical rather than granting a broad wildcard.

For example, if an administrator only needs to restart virtual machines, don’t automatically give that administrator every Compute operation.

31. Privileged Custom Roles

A custom role can itself become a highly privileged role.

For example, a custom Azure role that includes:

Microsoft.Authorization/roleAssignments/write

can grant the ability to create Azure RBAC assignments.

Likewise, permissions to create or modify role definitions are privileged capabilities.

Therefore, custom-role designers must evaluate not only the number of permissions but also the sensitivity of those permissions.

A small role containing a highly privileged authorization operation can be more dangerous than a larger role containing ordinary read operations.

32. Custom Roles and Privileged Identity Management

Microsoft Entra Privileged Identity Management (PIM) can be used with supported privileged role assignments to reduce standing administrative access.

Instead of giving an administrator permanent access, an organization can use an eligible assignment and require activation when the administrator needs to perform privileged work.

Possible controls include:

Time-limited activation
Approval
Multifactor authentication
Justification
Access reviews

This supports a broader security strategy:

Least privilege + just-in-time access + strong authentication

33. A Practical Process for Creating a Custom Azure Role

Use this process:

Step 1 — Identify the business requirement

Determine exactly what the person or workload needs to accomplish.

Step 2 — Identify the resource types

Determine which Azure resources are involved.

Step 3 — Review built-in roles

Check whether an existing built-in role already satisfies the requirement.

Step 4 — Identify exact operations

Determine the required control-plane and, if applicable, data-plane operations.

Step 5 — Build the custom role

Add only the necessary permissions.

Step 6 — Define assignable scopes

Make the role available only where it needs to be used.

Step 7 — Assign the role

Assign it to the appropriate principal at the narrowest practical scope.

Step 8 — Test effective access

Verify that required operations work and unnecessary permissions are not present.

Step 9 — Review periodically

Remove obsolete roles and permissions.

34. A Practical Process for Creating a Microsoft Entra Custom Role

Use a similar but separate process:

Step 1 — Identify the Microsoft Entra administrative task

For example:

Manage selected application-registration properties.

Step 2 — Review built-in Microsoft Entra roles

Determine whether a built-in role is sufficient.

Step 3 — Identify supported custom-use permissions

Select only the required Microsoft Entra resource actions.

Step 4 — Create the custom role

Define the role name, description, and permissions.

Step 5 — Select the appropriate scope

Use a supported directory or resource-specific scope.

Step 6 — Assign the role

Assign it to the appropriate user or group.

Step 7 — Validate effective permissions

Confirm that the administrator can perform the required operations but does not have unnecessary administrative access.

35. Common SC-500 Exam Traps

Trap 1: Azure custom roles manage Microsoft Entra users

False.

Azure custom roles manage Azure resources.

Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities.

Trap 2: Microsoft Entra custom roles can contain Azure permissions

False.

The permission models are separate.

Trap 3: Contributor can create custom Azure roles

Generally false.

Contributor does not include the permission required to create or update Azure role definitions.

Trap 4: Owner is required to assign an existing Azure custom role

Not necessarily.

The relevant requirement is permission to create the role assignment. Roles such as Owner, User Access Administrator, and Role Based Access Control Administrator can provide role-assignment capabilities in appropriate scopes.

Creating the custom role definition itself is a separate privilege.

Trap 5: NotActions explicitly denies an operation

False.

It removes operations from the permissions granted by that particular role definition.

Another role assignment could still grant the operation.

Trap 6: AssignableScopes determines where the permissions apply

Not exactly.

AssignableScopes determines where the custom role is available for assignment.

The role assignment scope determines where the permissions actually apply.

Trap 7: Custom roles automatically provide least privilege

False.

A poorly designed custom role can be overly permissive.

Least privilege depends on the permissions selected, scope, and effective role assignments.

Trap 8: A custom role replaces all built-in roles

False.

Built-in roles should generally be preferred when they appropriately satisfy the requirement.

Trap 9: DataActions are the same as Actions

False.

Actions generally represent control-plane operations, while DataActions represent data-plane operations.

Trap 10: Azure RBAC, Microsoft Entra RBAC, and application RBAC are the same

False.

They are separate authorization models serving different purposes.

36. SC-500 Comparison: Azure vs. Microsoft Entra Custom Roles

Characteristic	Azure Custom Role	Microsoft Entra Custom Role
Authorization system	Azure RBAC	Microsoft Entra RBAC
Primary target	Azure resources	Microsoft Entra resources/capabilities
Permission format	Azure resource-provider operations	Microsoft Entra resource actions
Control-plane/data-plane distinction	Yes, including Actions/DataActions where supported	Different Microsoft Entra permission model
Typical resources	VM, Storage, SQL, Network	Users, groups, applications, enterprise applications
Azure management-group scope	Yes	No
Azure subscription scope	Yes	No
Azure resource-group scope	Yes	No
Microsoft Entra directory scope	No	Yes
App registration resource scope	No	Supported
Creation tools	Azure portal, CLI, PowerShell, REST	Entra admin center, Graph PowerShell, Graph API
Typical creation privilege	Azure authorization permission such as `roleDefinitions/write`	Privileged Role Administrator
Permissions interchangeable?	No	No

37. Exam Scenario Strategy

When a question asks you to design a custom role, work through these questions:

Question 1: What is being secured?

If it is:

VM
Storage
SQL
Network
Key Vault

think:

Azure RBAC

If it is:

User
Group
Application
Enterprise application
Directory administration

think:

Microsoft Entra RBAC

Question 2: Is there already a suitable built-in role?

If yes, use the built-in role unless there is a compelling reason not to.

If no, consider a custom role.

Question 3: What exact permissions are required?

Don’t simply choose broad permissions because they are convenient.

Question 4: What is the narrowest scope?

Use the smallest practical scope.

Question 5: Does the role include privileged authorization permissions?

Be particularly careful with permissions that allow:

Assigning roles
Creating roles
Modifying roles
Deleting roles
Managing other privileged security controls

38. Key Takeaways

For the SC-500 exam, remember:

Azure custom roles are part of Azure RBAC.
Microsoft Entra custom roles are part of Microsoft Entra RBAC.
The two permission models are separate.
Azure custom roles manage Azure resources.
Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities.
A role definition describes permissions.
A role assignment grants a role to a principal at a scope.
Azure custom roles can contain Actions, NotActions, DataActions, and NotDataActions.
Actions generally represent control-plane operations.
DataActions represent data-plane operations where supported.
NotActions is not an explicit deny mechanism.
Azure custom-role AssignableScopes controls where the role can be assigned.
The role assignment’s scope determines where the assigned permissions apply.
Built-in roles should generally be used when they meet the requirement.
Custom roles are appropriate when built-in roles cannot provide the required level of precision.
Avoid unnecessary wildcard permissions.
Evaluate effective permissions across all role assignments, not just one role.
Privileged role-management permissions require particular caution.
PIM can help reduce standing privileged access.
Azure RBAC ≠ Microsoft Entra RBAC ≠ application RBAC.

Practice Exam Questions

Question 1

An organization needs to create a role that allows support personnel to restart Azure virtual machines but does not allow them to delete VMs or manage networking resources. No existing built-in role provides exactly the required permissions.

What should the security engineer do?

A. Assign Owner at the resource-group scope

B. Create an Azure custom role containing only the required VM permissions

C. Assign Contributor at the VM scope

D. Create a Microsoft Entra custom role

Correct Answer: B. Create an Azure custom role containing only the required VM permissions

Explanation:
The requirement involves Azure virtual machines, so Azure RBAC is the appropriate authorization system. Because the available built-in roles do not provide the required level of precision, an Azure custom role is appropriate. The custom role should contain only the necessary VM operations.

Question 2

An administrator is creating a custom role for Azure resources. The role should be available for assignment within only one subscription.

Which property should the administrator configure?

A. NotActions

B. DataActions

C. AssignableScopes

D. Role assignment name

Correct Answer: C. AssignableScopes

Explanation:
AssignableScopes specifies the scopes where an Azure custom role definition can be assigned. It should not be confused with the scope of an individual role assignment, which determines where the permissions apply to the principal.

Question 3

A user has a custom Azure role containing NotActions that excludes deletion of virtual machines. The user also has the Contributor role at the resource-group scope.

What should the security engineer conclude?

A. The user can never delete virtual machines

B. The custom role overrides Contributor

C. Contributor becomes read-only for the user

D. The user may still be able to delete virtual machines through Contributor

Correct Answer: D. The user may still be able to delete virtual machines through Contributor

Explanation:
NotActions removes an operation from the permissions granted by that particular role definition. It does not create a universal deny. If another role assignment grants the permission, the user can still receive it through that other role.

Question 4

An organization needs to create a custom role that allows an application-support team to update selected properties of Microsoft Entra application registrations. The team should not receive broad directory-administrator permissions.

Which solution should be used?

A. Microsoft Entra custom role

B. Azure Contributor role

C. Azure custom role

D. Azure Owner role

Correct Answer: A. Microsoft Entra custom role

Explanation:
Application registrations are Microsoft Entra resources. A Microsoft Entra custom role can contain the specific supported Microsoft Entra permissions required for the application-support scenario without granting broad directory administration.

Question 5

Which statement correctly distinguishes Azure custom roles from Microsoft Entra custom roles?

A. Azure custom roles manage Microsoft Entra users, while Microsoft Entra custom roles manage virtual machines

B. Azure custom roles and Microsoft Entra custom roles use exactly the same permission model

C. Azure custom roles manage Azure resources, while Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities

D. Microsoft Entra custom roles can contain Azure resource-provider permissions

Correct Answer: C. Azure custom roles manage Azure resources, while Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities

Explanation:
Azure RBAC and Microsoft Entra RBAC are separate authorization systems. Azure custom roles are used for Azure resources, while Microsoft Entra custom roles are used for supported Microsoft Entra administration scenarios.

Question 6

An Azure custom role needs to allow a service principal to read blob data from a storage account. Which type of permission is relevant to granting access to the actual blob data?

A. NotActions

B. DataActions

C. AssignableScopes

D. RoleDefinitions/write

Correct Answer: B. DataActions

Explanation:
DataActions represent data-plane operations for supported Azure services. Reading blob data is a data-plane operation and therefore requires an appropriate data-access permission rather than merely a management-plane Action.

Question 7

A security engineer wants to create an Azure custom role. Which Azure permission is directly associated with creating or updating an Azure custom role definition?

A. Microsoft.Authorization/roleDefinitions/write

B. Microsoft.Compute/virtualMachines/read

C. Microsoft.Authorization/roleAssignments/read

D. Microsoft.Storage/storageAccounts/read

Correct Answer: A. Microsoft.Authorization/roleDefinitions/write

Explanation:
Microsoft.Authorization/roleDefinitions/write is the authorization permission associated with creating or updating Azure role definitions. This is distinct from assigning an already existing role to a principal.

Question 8

A security administrator needs to create a Microsoft Entra custom role through the Microsoft Entra administrative experience.

Which role is associated with the required administrative privilege for creating the custom role?

A. Global Reader

B. Security Reader

C. Privileged Role Administrator

D. Azure Contributor

Correct Answer: C. Privileged Role Administrator

Explanation:
Creating Microsoft Entra custom roles requires appropriate Microsoft Entra administrative privileges. The documented prerequisite includes the Privileged Role Administrator role, along with the appropriate Microsoft Entra licensing.

Question 9

An Azure administrator creates a custom role with the following design:

Read virtual machines
Start virtual machines
Stop virtual machines
Delete virtual machines

The administrator assigns the role to a support group that only needs to start and stop VMs.

What should the security engineer recommend?

A. Keep the role because custom roles should contain broad permissions

B. Replace the role with Owner

C. Add more permissions so the role is easier to reuse

D. Remove the unnecessary delete permission to better follow least privilege

Correct Answer: D. Remove the unnecessary delete permission to better follow least privilege

Explanation:
The group does not need VM deletion capability. A custom role should contain only the permissions required for the business task. Removing unnecessary privileged operations reduces the potential impact of account compromise or misuse.

Question 10

A security engineer is deciding whether to create a custom Azure role or a custom Microsoft Entra role. The requirement is to allow administrators to manage selected users and groups in Microsoft Entra ID.

Which solution is appropriate?

A. Azure custom role

B. Microsoft Entra custom role

C. Azure Storage Blob Data Reader

D. Azure Contributor

Correct Answer: B. Microsoft Entra custom role

Explanation:
The requirement concerns management of Microsoft Entra users and groups rather than Azure resources. Therefore, the appropriate authorization system is Microsoft Entra RBAC, and a Microsoft Entra custom role should be considered if an existing built-in role does not provide the required permissions.

One particularly important distinction to memorize for this section is:

Azure custom role → Azure resources → Azure RBAC

Microsoft Entra custom role → Microsoft Entra resources/administration → Microsoft Entra RBAC

And for Azure custom roles, remember the three concepts that are easy to confuse on the exam: Actions/DataActions define permissions, AssignableScopes controls where the custom role can be assigned, and the role-assignment scope controls where the granted permissions actually apply.

Go to the SC-500 Exam Prep Hub main page

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

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:

Management group
Subscription
Resource group
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:

Role	General purpose
Reader	View resources without managing them
Contributor	Manage Azure resources but cannot normally assign Azure RBAC roles
Owner	Full resource-management access, including managing Azure RBAC access
User Access Administrator	Manage user access to Azure resources
Role Based Access Control Administrator	Manage Azure role assignments with fewer permissions than User Access Administrator
Virtual Machine Contributor	Manage virtual machines
Storage Account Contributor	Manage storage accounts
Network Contributor	Manage 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:

Role	Scope	Potential concern
Reader	Resource	Low
Reader	Subscription	May be appropriate
Contributor	Resource	Depends on requirement
Contributor	Resource group	Potentially broad
Contributor	Subscription	Frequently requires scrutiny
Owner	Resource	Highly privileged
Owner	Subscription	Highly privileged
User Access Administrator	Subscription	Highly 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:

Open the subscription, resource group, or resource.
Select Access control (IAM).
Select Role assignments.
Review the principals.
Review their roles.
Review the assignment scope.
Determine whether the assignment is direct or inherited.
Identify unnecessary or excessive permissions.
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:

Requirement	Preferred approach
User no longer needs access	Remove role assignment
User needs less powerful permissions	Replace with narrower role
User needs access to fewer resources	Reduce scope
Built-in role is too broad	Consider custom role
Privileged access is occasional	Consider PIM
Access comes through unnecessary group	Remove group membership
Assignment appears unexpectedly	Check inherited/group-based access
Application has excessive permissions	Right-size service principal/managed identity
Need regular confirmation of privileged access	Access reviews
Need to manage role assignments with fewer privileges	RBAC Administrator
Need to manage resources but not RBAC assignments	Contributor
Need full resource access including RBAC	Owner

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:

Reduce the role.
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

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

Implement and configure security controls by using infrastructure as code (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 and configure security controls by using infrastructure as code

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

Infrastructure as code (IaC) is the practice of defining and deploying infrastructure through machine-readable configuration files rather than manually creating and configuring resources through a portal.

For the SC-500 exam, IaC is important because security controls should be:

Consistent across environments
Repeatable and auditable
Enforced before deployment
Version-controlled
Reviewed through an approval process
Resistant to configuration drift
Integrated into the software development lifecycle

Common IaC technologies include:

Azure Resource Manager templates
Bicep
Terraform
Azure CLI and PowerShell scripts used within deployment automation
CI/CD pipelines such as GitHub Actions or Azure Pipelines

The objective is not simply to automate infrastructure deployment. The objective is to ensure that security and compliance requirements are built into the deployment process.

Why Infrastructure as Code Improves Security

Manual configuration can create inconsistent environments. For example, an administrator might enable encryption on one storage account but forget to enable it on another. A virtual network might be deployed with private access in one environment but with unnecessary public exposure in another.

IaC helps reduce these problems by defining the expected configuration in code.

Major security benefits

Benefit	Description
Consistency	Resources are deployed using the same approved configuration
Repeatability	The same secure configuration can be deployed multiple times
Version control	Changes can be tracked, reviewed, and reverted
Auditability	Organizations can identify who changed deployment code and when
Standardization	Security requirements can be applied across subscriptions and environments
Early detection	Misconfigurations can be identified before deployment
Reduced drift	Deployed resources can be compared with the approved configuration
Automation	Security checks can run automatically in CI/CD pipelines

IaC does not automatically make an environment secure. Poorly written infrastructure code can reproduce insecure configurations at scale. Security must therefore be included in the design, validation, deployment, and monitoring processes.

Security Controls That Can Be Implemented Through IaC

IaC can define many Azure security settings, including:

Identity and access

Azure role assignments
Managed identities
Resource scopes
Role definitions
Access policies where supported
Privileged access configuration
Group-based access patterns

Governance

Azure Policy definitions
Policy assignments
Policy initiatives
Resource locks
Management group hierarchy
Required tags
Allowed regions
Allowed resource types
Naming standards

Data protection

Storage encryption settings
Storage network restrictions
Secure transfer requirements
Key Vault configuration
Key and secret access
Azure SQL firewall rules
Auditing settings
Microsoft Defender plans

Compute security

Virtual machine encryption
Trusted launch settings
Managed identities
Just-in-time access configuration
Diagnostic settings
Container registry security
App Service authentication and networking settings

Security Should Be Defined at Multiple Layers

A mature IaC security strategy generally uses several layers.

1. Source-code controls

Security begins in the infrastructure repository.

Examples include:

Requiring pull requests
Requiring peer review
Protecting the main branch
Scanning for secrets
Scanning IaC files for insecure configurations
Preventing direct production changes
Maintaining approved modules
Tracking changes through version control

2. Pre-deployment validation

Before infrastructure is deployed, the code should be checked for:

Syntax errors
Invalid resource properties
Insecure defaults
Excessive permissions
Public network exposure
Missing encryption
Missing diagnostic settings
Noncompliant locations or resource types
Unapproved role assignments

Examples of tools and techniques include:

Bicep validation and linting
ARM template validation
Terraform validation and planning
Static analysis tools
Policy-as-code checks
Security scanning in CI/CD pipelines

3. Deployment-time controls

Azure Policy can evaluate resources during deployment and determine whether they comply with organizational requirements.

Depending on the policy effect, Azure Policy can:

Audit noncompliant resources
Deny noncompliant deployments
Modify resource properties
Deploy supporting configuration
Append required properties
Audit or deny public network access
Require diagnostic settings
Enforce approved resource locations

A secure deployment pipeline should use preventive controls where practical and auditing controls where immediate denial would disrupt legitimate deployment requirements.

4. Post-deployment monitoring

After deployment, organizations should continue checking for:

Configuration drift
Unauthorized changes
Newly created resources
Changes to role assignments
Disabled security controls
Public exposure
Missing logs
Noncompliant resources

Microsoft Defender for Cloud, Azure Policy compliance data, Azure Activity Logs, and Microsoft Sentinel can support this process.

Azure Policy and Infrastructure as Code

Azure Policy is a governance service used to enforce organizational standards and assess resource compliance.

IaC defines the desired infrastructure configuration, while Azure Policy provides an additional governance layer that can evaluate or enforce requirements across deployments.

Example

An organization requires all storage accounts to disable public blob access.

The organization can:

Define the desired storage configuration in Bicep or Terraform.
Add a validation check to the deployment pipeline.
Assign an Azure Policy that audits or denies public blob access.
Monitor compliance after deployment.
Remediate existing noncompliant resources.

This layered approach is stronger than relying on IaC alone.

Common Azure Policy effects

Effect	Purpose
Audit	Records noncompliance without blocking deployment
Deny	Blocks creation or update of noncompliant resources
Modify	Changes or adds resource properties during deployment
Append	Adds properties to a resource request
DeployIfNotExists	Deploys supporting resources or configuration when missing
AuditIfNotExists	Audits resources when a related configuration is missing
Disabled	Disables the policy

A policy assignment can be scoped at a management group, subscription, resource group, or resource level. Policies assigned at a parent scope can affect child resources.

Policy as Code

Policy as code means representing governance and security requirements in a format that can be version-controlled, reviewed, tested, and deployed through automation.

Examples include:

Azure Policy definitions stored in a repository
Policy initiatives defined as code
Terraform configurations for policy assignments
Bicep modules that deploy policy definitions and assignments
Automated compliance tests in a pipeline

Benefits of policy as code

Policies can be reviewed like application code.
Changes can be approved before deployment.
Policy definitions can be reused across environments.
Organizations can maintain consistent governance.
Policy changes can be rolled back.
Compliance requirements become visible and traceable.

Example workflow

A security team creates a policy requiring private endpoints for selected PaaS services.
The policy is stored in source control.
A pull request is created.
Automated checks validate the policy syntax and scope.
Security and platform teams review the change.
The policy is deployed through a pipeline.
Compliance results are monitored.
Exceptions are documented and approved.

Secure Bicep and ARM Deployments

Bicep is a declarative language used to define Azure resources. Bicep files are compiled into Azure Resource Manager templates.

Security practices for Bicep and ARM templates include:

Avoid hard-coded secrets

Do not place passwords, access keys, connection strings, or tokens directly in templates or parameter files.

Use services such as:

Azure Key Vault
Managed identities
Secure pipeline variables
Secret references supported by the deployment mechanism

Even when a secret is stored in a parameter file, the file may still be exposed through source control, build logs, or deployment artifacts.

Use secure parameters

Sensitive values should be handled as secure parameters where supported. However, secure parameters do not replace proper secret management.

Prefer managed identities

Managed identities reduce the need to store credentials in application configuration or deployment scripts.

For example, an application can use a managed identity to access Key Vault instead of storing a client secret in the application.

Use modules

Reusable Bicep modules can standardize secure configurations, such as:

Storage accounts with public access disabled
Private endpoints
Diagnostic settings
Required tags
Approved network rules
Managed identities
Standardized role assignments

Limit role-assignment scope

Role assignments should be deployed at the narrowest scope required.

A deployment should not assign subscription-level Owner access when resource-group-level access is sufficient.

Use explicit resource properties

Security-sensitive settings should be explicitly defined rather than relying on uncertain defaults.

Examples include:

Disabling public network access
Requiring secure transfer
Enabling diagnostic settings
Enabling encryption
Restricting network access
Selecting approved SKUs and regions

Secure Terraform Deployments

Terraform can manage Azure infrastructure through the Azure provider.

Important security practices include:

Store Terraform code in version control.
Protect the Terraform state file.
Use a secure remote backend.
Restrict access to state files.
Avoid storing secrets in state whenever possible.
Use managed identities or workload identities for pipeline authentication.
Review Terraform plans before applying changes.
Use policy checks before deployment.
Separate development and production state.
Restrict who can execute production applies.

Terraform state security

Terraform state may contain sensitive information about deployed resources and, depending on the configuration, may contain secrets or sensitive values.

Therefore:

Do not store state in a public location.
Encrypt state at rest.
Restrict access using Azure RBAC.
Enable appropriate storage protections.
Use locking to prevent conflicting changes.
Avoid placing state files in source control.

Protecting the IaC code is not enough. The state file and pipeline credentials must also be protected.

Secure CI/CD Pipelines

A deployment pipeline should treat infrastructure code as production code.

Recommended controls

Require approval for production deployments.
Use separate deployment identities for different environments.
Grant the pipeline only the permissions it needs.
Use workload identity federation where supported.
Avoid long-lived client secrets.
Store secrets in an approved secret-management service.
Scan templates and scripts before deployment.
Require successful policy checks.
Log deployment activity.
Restrict who can modify pipeline definitions.
Protect deployment branches.
Use separate stages for validation, testing, approval, and deployment.

Pipeline identity permissions

The pipeline identity should not automatically receive Owner at the subscription level.

For example, if a pipeline only deploys resources in one resource group, its permissions should be limited to that resource group whenever possible.

If the pipeline must create role assignments, that capability should be granted deliberately because role-assignment permissions are highly privileged.

Role Assignments in Infrastructure as Code

A role assignment consists of:

A security principal
A role definition
A scope

The principal may be:

A user
A security group
A service principal
A managed identity
Another supported workload identity

When defining role assignments through IaC, consider:

Whether the assignment is necessary
Whether the role is too broad
Whether the scope is too broad
Whether a group should be used instead of an individual
Whether the assignment should be temporary
Whether the principal still exists
Whether the assignment creates privilege escalation risk

Example of an insecure pattern

A deployment template assigns Owner at the subscription scope to an application service principal.

This creates a significant risk because the service principal may be able to:

Modify resources
Delete resources
Create role assignments
Grant access to other identities
Escalate privileges

A safer design would use:

A narrower built-in role
A resource-group or resource scope
A managed identity
A custom role only if necessary
Separate deployment and runtime identities

Preventing Excessive Permissions

IaC should be reviewed for permissions that can lead to privilege escalation.

Particular attention should be given to permissions such as:

Creating or deleting role assignments
Managing role definitions
Assigning Owner or User Access Administrator
Managing policy assignments
Modifying Key Vault access
Changing network access controls
Disabling security monitoring
Modifying diagnostic settings
Deleting security resources

A custom role containing broad wildcard permissions may be more dangerous than a carefully selected built-in role.

Custom roles should be used only when built-in roles cannot satisfy the requirement. Their permissions should be narrowly defined and regularly reviewed.

Resource Locks and IaC

Resource locks can help protect critical resources from accidental deletion or modification.

Common lock types include:

Read-only
CanNotDelete

However, locks must be considered carefully in IaC workflows.

For example:

A deployment may fail if it attempts to modify a resource protected by a read-only lock.
A delete operation may fail because of a CanNotDelete lock.
The identity managing locks must have appropriate permissions.
Locks should not be treated as a replacement for RBAC, backups, or change control.

IaC can deploy and manage locks, but the deployment process should account for their effect on future updates.

Managing Exceptions

Security policies sometimes need exceptions for legitimate business requirements.

Exceptions should be:

Explicitly documented
Limited in scope
Time-bound where possible
Approved by the appropriate authority
Associated with a business justification
Monitored for continued necessity

Avoid broad exemptions at the subscription or management-group level when a resource-level exemption would be sufficient.

An exception should not become a permanent way to bypass security controls.

Handling Configuration Drift

Configuration drift occurs when deployed resources no longer match the approved IaC configuration.

Drift can occur when:

An administrator changes a resource manually
A script modifies a setting
A security control is disabled
A resource is updated outside the pipeline
A policy assignment changes
A role assignment is added directly through the portal

Drift-management process

Detect the difference.
Determine whether the change was authorized.
Identify the responsible identity.
Restore the approved configuration if necessary.
Update the IaC code if the change is legitimate.
Review whether additional controls are needed to prevent recurrence.

IaC should be treated as the authoritative definition of the desired state, but organizations should establish clear procedures for handling legitimate emergency changes.

Recommended Secure IaC Workflow

A secure end-to-end workflow can be organized as follows:

Step 1: Define security requirements

Identify requirements for:

Identity
Access
Network exposure
Encryption
Logging
Monitoring
Compliance
Data protection
Resource ownership

Step 2: Create reusable secure modules

Build approved modules for common resource types and configurations.

Step 3: Store code in source control

Use protected repositories and require peer review.

Step 4: Validate the code

Run:

Syntax validation
Static analysis
Secret scanning
Policy checks
Security configuration checks

Step 5: Generate and review the deployment plan

Review what the deployment will create, modify, or delete.

Step 6: Apply governance controls

Use Azure Policy and other preventive controls to block noncompliant deployments.

Step 7: Require approval for sensitive environments

Production deployments and privilege changes should require appropriate approval.

Step 8: Deploy using least privilege

Use a dedicated deployment identity with only the required permissions.

Step 9: Monitor compliance

Review policy compliance, activity logs, Defender for Cloud recommendations, and security alerts.

Step 10: Remediate drift

Investigate unauthorized changes and restore the approved configuration.

Common Exam Traps

Trap 1: IaC alone guarantees security

IaC can reproduce insecure settings. Security validation and governance are still required.

Trap 2: Azure Policy and IaC are identical

IaC defines desired infrastructure. Azure Policy evaluates or enforces governance requirements. They complement each other.

Trap 3: A pipeline identity should be Owner

The pipeline should receive only the permissions required for deployment. Owner is often unnecessarily broad.

Trap 4: Secure parameters eliminate secret-management risks

Secrets may still appear in state files, logs, artifacts, or source control. Use a dedicated secret-management solution.

Trap 5: A custom role is automatically safer

A custom role with wildcard permissions can be extremely broad. Least privilege depends on the actual permissions and scope.

Trap 6: Policy audit and policy deny have the same effect

Audit reports noncompliance. Deny blocks the deployment or update.

Trap 7: Resource locks replace RBAC

Locks protect against certain deletion or modification operations but do not determine who can access a resource.

Trap 8: A deployment at subscription scope is always appropriate

The deployment identity and role assignments should be scoped as narrowly as possible.

Trap 9: Terraform state is harmless

State may contain sensitive infrastructure details and secrets. It must be protected.

Trap 10: Manual emergency changes do not matter

Manual changes can create configuration drift and should be investigated, documented, and reconciled with IaC.

Practice Exam Questions

Question 1

A company uses Bicep to deploy storage accounts. Security requires that all storage accounts disable public network access. The company wants noncompliant deployments to be blocked automatically.

What should the company implement?

A. An Azure Activity Log alert
B. An Azure Policy with the Deny effect
C. A resource lock on each storage account
D. A Microsoft Sentinel workbook

Correct answer: B

Explanation: An Azure Policy with the Deny effect can block the creation or update of resources that do not meet the required configuration. Activity Log alerts and Sentinel workbooks provide monitoring, while resource locks do not enforce storage network settings.

Question 2

A Terraform deployment pipeline creates resources in a single resource group. The pipeline currently has Owner access at the subscription scope.

What is the best security improvement?

A. Grant the pipeline Global Administrator
B. Replace Terraform with manual deployments
C. Give the pipeline Contributor access at the subscription scope
D. Reduce the pipeline identity’s permissions and scope to what the deployment requires

Correct answer: D

Explanation: The pipeline should follow least privilege. If it only deploys resources in one resource group, its permissions should be limited to that resource group and should exclude unnecessary role-assignment or administrative permissions.

Question 3

An organization wants security policies to be reviewed, version-controlled, and deployed through a CI/CD pipeline.

Which approach best meets this requirement?

A. Store Azure Policy definitions in source control and deploy them as policy as code
B. Configure all policies manually in the Azure portal
C. Use resource locks instead of policies
D. Review policy compliance only once each year

Correct answer: A

Explanation: Policy as code allows policy definitions and assignments to be version-controlled, peer-reviewed, tested, and deployed consistently through automation.

Question 4

A developer places a database password directly in a Bicep parameter file stored in a private repository.

Why is this still a security concern?

A. The password may be exposed through source control, logs, or deployment artifacts
B. Parameter files cannot contain strings
C. Bicep cannot deploy database resources
D. Azure Policy automatically publishes parameter values

Correct answer: A

Explanation: A private repository does not eliminate the risk of secret exposure. Secrets may appear in source history, build logs, deployment outputs, artifacts, or copied files. Secrets should be stored and retrieved through an approved secret-management solution.

Question 5

A company wants to ensure that every production resource has diagnostic settings configured.

Which Azure Policy effect is most appropriate when the organization wants Azure to deploy the missing configuration automatically?

A. Audit
B. DeployIfNotExists
C. Disabled
D. Deny

Correct answer: B

Explanation: DeployIfNotExists can deploy supporting configuration when the required related resource or setting is missing. Audit only reports noncompliance, while Deny blocks noncompliant deployments.

Question 6

A Terraform state file is stored in a publicly accessible storage container.

What should the security team do first?

A. Delete all Terraform configuration files
B. Grant all administrators access to the container
C. Move the state to a protected backend and restrict access
D. Add a resource lock to the storage account only

Correct answer: C

Explanation: Terraform state can contain sensitive infrastructure information and potentially secret values. It should be stored in a secured backend with encryption, access controls, and appropriate protection against unauthorized access.

Question 7

A Bicep template assigns the Owner role at the subscription scope to a service principal used by an application at runtime.

What is the best remediation?

A. Replace the service principal with a user account
B. Assign the Owner role at the management-group scope
C. Disable Azure RBAC
D. Use a managed identity and grant only the required role at the narrowest scope

Correct answer: D

Explanation: Runtime applications should not normally receive Owner access. A managed identity and a narrowly scoped role reduce credential-management risk and limit the impact of compromise.

Question 8

A policy requiring private endpoints is stored in a repository. A developer submits a change that changes the policy effect from Deny to Audit without approval.

Which control would best prevent this change from being deployed?

A. A protected branch and required pull-request approval
B. A read-only resource lock
C. A storage firewall rule
D. A virtual network peering connection

Correct answer: A

Explanation: Source-control protections and required reviews can prevent unauthorized changes to policy code before it reaches the deployment pipeline. Resource locks and network controls do not govern repository changes.

Question 9

An administrator manually disables encryption on a resource that was originally deployed through IaC.

What is this situation called, and what should the organization do?

A. Privilege activation; permanently assign the administrator Owner
B. Configuration drift; investigate and restore the approved configuration
C. Policy inheritance; remove the management group
D. Deployment compilation; rebuild the Bicep compiler

Correct answer: B

Explanation: Configuration drift occurs when the deployed environment no longer matches the approved IaC configuration. The organization should investigate the change, determine whether it was authorized, and restore or update the desired configuration appropriately.

Question 10

An organization wants to allow a deployment pipeline to create resources and assign a specific role to a managed identity, but it does not want the pipeline to have unrestricted access to all role assignments.

What is the best approach?

A. Grant the pipeline subscription-level Owner access
B. Grant the pipeline Global Administrator
C. Use narrowly scoped role-assignment permissions and conditions where supported
D. Allow the pipeline to modify all custom role definitions

Correct answer: C

Explanation: Role-assignment management is highly privileged. The organization should limit the pipeline’s scope and permissions and use supported conditions to constrain which roles, principals, or actions it can manage.

Final Takeaways

For the SC-500 exam, remember these principles:

Define security requirements in infrastructure code.
Validate IaC before deployment.
Use Azure Policy as an additional governance layer.
Prefer Deny for requirements that must block noncompliant deployments.
Use DeployIfNotExists when missing supporting configuration should be deployed automatically.
Protect secrets, pipeline credentials, and Terraform state.
Use managed identities and workload identities instead of long-lived secrets.
Scope deployment permissions narrowly.
Review role assignments carefully, especially Owner and role-assignment management permissions.
Use source control, peer review, and protected deployment pipelines.
Monitor for configuration drift after deployment.
Treat IaC as a repeatable security-control mechanism, not as a substitute for monitoring and governance.

Go to the SC-500 Exam Prep Hub main page

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

Implement and configure security for storage accounts (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 storage accounts
      --> Implement and configure security for storage accounts

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 Storage provides cloud storage for:

Blob Storage
Azure Files
Queue Storage
Table Storage
Azure Data Lake Storage capabilities

Because storage accounts frequently contain sensitive business, application, backup, and analytical data, they must be protected against:

Unauthorized access
Accidental exposure
Data exfiltration
Credential theft
Malware uploads
Ransomware
Accidental deletion
Insecure network connections
Excessive permissions
Configuration drift

For the SC-500 exam, securing an Azure Storage account involves combining:

Identity and access controls
Network security
Encryption and data protection
Monitoring and threat detection
Governance and compliance
Backup, recovery, and data-retention controls

A secure configuration should follow the Zero Trust principles of verifying explicitly, using least-privilege access, and assuming that a breach may occur.

1. Use the Correct Storage Account Configuration

New storage accounts should use the Azure Resource Manager deployment model rather than the classic deployment model.

Azure Resource Manager-based storage accounts support modern security and governance capabilities, including:

Azure RBAC
Managed identities
Microsoft Entra authorization
Resource locks
Azure Policy
Tags
Modern deployment and management controls

The storage account configuration selected during creation can affect the security posture of every workload that uses the account. Therefore, account type, redundancy, networking, and endpoint configuration should be selected carefully.

2. Control Network Access

Azure Storage accounts have public endpoints. Network access should be restricted to only the clients and services that require it.

Public network access

If a storage account is intended to be accessed only through private connectivity, disable public network access.

This configuration helps ensure that clients must use private endpoints rather than the public endpoint.

However, creating a private endpoint does not automatically disable the public endpoint. The public endpoint must be separately blocked or restricted.

Private endpoints

A private endpoint provides a private IP address from an Azure virtual network for accessing a storage service.

Traffic travels through Azure Private Link and the Microsoft backbone rather than through the public internet.

Private endpoints are useful when:

Applications run in Azure virtual networks
Storage should not be publicly reachable
On-premises systems connect through VPN or ExpressRoute
Data exfiltration risk must be reduced
The organization requires private connectivity to PaaS services

A private endpoint can be created for the required storage service, such as Blob Storage, File Storage, Queue Storage, or Table Storage.

Important exam point

A private endpoint does not replace authorization. A client must still have appropriate permissions to access the storage data.

Network access and data authorization are separate controls:

Network controls determine whether the client can reach the service.
Authorization controls determine what the client can do after reaching it.

Storage firewalls and virtual network rules

When public access is necessary, use storage firewall rules to restrict access.

Possible network rule sources include:

Specific virtual network subnets
Public IP address ranges
Azure resource instances
Trusted Azure services

A common secure configuration is:

Set the public network access rule to Selected networks.
Set the default network action to Deny.
Allow only approved IP ranges or virtual network subnets.
Add narrowly scoped exceptions when required.

Virtual network rules generally require a service endpoint on the applicable subnet.

Example

A storage account is used by an application running in a specific subnet.

A secure design might:

Enable the Microsoft.Storage service endpoint on the subnet.
Add the subnet to the storage account’s virtual network rules.
Set the default network action to Deny.
Disable public access if a private endpoint is used instead.

Trusted Azure services

Some Azure services may need to access a storage account even though they do not originate from an explicitly approved virtual network or IP address.

A trusted-service exception can allow approved Azure services to access the account.

However, broad trusted-service exceptions increase the trust boundary. Where supported, a resource instance rule can provide a more narrowly scoped alternative by authorizing a specific Azure resource and its managed identity.

Exam consideration

Do not automatically select “Allow trusted Microsoft services” when the requirement is to allow only one specific Azure resource. A resource instance rule may provide a narrower security boundary.

Network security perimeter

A network security perimeter can establish a broader security boundary around supported PaaS resources.

It can help control:

Inbound traffic
Outbound traffic
PaaS-to-PaaS communication
Data-exfiltration paths

A perimeter may be useful when multiple storage accounts and other PaaS resources need to be governed as a group rather than through independent account-level rules.

3. Require Secure Connections

Secure transfer required

Enable the Secure transfer required setting to reject requests made over HTTP.

This setting applies to:

Storage REST endpoints
Azure Files SMB access

Secure transfer helps protect data in transit against interception and other network attacks.

Minimum TLS version

Configure the storage account to require TLS 1.2 or later.

This prevents clients from negotiating older, deprecated TLS versions.

A strong baseline is:

Secure transfer required: Enabled
Minimum TLS version: TLS 1.2 or later

These controls work together:

Secure transfer prevents unencrypted HTTP access.
Minimum TLS controls the strength of the encrypted connection.

4. Prevent Anonymous Public Blob Access

Blob containers can potentially be configured for anonymous public access.

Anonymous access should be disabled unless there is a documented business requirement for public content.

Important controls include:

Disable public blob access at the storage-account level.
Avoid configuring containers for anonymous access.
Use authenticated access for private data.
Use Azure Front Door and a Web Application Firewall when publicly serving appropriate content through a controlled application architecture.

Public access is especially dangerous when a storage account contains:

Customer information
Internal documents
Backups
Application data
AI training data
Logs
Personally identifiable information

A storage account can have network restrictions and still expose data anonymously if public blob access is enabled. Network security and authorization must both be evaluated.

5. Use Microsoft Entra ID and Azure RBAC

Azure RBAC is generally preferred over shared account keys for identity-based access to Azure Storage data.

RBAC assignments can be made to:

Users
Security groups
Managed identities
Service principals
Other supported workload identities

Assign roles at the narrowest scope required:

Storage account
Container
Resource group
Subscription, only when necessary

Use groups instead of assigning roles individually where practical.

Common data-access roles

Examples of storage data roles include:

Storage Blob Data Reader
Storage Blob Data Contributor
Storage Blob Data Owner
Storage Queue Data Contributor
Storage Table Data Contributor
Storage File Data SMB Share Reader
Storage File Data SMB Share Contributor

The correct role depends on the service and the required operations.

Reader versus Contributor

A principal that only needs to read blobs should not receive a data-contributor role.

A contributor role may allow the principal to create, modify, or delete data. Therefore, it should be used only when those capabilities are required.

Control-plane versus data-plane access

Azure RBAC permissions can relate to two different areas:

Control plane

Control-plane permissions manage the storage account resource itself.

Examples include:

Creating the storage account
Changing networking settings
Modifying account configuration
Deleting the account

Data plane

Data-plane permissions control access to the data stored in the account.

Examples include:

Reading blobs
Writing blobs
Deleting blobs
Reading queue messages
Accessing file shares

A user may have permission to manage the storage account without having the required data-plane role, or may have data access without being able to modify the storage account configuration.

6. Prefer Managed Identities for Applications

Applications running in Azure should generally use managed identities instead of storing storage account keys or client secrets.

Managed identities can be used by supported Azure resources to obtain Microsoft Entra tokens without requiring developers to manage credentials.

A typical design is:

Enable a managed identity on the application.
Assign the required storage data role to the identity.
Scope the assignment to the storage account or container.
Configure the application to authenticate using Microsoft Entra ID.
Remove unnecessary account-key usage.

This reduces the risk of:

Secrets being stored in code
Credentials appearing in configuration files
Secret rotation failures
Long-lived credentials being compromised

7. Understand Shared Key Authorization and SAS

Storage account keys

Storage account keys provide broad access to storage services. Anyone who obtains a valid key may be able to access data or perform operations allowed by that key.

Risks include:

Broad permissions
Difficult attribution to individual users
Credential leakage
Long-lived access
Difficult rotation processes

Where possible, use Microsoft Entra authorization and Azure RBAC instead.

Shared Access Signatures

A Shared Access Signature, or SAS, grants delegated access to storage resources.

A SAS can restrict:

Resource
Permissions
Start time
Expiration time
Allowed protocol
IP address, where supported

SAS is useful when a client needs limited, temporary access without receiving the storage account key.

However, a SAS is still a bearer token. Anyone who obtains it may use it until it expires or is revoked through the applicable mechanism.

SAS best practices

Use the shortest practical expiration period.
Grant only the required permissions.
Restrict the resource scope.
Require HTTPS.
Avoid exposing SAS tokens in URLs, logs, or source control.
Prefer user delegation SAS for Blob Storage when appropriate because it is authorized through Microsoft Entra credentials rather than the storage account key.
Have a revocation strategy for compromised tokens.

Important distinction

A SAS does not bypass network restrictions. A request must satisfy both:

Storage network access rules
SAS or identity authorization requirements

8. Consider Disabling Shared Key Authorization

If an organization wants to require Microsoft Entra-based authorization, it can disable shared key access where supported.

Disabling shared key authorization also affects account-key-based and service SAS access because those SAS types depend on shared keys.

Before disabling shared key authorization, verify that all applications and services have been migrated to supported alternatives, such as:

Microsoft Entra ID
Azure RBAC
Managed identities
User delegation SAS

The change should be tested carefully because legacy applications may still depend on account keys.

9. Protect Data at Rest

Azure Storage encrypts data at rest by default using Microsoft-managed keys.

Additional controls may be required for sensitive or regulated data.

Customer-managed keys

Customer-managed keys allow the organization to control the encryption key used for storage encryption.

Keys can be managed through:

Azure Key Vault
Azure Key Vault Managed HSM

Customer-managed keys can support requirements involving:

Customer control of encryption keys
Key rotation
Key access auditing
Key revocation
Regulatory compliance

Customer-managed keys introduce additional responsibilities. The organization must protect the key-management service and ensure that the storage account can access the key when required.

If the key becomes unavailable or access is revoked incorrectly, storage operations may be affected.

Infrastructure encryption

Infrastructure encryption provides an additional service-managed encryption layer.

It is sometimes described as double encryption because data receives an additional encryption layer beyond the primary storage encryption.

Infrastructure encryption must be enabled when the storage account is created and may not be available as a setting that can be enabled later for an existing account.

Encryption scopes

Encryption scopes allow different encryption keys or key-management policies to be applied to specific containers or blobs.

They can be useful when:

Multiple tenants share a storage account
Different data sets require separate key control
Data classification requires different encryption arrangements

10. Protect Data from Accidental or Malicious Deletion

Encryption does not protect against deletion. Additional data-protection features are required.

Blob soft delete

Blob soft delete allows deleted blobs to be retained for a configured period so they can be recovered.

It helps protect against:

Accidental deletion
Malicious deletion
Application errors
Ransomware-related deletion activity

Container soft delete

Container soft delete protects deleted containers and their contents during the retention period.

Versioning

Blob versioning automatically maintains previous versions of blob data when supported operations modify or overwrite blobs.

Versioning can help recover from:

Accidental overwrites
Malicious changes
Application defects
Data corruption

Immutable blob storage

Immutable storage can enforce write-once, read-many behavior.

It is useful for data that must not be modified or deleted during a retention period, such as:

Compliance records
Financial records
Legal evidence
Audit logs
Regulatory archives

Immutable storage can use:

Time-based retention
Legal holds

Important exam distinction

Soft delete helps recover deleted data. Immutable storage helps prevent modification or deletion during a protected retention period. They address different risks and may be used together.

11. Use Resource Locks Carefully

Resource locks protect the storage account resource from accidental deletion or modification.

Common lock types include:

CanNotDelete
ReadOnly

A CanNotDelete lock helps prevent deletion of the storage account.

A ReadOnly lock prevents modification and deletion operations against the locked resource, although it can interfere with normal management operations.

Resource locks:

Apply to the resource configuration
Do not protect individual blobs by themselves
Do not replace soft delete
Do not replace immutable storage
Do not replace RBAC
Do not replace backups

Locks should be included in IaC where appropriate, but deployment pipelines must account for the restrictions imposed by the locks.

12. Enable Microsoft Defender for Storage

Microsoft Defender for Storage provides threat detection and security capabilities for storage accounts.

Depending on the enabled capabilities and supported services, Defender for Storage can help detect:

Suspicious access patterns
Malicious IP addresses
Unusual authentication activity
Potential data exfiltration
Malware uploaded to blobs
Sensitive data-related risks

Defender for Storage can include malware scanning for blob uploads and sensitive data discovery capabilities.

It can be enabled at the subscription level or for selected storage accounts, depending on the required configuration.

Defender for Storage complements preventive controls. It does not replace:

RBAC
Network restrictions
Encryption
Secure transfer
Public-access controls
Data-retention features

13. Enable Logging and Monitoring

Storage accounts should be monitored continuously.

Diagnostic settings can send logs and metrics to services such as:

Log Analytics
Microsoft Sentinel
Event Hubs
Storage accounts for archival purposes

Important events to monitor include:

Storage account key regeneration
Changes to firewall rules
Changes to public network access
Changes to encryption settings
Role-assignment changes
Shared Key usage
Anonymous access
Storage read operations
Storage write operations
Storage delete operations
Defender for Storage alerts

Storage logs can indicate how a request was authorized, such as through:

Microsoft Entra ID
Shared Key
SAS
Anonymous access

This information can help identify unexpected authentication methods or unauthorized access patterns.

14. Apply Azure Policy

Azure Policy can enforce or audit storage security requirements across subscriptions and management groups.

Examples of useful policy requirements include:

Require secure transfer
Require TLS 1.2 or later
Deny public network access
Deny public blob access
Require infrastructure encryption
Require customer-managed keys
Require diagnostic settings
Require approved locations
Require specific tags
Restrict allowed resource types

Common policy effects include:

Effect	Purpose
Audit	Reports noncompliant resources
Deny	Blocks noncompliant creation or updates
Modify	Changes resource properties during deployment
DeployIfNotExists	Deploys missing supporting configuration
AuditIfNotExists	Reports missing related configuration

For example, a policy with a Deny effect can prevent the deployment of a storage account that permits public network access.

An Audit policy is useful when the organization needs to discover existing noncompliance without immediately blocking deployments.

15. Use Infrastructure as Code for Secure Storage Deployments

Storage accounts should be deployed through approved infrastructure-as-code templates or modules.

IaC can define:

Network access settings
Private endpoints
Firewall rules
Secure transfer
Minimum TLS version
Encryption settings
Diagnostic settings
Role assignments
Blob versioning
Soft-delete retention
Public access settings
Resource locks
Tags

A secure deployment pipeline should:

Store templates in source control.
Require peer review.
Scan templates for insecure settings.
Prevent secrets from being embedded in code.
Validate policy compliance.
Review deployment plans.
Require approval for production changes.
Deploy using a least-privileged identity.
Monitor the deployed resources.
Detect and remediate configuration drift.

IaC is not inherently secure. An insecure template can reproduce the same vulnerability across many storage accounts.

16. Recommended Secure Storage Baseline

A general secure baseline may include:

Use Azure Resource Manager-based storage accounts.
Disable public network access when private connectivity is sufficient.
Use private endpoints for internal workloads.
Set public network rules to deny by default.
Require secure transfer.
Require TLS 1.2 or later.
Disable public blob access.
Prefer Microsoft Entra ID and Azure RBAC.
Use managed identities for applications.
Avoid account keys where possible.
Use short-lived, narrowly scoped SAS tokens when required.
Enable encryption at rest.
Use customer-managed keys for applicable compliance requirements.
Enable infrastructure encryption when required.
Enable soft delete and versioning.
Use immutable storage for protected records.
Enable Defender for Storage.
Configure diagnostic settings.
Apply Azure Policy.
Monitor role assignments and network changes.
Protect storage configuration with resource locks where appropriate.

Common Exam Traps

Trap 1: A private endpoint automatically disables public access

It does not. Public network access must be separately disabled or restricted.

Trap 2: A firewall rule grants data access

A firewall rule controls network reachability. The client still needs appropriate authorization.

Trap 3: Contributor provides blob data access

The Contributor role is primarily a management-plane role. Data access generally requires an appropriate storage data role.

Trap 4: SAS is always secure

SAS tokens can be leaked and may provide access until expiration or revocation. They must be narrowly scoped and short-lived.

Trap 5: Encryption prevents deletion

Encryption protects confidentiality of data at rest. It does not prevent deletion or overwriting.

Trap 6: Soft delete prevents all changes

Soft delete helps recover deleted data. It does not provide the same protection as immutable storage.

Trap 7: Resource locks protect blobs

Resource locks protect the storage account resource. They do not independently protect individual blobs from deletion.

Trap 8: Trusted Azure services is always the best option

A resource instance rule may provide a narrower exception when only one specific Azure resource needs access.

Trap 9: Azure RBAC replaces network security

RBAC and network controls solve different problems. Both may be required.

Trap 10: Defender for Storage prevents every attack

Defender for Storage provides detection and protection capabilities, but it does not replace preventive configuration controls.

Practice Exam Questions

Question 1

A company has a storage account that is used only by applications running inside an Azure virtual network. The security team requires that the account not be accessible through the public internet.

What should the company implement?

A. A storage firewall rule allowing all public IP addresses
B. A private endpoint and disabled public network access
C. A SAS token with a one-year expiration
D. A resource lock

Correct answer: B

Explanation: A private endpoint provides private connectivity from the virtual network. Public network access should also be disabled because creating a private endpoint does not automatically block the public endpoint.

Question 2

An application needs to read blobs from one container but must not upload, modify, or delete blobs.

Which access configuration should be used?

A. Storage Blob Data Owner at the subscription scope
B. Storage Blob Data Contributor at the storage-account scope
C. Owner at the resource-group scope
D. Storage Blob Data Reader at the narrowest appropriate scope

Correct answer: D

Explanation: Storage Blob Data Reader provides read access without granting write or delete permissions. The assignment should be scoped to the container or storage account as appropriate.

Question 3

A storage account must allow access from only two corporate public IP ranges. All other public network traffic must be blocked.

Which configuration should be used?

A. Create a resource lock
B. Enable anonymous blob access
C. Assign the Reader role to the corporate users
D. Set the default public network action to Deny and add the two IP ranges

Correct answer: D

Explanation: Storage firewall rules can restrict public endpoint access to specified IP ranges. The default action should be Deny so that only explicitly permitted sources can connect.

Question 4

A company wants to prevent applications from using storage account keys and require Microsoft Entra-based authorization instead.

What should the company consider?

A. Enable anonymous public access
B. Disable all diagnostic settings
C. Disable shared key authorization after migrating dependent applications
D. Assign Owner to every application identity

Correct answer: C

Explanation: Disabling shared key authorization can require applications to use Microsoft Entra ID, managed identities, Azure RBAC, or supported alternatives. The organization must first identify and migrate applications that depend on account keys or key-based SAS.

Question 5

A storage account contains financial records that must not be modified or deleted for seven years.

Which feature is most appropriate?

A. Blob versioning only
B. Immutable blob storage with time-based retention
C. A storage firewall
D. A private endpoint

Correct answer: B

Explanation: Immutable storage with time-based retention is designed to prevent modification or deletion during a defined retention period. Versioning helps recover previous versions but does not provide the same write-once, read-many protection.

Question 6

An Azure application needs temporary access to upload files to a specific blob container. The application should not receive the storage account key.

Which option is most appropriate?

A. A narrowly scoped, short-lived SAS token
B. Subscription-level Owner access
C. Anonymous public access to the container
D. A ReadOnly resource lock

Correct answer: A

Explanation: A SAS token can provide limited permissions to a specific resource for a defined period. It should be short-lived, restricted to the required operations, and transmitted only over HTTPS.

Question 7

A security team wants Azure to block the deployment of storage accounts that permit public blob access.

Which control should be used?

A. Microsoft Sentinel workbook
B. Azure Monitor metric alert
C. Azure Policy with the Audit effect
D. Azure Policy with the Deny effect

Correct answer: D

Explanation: The Deny effect blocks creation or updates that violate the policy. Audit identifies noncompliant resources but does not prevent deployment.

Question 8

A company wants to detect suspicious access patterns, malware uploaded to blobs, and unusual authentication activity.

Which service should it enable?

A. Azure Resource Locks
B. Microsoft Defender for Storage
C. Azure Private DNS
D. Azure Policy only

Correct answer: B

Explanation: Microsoft Defender for Storage provides threat-detection capabilities for storage accounts, including supported malware scanning and detection of suspicious access activity.

Question 9

A storage account uses a private endpoint, but users can still access the account through its public endpoint.

What is the most likely explanation?

A. Private endpoints do not provide encryption
B. Azure RBAC is disabled
C. Public network access was not separately disabled or restricted
D. Blob versioning is not enabled

Correct answer: C

Explanation: Creating a private endpoint does not automatically disable the public endpoint. The storage account’s public network access must be disabled or restricted separately.

Question 10

An organization wants to require secure connections and prevent clients from using outdated encryption protocols.

Which configuration should it use?

A. Enable Secure transfer required and require TLS 1.2 or later
B. Enable anonymous blob access and SAS
C. Create a CanNotDelete resource lock
D. Assign Storage Blob Data Reader to all users

Correct answer: A

Explanation: Secure transfer required rejects HTTP requests, while the minimum TLS version setting prevents clients from negotiating older TLS versions. Together, they strengthen protection for data in transit.

Final Takeaways

For the SC-500 exam, remember the following:

Use private endpoints and disable public network access when public connectivity is unnecessary.
If public access is required, use firewall rules with a default Deny action.
Network access does not replace authorization.
Prefer Microsoft Entra ID, Azure RBAC, and managed identities.
Use SAS only when temporary delegated access is required.
Keep SAS permissions and expiration periods narrow.
Require secure transfer and TLS 1.2 or later.
Disable anonymous public blob access unless explicitly required.
Use customer-managed keys when additional key control is necessary.
Use soft delete for recovery and immutable storage for retention enforcement.
Enable Defender for Storage and diagnostic logging.
Apply Azure Policy to enforce storage security baselines.
Use infrastructure as code to deploy consistent, reviewable configurations.
Monitor for unauthorized changes and configuration drift.

Go to the SC-500 Exam Prep Hub main page

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

Implement conditional access policies (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%)
   --> Secure access to resources by using Microsoft Entra ID
      --> Implement conditional access policies

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 Entra Conditional Access is a policy-based access-control capability that allows an organization to make access decisions based on contextual information about a sign-in.

Rather than simply asking:

“Is this user allowed to access the resource?”

Conditional Access enables an organization to ask:

“Under what circumstances should this user be allowed to access this resource, and what security requirements must be satisfied?”

Conditional Access policies can evaluate signals such as:

User or group
Target resource
Device platform
Client application
Network location
User risk
Sign-in risk
Device state
Authentication context
Other contextual signals

Based on those conditions, a policy can:

Allow access
Require additional security controls
Require stronger authentication
Require a compliant device
Require an approved client application
Apply session restrictions
Block access

This makes Conditional Access an important component of a Zero Trust security strategy.

1. The Basic Conditional Access Model

A Conditional Access policy can be understood as:

IF certain conditions are met
THEN apply specified access controls.

For example:

IF a user accesses Microsoft 365 from an unmanaged device
THEN require multifactor authentication.

Another example:

IF a user attempts to access an application from a high-risk sign-in
THEN block access.

A more sophisticated policy might be:

IF a privileged administrator accesses sensitive resources from outside trusted locations
THEN require strong authentication and a compliant device.

The fundamental structure is:

Assignments + Conditions → Access Controls

2. Conditional Access Policy Components

A Conditional Access policy generally contains several major components:

Users and workload identities
Target resources
Conditions
Grant controls
Session controls
Policy state

Understanding these components is essential for the SC-500 exam.

3. Users and Workload Identities

The first question is:

Who should the policy apply to?

Conditional Access can target users and groups.

For example, a policy could apply to:

All users
Members of a specific group
Administrators
Guest users
External users
Specific directory roles

You can also configure exclusions.

For example:

Include all users except members of the Emergency Access Accounts group.

This is extremely important for preventing administrative lockout.

Example

A company wants MFA for all employees.

The policy could be:

Include: All users
Exclude: Emergency access accounts

Grant: Require multifactor authentication

4. Workload Identities

Conditional Access also has capabilities for workload identities, such as service principals.

This is important because user-targeted Conditional Access policies shouldn’t be assumed to protect service principals.

For example:

A service principal authenticates to Azure programmatically.

A Conditional Access policy scoped only to users doesn’t provide the same control over that service principal.

Organizations can instead use Conditional Access for workload identities where applicable.

This is an important exam distinction:

User Conditional Access ≠ workload identity Conditional Access

5. Target Resources

The next question is:

What is being accessed?

Conditional Access policies can target resources such as:

Cloud applications
Microsoft services
Specific applications
All resources

Microsoft’s terminology has evolved, so you may encounter older material referring to Cloud apps or actions and newer interfaces referring to Target resources or Resources.

For exam purposes, understand the underlying concept:

Target resources identify what the policy is protecting.

Example

A company might create a policy that requires MFA only when users access:

Exchange Online
SharePoint Online
Microsoft Teams
A specific enterprise application

rather than requiring the control for every resource.

6. Conditions

Conditions determine when the policy should apply.

Common Conditional Access conditions include:

User risk
Sign-in risk
Device platforms
Locations
Client applications
Filter for devices
Authentication context
Other supported contextual signals

The important concept is:

Conditions determine whether the policy applies to a particular sign-in.

7. Device Platforms

Conditional Access can evaluate the platform being used.

Examples include:

Windows
macOS
iOS
Android
Linux
Other or unknown platforms

This allows organizations to create policies such as:

Require compliant devices when accessing corporate applications from Windows.

Or:

Block access from unsupported platforms.

However, device-platform detection is based on signals such as the user-agent information and should not necessarily be treated as a complete device-security solution. Microsoft recommends combining platform-based controls with stronger controls such as device compliance or application protection where appropriate.

8. Locations

Conditional Access can make decisions based on network location.

Organizations can define named locations to represent trusted or known network locations.

Examples include:

Corporate offices
Corporate VPN ranges
Approved network ranges
Specific countries or regions

A policy might say:

Require MFA when users sign in from outside corporate locations.

Another might say:

Block access from a specific geographic region.

Important distinction

A trusted location doesn’t automatically mean:

“This user is safe.”

It simply provides a contextual signal that can be incorporated into an access decision.

9. Named Locations

Named locations provide administrators with a reusable way to identify network locations.

For example:

Corporate Headquarters

could represent:

203.0.113.0/24

A policy could then reference Corporate Headquarters instead of repeatedly specifying the IP range.

Named locations can be useful for:

Trusted corporate networks
VPN ranges
Specific countries/regions
Other known network locations

10. Client Applications

Conditional Access can evaluate how the user is accessing a resource.

Examples include:

Browser
Mobile applications
Desktop clients
Legacy authentication clients
Other supported client types

This can be used to create policies such as:

Block legacy authentication.

This is an important security practice because older authentication protocols may not support modern authentication protections.

11. User Risk

User risk represents the likelihood that an identity or account has been compromised.

Microsoft Entra ID Protection provides risk information that Conditional Access can use to make access decisions.

For example:

If the user’s risk is high, require remediation or stronger authentication.

Possible responses can include:

Require additional authentication
Require risk remediation
Block access

Example

A user’s credentials are detected in a way that suggests the account may be compromised.

Conditional Access can detect the elevated user risk and require appropriate remediation before access is allowed.

12. Sign-In Risk

Sign-in risk represents the probability that a particular authentication request isn’t being performed by the legitimate identity owner.

This is different from user risk.

User risk

Is this user’s account likely to be compromised?

Sign-in risk

Is this particular sign-in likely to be suspicious?

This distinction is very important for the exam.

13. User Risk vs. Sign-In Risk

Risk	Focus
User risk	Likelihood that the identity/account is compromised
Sign-in risk	Likelihood that the current authentication request is suspicious

Example

A user might have:

Low user risk

but experience:

High sign-in risk

because the current login originates from an unusual location or demonstrates suspicious characteristics.

Conversely, a user may have elevated user risk even when the current sign-in itself doesn’t appear particularly unusual.

14. Grant Controls

Once Conditional Access determines that a policy applies, it needs to determine:

What should happen?

This is where grant controls are used.

Common grant controls include:

Require multifactor authentication
Require authentication strength
Require device to be marked as compliant
Require Microsoft Entra hybrid joined device
Require approved client app
Require app protection policy
Require password change
Block access

Current Conditional Access supports combining grant controls using either:

Require all selected controls

Require one of the selected controls.

15. Require Multifactor Authentication

One of the most common Conditional Access controls is:

Require multifactor authentication

This requires the user to satisfy Microsoft Entra MFA requirements.

For example:

Condition:

User accesses Microsoft 365 from outside trusted locations.

Grant:

Require multifactor authentication.

Result:

Users accessing Microsoft 365 from outside the trusted location must perform MFA.

16. Authentication Strength

Conditional Access can require a particular authentication strength rather than simply requiring generic MFA.

This allows organizations to establish stronger authentication requirements.

For example, an organization might require:

Phishing-resistant authentication
A particular authentication method
A custom authentication-strength configuration

This is particularly useful for highly sensitive applications and privileged operations.

Exam clue

If the question says:

“Require a specific or stronger authentication method.”

Think:

Authentication strength

rather than simply:

Require MFA

17. Require a Compliant Device

Conditional Access can require the device to be marked as compliant.

This is commonly integrated with Microsoft Intune.

For example:

Users can access corporate applications only from devices that satisfy the organization’s device-compliance policies.

A device might need to satisfy requirements such as:

Encryption
Password requirements
Security software
Operating-system requirements
Other organizational compliance requirements

The important distinction is:

Conditional Access determines whether a compliant device is required; Intune evaluates device compliance.

18. Require Microsoft Entra Hybrid Joined Device

Conditional Access can require users to access resources only from devices that are Microsoft Entra hybrid joined.

This can be useful in organizations operating a hybrid identity environment where corporate Windows devices are joined to both:

On-premises Active Directory
Microsoft Entra ID

This is different from simply requiring an Intune-compliant device.

19. Require an Approved Client App

Conditional Access can require users to access supported resources through an approved client application.

This can help organizations control which applications are permitted to access corporate data.

20. Require App Protection Policy

Conditional Access can require an app protection policy.

App protection policies are associated with Microsoft Intune and can provide application-level protection for organizational data.

This is particularly relevant for mobile scenarios and bring-your-own-device environments.

For example:

A user can access corporate email from a personal mobile device, but the application must satisfy organizational app-protection requirements.

21. Block Access

Block access is the strongest Conditional Access decision.

If the policy applies and the block control is selected, access is denied.

For example:

Block access to corporate resources from unsupported device platforms.

Or:

Block access from a prohibited geographic region.

Block policies must be designed carefully because a misconfigured block policy can prevent legitimate users or administrators from accessing critical resources. Microsoft recommends testing and validating such policies before broad enforcement.

22. Require All vs. Require One

When multiple grant controls are selected, Conditional Access can be configured to require:

Require all selected controls

Every selected requirement must be satisfied.

Example:

Require MFA AND compliant device.

The user must satisfy both.

Require one of the selected controls

Any one of the selected requirements can satisfy the policy.

Example:

Require MFA OR compliant device.

The user needs to satisfy one of them.

Exam tip

Pay close attention to:

AND vs. OR

A question can change the correct answer simply by changing whether all controls or only one control must be satisfied.

23. Session Controls

Grant controls determine what must happen to allow access.

Session controls control what happens after access has been granted.

Examples include:

Sign-in frequency
Persistent browser session
Other supported session-management controls

This distinction is important.

Grant control

“You must perform MFA.”

Session control

“You must authenticate again after a specified period.”

24. Sign-In Frequency

Sign-in frequency can be used to control how often users must authenticate.

For example:

Require users to authenticate again every 8 hours.

This can help reduce the risk associated with long-lived authenticated sessions.

A more sensitive application might use a shorter sign-in frequency than a lower-risk application.

25. Persistent Browser Session

Conditional Access can control whether browser sessions remain persistent.

This can influence whether users remain signed in when they close and reopen their browser.

This is useful when an organization wants to reduce persistent authentication sessions on devices or in environments where persistent sessions aren’t desirable.

26. Policy States

Conditional Access policies have different states.

The most important are:

On
Off
Report-only

On

The policy is enforced.

Off

The policy isn’t evaluated for enforcement.

Report-only

The policy is evaluated for sign-ins, but its access controls aren’t enforced.

Report-only mode is extremely important when deploying new policies because administrators can evaluate the expected impact before enforcement. Results are available through sign-in logs and Conditional Access reporting capabilities.

27. Report-Only Mode

A recommended deployment pattern is:

Create → Report-only → Test → Analyze → Adjust → Enable

Report-only mode allows administrators to see how a policy would affect users without actually enforcing its grant or session controls.

For example:

A new policy requires MFA for all users accessing Microsoft 365.

Before enabling it, the administrator puts the policy into Report-only mode.

The administrator then examines sign-in activity to determine:

Which users would be affected
Which applications would be affected
Which users would be blocked
Which requirements users would need to satisfy
Whether exclusions are appropriate

Only after validating the results should the policy be enabled.

28. Conditional Access Sign-In Logs

The Microsoft Entra sign-in logs are one of the most important troubleshooting tools for Conditional Access.

When investigating a sign-in, administrators can determine:

Which policies applied
Which policies didn’t apply
Whether a policy succeeded
Whether a policy failed
What conditions were evaluated
Which access controls affected the sign-in

This makes sign-in logs particularly valuable when a user reports:

“I can’t access the application.”

29. The Conditional Access What If Tool

The What If tool allows administrators to simulate how Conditional Access policies would evaluate a particular scenario.

Administrators can specify factors such as:

Identity
Target resource
Device platform
Client application
Location
Other conditions

The tool then identifies the policies that would affect the simulated sign-in.

Exam clue

If the question asks:

“You need to determine which Conditional Access policies would apply to a particular user and scenario without performing an actual sign-in.”

Think:

What If

30. Conditional Access Insights and Reporting

Organizations can use Conditional Access reporting capabilities to analyze policy impact.

These capabilities can help answer questions such as:

How many users are affected?
Which policies are blocking access?
Which policies are requiring MFA?
Which policies are being triggered?
What would happen if a report-only policy were enabled?

This is particularly useful when several Conditional Access policies interact.

31. Multiple Conditional Access Policies

Multiple Conditional Access policies can apply to the same sign-in.

For example:

Policy 1

All users accessing Microsoft 365:

Require MFA.

Policy 2

Administrators accessing Microsoft 365:

Require compliant device.

An administrator signing in to Microsoft 365 could be subject to both policies.

Therefore, the effective access decision can depend on the combined effect of multiple policies.

Exam tip

Don’t analyze a Conditional Access policy in isolation when a question describes several policies.

Look for:

Includes
Exclusions
Conditions
Grant controls
Session controls
Other policies affecting the same sign-in

32. Exclusions Are Extremely Important

Exclusions can prevent a Conditional Access policy from applying to specific users, groups, or other supported identities.

A common example is excluding emergency access/break-glass accounts from policies that could otherwise lock out administrators.

Microsoft specifically recommends protecting emergency access accounts from accidental lockout caused by Conditional Access misconfiguration.

Important principle

Don’t blindly exclude large groups of users simply to make a policy easier to deploy.

Exclusions should be:

Deliberate
Documented
Minimal
Reviewed regularly

33. Emergency Access Accounts

Emergency access accounts are particularly important when implementing Conditional Access.

Imagine an organization creates:

All users → Block access from outside the corporate network.

If the policy is incorrectly configured, administrators might also be blocked.

An emergency access account provides a recovery mechanism.

These accounts should be:

Highly protected
Monitored
Used only for emergencies
Excluded appropriately from policies that could cause tenant-wide lockout

34. Conditional Access and Zero Trust

Conditional Access is closely aligned with the Zero Trust principles of:

Verify explicitly

Use least privilege

Assume breach

Conditional Access doesn’t simply trust a user because the user successfully authenticated.

Instead, access can depend on multiple signals.

For example:

Identity + device + location + application + risk + authentication strength

This creates a more contextual access decision.

35. Common Conditional Access Design Patterns

Pattern 1: Require MFA for all users

Users: All users
Resources: All resources
Grant: Require MFA

This establishes a foundational authentication requirement.

Pattern 2: Require MFA outside trusted locations

Users: All users
Resources: Corporate applications
Location: Any location except trusted locations
Grant: Require MFA

This reduces unnecessary MFA prompts from trusted corporate networks while requiring stronger verification from elsewhere.

Pattern 3: Require compliant devices

Users: Employees
Resources: Corporate applications
Grant: Require device to be marked as compliant

This helps ensure that corporate resources are accessed from appropriately managed devices.

Pattern 4: Protect administrators

Users: Privileged administrators
Resources: Sensitive resources
Grant: Require authentication strength and/or compliant device

This creates stronger controls for high-value identities.

Pattern 5: Block legacy authentication

Users: All users
Client app: Legacy authentication clients
Grant: Block access

This prevents older authentication methods from bypassing modern security controls.

Pattern 6: Respond to risky sign-ins

Users: Users affected by risk policy
Condition: Elevated sign-in risk
Grant: Require MFA or block access

This allows security controls to respond dynamically to risk.

36. Conditional Access and Authentication Methods

Conditional Access determines when additional authentication is required.

Authentication policies determine which authentication methods are available.

For example:

Conditional Access: Require authentication strength.

The authentication-strength configuration then determines what authentication methods satisfy that requirement.

This distinction is important.

Conditional Access

When should stronger authentication be required?

Authentication methods/authentication strength

What authentication is strong enough?

37. Conditional Access and Microsoft Intune

Conditional Access and Microsoft Intune frequently work together.

A typical pattern is:

Intune evaluates device compliance → Conditional Access requires a compliant device → Access allowed or denied

For example:

A device is:

Encrypted
Running an approved operating-system version
Protected by required security software
Meeting organizational compliance policies

Intune marks the device compliant.

Conditional Access then allows the user to access the protected resource because the policy requirement has been satisfied.

38. Conditional Access and Microsoft Entra ID Protection

Microsoft Entra ID Protection provides risk signals.

Conditional Access can use these signals to make access decisions.

This creates a relationship:

ID Protection detects risk → Conditional Access responds to risk

For example:

High sign-in risk → Require stronger authentication.

Or:

High user risk → Require remediation.

39. Conditional Access for AI and Agents

As AI workloads increasingly use identities and agents, Conditional Access can also participate in securing AI-related access scenarios.

The SC-500 material you provided specifically includes AI security topics involving:

Microsoft Entra Agent Identity
Microsoft Defender XDR
Copilot Studio
Microsoft Foundry
Microsoft Defender for Cloud
Microsoft Purview

Conditional Access should therefore be understood as part of a larger identity-centric security architecture rather than as a control that applies only to traditional human users.

40. Common Implementation Mistakes

Mistake 1: Enabling a broad policy immediately

A policy that applies to all users and all resources can have a massive impact.

Better: Use report-only mode and test first.

Mistake 2: Forgetting exclusions

A policy might unintentionally affect emergency access accounts or other critical identities.

Better: Carefully evaluate exclusions.

Mistake 3: Using block access too broadly

A block policy can cause widespread outages.

Better: Test thoroughly before enforcement.

Mistake 4: Confusing user risk and sign-in risk

These represent different security signals.

Remember:

User risk = account compromise

Sign-in risk = suspicious authentication event

Mistake 5: Assuming MFA and authentication strength are identical

Authentication strength can impose more specific authentication requirements than a generic MFA requirement.

Mistake 6: Assuming report-only means nothing is evaluated

Report-only policies are evaluated during sign-in; they simply don’t enforce their grant or session controls. Results can be reviewed in sign-in logs and reporting tools.

Mistake 7: Ignoring workload identities

A policy scoped to users isn’t automatically a policy protecting service principals.

Use workload-identity Conditional Access where appropriate.

41. Conditional Access Deployment Strategy

A good deployment strategy is:

Step 1 — Identify the security objective

Example:

Require MFA for privileged administrators.

Step 2 — Identify the users

Example:

Members of the Security Administrators group.

Step 3 — Identify the resources

Example:

Sensitive administrative applications.

Step 4 — Identify the conditions

Example:

Any location.

Step 5 — Define the grant control

Example:

Require authentication strength.

Step 6 — Define exclusions

Example:

Emergency access accounts.

Step 7 — Deploy in report-only mode

Observe the expected impact.

Step 8 — Test

Test:

Included users
Excluded users
Different devices
Different locations
Different applications
Different authentication methods

Step 9 — Review logs

Use sign-in logs and Conditional Access reporting.

Step 10 — Enable the policy

Only after validating the expected behavior.

Microsoft currently recommends using report-only mode and reviewing policy impact before enforcement.

42. SC-500 Conditional Access Quick Reference

Concept	Key point
Conditional Access	Context-based access control
Users/groups	Defines who the policy applies to
Workload identities	Controls supported non-user identities such as service principals
Target resources	Defines what the policy protects
Conditions	Determine when the policy applies
Locations	Uses network/location context
Device platforms	Evaluates device platform
User risk	Likelihood that the account is compromised
Sign-in risk	Likelihood that the current sign-in is suspicious
Grant controls	Determine what is required to gain access
MFA	Requires multifactor authentication
Authentication strength	Requires a particular authentication strength
Compliant device	Requires Intune-compliant device
Hybrid joined device	Requires Microsoft Entra hybrid joined device
Approved client app	Requires an approved application
App protection policy	Requires an applicable Intune app-protection policy
Block access	Denies access
Session controls	Control aspects of an authenticated session
Sign-in frequency	Controls how often authentication is required
Report-only	Evaluates without enforcing grant/session controls
What If	Simulates which policies would apply
Sign-in logs	Shows policy evaluation for actual sign-ins
Emergency access accounts	Help prevent administrative lockout
Zero Trust	Conditional Access supports explicit verification and least privilege

Practice Exam Questions

Question 1

An organization wants to require MFA whenever employees access Microsoft 365 from outside the company’s trusted corporate networks.

Which Conditional Access configuration should you use?

A. Include all users, exclude trusted locations, and require MFA

B. Include trusted locations and block access

C. Include all users and require a compliant device

D. Include all users and require an approved client application

Answer: A

Explanation: The policy should target the users and apply when the sign-in originates from locations other than the organization’s trusted locations. The appropriate grant control is Require multifactor authentication.

Question 2

A security administrator wants to determine which Conditional Access policies would apply if a specific user attempted to access an application from an Android device without actually performing the sign-in.

Which tool should the administrator use?

A. Microsoft Entra audit logs

B. Conditional Access What If

C. Microsoft Defender for Cloud

D. Access reviews

Answer: B

Explanation: The Conditional Access What If tool allows administrators to simulate a sign-in scenario and determine which enabled or report-only Conditional Access policies would apply.

Question 3

An organization wants to deploy a new Conditional Access policy requiring compliant devices. Administrators want to evaluate the policy’s effect without preventing users from accessing applications.

What should they do first?

A. Enable the policy

B. Configure the policy as a block policy

C. Configure the policy in report-only mode

D. Disable all existing Conditional Access policies

Answer: C

Explanation: Report-only mode evaluates the policy without enforcing its grant or session controls. Administrators can review the results in sign-in logs and Conditional Access reporting before enabling the policy.

Question 4

A company wants administrators accessing sensitive applications to use phishing-resistant authentication rather than simply satisfying a generic MFA requirement.

Which Conditional Access control is most appropriate?

A. Require an approved client app

B. Require authentication strength

C. Require a compliant device

D. Require password change

Answer: B

Explanation: Authentication strength allows an organization to specify the strength and type of authentication required. This is more precise than simply requiring generic MFA.

Question 5

An organization wants to block users from accessing corporate applications from unknown or unsupported device platforms.

Which Conditional Access configuration should be used?

A. Require MFA

B. Require an authentication strength

C. Require a compliant device

D. Block access based on the device platform condition

Answer: D

Explanation: The policy should use the Device platforms condition to identify the relevant platforms and use Block access as the grant control. Device-platform policies should be designed carefully because platform identification alone isn’t a complete device-security control.

Question 6

A Conditional Access policy applies to all users and requires MFA. The organization’s emergency access account is also subject to the policy. A configuration error causes all administrators to be unable to satisfy the policy.

What is the primary concern?

A. The emergency account could be locked out along with other administrators

B. The policy will automatically disable MFA

C. The emergency account will become a service principal

D. Conditional Access will automatically remove the policy

Answer: A

Explanation: Emergency or break-glass accounts should be appropriately excluded from policies that could cause administrative lockout. They provide a recovery mechanism if Conditional Access is misconfigured.

Question 7

An administrator wants to require both MFA and a compliant device before users can access a sensitive application.

How should the Conditional Access grant controls be configured?

A. Require one of the selected controls

B. Require only MFA

C. Require all the selected controls

D. Use session controls instead of grant controls

Answer: C

Explanation: Because users must satisfy both requirements, the policy should use Require all the selected controls. Conditional Access supports both “require all” and “require one” behavior when multiple grant controls are configured.

Question 8

A user has a low user-risk level but the current authentication request has been identified as highly suspicious.

Which Conditional Access condition should be used to respond specifically to the current authentication event?

A. User risk

B. Sign-in risk

C. Device platform

D. Named location

Answer: B

Explanation: Sign-in risk evaluates the likelihood that a particular authentication request isn’t being performed by the legitimate identity owner. User risk, by contrast, concerns the likelihood that the user’s account or identity is compromised.

Question 9

A user reports that access to an application was denied. The security administrator needs to determine which Conditional Access policy caused the denial and why the policy applied.

Where should the administrator investigate first?

A. Microsoft Entra sign-in logs

B. Azure Cost Management

C. Azure Resource Graph

D. Microsoft Entra access reviews

Answer: A

Explanation: Microsoft Entra sign-in logs provide detailed information about Conditional Access policy evaluation for individual sign-in events, including policies that applied, succeeded, failed, or weren’t applied.

Question 10

An organization has a Conditional Access policy that applies to all users accessing a sensitive application. The policy requires MFA. The organization also has a second policy that applies only to administrators and requires a compliant device.

An administrator attempts to access the application.

What should the administrator expect?

A. Only the first policy can apply because Conditional Access policies cannot overlap

B. Only the more restrictive policy applies

C. The administrator is automatically excluded from the first policy

D. Multiple applicable Conditional Access policies can affect the sign-in

Answer: D

Explanation: Multiple Conditional Access policies can apply to the same sign-in. The administrator can therefore be subject to both the MFA requirement from the first policy and the compliant-device requirement from the second policy. This is why policy interactions must be evaluated together during deployment and troubleshooting.

Final Exam Takeaways

For the SC-500 exam, remember Conditional Access as a context-driven access decision engine:

Who + What + Conditions → Grant/Block + Session Controls

The distinctions most worth memorizing are:

User risk ≠ sign-in risk
Grant controls ≠ session controls
MFA ≠ authentication strength
User policies ≠ workload-identity policies
Report-only evaluates but doesn’t enforce
What If simulates policy applicability
Sign-in logs show what happened during an actual sign-in
Require all ≠ require one
Compliant device ≠ hybrid joined device
Block access is powerful and must be tested carefully
Emergency access accounts should be protected from accidental lockout
Multiple Conditional Access policies can affect the same sign-in
Conditional Access works particularly well alongside Microsoft Entra ID Protection and Intune

A useful exam mental model is:

Identify the user → identify the resource → identify the conditions → determine the required control → test the policy → monitor the result.

Go to the SC-500 Exam Prep Hub main page

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

Implement and configure authentication methods, including multifactor authentication (MFA) and passwordless (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%)
   --> Secure access to resources by using Microsoft Entra ID
      --> Implement and configure authentication methods, including multifactor authentication (MFA) and passwordless

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

Authentication is the process of establishing that a user, application, device, or other identity is who or what it claims to be.

In Microsoft Entra ID, authentication is a foundational component of a broader Zero Trust security strategy. Strong authentication reduces the risk associated with stolen, guessed, or phished passwords and provides organizations with additional signals that can be used to establish identity.

For the SC-500 exam, this topic centers on understanding how to:

Configure authentication methods in Microsoft Entra ID
Implement multifactor authentication (MFA)
Implement passwordless authentication
Understand authentication method policies
Select appropriate authentication methods for different scenarios
Understand authentication strengths
Manage authentication method registration
Understand the relationship between authentication methods and Conditional Access
Troubleshoot authentication-related issues

A useful way to think about the topic is:

Authentication methods determine how an identity proves who it is; Conditional Access determines when stronger authentication should be required.

1. Authentication vs. Authorization

Before examining authentication methods, it is important to distinguish authentication from authorization.

Authentication

Authentication answers:

Who are you?

Examples:

Password
Microsoft Authenticator
FIDO2 security key
Windows Hello for Business
Certificate

Authorization

Authorization answers:

What are you allowed to do?

Examples:

Microsoft Entra roles
Azure RBAC
Application permissions
Group membership

Therefore:

Authentication → establishes identity

Authorization → determines access

A user could successfully authenticate but still be denied access because they don’t have the required permissions.

2. Authentication Factors

Multifactor authentication is based on combining different types of authentication factors.

The traditional categories are:

Something you know

Examples:

Password
PIN

Something you have

Examples:

Security key
Authenticator application
Hardware token

Something you are

Examples:

Fingerprint
Facial recognition

The security benefit of MFA comes from requiring multiple independent factors.

For example:

Password + Authenticator approval

is stronger than:

Password alone.

3. What Is Microsoft Entra Authentication?

Microsoft Entra ID provides authentication services for users and applications accessing Microsoft cloud resources and integrated applications.

Authentication can involve:

A username or other identifier
A credential or authentication method
Additional authentication requirements
Risk and contextual evaluation
Token issuance
Authorization to the requested resource

The authentication experience can vary depending on:

User
Application
Device
Location
Authentication method
Risk
Conditional Access policies

4. Microsoft Entra Authentication Methods

Microsoft Entra supports a variety of authentication methods.

Important methods for the SC-500 exam include:

Password
Microsoft Authenticator
Passkeys/FIDO2 security keys
Windows Hello for Business
Certificate-based authentication
Temporary Access Pass
OATH hardware/software tokens
SMS
Voice calls
Email OTP in supported scenarios

Not every method provides the same level of security.

For example:

A phishing-resistant authentication method generally provides stronger protection than SMS-based authentication.

Understanding those differences is more important than simply memorizing the list.

5. Password Authentication

Passwords are the traditional authentication mechanism.

They are easy to understand and widely supported, but they have significant weaknesses.

Passwords can be:

Guessed
Reused
Shared
Stolen
Phished
Captured through malware
Exposed through data breaches

This is one reason Microsoft promotes stronger authentication methods and passwordless authentication.

6. Passwordless Authentication

Passwordless authentication allows users to authenticate without entering a traditional account password.

Microsoft Entra passwordless methods include technologies such as:

Windows Hello for Business
FIDO2 security keys
Passkeys
Microsoft Authenticator passwordless phone sign-in

Passwordless authentication can improve security while also reducing password-related support issues.

7. Why Passwordless Is More Secure

Passwords are attractive targets because attackers can attempt to obtain them remotely.

Passwordless authentication can instead use:

Cryptographic keys
Device-bound credentials
Biometrics
PINs
Secure hardware

For example, with Windows Hello for Business, the user’s private key is protected on the device rather than being transmitted as a password.

The user may unlock the credential using:

PIN
Fingerprint
Facial recognition

The important distinction is:

The biometric or PIN unlocks the credential; it isn’t necessarily the credential itself.

8. Microsoft Authenticator

The Microsoft Authenticator app can support several authentication experiences.

It can be used for:

MFA
Passwordless authentication
Number matching
Push notifications
Account registration

For passwordless phone sign-in, the user authenticates through the Authenticator app rather than entering a traditional password.

9. Number Matching

Number matching is an important security improvement for Microsoft Authenticator push notifications.

Instead of simply asking the user:

“Approve this sign-in?”

the user is presented with a number during the sign-in process and must enter the matching number in the Authenticator application.

This helps reduce attacks in which users blindly approve unexpected authentication requests.

Example

The sign-in page displays:

42

The Authenticator app asks the user to enter:

42

The user enters the number and completes the authentication process.

10. Microsoft Authenticator Passwordless Authentication

With passwordless authentication using Microsoft Authenticator, the user doesn’t need to enter a password during the authentication experience.

A typical flow is:

User enters their username.
Microsoft Entra initiates authentication.
The user receives an authentication request.
The user interacts with Microsoft Authenticator.
Number matching may be required.
The user completes the authentication.
Authentication succeeds.

This can provide a more secure and convenient alternative to password-based authentication.

11. FIDO2 Security Keys

FIDO2 security keys are physical authentication devices that use public-key cryptography.

Examples include USB, NFC, or other compatible security keys.

The key contains cryptographic credentials that can be used to authenticate the user.

A major advantage is:

FIDO2 authentication is designed to resist phishing.

The authentication process is cryptographically bound to the legitimate website or service.

12. Passkeys

Passkeys are another passwordless authentication technology based on public-key cryptography.

Passkeys can be stored on supported devices or credential managers and can use local user verification such as:

Biometrics
Device PIN
Other supported local unlock mechanisms

The private key remains protected by the credential provider while the service uses the corresponding public key.

Passkeys are based on the FIDO authentication model.

13. Windows Hello for Business

Windows Hello for Business provides passwordless authentication for Windows devices.

It uses asymmetric cryptography.

A private key is protected on the user’s device, while the corresponding public key is registered with the identity provider.

The user typically unlocks the credential using:

PIN
Fingerprint
Facial recognition

Windows Hello for Business is particularly useful for organizations with managed Windows devices.

14. Windows Hello for Business vs. Microsoft Authenticator

These are both passwordless approaches, but they serve different scenarios.

Feature	Windows Hello for Business	Microsoft Authenticator
Primary environment	Windows devices	Mobile devices
Passwordless	Yes	Yes
Local device credential	Yes	Uses mobile authentication
Biometrics	Supported	Supported by device
PIN	Supported	Device/app authentication mechanisms
Enterprise Windows integration	Strong	Less device-centric
Typical use	Managed Windows workstation	Mobile/passwordless sign-in

Exam clue

If the scenario emphasizes:

Windows device + enterprise credentials + PIN/biometrics

Think:

Windows Hello for Business

If it emphasizes:

Mobile phone + passwordless authentication

Think:

Microsoft Authenticator

15. Certificate-Based Authentication

Microsoft Entra also supports certificate-based authentication (CBA).

With CBA, the user authenticates using a certificate rather than a traditional password.

This can be useful in organizations that already have a public key infrastructure (PKI).

Certificate-based authentication can provide strong authentication and can be incorporated into authentication-strength requirements.

16. Temporary Access Pass

A Temporary Access Pass (TAP) is a time-limited passcode that can be used to bootstrap authentication.

It is particularly useful when a user needs to register a passwordless authentication method but doesn’t yet have another strong authentication method available.

For example:

New employee receives a Temporary Access Pass.
Employee uses TAP to authenticate.
Employee registers Microsoft Authenticator or another passwordless method.
TAP expires.

This makes TAP particularly useful for:

New-user onboarding
Passwordless registration
Recovery scenarios
Registering authentication methods

Important

A TAP is temporary.

It is not intended to replace a user’s long-term authentication method.

17. Multifactor Authentication

Multifactor authentication (MFA) requires users to satisfy authentication requirements involving multiple factors.

For example:

Password + Authenticator

or:

Password + FIDO2 security key

MFA provides additional protection when one authentication factor is compromised.

18. Microsoft Entra MFA

Microsoft Entra MFA can be required using Conditional Access and other supported authentication mechanisms.

A common configuration is:

User signs in → Conditional Access evaluates conditions → MFA is required → User completes MFA → Access continues

This is different from configuring the authentication method itself.

For example:

Authentication method

Microsoft Authenticator is enabled.

Conditional Access

The organization requires MFA when users access sensitive applications.

Therefore:

Authentication methods provide the mechanisms; Conditional Access can require them based on context.

19. Authentication Method Policies

Administrators can control which authentication methods users are permitted to register and use.

Authentication method policies help organizations:

Enable or disable methods
Define who can use particular methods
Configure method-specific settings
Manage authentication-method availability

This is important because simply having an authentication method available doesn’t mean every user should be permitted to use it.

20. Authentication Method Registration

Users need to register their authentication methods before they can use many of them.

For example, a user may need to register:

Microsoft Authenticator
FIDO2 security key
Phone number
Other supported methods

Microsoft Entra provides registration experiences that help users configure authentication methods.

Administrators should consider:

Which users can register
Which methods they can register
How registration is secured
How users recover access
Which methods satisfy organizational security requirements

21. Authentication Registration Policy

Organizations can control which authentication methods users are encouraged or required to register.

For example, an organization could prioritize:

Microsoft Authenticator

over:

SMS

for MFA registration.

This helps organizations gradually move users toward stronger authentication methods.

22. Self-Service Password Reset

Although passwordless authentication reduces reliance on passwords, organizations may still have users who authenticate with passwords.

Self-Service Password Reset (SSPR) allows users to reset their passwords without requiring help-desk intervention.

SSPR can use registered authentication methods to verify the user’s identity.

For example:

User forgets password → verifies identity → creates new password.

23. SSPR and MFA Are Related but Different

This distinction is important.

MFA

Protects authentication to resources.

SSPR

Helps users reset or change passwords.

They can use some of the same authentication methods, but they solve different problems.

24. Authentication Strength

Authentication strength allows an organization to specify the type or strength of authentication required for access.

This is particularly useful with Conditional Access.

Instead of saying:

Require MFA.

an organization can say:

Require a phishing-resistant authentication method.

This provides greater control over which authentication methods satisfy the policy.

25. Built-In Authentication Strengths

Microsoft Entra provides predefined authentication-strength configurations, including concepts such as:

Multifactor authentication
Passwordless MFA
Phishing-resistant MFA

These allow organizations to align authentication requirements with the sensitivity of the resource.

26. Phishing-Resistant Authentication

Phishing-resistant authentication is designed to prevent attackers from successfully using stolen authentication information on a fraudulent website.

Examples include:

FIDO2 security keys
Passkeys
Windows Hello for Business
Certain certificate-based authentication scenarios

By contrast, methods such as SMS codes can potentially be intercepted or socially engineered.

Exam clue

If the question says:

“The organization requires an authentication method that is resistant to phishing.”

Look for:

FIDO2 / passkeys / Windows Hello for Business / appropriate phishing-resistant authentication strength

rather than simply:

SMS MFA

27. Authentication Methods and Conditional Access

These two concepts work together.

Authentication methods

Determine what authentication mechanisms are available.

Conditional Access

Determines when a particular level or type of authentication is required.

For example:

Authentication method policy

Enable FIDO2 for administrators.

Conditional Access

Require phishing-resistant MFA for administrators accessing privileged resources.

This combination provides much stronger control than simply enabling authentication methods globally.

28. Example: Protect Administrators

Suppose an organization wants to protect privileged administrators.

A good design could be:

Step 1

Enable a strong authentication method such as FIDO2 or Windows Hello for Business.

Step 2

Ensure administrators can register the method.

Step 3

Create a Conditional Access policy targeting privileged administrators.

Step 4

Require an appropriate authentication strength.

Step 5

Monitor authentication activity.

The result is stronger protection for high-value identities.

29. Example: Passwordless Deployment

A company wants to move users away from passwords.

A possible deployment strategy is:

Phase 1

Enable passwordless methods.

Phase 2

Allow users to register them.

Phase 3

Use Temporary Access Pass to help users bootstrap registration.

Phase 4

Train users.

Phase 5

Use Conditional Access to require stronger authentication for appropriate applications.

Phase 6

Gradually reduce reliance on passwords.

This staged approach reduces deployment risk.

30. Authentication Method Selection

Choosing the right authentication method depends on the scenario.

Scenario	Strong candidate
Managed Windows workstation	Windows Hello for Business
Phishing-resistant hardware authentication	FIDO2 security key
Passwordless mobile authentication	Microsoft Authenticator
Passwordless modern authentication	Passkey
Existing PKI infrastructure	Certificate-based authentication
Bootstrap passwordless registration	Temporary Access Pass
Legacy/simple MFA scenario	SMS or voice, where supported
Strong privileged-user authentication	Phishing-resistant authentication

The strongest option isn’t always the easiest to deploy, so security requirements and operational considerations must both be evaluated.

31. Why SMS Is Weaker

SMS-based authentication can provide an additional authentication factor, but it has known security limitations.

Potential threats include:

SIM swapping
Social engineering
Phone-number takeover
Interception
Phishing

Therefore:

SMS can be better than password-only authentication, but it generally isn’t the preferred option when stronger phishing-resistant methods are available.

32. Authentication Method vs. Authentication Strength

This distinction can appear in scenario questions.

Authentication method

Examples:

FIDO2
Authenticator
SMS
Windows Hello

Authentication strength

Describes the security requirements that an authentication method or combination must satisfy.

For example:

Conditional Access requires phishing-resistant MFA.

The administrator then needs to configure users with authentication methods capable of satisfying that requirement.

33. Passwordless Does Not Mean “No User Verification”

Passwordless authentication doesn’t mean that the user doesn’t have to prove control of the credential.

For example:

Windows Hello for Business might require:

PIN or biometric verification.

FIDO2 might require:

Security-key interaction and/or PIN/biometric verification.

Passkeys may use:

Device-based user verification.

The key difference is:

The user isn’t authenticating by transmitting a traditional password.

34. Common Authentication Security Principles

A secure authentication strategy should:

Prefer phishing-resistant authentication
Reduce password dependency
Use MFA for appropriate scenarios
Protect privileged accounts more strongly
Minimize weaker authentication methods
Control authentication-method registration
Monitor authentication activity
Provide secure recovery mechanisms
Use Conditional Access for contextual requirements
Regularly review authentication methods

35. Common Exam Traps

Trap 1: MFA = passwordless

False.

MFA can use a password as one of its factors.

Example:

Password + Authenticator = MFA

Passwordless authentication doesn’t use a traditional password.

Trap 2: Authentication method = Conditional Access

False.

Authentication methods define available authentication mechanisms.

Conditional Access determines when authentication requirements should apply.

Trap 3: SMS is phishing-resistant

False.

SMS is not generally considered a phishing-resistant authentication method.

Trap 4: TAP is a permanent credential

False.

A Temporary Access Pass is designed to be temporary and is commonly used to bootstrap authentication-method registration.

Trap 5: Biometrics are always the authentication credential

Not necessarily.

With Windows Hello for Business, for example, biometric verification can unlock a credential stored on the device.

Trap 6: SSPR is the same as MFA

False.

SSPR addresses password reset.

MFA strengthens authentication.

Trap 7: Passwordless means no authentication

False.

Passwordless authentication still strongly authenticates the user; it simply doesn’t rely on a traditional password.

Trap 8: Enabling an authentication method automatically requires users to use it

False.

Enabling a method and requiring a method are separate concepts.

Authentication-method configuration controls availability.

Conditional Access and authentication-strength requirements can control when stronger authentication is required.

36. Recommended Authentication Strategy

A mature Microsoft Entra authentication strategy can look like this:

Tier 1 — Eliminate unnecessary passwords

Adopt passwordless authentication where practical.

Tier 2 — Protect users with MFA

Require MFA for appropriate applications and scenarios.

Tier 3 — Protect privileged identities

Require stronger, preferably phishing-resistant authentication for administrators.

Tier 4 — Use Conditional Access

Apply authentication requirements based on:

User
Resource
Device
Location
Risk
Application
Other contextual signals

Tier 5 — Monitor

Review authentication activity and investigate suspicious behavior.

37. SC-500 Quick Reference

Concept	Remember
Authentication	Proves identity
Authorization	Determines permissions
MFA	Uses multiple authentication factors
Passwordless	Authenticates without traditional password
Microsoft Authenticator	Supports MFA and passwordless authentication
Number matching	Helps defend against accidental MFA approval
FIDO2	Strong, phishing-resistant authentication
Passkeys	Passwordless, public-key-based authentication
Windows Hello for Business	Passwordless Windows authentication
Certificate-based authentication	Uses certificates instead of passwords
Temporary Access Pass	Temporary bootstrap credential
SSPR	Enables user password reset
Authentication methods	Define available authentication mechanisms
Authentication strength	Defines required authentication security level
Conditional Access	Determines when access/authentication requirements apply
Phishing-resistant authentication	Designed to resist credential phishing
SMS	Weaker than modern phishing-resistant methods
Registration	Establishes the user’s authentication method
Privileged users	Should receive stronger authentication protections

Practice Exam Questions

Question 1

An organization wants users to authenticate to Microsoft Entra ID without entering a traditional password. Users have managed Windows 11 devices and can use a PIN or biometric authentication.

Which authentication method is the best fit?

A. SMS authentication

B. Windows Hello for Business

C. Voice call authentication

D. Password hash synchronization

Answer: B

Explanation: Windows Hello for Business provides passwordless authentication for Windows devices and can use a PIN or biometric gesture to unlock the user’s credential. The private key is protected on the device.

Question 2

A security administrator wants to protect privileged administrators against phishing attacks. The organization wants administrators to use hardware security keys based on public-key cryptography.

Which authentication method should the administrator implement?

A. SMS

B. Voice call

C. FIDO2 security keys

D. Email OTP

Answer: C

Explanation: FIDO2 security keys use public-key cryptography and are designed to provide phishing-resistant authentication. They are particularly appropriate for protecting privileged identities.

Question 3

An organization is deploying passwordless authentication. Many users do not yet have a registered passwordless authentication method.

The administrator needs a temporary authentication mechanism that users can use to bootstrap registration of a passwordless method.

What should the administrator use?

A. Temporary Access Pass

B. Azure RBAC

C. Security Defaults

D. Access reviews

Answer: A

Explanation: A Temporary Access Pass (TAP) is a time-limited credential that can be used to bootstrap authentication-method registration, including passwordless methods. It isn’t intended to be a permanent authentication credential.

Question 4

An organization currently uses SMS-based MFA but wants to provide administrators with authentication that is resistant to phishing.

Which approach should the organization take?

A. Require longer SMS codes

B. Increase the SMS message frequency

C. Require password changes every 30 days

D. Require a phishing-resistant authentication method

Answer: D

Explanation: SMS provides an additional factor but isn’t considered phishing-resistant. The organization should use a phishing-resistant method such as FIDO2, passkeys, Windows Hello for Business, or another method that satisfies the required authentication strength.

Question 5

An administrator wants to require MFA whenever users access a sensitive application. The organization has already enabled Microsoft Authenticator as an authentication method.

Which capability should the administrator use to determine when users must perform MFA?

A. Microsoft Entra Conditional Access

B. Azure Resource Manager locks

C. Azure Policy

D. Azure Storage firewall

Answer: A

Explanation: Authentication-method configuration makes Microsoft Authenticator available. Conditional Access can determine when MFA must be performed based on users, resources, conditions, and other contextual signals.

Question 6

A user has configured Windows Hello for Business with facial recognition. Which statement best describes how the biometric is used?

A. The user’s facial image is transmitted to Microsoft Entra ID as the password

B. The biometric replaces all cryptographic credentials

C. The biometric can be used to unlock the credential on the device

D. The biometric is stored as the user’s Microsoft Entra password

Answer: C

Explanation: Windows Hello for Business uses asymmetric cryptography. The local PIN or biometric can unlock the credential on the device. The biometric isn’t simply transmitted to Microsoft Entra ID as a password.

Question 7

An organization wants users to be able to reset forgotten passwords without contacting the help desk. The organization wants users to verify their identity using registered authentication methods.

Which feature should be implemented?

A. Microsoft Entra Privileged Identity Management

B. Self-Service Password Reset

C. Azure Policy

D. Microsoft Defender for Cloud

Answer: B

Explanation: Self-Service Password Reset (SSPR) allows users to reset their passwords after satisfying the configured identity-verification requirements. MFA and SSPR are related but serve different purposes.

Question 8

An organization wants to require administrators to use authentication that meets a phishing-resistant authentication requirement. The administrator wants Conditional Access to enforce this requirement rather than simply requiring generic MFA.

Which capability should be configured?

A. Named locations

B. Authentication strength

C. Device compliance

D. Sign-in frequency

Answer: B

Explanation: Authentication strength allows Conditional Access to require a specific level or type of authentication, including phishing-resistant authentication. This is more precise than simply selecting a generic “Require MFA” control.

Question 9

An organization enables Microsoft Authenticator push notifications. The security team wants to reduce the risk that users will accidentally approve fraudulent authentication requests.

Which capability should be used?

A. Number matching

B. Password expiration

C. Azure Resource Locks

D. SSPR

Answer: A

Explanation: Number matching requires the user to enter the number displayed during the sign-in process into the Authenticator application. This helps reduce accidental approval of unexpected authentication requests.

Question 10

An organization has enabled several authentication methods in Microsoft Entra ID. The security team wants to ensure that users can register only authentication methods approved for their particular group.

Which capability should the administrator configure?

A. Azure Policy

B. Azure Firewall

C. Authentication method policies

D. Resource locks

Answer: C

Explanation: Authentication method policies allow administrators to control which authentication methods are available to users and groups and configure method-specific settings. This allows organizations to manage authentication-method availability rather than simply enabling every method for everyone.

Final Exam Takeaways

For this SC-500 objective, the most important mental model is:

Authentication methods define how users authenticate. Conditional Access determines when stronger authentication is required. Authentication strength determines how strong that authentication must be.

And remember these high-value distinctions:

MFA can include a password; passwordless does not use a traditional password.
FIDO2, passkeys, and Windows Hello for Business are important passwordless/phishing-resistant technologies.
Microsoft Authenticator supports both MFA and passwordless authentication.
Number matching helps protect against unwanted Authenticator approvals.
Temporary Access Pass is primarily a temporary bootstrap mechanism.
SSPR is for password reset, not simply for enforcing MFA.
Authentication-method policies control method availability and configuration.
Authentication strength lets Conditional Access require a particular level/type of authentication.
Conditional Access determines when authentication requirements apply.
SMS MFA is weaker than modern phishing-resistant authentication.
Biometrics/PINs can unlock a device-bound credential rather than being transmitted as a password.
Privileged identities deserve stronger authentication requirements than ordinary users.

A useful exam formula is:

Available method → Registration → Conditional Access → Authentication strength → Authentication → Access.

Go to the SC-500 Exam Prep Hub main page

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

Implement and configure identity for applications, including enterprise applications and app registrations (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%)
   --> Secure access to resources by using Microsoft Entra ID
      --> Implement and configure identity for applications, including enterprise applications and app registrations

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

Modern cloud applications need identities just as users and devices do. Microsoft Entra ID provides the identity platform that applications use to authenticate, obtain tokens, access APIs, and authorize users or workloads.

For the SC-500 exam, it is important to understand the difference between an application registration, an application object, and an enterprise application/service principal. You should also understand how to configure authentication, permissions, consent, credentials, application roles, and access controls.

A particularly important concept is that App registrations and Enterprise applications are related but serve different purposes.

Microsoft Entra represents an application through an application object and service principal objects. The application object is essentially the application’s definition or blueprint, while the service principal is the application’s local identity in a particular tenant.

1. Application Identity in Microsoft Entra ID

An application that needs to authenticate through Microsoft Entra ID generally needs to be represented in the directory.

Consider an application called Contoso Expense Manager.

The application might need to:

Authenticate employees.
Request access to Microsoft Graph.
Call a custom API.
Restrict access to members of a particular group.
Use certificates instead of passwords.
Support single sign-on.
Operate across multiple Microsoft Entra tenants.

Microsoft Entra provides the identity infrastructure needed to accomplish these tasks.

The two most important objects to understand are:

Object	Primary purpose
Application object	Defines the application and its identity configuration
Service principal	Represents an instance of the application in a specific tenant

A useful way to remember this is:

Application object = blueprint
Service principal = local instance

An application normally has one application object in its home tenant, while it can have multiple service principals, including one in each tenant where the application is used.

2. What Is an App Registration?

An app registration is the process of registering an application with Microsoft Entra ID.

When you register an application, you tell Microsoft Entra how the application should interact with the identity platform.

An app registration can define:

Application name
Supported account types
Redirect URIs
Authentication configuration
API permissions
Exposed APIs
Application roles
Client credentials
Certificates
Federated credentials
Other identity-related configuration

Microsoft Entra uses this information when issuing tokens and determining how the application interacts with users and APIs.

Common application types

Applications can include:

Web applications
Single-page applications
Mobile applications
Desktop applications
Web APIs
Daemon/background applications

The application type affects how authentication and credentials should be configured.

3. Application Object vs. Service Principal

This is one of the most important concepts for the SC-500 exam.

Suppose a software vendor creates a multitenant application called Contoso CRM.

The vendor registers the application in its home tenant.

That registration creates an application object.

When another organization’s tenant uses the application, Microsoft Entra creates a service principal in that customer’s tenant.

Therefore:

                  APPLICATION
                       │
                       ▼
              Application Object
              (Home Tenant)
                       │
             ┌─────────┼─────────┐
             ▼         ▼         ▼
       Service       Service    Service
       Principal     Principal  Principal
       Tenant A      Tenant B   Tenant C

The application object contains the application’s global/default configuration.

The service principal represents the application’s identity within a particular tenant and contains tenant-specific settings such as permissions and assignments.

Exam tip

If a question asks:

“Where does an administrator configure which users in their organization can access an application?”

Think:

Enterprise application / service principal

If it asks:

“Where does the developer configure redirect URIs, exposed APIs, or application credentials?”

Think:

App registration / application object

4. App Registrations vs. Enterprise Applications

The Microsoft Entra admin center provides separate experiences for these objects.

App registrations

App registrations primarily manage the application’s definition.

Typical activities include:

Registering an application
Configuring authentication
Configuring redirect URIs
Defining API permissions
Creating client secrets
Uploading certificates
Defining application roles
Exposing APIs

Enterprise applications

Enterprise applications primarily manage the application’s presence and access within a particular tenant.

Typical activities include:

Assigning users and groups
Managing application access
Configuring tenant-specific settings
Reviewing permissions and consent
Managing Conditional Access-related controls
Managing single sign-on configuration for applicable applications
Viewing sign-in information

Microsoft describes Enterprise Applications as the management experience for service principals.

Simple exam distinction

If the question says…	Think…
Register an application	App registrations
Configure redirect URI	App registrations
Add client secret	App registrations
Add certificate	App registrations
Configure API permissions	App registrations
Define application roles	App registrations
Assign users to an application	Enterprise applications
Assign groups to an application	Enterprise applications
Control tenant-specific application access	Enterprise applications
Review application sign-ins	Enterprise applications
Manage a service principal	Enterprise applications

5. Application IDs and Object IDs

Several identifiers can appear when working with applications.

Two particularly important identifiers are:

Application (client) ID

The Application (client) ID identifies the application.

Applications use this value when communicating with Microsoft Entra ID.

It is commonly referred to as the:

Client ID
Application ID
App ID

Object ID

The Object ID identifies a specific Microsoft Entra directory object.

An application object and a service principal each have their own object ID.

This distinction becomes particularly important when managing applications programmatically.

Exam warning

Do not automatically treat:

Application (client) ID

and

Object ID

as interchangeable.

They identify different things.

6. Configure Supported Account Types

When registering an application, you must determine who can use it.

Common choices include:

Accounts in this organizational directory only

This creates a single-tenant application.

The application is intended for users in the application’s home Microsoft Entra tenant.

This is commonly appropriate for an organization’s internal line-of-business applications.

Accounts in any organizational directory

This creates a multitenant application.

Users from other Microsoft Entra tenants can authenticate to the application, subject to the appropriate configuration and consent.

This is common for SaaS applications intended for customers from multiple organizations.

Accounts in any organizational directory and personal Microsoft accounts

This allows organizational accounts and supported personal Microsoft accounts.

Exam decision

If a question says:

“The application will only be used by employees of the organization.”

A single-tenant configuration is generally the appropriate choice.

If the question says:

“The application is a SaaS application that must be accessed by customers from multiple Microsoft Entra tenants.”

Think:

Multitenant application.

Microsoft Entra’s application model explicitly distinguishes single-tenant and multitenant applications.

7. Configure Authentication

The Authentication configuration of an app registration determines how users or applications authenticate.

Depending on the application type, configuration can include:

Platform configuration
Redirect URIs
Front-channel logout URL
ID token issuance
Access token issuance
Supported authentication flows

The authentication configuration must correspond to the application architecture.

For example:

A web application has a server component and can protect confidential credentials.
A single-page application executes in the browser and cannot safely store a client secret.
A daemon application runs without interactive user involvement.

Understanding the difference between public clients and confidential clients is important.

8. Redirect URIs

A redirect URI, also called a reply URL, specifies where Microsoft Entra ID sends the authentication response after authentication.

For example:

https://app.contoso.com/signin-oidc

The redirect URI is an important security control.

Microsoft Entra validates the redirect URI against the URIs configured for the application.

Why does this matter?

Imagine an attacker attempting to manipulate an authentication response so that it is sent to an unauthorized location.

Restricting valid redirect URIs helps prevent this type of attack.

Exam scenario

If the question says:

“Users successfully authenticate, but the application returns an error because the authentication response cannot be redirected to the application.”

Check:

Redirect URI configuration.

The redirect URI configured by the application must correspond to an allowed URI in the app registration.

9. Client Secrets

A client secret is a credential that a confidential client can use to authenticate itself to Microsoft Entra ID.

Client secrets are commonly used by:

Web applications
Daemon applications
Background services
Server-side applications

For example:

			
Application
     │
     │ client ID + client secret
     ▼
Microsoft Entra ID
     │
     ▼
Access token

		

Security concerns

Client secrets are sensitive credentials.

They should:

Never be embedded in source code.
Never be committed to a public Git repository.
Be protected from unauthorized access.
Be rotated regularly.
Have appropriate expiration periods.

For Azure-hosted applications, a managed identity may eliminate the need to manage a client secret altogether.

10. Certificates

Certificates provide another way for a confidential application to authenticate.

Instead of sending a shared secret, the application proves possession of the corresponding private key.

For confidential clients, Microsoft recommends certificates over client secrets when practical because certificates provide stronger security characteristics.

A simplified model is:

			
Application
    │
    │ Certificate/private key
    ▼
Microsoft Entra ID
    │
    │ validates public key
    ▼
Authentication

		

Exam consideration

If a question asks for a more secure alternative to a client secret for a confidential application, consider:

Certificate-based authentication.

11. Federated Credentials

Federated credentials provide another approach for workload authentication.

They are particularly useful when an external workload already has an identity issued by a trusted identity provider.

Instead of storing a long-lived client secret, the workload can exchange a trusted token for a Microsoft Entra access token.

This can be especially valuable for:

CI/CD pipelines
GitHub Actions
Kubernetes workloads
Other supported external workload identity scenarios

The major security benefit is reducing the need for long-lived application secrets.

12. Managed Identities

For Azure resources that support managed identities, a managed identity is often preferable to maintaining credentials manually.

For example:

			
Azure Function
      │
      │ Managed Identity
      ▼
Microsoft Entra ID
      │
      ▼
Azure Key Vault

		

The application does not need to store a client secret.

Microsoft explicitly recommends considering managed identities instead of manually managed service principals when an application runs on an Azure service that supports managed identities and accesses resources that support Microsoft Entra authentication.

Exam tip

If the scenario says:

“An Azure-hosted application needs to access Azure Key Vault without storing credentials.”

Think:

Managed identity.

13. API Permissions

Applications frequently need to access APIs.

For example, an application might need to access:

Microsoft Graph
Azure resources
A custom API
Another organization’s API

The app registration can specify the APIs and permissions the application requires.

There are two major permission models you should know.

14. Delegated Permissions

Delegated permissions are used when an application accesses a resource on behalf of a signed-in user.

The effective access is generally constrained by both:

The permissions granted to the application.
The privileges available to the signed-in user.

For example:

			
User
 │
 │ signs in
 ▼
Application
 │
 │ delegated permission
 ▼
Microsoft Graph

		

A typical example would be an application that reads a user’s profile or email while that user is actively using the application.

Exam clue

If the scenario says:

“The application accesses data on behalf of the signed-in user.”

Think:

Delegated permissions.

15. Application Permissions

Application permissions are designed for applications that operate without a signed-in user.

They are commonly used by:

Background services
Daemons
Scheduled jobs
Automation
Server-to-server applications

For example:

			
Background service
       │
       │ Application permission
       ▼
Microsoft Graph

		

Because application permissions can grant broad access, they require careful governance and frequently require administrator consent.

Microsoft Graph, for example, supports application permissions that allow non-interactive applications to access organizational resources.

Key distinction

Delegated	Application
User is involved	No user required
Runs on behalf of user	Runs as the application
User context matters	Application identity determines access
Interactive scenarios	Daemon/background scenarios

Exam shortcut

“On behalf of a user” → Delegated

“As the application” → Application

16. Consent

Consent is the mechanism through which permissions requested by an application can be authorized.

There are two major concepts:

User consent

A user may be allowed to consent to certain permissions depending on tenant configuration and the permissions requested.

Admin consent

An administrator can consent to permissions on behalf of users in the organization.

Admin consent is particularly important when the requested permissions are considered privileged or when organizational policy requires administrator approval.

For example:

			
Application
     │
     │ requests Mail.Read
     ▼
Microsoft Entra
     │
     ▼
Admin consent
     │
     ▼
Permission granted

		

Security principle

Do not automatically grant every requested permission.

Instead:

Grant the minimum permissions necessary for the application to perform its function.

This follows the principle of least privilege.

17. Application Roles

Application roles allow an application to implement role-based authorization.

For example, an application could define:

Reader
Contributor
Administrator

A user or group can then be assigned an application role.

Application roles can also be assigned to service principals for application-to-application authorization.

When an appropriate role is assigned, Microsoft Entra can include the role in the token through the roles claim.

Example:

			
User
  │
  │ assigned "ReportReader"
  ▼
Application
  │
  ▼
Token
  │
  └── roles: ReportReader

		

The application can inspect the claim and determine what functionality the user is authorized to perform.

18. Enterprise Application Access Control

Enterprise applications allow administrators to control who can use an application in their tenant.

For example, an organization may have 10,000 employees but only 200 should have access to a particular application.

The administrator can configure the application so that access is assigned to:

Specific users
Groups

This provides centralized control over application access.

Service principals maintain tenant-specific information such as local user and group assignments, permissions, and policies.

19. Assignment Required

An enterprise application can be configured to require users to be explicitly assigned before they can access the application.

This is useful when an organization wants to prevent every user from automatically accessing an application.

For example:

			
10,000 employees
       │
       ▼
Enterprise Application
       │
       │ Assignment required
       ▼
Only assigned users/groups

		

This is particularly useful for sensitive applications.

Exam scenario

If the requirement is:

“Only users explicitly assigned to the application should be allowed to access it.”

Think:

Require user assignment / configure enterprise application assignments.

20. Single Sign-On

Enterprise applications can support different single sign-on approaches depending on the application.

Common technologies include:

OpenID Connect
OAuth
SAML
Password-based SSO
Integrated Windows authentication for appropriate scenarios

SSO allows users to authenticate through Microsoft Entra ID rather than maintaining separate authentication experiences for every application.

For modern applications, OpenID Connect and OAuth 2.0 are particularly important concepts.

21. Conditional Access and Applications

Conditional Access can be used to apply access requirements to applications.

For example, an organization might require:

MFA
A compliant device
A trusted location
Specific authentication strength
Risk-based controls

A simplified example:

			
User
  │
  ▼
Enterprise Application
  │
  ▼
Conditional Access
  │
  ├── MFA required
  ├── Device must be compliant
  └── Risk must be acceptable
  │
  ▼
Access granted

		

This provides an important security layer beyond simply registering the application.

22. Application Ownership and Governance

Applications should have clear ownership.

Application owners may be responsible for:

Maintaining application configuration
Managing credentials
Reviewing permissions
Monitoring usage
Removing obsolete applications
Ensuring permissions remain appropriate

Poor application governance can create significant security risks.

For example, an organization might have:

Hundreds of unused app registrations
Expired certificates
Forgotten client secrets
Excessive API permissions
Applications owned by employees who have left the organization

These conditions increase the attack surface.

23. Least Privilege for Applications

Least privilege applies to applications just as it does to users.

An application should receive only the permissions it needs.

For example, suppose an application only needs to read calendar information.

Giving it permission to:

Read and write all mailboxes

would violate least privilege.

A better design is to grant the smallest permission scope necessary.

Security checklist

For every application, ask:

What resources does it need?
What permissions does it need?
Does it need delegated or application permissions?
Does it really need write access?
Can a managed identity be used?
Can a certificate or federated credential replace a secret?
Who can access the application?
Is administrator consent required?
Are the permissions periodically reviewed?
Is the application still required?

24. Common SC-500 Exam Traps

Trap 1: Confusing app registrations with enterprise applications

Remember:

App registration → application definition

Enterprise application → tenant-specific service principal and access management

Trap 2: Confusing application object and service principal

Remember:

Application object → blueprint

Service principal → instance in a tenant

Trap 3: Using delegated permissions for a daemon

If no user is signed in, delegated permissions generally aren’t the appropriate model.

Think:

Application permissions.

Trap 4: Using a client secret unnecessarily

If an Azure resource supports managed identity and the target resource supports Microsoft Entra authentication, a managed identity can eliminate credential management.

Trap 5: Giving an application excessive permissions

Always consider:

Least privilege.

Trap 6: Confusing Application ID and Object ID

The Application (client) ID identifies the application.

The Object ID identifies a particular Microsoft Entra object.

Trap 7: Assuming every application is single-tenant

SaaS applications frequently require multitenant configuration.

Trap 8: Treating application permissions and Azure RBAC as the same thing

Application API permissions and Azure RBAC are separate authorization mechanisms.

An application can have Microsoft Graph permissions while also having an Azure RBAC role assignment against an Azure resource.

25. SC-500 Quick Reference

Concept	Remember
App registration	Defines/registers an application
Application object	Global/home-tenant application definition
Service principal	Tenant-specific application identity
Enterprise application	Management experience for service principals
Application (client) ID	Identifies the application
Object ID	Identifies a particular directory object
Single tenant	Users from the application’s home tenant
Multitenant	Users from multiple Entra tenants
Redirect URI	Where authentication response is returned
Client secret	Credential for confidential clients
Certificate	Stronger credential option for confidential clients
Federated credential	Reduces need for long-lived secrets
Managed identity	Azure-managed workload identity
Delegated permission	Application acts on behalf of a user
Application permission	Application acts without a user
Admin consent	Administrator authorizes requested permissions
Application role	Role-based authorization for an application
Enterprise application assignment	Controls which users/groups can access
Conditional Access	Applies contextual access requirements
Least privilege	Grant only required access

Practice Exam Questions

Question 1

A company develops an internal web application that will only be used by employees in its Microsoft Entra tenant. The application must authenticate employees using Microsoft Entra ID.

Which configuration should you use?

A. Register the application as single-tenant
B. Register the application as multitenant
C. Create an enterprise application without an app registration
D. Configure the application to accept personal Microsoft accounts

Answer: A

Explanation:
A single-tenant application is appropriate when the application is intended for identities from the organization’s home Microsoft Entra tenant. A multitenant configuration is intended for applications that need to support users from multiple Microsoft Entra tenants.

Question 2

A SaaS vendor has developed an application that must be used by customers in hundreds of different Microsoft Entra tenants. Each customer must be able to configure access for users within its own tenant.

What should the application use?

A. A separate application registration in every customer tenant
B. A multitenant application with a service principal in each customer tenant
C. A single service principal shared across all customer tenants
D. A managed identity created in each customer tenant

Answer: B

Explanation:
A multitenant application has an application object in its home tenant and can have a service principal representing the application in each customer tenant. The customer tenant administrators manage the local service principal through Enterprise Applications.

Question 3

An administrator needs to ensure that only members of the Finance group can access a third-party enterprise application. Where should the administrator primarily configure this tenant-specific access?

A. App registrations > Authentication
B. App registrations > Certificates & secrets
C. Enterprise applications > Users and groups
D. App registrations > Expose an API

Answer: C

Explanation:
Enterprise Applications provides tenant-specific management of the application’s service principal, including user and group assignments. App registrations is primarily concerned with the application’s definition and identity configuration.

Question 4

A background service runs every night without any user interaction. It needs to access Microsoft Graph to perform its assigned task.

Which permission model is most appropriate?

A. Delegated permissions
B. User consent only
C. Application permissions
D. Interactive authentication

Answer: C

Explanation:
Application permissions are intended for applications that operate without a signed-in user. A daemon or background service is a classic example. Delegated permissions are designed for applications acting on behalf of a user.

Question 5

A web application currently uses a client secret to authenticate to Microsoft Entra ID. The security team wants to replace the secret with a stronger credential-based mechanism for the confidential application.

Which option should you consider?

A. Redirect URI
B. Application role
C. Delegated permission
D. Certificate credential

Answer: D

Explanation:
Certificates can be used by confidential clients to authenticate the application and are generally preferred over client secrets when practical. A redirect URI controls where authentication responses are returned; it isn’t an application credential.

Question 6

An Azure-hosted application needs to retrieve secrets from Azure Key Vault. The security team does not want developers to store a client secret in application configuration.

Which solution provides the best approach when the Azure services involved support Microsoft Entra authentication?

A. Use a managed identity
B. Store the client secret in source code
C. Create a second client secret with a longer expiration
D. Store the password in an environment variable

Answer: A

Explanation:
A managed identity allows an Azure resource to authenticate to supported resources without requiring developers to manage an application credential. This reduces the risk associated with storing and rotating secrets.

Question 7

An application needs to read a user’s email while the user is signed in. The application should access the data within the user’s context rather than operating independently.

Which permission model should be used?

A. Application permissions
B. Delegated permissions
C. Managed identity permissions
D. Azure resource locks

Answer: B

Explanation:
Delegated permissions allow an application to access resources on behalf of a signed-in user. Application permissions are intended for scenarios where the application operates without a user.

Question 8

A developer reports that authentication succeeds, but Microsoft Entra ID cannot return the authentication response to the web application.

Which app registration setting should you investigate first?

A. Application roles
B. API permissions
C. Redirect URI
**D. Enterprise application assignment

Answer: C

Explanation:
The redirect URI specifies where Microsoft Entra ID returns the authentication response. The URI used by the application must correspond to an allowed redirect URI configured for the application.

Question 9

A custom API defines three application roles: Reader, Contributor, and Administrator. A user is assigned the Reader role. The API needs to determine which role the user has after authentication.

Which token information should the API inspect?

A. The roles claim
B. The redirect_uri claim
C. The client secret
D. The application object ID

Answer: A

Explanation:
Application roles can be assigned to users, groups, service principals, or supported managed identities. When appropriate, Microsoft Entra ID includes assigned application roles in the token’s roles claim, allowing the application to implement role-based authorization.

Question 10

A security team discovers that an enterprise application is available to every employee, but company policy requires users to be explicitly assigned before they can use it.

What should the administrator configure?

A. Change the application’s client ID
B. Require user assignment and assign the appropriate users or groups
C. Add another redirect URI
D. Change the application from single-tenant to multitenant

Answer: B

Explanation:
Requiring assignment allows the organization to control which users or groups can access an enterprise application. This is particularly useful for sensitive applications where broad access is not appropriate.

Final Exam Takeaways

If you remember only a handful of things from this topic, remember these:

App registration = application definition.
Application object = blueprint for the application.
Service principal = application’s identity/instance in a specific tenant.
Enterprise Applications = primarily where tenant administrators manage service principals and application access.
Single-tenant = one organization’s tenant.
Multitenant = users from multiple Microsoft Entra tenants.
Delegated permissions = application acts on behalf of a user.
Application permissions = application acts without a user.
Managed identity = preferred way to avoid managing credentials for supported Azure workloads.
Certificates are generally preferable to client secrets for confidential clients when practical.
Redirect URIs are critical to authentication configuration.
Application roles enable role-based authorization.
Enterprise application assignments control who can access an application.
Admin consent is important for authorizing privileged application permissions.
Always apply least privilege to application permissions and access.

The biggest SC-500 mental model is:

Register the application → configure how it authenticates → define what it can access → create/manage its service principal → control who can use it → enforce least privilege and Conditional Access.

Go to the SC-500 Exam Prep Hub main page

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

Implement and Configure Privileged Identity Management (PIM) (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%)
   --> Secure access to resources by using Microsoft Entra ID
      --> Implement and configure Privileged Identity Management (PIM)


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 Entra Privileged Identity Management (PIM) is a Microsoft Entra ID Governance capability that helps organizations manage, control, and monitor privileged access to resources.

The primary security objective of PIM is to reduce the risks associated with standing privileged access. Rather than giving administrators permanent access to highly privileged roles, PIM can make users eligible for those roles and require them to activate the role only when they need it.

This approach is commonly called just-in-time (JIT) privileged access.

PIM is particularly important for protecting highly privileged roles such as:

Global Administrator
Privileged Role Administrator
Security Administrator
User Administrator
Application Administrator
Other Microsoft Entra built-in or custom roles
Azure resource roles such as Owner, Contributor, and User Access Administrator

PIM can also be used with Azure resource roles and groups, providing a broader privileged-access-management strategy.

1. Why Privileged Identity Management Is Important

Traditional role assignment often creates a problem:

A user receives powerful permissions and retains those permissions whether or not they are currently performing privileged work.

For example, suppose an administrator is assigned the Global Administrator role permanently.

When the administrator needs to configure Microsoft Entra ID, that access is necessary.

However, when the administrator is simply reading email or working on an unrelated task, the Global Administrator privileges are still available.

This creates a larger attack surface.

If the administrator’s account is compromised, an attacker may immediately inherit the administrator’s privileges.

PIM addresses this problem by allowing the administrator to be eligible rather than permanently active.

The administrator activates the role when needed, and the elevated access can automatically expire after a defined period.

Traditional standing access

User → Permanent privileged role → Privileges always available

PIM-based JIT access

User → Eligible for privileged role → Activation → Temporary privileged access → Automatic expiration

The second model supports the principle of least privilege and significantly reduces the amount of time highly privileged permissions are available.

2. PIM Assignment Types

One of the most important concepts for the SC-500 exam is understanding the difference between Eligible and Active assignments.

Eligible assignment

An eligible assignment means that the user is authorized to activate the role, but doesn’t currently have the role’s privileges.

The user must perform the required activation process before receiving the privileges.

Depending on the configuration, activation might require:

Multifactor authentication
A business justification
Ticket information
Approval
Additional authentication requirements
A specified activation duration

Example

John is an eligible Global Administrator.

John isn’t currently a Global Administrator.

When John needs to perform a privileged operation, he activates the role.

PIM then temporarily activates the assignment.

Active assignment

An active assignment means the user already has the role’s permissions.

The user doesn’t have to activate the role before using it.

For example:

Sarah has an active Security Administrator assignment.

Sarah can immediately use the Security Administrator privileges.

This is essentially standing access, although PIM can still apply duration controls to active assignments.

Eligible vs. Active

Characteristic	Eligible	Active
Has privileges immediately?	No	Yes
Requires activation?	Yes	No
Supports JIT access?	Yes	No
MFA can be required at activation?	Yes	Not as an activation requirement
Approval can be required?	Yes	No activation approval
Justification can be required?	Yes	No activation justification
Can be time-bound?	Yes	Yes
Best for least privilege?	Yes	Generally no

Exam tip

If a question says:

“Administrators should have access only when they need it.”

Think:

Eligible assignment + activation = JIT access

3. Permanent vs. Time-Bound Assignments

PIM also distinguishes between permanent and time-bound assignments.

Permanent eligible

The user remains eligible indefinitely.

They still must activate the role before using it.

Example:

A full-time security administrator is permanently eligible for Security Administrator.

The administrator can activate the role whenever necessary, subject to the configured PIM policies.

Time-bound eligible

The user’s eligibility exists only during a specified period.

Example:

A contractor is eligible for Contributor access from September 1 through September 30.

After September 30, the eligibility expires.

This is especially useful for:

Contractors
Temporary projects
Mergers and acquisitions
Incident-response teams
Temporary administrative responsibilities

Permanent active

The user permanently has the privileges without activation.

This provides the least amount of privilege protection among these options.

Time-bound active

The user has the privileges during a specified period, but doesn’t need to activate them.

For example:

A consultant has active Contributor access from September 1 through September 15.

During that period, the consultant can immediately use the role.

4. Just-In-Time Access

Just-in-time access is one of the fundamental security concepts behind PIM.

Instead of providing privileged permissions continuously, access is granted temporarily when required.

The general process is:

User is assigned an eligible role.
User needs to perform privileged work.
User requests activation.
PIM evaluates the activation requirements.
User completes required security controls.
Role becomes active.
User performs the privileged task.
Activation expires.

This reduces the amount of time privileged permissions are exposed.

Example

An administrator normally doesn’t need Global Administrator permissions.

The administrator receives an alert that a tenant-wide configuration change is required.

The administrator:

Opens PIM.
Selects Global Administrator.
Requests activation.
Completes MFA.
Provides a justification.
Receives approval if required.
Gets temporary Global Administrator access.
Performs the required task.
Access automatically expires.

5. Configuring PIM Role Settings

PIM role settings, also called PIM policies, determine what users must do when activating a role and how long assignments can remain active.

Role settings are configured for individual roles.

Important settings include:

Activation maximum duration
MFA requirements
Conditional Access authentication context
Authentication strength
Justification requirements
Ticket information requirements
Approval requirements
Eligible assignment duration
Active assignment duration
Notifications

6. Activation Maximum Duration

The activation maximum duration specifies the maximum amount of time a user can have an activated eligible role.

For example:

Maximum activation duration = 2 hours

A user can activate the role for a period up to two hours.

After the activation expires, the user must activate the role again if additional privileged work is necessary.

Microsoft Entra PIM currently allows the activation maximum duration for Microsoft Entra roles to be configured from 1 to 24 hours.

Security consideration

A shorter activation duration generally reduces the window during which privileged access can be abused.

However, setting the duration too short can create unnecessary administrative friction.

The goal is to choose a duration appropriate to the organization’s operational requirements.

7. Require Multifactor Authentication on Activation

PIM can require multifactor authentication (MFA) when a user activates an eligible role.

This creates an additional security barrier between the user’s normal account and privileged access.

For example:

A user signs into Microsoft Entra ID normally and later attempts to activate Global Administrator.

PIM can require the user to perform MFA before the role becomes active.

Important distinction

MFA requirements for activation should not be confused with MFA requirements for creating an active assignment.

PIM can also require MFA when an administrator creates an active assignment, but that doesn’t mean PIM will repeatedly enforce MFA whenever the user uses the already-active role.

8. Conditional Access Authentication Context

PIM can use Microsoft Entra Conditional Access authentication context to impose stronger authentication requirements when a privileged role is activated.

This can be useful when simply requiring a generic MFA check isn’t sufficient.

For example, an organization could require a stronger authentication method for privileged operations than it requires for ordinary sign-in.

Authentication strength policies can be used together with authentication context to establish stronger requirements.

Exam scenario

If a question asks for:

“Require stronger authentication specifically when a privileged role is activated.”

Consider:

Conditional Access authentication context + appropriate authentication strength

9. Require Justification

PIM can require the user to provide a business justification when activating a role.

For example:

“Activating Security Administrator to investigate suspicious sign-in activity.”

The justification provides context for why privileged access was required.

This supports:

Accountability
Auditing
Security investigations
Compliance
Operational review

Important distinction

A justification explains why access is needed.

It doesn’t itself provide authorization.

10. Require Ticket Information

PIM can also require users to provide ticket information during activation.

For example:

INC00123456

This allows an organization to associate privileged activity with a service-management or incident-management ticket.

However, an important detail is that PIM’s ticket-information field is informational.

PIM doesn’t inherently validate the ticket against an external ticketing system.

Exam tip

If a question says:

“Require administrators to provide a change or incident ticket number when activating a privileged role.”

Think:

Require ticket information on activation.

11. Require Approval

PIM can require an eligible user to obtain approval before the role becomes active.

The workflow is approximately:

User requests activation → Approval required → Approver reviews request → Approve/Deny → Role activates if approved

An organization can configure one or more designated approvers.

For important privileged roles, having multiple possible approvers can improve availability and reduce the risk of a single point of failure.

Example

An organization wants every Global Administrator activation to be approved.

The user submits:

Requested role
Requested duration
Business justification
Ticket information

The designated approver reviews the request.

If approved, the role becomes active for the permitted duration.

12. Approval Is Different from Eligibility

This distinction is important.

Being eligible doesn’t necessarily mean that approval is required.

An eligible user may be able to activate immediately if the PIM policy only requires MFA and justification.

Alternatively, the policy can require approval.

Therefore:

Eligible describes the user’s assignment status.

Approval required describes an activation policy.

These are different concepts.

13. Notifications

PIM provides notifications associated with privileged-role management and activation.

Notifications can help security teams and administrators identify:

Role assignments
Activation activity
Approval requests
Changes to privileged access
Other PIM-related events

Notifications can be used as part of a broader privileged-access monitoring strategy.

14. Assigning a Role Through PIM

A typical administrator workflow for assigning a Microsoft Entra role through PIM is:

Open the Microsoft Entra admin center.
Open ID Governance.
Open Privileged Identity Management.
Select Microsoft Entra roles.
Select the appropriate role.
Select Add assignments.
Select the member.
Select Eligible or Active.
Configure the assignment duration.
Complete the assignment.

The appropriate administrator permissions are required to manage these assignments.

For Microsoft Entra role PIM settings, the Privileged Role Administrator role is an important administrative role to know for the exam.

15. Activating an Eligible Role

When an eligible user needs privileged access, the user initiates an activation request.

A typical activation workflow is:

Open Microsoft Entra PIM.
Locate the eligible role.
Select Activate.
Specify the requested duration.
Complete additional verification if required.
Provide justification if required.
Provide ticket information if required.
Submit the activation.
Wait for approval if required.
Use the role while it is active.

Once the activation expires, the privileges are removed.

16. Limiting the Activation Scope

PIM can support limiting the scope of access when activating certain roles.

This is particularly important because the principle of least privilege says that administrators shouldn’t request broader access than necessary.

For example, if an administrator only needs access to a particular resource, the administrator should avoid requesting access to an unnecessarily broad scope when the relevant PIM configuration supports a narrower scope.

Security principle

Give the administrator the smallest scope and shortest duration necessary to complete the task.

17. Deactivating a Role Early

PIM doesn’t require users to wait until the activation period expires.

If a user finishes their privileged work early, the user can deactivate the role.

For example:

Maximum activation duration = 4 hours
Administrator finishes the task after 45 minutes.

The administrator can deactivate the role rather than leaving it active for the remaining 3 hours and 15 minutes.

This is another application of least privilege.

18. PIM for Azure Resources

PIM isn’t limited to Microsoft Entra directory roles.

PIM can also manage Azure resource roles.

Examples include:

Owner
Contributor
User Access Administrator
Other Azure RBAC roles

For Azure resources, PIM can provide:

Eligible assignments
Active assignments
Time-bound assignments
Activation
MFA requirements
Approval workflows
Justification
Auditability
Scope controls

Example

Instead of permanently assigning:

User → Subscription Owner

an organization could use:

User → Eligible Owner → Activate when necessary → Temporary Owner → Expire

This significantly reduces standing privileged access to Azure resources.

19. PIM for Groups

PIM can also be used with groups.

This allows organizations to manage privileged membership in groups through PIM.

For example, imagine a group called:

Production-Administrators

Membership in this group grants administrative privileges.

Instead of permanently making an administrator a member of the group, PIM can allow the user to become eligible for group membership and activate that membership when needed.

This provides another way to implement JIT access.

20. PIM and Least Privilege

PIM should be viewed as one component of a broader least-privilege strategy.

A good privileged-access design should consider:

Who?

Only authorized administrators should receive privileged access.

What?

Assign the smallest role necessary.

Where?

Limit access to the required scope.

When?

Provide access only when necessary.

How long?

Use the shortest practical activation duration.

Under what conditions?

Require appropriate authentication, justification, approval, and other controls.

This results in the security principle:

Right person + right privilege + right scope + right time + right conditions

21. PIM and Emergency Access Accounts

Organizations should maintain emergency access accounts, sometimes called break-glass accounts, for situations where normal administrative access isn’t available.

This is particularly important when configuring PIM.

For example, imagine that:

All Privileged Role Administrators are eligible rather than active.
Activation requires approval.
No approvers are configured.

Administrators could potentially lock themselves out of the tenant.

Emergency access accounts provide a recovery mechanism for scenarios such as:

Incorrect PIM configuration
Conditional Access misconfiguration
Authentication problems
Loss of administrator access
Other tenant-wide administrative emergencies

Emergency access accounts should themselves be carefully protected and monitored.

22. PIM and Access Reviews

PIM can be used alongside access reviews to periodically evaluate whether users still need privileged access.

For example:

50 users are eligible for a privileged role.

A periodic access review can determine:

Who still needs eligibility?
Who has changed responsibilities?
Who should be removed?
Who should have a less privileged role?

This helps prevent privilege accumulation over time.

23. PIM and Auditability

Privileged access should be observable.

PIM provides information that can help organizations understand:

Who was assigned a role
Who activated a role
When activation occurred
How long access was requested
Whether approval was required
Who approved or denied requests
Why the user requested access

This information can support:

Security investigations
Compliance
Auditing
Incident response
Administrative accountability

24. Discovery and Insights

PIM provides capabilities that help organizations identify privileged assignments and improve their privileged-access posture.

For example, organizations can identify users with standing privileged assignments and consider converting them to eligible assignments.

The objective is to reduce unnecessary permanent privileged access.

A common improvement process is:

Discover privileged access → Evaluate necessity → Remove unnecessary access → Convert standing access to eligible access → Configure activation controls → Monitor

25. Common PIM Security Recommendations

For an SC-500 exam scenario, strong PIM implementations generally follow these principles:

1. Prefer eligible assignments

Use eligible assignments instead of permanent active assignments whenever operationally practical.

2. Use JIT activation

Allow privileged access only when it is needed.

3. Require MFA

Require strong authentication when activating sensitive roles.

4. Require justification

Make administrators explain why privileged access is needed.

5. Require approval for highly sensitive roles

Use approval workflows where an additional authorization step is appropriate.

6. Limit activation duration

Don’t provide eight hours of privileged access for a task that takes 20 minutes.

7. Limit assignment scope

Don’t give subscription-wide access when resource-level access is sufficient.

8. Review privileged access regularly

Remove users who no longer require privileged permissions.

9. Maintain emergency access

Ensure that a PIM or Conditional Access configuration problem doesn’t permanently lock administrators out.

10. Monitor privileged activity

Use logs, alerts, Microsoft Defender capabilities, and Microsoft Sentinel as appropriate to detect suspicious privileged activity.

26. Common Exam Traps

Trap 1: Eligible doesn’t mean active

An eligible user does not currently have the role’s privileges.

They must activate the role.

Trap 2: Active doesn’t mean activation is required

An active assignment is already usable.

The user doesn’t have to activate it.

Trap 3: Justification isn’t approval

A justification explains why the user wants access.

Approval requires another designated person to approve the activation request.

Trap 4: Time-bound isn’t the same as JIT

A time-bound assignment has a start/end period.

JIT generally refers to activating privileges when they are needed for a limited period.

An eligible assignment can be both time-bound and JIT.

Trap 5: MFA isn’t the same as Conditional Access authentication context

MFA can be required during activation.

Authentication context can be used when the organization needs a specific Conditional Access-based authentication requirement for the privileged operation.

Trap 6: Ticket information isn’t ticket validation

PIM can require ticket information, but the ticket field is informational and isn’t inherently validated against an external ticketing system.

Trap 7: PIM isn’t just for Global Administrator

PIM can manage many Microsoft Entra roles and Azure resource roles.

27. SC-500 Quick Reference

Concept	Remember
PIM	Controls and governs privileged access
JIT	Give privileged access only when needed
Eligible	User can activate the role
Active	User already has the role
Permanent eligible	Eligible indefinitely
Time-bound eligible	Eligible only during a defined period
Permanent active	Privileges continuously available
Time-bound active	Privileges available during a defined period
Activation	Converts eligible access into active access temporarily
MFA	Can be required during activation
Authentication context	Can enforce additional Conditional Access authentication requirements
Justification	Explains why privileged access is needed
Ticket information	Records a ticket/reference number
Approval	Requires designated approver authorization
Activation duration	Limits how long activated access remains active
Least privilege	Give only required permissions
JIT + eligible	Preferred pattern for reducing standing privilege
Access reviews	Periodically validate whether access is still needed
Emergency access	Recovery mechanism for administrative lockout
Azure resource PIM	Applies PIM concepts to Azure RBAC roles
PIM for Groups	Controls privileged group membership

Practice Exam Questions

Question 1

An organization wants its administrators to have Global Administrator permissions only when they are actively performing a privileged task. Administrators should normally have no Global Administrator privileges, but they must be able to obtain them when necessary.

Which PIM assignment type should you use?

A. Active

B. Eligible

C. Permanent active

D. Time-bound active

Answer: B

Explanation: An eligible assignment allows a user to activate a privileged role when needed. Before activation, the user doesn’t have the role’s privileges. This is the fundamental PIM pattern for just-in-time access.

Question 2

A company requires administrators activating the Security Administrator role to provide a business reason for the activation. The company doesn’t want another administrator to approve the request.

Which PIM setting should you configure?

A. Require approval to activate

B. Require ticket information on activation

C. Require justification on activation

D. Require MFA on active assignment

Answer: C

Explanation: Require justification on activation requires the administrator to provide a business reason for activating the eligible role. Approval isn’t required unless the approval setting is separately enabled.

Question 3

An organization wants Global Administrator activations to require authorization from another designated administrator before the role becomes active.

Which PIM capability should be configured?

A. Activation maximum duration

B. Require approval to activate

C. Require ticket information

D. Access reviews

Answer: B

Explanation: Require approval to activate creates an approval workflow for eligible-role activation. Designated approvers review and approve or deny activation requests.

Question 4

A user has an eligible Contributor assignment for an Azure subscription. The user activates the assignment and selects a four-hour activation period. After completing the required work in one hour, what should the user do to minimize the amount of time privileged access remains available?

A. Deactivate the role

B. Convert the assignment to active

C. Extend the activation period

D. Create another eligible assignment

Answer: A

Explanation: The user should deactivate the role after completing the privileged task. This follows the principle of least privilege by reducing the time that elevated permissions remain active.

Question 5

A security team wants to ensure that users cannot activate a privileged role for more than two hours at a time.

Which PIM configuration should the security team modify?

A. Assignment expiration

B. Approval workflow

C. Activation maximum duration

D. Access review frequency

Answer: C

Explanation: Activation maximum duration controls the maximum amount of time an eligible role can remain activated. For Microsoft Entra roles, this setting can be configured from 1 to 24 hours.

Question 6

An organization wants administrators to provide an incident or change ticket number whenever they activate a privileged role. The organization does not require PIM to validate the ticket against its external ticketing system.

Which PIM setting should be used?

A. Require justification on activation

B. Require approval to activate

C. Require authentication context

D. Require ticket information on activation

Answer: D

Explanation: Require ticket information on activation prompts the user to provide ticket information. The information is recorded for context, but PIM doesn’t inherently validate the ticket against an external ticketing system.

Question 7

A security architect wants privileged administrators to use stronger authentication when activating a sensitive role. The organization specifically wants to use Microsoft Entra Conditional Access authentication context together with an authentication strength policy.

Which capability addresses this requirement?

A. Authentication context

B. Access reviews

C. Assignment duration

D. Ticket information

Answer: A

Explanation: Conditional Access authentication context can be used with authentication strengths to require specific authentication requirements during privileged-role activation.

Question 8

An administrator has a permanent active assignment for a highly privileged Microsoft Entra role. The security team wants the administrator to retain the ability to obtain the role but not continuously possess its permissions.

What should the security team do?

A. Make the assignment permanently active

B. Convert the assignment to eligible

C. Increase the activation maximum duration

D. Remove MFA requirements

Answer: B

Explanation: Converting the assignment to eligible allows the administrator to activate the role when needed rather than continuously having its privileges. This is a core PIM strategy for reducing standing privileged access.

Question 9

An organization requires all privileged-role activations to be approved. All Privileged Role Administrators are eligible for the Privileged Role Administrator role, but no specific approvers have been configured.

Why is this configuration potentially dangerous?

A. Users will automatically receive permanent active assignments

B. PIM will disable all Conditional Access policies

C. Administrators may be unable to activate the role and could potentially lock themselves out of the tenant

D. Eligible assignments will automatically become permanent

Answer: C

Explanation: If all privileged administrators are only eligible, activation requires approval, and no appropriate approvers are available, administrators may be unable to activate their privileged roles. Organizations should carefully configure approvers and maintain appropriate emergency access mechanisms.

Question 10

A company has several contractors who require Contributor permissions during a three-month project. The contractors should be able to activate the role only during those three months, and the privileges shouldn’t remain continuously active.

Which configuration best meets the requirement?

A. Permanent active assignment

B. Permanent eligible assignment

C. Time-bound active assignment

D. Time-bound eligible assignment

Answer: D

Explanation: A time-bound eligible assignment limits the period during which the contractor can activate the role while still requiring activation before the privileges are granted. This combines time-limited eligibility with just-in-time access.

Final Exam Takeaways

For SC-500, the most important PIM concepts to be able to distinguish quickly are:

Eligible vs. Active
Permanent vs. Time-bound
Just-in-time activation
Activation maximum duration
MFA during activation
Conditional Access authentication context
Authentication strength
Justification
Ticket information
Approval workflows
Least-privilege scope
Early deactivation
PIM for Microsoft Entra roles
PIM for Azure resource roles
PIM for Groups
Access reviews
Emergency access accounts
Monitoring and auditing privileged activity

The single most useful mental model for scenario questions is:

Eligible → Activate → Verify/Justify/Approve → Temporarily Active → Deactivate/Expire

If a scenario describes standing administrative access that should be available only when needed, the answer will very often involve PIM + an eligible assignment + JIT activation, with MFA, approval, justification, limited duration, or other controls layered on according to the requirements.

Go to the SC-500 Exam Prep Hub main page

Introduction

1. What Are Azure Resource Locks?

2. Resource Locks vs. Azure RBAC

Simple comparison

3. The Two Primary Resource Lock Types

4. CanNotDelete Lock

Example

Think of it as:

5. ReadOnly Lock

Think of it as:

6. CanNotDelete vs. ReadOnly

Easy memory trick

7. Where Can Resource Locks Be Applied?

Subscription

Resource Group

Individual Resource

8. Lock Inheritance

Exam scenario

9. The Most Restrictive Lock Takes Precedence

10. Resource Locks Are Control-Plane Controls

Control plane

Data plane

11. Example: Storage Account Lock

12. Resource Locks Do Not Replace Data Protection

13. Why Use CanNotDelete?

Example

14. Why Use ReadOnly?

15. ReadOnly Can Break Operations

16. Resource Locks and Resource Groups

17. Resource Locks and Resource Group Deletion

Exam takeaway

18. Resource Locks and RBAC Assignments

19. Resource Locks and Azure Backup

Exam lesson

20. Resource Locks and Azure Machine Learning

21. Resource Locks and Deployment History

22. Who Can Create or Delete Resource Locks?

Important distinction

23. Removing a Resource Lock

24. Creating Resource Locks in the Azure Portal

25. Creating Locks with Azure CLI

26. Creating Locks with Azure PowerShell

27. Resource Locks with ARM Templates and Bicep

28. Resource Locks and Infrastructure as Code

Infrastructure as code

Azure Policy

RBAC

Resource locks

29. Resource Locks Are Not a Replacement for Azure Policy

Resource lock

Azure Policy

Easy distinction

30. Resource Locks and Tags

Tags

Locks

31. Resource Locks and Resource Health

32. Choosing the Correct Lock

Requirement 1

Requirement 2

Requirement 3

Requirement 4

Requirement 5

Requirement 6

33. Common Resource Lock Exam Traps

Trap 1: “Owner can always delete the resource.”

Trap 2: “CanNotDelete prevents modifications.”

Trap 3: “ReadOnly only prevents deletion.”

Trap 4: “A storage account lock prevents users from deleting blobs.”

Trap 5: “A resource-group lock protects only the resource group.”

Trap 6: “Locks are inherited upward.”

Trap 7: “Resource locks replace RBAC.”

Trap 8: “ReadOnly is always better because it provides stronger security.”

Trap 9: “Resource locks protect against every kind of deletion.”

Trap 10: “A resource lock automatically protects backups.”

34. Best Practices for Resource Locks

1. Use CanNotDelete for critical resources that still require routine administration

2. Use ReadOnly sparingly

3. Apply locks at the narrowest practical scope

4. Document locks

5. Consider service dependencies

Trap 2: “`CanNotDelete` prevents modifications.”

Trap 3: “`ReadOnly` only prevents deletion.”