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

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

3. The Two Primary Resource Lock Types

Azure provides two primary management lock levels:

1. CanNotDelete
2. ReadOnly

The names used in the Azure portal are:

• Delete
• Read-only

The underlying Azure Resource Manager lock levels are:

• CanNotDelete
• ReadOnly

Understanding exactly what each does is essential for the exam.

4. CanNotDelete Lock

A CanNotDelete lock prevents the locked resource from being deleted.

Authorized users can still:

• Read the resource
• Modify the resource

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

Example

Suppose a production SQL database has a CanNotDelete lock.

An administrator can still change supported configuration settings.

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

Think of it as:

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

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

5. ReadOnly Lock

A ReadOnly lock is more restrictive.

It prevents users from:

• Modifying the resource
• Deleting the resource

Users can still read the resource.

Think of it as:

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

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

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

6. CanNotDelete vs. ReadOnly

This comparison should be memorized for the exam.

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

Easy memory trick

CanNotDelete:

Change it, but don’t delete it.

ReadOnly:

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

7. Where Can Resource Locks Be Applied?

Resource locks can be applied at several scopes.

Subscription

A lock can be applied to an entire Azure subscription.

This can protect resources throughout the subscription.

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

Resource Group

A lock can be applied to a resource group.

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

For example:

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

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

Individual Resource

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

For example:

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

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

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

8. Lock Inheritance

Locks can be inherited from a parent scope.

For example:

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

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

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

Exam scenario

Suppose:

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

The storage account inherits the applicable lock.

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

9. The Most Restrictive Lock Takes Precedence

Multiple locks can exist within an inheritance hierarchy.

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

For example:

Resource Group
   CanNotDelete
        ↓
Storage Account
   ReadOnly

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

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

Consider:

1. The resource’s own lock
2. The parent resource group’s lock
3. The subscription-level lock
4. Which applicable lock is most restrictive

10. Resource Locks Are Control-Plane Controls

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

They do not universally protect data-plane operations.

Control plane

The control plane manages Azure resources themselves.

Examples include operations such as:

• Creating resources
• Deleting resources
• Updating resource configuration
• Changing resource properties

These operations generally go through Azure Resource Manager.

Data plane

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

Examples include:

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

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

11. Example: Storage Account Lock

Consider a storage account containing:

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

You apply a CanNotDelete lock to the storage account.

The lock protects the storage account resource against deletion.

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

Why?

Because:

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

This is a very common exam trap.

12. Resource Locks Do Not Replace Data Protection

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

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

But it should not be treated as a replacement for:

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

The lock protects the resource management operation.

Other controls protect the data.

13. Why Use CanNotDelete?

CanNotDelete is useful when:

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

Example

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

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

A CanNotDelete lock is appropriate.

The administrator can modify the resource but cannot delete it.

14. Why Use ReadOnly?

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

Examples might include:

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

However, ReadOnly should be used carefully.

It is significantly more restrictive than CanNotDelete.

15. ReadOnly Can Break Operations

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

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

Consequently, applying ReadOnly can interfere with normal service functionality.

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

Therefore:

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

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

16. Resource Locks and Resource Groups

Resource-group-level locks require particular attention.

Suppose:

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

You apply:

CanNotDelete

to ProductionRG.

The resources inherit the protection.

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

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

The lock blocks the overall deletion operation.

17. Resource Locks and Resource Group Deletion

Consider:

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

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

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

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

Exam takeaway

If a scenario says:

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

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

18. Resource Locks and RBAC Assignments

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

This is another reason resource locks should be planned carefully.

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

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

19. Resource Locks and Azure Backup

Resource locks can also affect Azure Backup operations.

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

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

Exam lesson

Don’t assume:

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

Instead, consider:

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

Security controls must be designed with service dependencies in mind.

20. Resource Locks and Azure Machine Learning

Another example of an operational consequence involves Azure Machine Learning.

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

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

This can result in unused compute resources remaining active.

The broader lesson is:

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

21. Resource Locks and Deployment History

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

Azure Resource Manager can automatically remove older deployment records.

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

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

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

