3.6 Resource Locks, RBAC, Policy, and Tags Combined

Four controls, four jobs

Azure administrators often combine RBAC, Azure Policy, resource locks, and tags on the same workload. They are not interchangeable. RBAC decides who can perform actions at a scope. Azure Policy decides whether resource configurations are allowed, audited, modified, or remediated. Resource locks protect existing scopes or resources from delete or write operations. Tags classify resources for reporting, automation, and cost allocation.

This mapping is one of the highest-value governance skills for AZ-104. When a question says ensure users cannot delete, think lock or RBAC depending on whether users still need other write actions. When it says ensure resources include a tag, think Policy. When it says identify all resources owned by finance, think tags and resource graph or portal filters. When it says allow a user to restart VMs but not create networks, think built-in or custom RBAC role.

Resource locks in practice

Azure supports two main lock levels: CanNotDelete and ReadOnly. A CanNotDelete lock allows authorized users to read and modify a resource but prevents deletion. A ReadOnly lock prevents delete and write operations, making the scope behave like read-only for management-plane operations. Locks can be applied at subscription, resource group, or resource scope, and child resources inherit locks from parent scopes.

Subscription lock
`-- Resource group inherits lock
    `-- VM inherits lock

Resource group CanNotDelete lock
|-- VM cannot be deleted
|-- NIC cannot be deleted
`-- Disk cannot be deleted

A lock can block an Owner. This surprises many candidates. Owner includes permissions to manage resources and access, but if a lock is present, the operation is blocked until the lock is removed. The user must have permission to remove the lock, usually through Microsoft.Authorization/locks/delete, and then perform the operation. In production, lock removal should be controlled and monitored.

CLI examples:

az lock create --name protect-prod-rg --lock-type CanNotDelete --resource-group rg-app-payments-prod
az lock list --resource-group rg-app-payments-prod --output table
az lock delete --name protect-prod-rg --resource-group rg-app-payments-prod

How controls interact

Consider a production resource group with these settings: a CanNotDelete lock, a policy requiring CostCenter, a policy denying public IPs, tags for owner and application, and RBAC granting the app team Contributor. The app team can deploy compliant resources that do not violate policy. They cannot deploy a public IP because policy denies it. They cannot delete the resource group because the lock blocks deletion. Their resources show in cost reports because tags exist. Finance receives budget alerts when spending crosses thresholds.

If the app team asks why a deployment failed, the error source matters. A policy denial usually appears in the deployment error with the policy assignment and definition. A lock failure mentions scope is locked. An RBAC failure says authorization failed or the client lacks permission. A quota failure mentions limits. A provider registration failure mentions unregistered provider or missing namespace. AZ-104 troubleshooting questions often include these clues.

Scenario workflow

A production database resource group must be protected from accidental deletion, must include cost tags, and must only allow the database team to manage resources. Start with RBAC: assign the database team Contributor at the resource group scope, not subscription Owner. Assign Reader to auditors if they only need visibility. Next, apply a CanNotDelete lock to the resource group. Then assign tag policies at the subscription or management group to require and inherit cost tags. Finally, create budgets and alerts at the resource group or subscription scope as required.

If the database team also needs to prevent changes, not just deletion, consider a ReadOnly lock. But this can break normal operations because many Azure services require write operations for scaling, backup configuration, diagnostic settings, key rotation, or agent updates. For active production workloads, CanNotDelete is often safer than ReadOnly unless a change freeze is intended.

RBAC and Policy exam contrast

RBAC is allow-based. If no role assignment grants the action, the action fails. Azure Policy is rule-based governance over resource properties and related configuration. If RBAC allows a create operation but Policy denies the requested SKU, the create fails. If Policy would allow the resource but RBAC does not grant write permission, the create fails. Both must permit the operation.

Tags do not affect either permission or policy unless a policy rule uses tag conditions. A tag such as Environment=Prod can be used by a policy condition, but the tag itself does not enforce anything. A lock does not classify the resource or show cost ownership. Each control has a limited role, and the correct design layers them.

Exam traps

Do not choose a lock to require tags. Do not choose tags to restrict access. Do not choose RBAC to force all storage accounts to use private endpoints if users still need broad create rights; use Policy for the configuration rule. Do not choose Policy to notify at 80 percent cost; use a budget.

Also remember scope inheritance. A lock at a resource group affects resources inside the group. A policy at a management group affects child subscriptions. RBAC at a subscription can give access to all resource groups in that subscription. Scope mistakes are often more important than feature mistakes.