A company manages its production workloads in a dedicated Azure subscription under the root management group. The infrastructure team recently created a critical resource group named 'rg-prod-core' that contains networking resources. To prevent accidental deletion of this entire resource group, the team needs a mechanism that blocks delete operations on 'rg-prod-core' while still allowing changes to resources within it. The solution must not affect any other resource groups in the subscription. Which Azure feature should the team apply to 'rg-prod-core'?

Assign an Azure Policy with the 'deny' effect at the management group scope to block deletions of any resource group.

This would affect all resource groups under the management group, not just the specific one. Additionally, Azure Policy is typically used for compliance and governance rules, not primarily to prevent accidental deletions; a resource lock is the simpler and more targeted solution.

Create a custom RBAC role that explicitly denies the delete action, and assign it to the infrastructure team at the resource group scope.

While a custom role could theoretically block deletions for a specific team, it does not prevent the resource owner or another privileged user from deleting the resource group. It also adds unnecessary complexity compared to using a resource lock, which is the recommended practice for preventing accidental deletion.

Deploy an Azure Blueprint that includes a policy to audit deletions of the resource group.

Azure Blueprints are used to deploy a collection of resources and policies consistently. An audit policy only reports on compliance but does not actively prevent deletion. This does not meet the requirement to block delete operations.

What does this AZ-900 question test?

Standard ACLs match source addresses.

What is the correct answer to this question?

The correct answer is: Apply a resource lock with the 'CanNotDelete' setting to the resource group. — Resource locks are the appropriate Azure feature to prevent accidental deletion or modification of critical resources. A 'CanNotDelete' lock blocks delete operations but still allows changes to the resources, and it can be applied at the resource group level to affect only that specific group. Azure Policy with the 'deny' effect would apply broadly unless scoped specifically, but resource locks are simpler and designed for this purpose. Custom RBAC roles add complexity and are not the recommended approach. Azure Blueprints are used for deploying environments, not for locking resources.

What should I do if I get this AZ-900 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.