22. Who Can Create or Delete Resource Locks?

Resource locks are themselves Azure resources and require appropriate authorization.

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

Microsoft.Authorization/*

or

Microsoft.Authorization/locks/*

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

Specialized roles may also provide the necessary permissions.

Important distinction

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

Lock management requires appropriate authorization to manage locks.

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

23. Removing a Resource Lock

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

For example:

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

The ability to remove the lock itself requires appropriate permissions.

This creates an additional administrative boundary around highly sensitive resources.

24. Creating Resource Locks in the Azure Portal

A resource lock can be configured through the Azure portal.

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

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

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

25. Creating Locks with Azure CLI

Resource locks can also be managed through Azure CLI.

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

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

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

--lock-type ReadOnly

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

Instead, understand that Azure CLI supports both:

• CanNotDelete
• ReadOnly

and can apply them at appropriate scopes.

26. Creating Locks with Azure PowerShell

Azure PowerShell also supports resource locks.

For example:

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

You can use PowerShell commands such as:

• New-AzResourceLock
• Get-AzResourceLock
• Remove-AzResourceLock

to manage locks.

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

27. Resource Locks with ARM Templates and Bicep

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

The resource type is:

Microsoft.Authorization/locks

For example, a Bicep resource can conceptually specify:

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

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

However, teams should carefully consider lifecycle management.

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

28. Resource Locks and Infrastructure as Code

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

For example:

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

Each control addresses a different concern.

Infrastructure as code

Provides repeatable and controlled deployments.

Azure Policy

Enforces organizational configuration requirements.

RBAC

Controls who can perform actions.

Resource locks

Prevent deletion or modification at the locked scope.

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

29. Resource Locks Are Not a Replacement for Azure Policy

Resource locks and Azure Policy solve different problems.

Resource lock

Protects a specific scope from deletion or modification.

Azure Policy

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

For example:

Requirement:

All storage accounts must use approved network configurations.

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

Requirement:

Prevent accidental deletion of this production storage account.

A resource lock is appropriate.

Easy distinction

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

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

30. Resource Locks and Tags

Tags and resource locks serve very different purposes.

Tags

Provide metadata for:

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

Locks

Restrict control-plane operations.

A tag such as:

Environment = Production

doesn’t protect a resource from deletion.

A CanNotDelete lock does.

31. Resource Locks and Resource Health

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

A lock doesn’t:

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

Its purpose is much narrower:

Prevent specified management operations against a resource or scope.

32. Choosing the Correct Lock

A useful decision framework is:

Requirement 1

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

Use: CanNotDelete

Requirement 2

“The resource should not be modified or deleted.”

Use: ReadOnly

Requirement 3

“Only this one resource must be protected.”

Apply the lock directly to the resource.

Requirement 4

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

Apply a CanNotDelete lock to the resource group.

Requirement 5

“Prevent resources from being deployed with insecure configurations.”

Consider Azure Policy rather than a resource lock.

Requirement 6

“Protect blob data from unauthorized deletion.”

Don’t rely solely on a resource lock.

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

33. Common Resource Lock Exam Traps

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

Not necessarily.

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

Trap 2: “CanNotDelete prevents modifications.”

Incorrect.

CanNotDelete permits authorized users to modify the resource.

It prevents deletion.

Trap 3: “ReadOnly only prevents deletion.”

Incorrect.

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

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

Not necessarily.

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

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

Not exactly.

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

Trap 6: “Locks are inherited upward.”

Incorrect.

Inheritance flows downward from a parent scope to child resources.

Trap 7: “Resource locks replace RBAC.”

Incorrect.

RBAC controls authorization.

Locks impose additional management restrictions.

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

Not necessarily.

ReadOnly can interfere with legitimate service operations.

The appropriate lock depends on the required operational behavior.

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

Incorrect.

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

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

Incorrect.

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

34. Best Practices for Resource Locks

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

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

2. Use ReadOnly sparingly

ReadOnly is highly restrictive and can interfere with service operations.

3. Apply locks at the narrowest practical scope

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

4. Document locks

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

5. Consider service dependencies

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

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

Combine locks with appropriate:

• RBAC
• Data-plane authorization
• Backup
• Soft delete
• Versioning
• Immutability
• Monitoring

7. Combine locks with Azure Policy

Use Policy for configuration governance and locks for resource protection.

8. Review locks periodically

An outdated lock can become an operational problem.

9. Establish a controlled lock-removal process

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

10. Use infrastructure as code when appropriate

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

35. Resource Locks: Quick Reference

36. SC-500 Exam Review

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

What is a resource lock?

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

What are the two lock types?

• CanNotDelete
• ReadOnly

What does CanNotDelete do?

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

What does ReadOnly do?

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

Does a resource lock override RBAC permissions?

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

Where can locks be applied?

At subscription, resource group, or resource scope.

Are locks inherited?

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

Which lock takes precedence if multiple locks apply?

The most restrictive applicable lock.

Do locks protect data-plane operations?

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

Does CanNotDelete allow modifications?

Yes.

Does ReadOnly prevent deletion?

Yes.

Should ReadOnly be used everywhere?

No. It can interfere with legitimate service operations.

Do locks replace Azure Policy?

No.

Do locks replace RBAC?

No.

Do locks replace backup and data-protection controls?

No.

Practice Exam Questions

Question 1

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

Which resource lock should you apply?

A. ReadOnly

B. CanNotDelete

C. Audit

D. Deny

Correct Answer: B

Explanation

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

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

Question 2

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

The administrator attempts to delete the resource group.

What happens?

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

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

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

D. The deletion is blocked by the resource lock

Correct Answer: D

Explanation

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

The CanNotDelete lock prevents deletion of the locked scope.

An Owner role does not automatically bypass a resource lock.

Question 3

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

Which lock should be used?

A. ReadOnly

B. CanNotDelete

C. AuditIfNotExists

D. Deny

Correct Answer: A

Explanation

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

CanNotDelete would still allow authorized users to modify the resource.

Question 4

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

What is the expected effect?

A. Only the resource group name becomes read-only

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

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

D. Azure Policy is automatically assigned to every resource

Correct Answer: C

Explanation

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

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

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

Question 5

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

Why can this occur?

A. CanNotDelete locks only work for virtual machines

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

C. Storage accounts cannot have resource locks

D. Blob deletion always bypasses Azure RBAC

Correct Answer: B

Explanation

Resource locks primarily protect control-plane operations.

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

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

Question 6

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

What should the administrator consider before applying the lock?

A. The lock automatically increases backup storage capacity

B. The lock converts all backup data to immutable storage

C. The lock has no effect on Azure Backup

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

Correct Answer: D

Explanation

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

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

Question 7

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

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

What should they do?

A. Replace the lock with a ReadOnly lock

B. Add an Azure tag

C. Change the RBAC role to Reader for every resource

D. Enable Microsoft Sentinel

Correct Answer: A

Explanation

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

A CanNotDelete lock only prevents deletion.

Question 8

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

The organization has two requirements:

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

Which combination should the engineer consider?

A. Resource lock for both requirements

B. Microsoft Sentinel for both requirements

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

D. RBAC alone for both requirements

Correct Answer: C

Explanation

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

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

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

Question 9

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

Which lock behavior applies to the resource?

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

B. No lock because multiple locks cancel each other

C. ReadOnly because the most restrictive applicable lock takes precedence

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

Correct Answer: C

Explanation

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

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

Question 10

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

Which solution best meets the requirement?

A. Apply a ReadOnly lock

B. Apply a CanNotDelete lock

C. Assign the Reader role to administrators

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

Correct Answer: B

Explanation

A CanNotDelete lock is specifically designed for this scenario.

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

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

Final SC-500 Takeaways

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

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

The key exam rule to remember

CanNotDelete = Read + Modify, but NO Delete

ReadOnly = Read, but NO Modify and NO Delete

And perhaps the most important conceptual distinction:

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

Go to the SC-500 Exam Prep Hub main page