AZ-900 Describe Azure management and governance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Azure RBAC deny assignments

  Why it's wrong here

  RBAC deny assignments explicitly block specific actions for specific principals (users, groups, service principals) by providing an explicit deny rule that takes precedence over allow assignments. They are used primarily by Azure managed services like Azure Blueprints or by system-assigned managed identities to protect managed resources, but they are scoped to a principal and a set of actions, not to a resource itself. A Resource Lock, however, is not tied to any identity; it applies to every principal and only to deletion/modification actions, and it is managed independently of RBAC. So deny assignments provide an identity-centric restriction, while Resource Locks provide a resource-centric protection.

• ✗

  Azure Policy deny effects

  Why it's wrong here

  Azure Policy's deny effect is part of policy-based governance that evaluates resource properties (such as allowed locations or SKUs) during create or update operations, and denies any action that violates a policy definition. However, deny effects are not evaluated when a resource is deleted, and they do not quarantine or protect already deployed resources from deletion or modification. A Resource Lock, in contrast, proactively blocks any delete or update call on existing resources, regardless of whether the resource is compliant with any policy. Thus, Policy deny effects address non-compliance at admission time, not protection of existing resources.

• ✓

  Azure Resource Locks overriding RBAC

  Why this is correct

  Resource Locks are applied to a subscription, resource group, or individual resource and can be set to CanNotDelete or ReadOnly, which block deletion and modification actions at the Azure Resource Manager layer. Critically, a lock is evaluated after RBAC authorization, so even a user with the Owner role cannot delete or modify a locked resource unless they first remove the lock (which requires Microsoft.Authorization/locks/write permission). This explicit lock check is what allows Resource Locks to override RBAC permissions for those protected operations, providing a safety net against accidental or unauthorized changes. Therefore, when a resource must be safeguarded from deletion, the correct mechanism is the Resource Lock.

• ✗

  Azure AD Privileged Identity Management restrictions

  Why it's wrong here

  AAD PIM controls when and how long administrators can activate privileged roles such as Owner or Contributor, using just-in-time assignments and approvals. It manages the lifecycle of role assignment eligibility but does not impose any operation-level restrictions on Azure resources themselves. PIM does not prevent an authorized user from deleting an existing resource; it merely limits who can assume the role and for how long. Therefore it is not the mechanism that overrides RBAC for deletion/modification—that is the Resource Lock.

Go deeper

Related to this question