A municipal-water lab assigns Backup Contributor at the subscription and then finds the same principal can start backup jobs in every child resource group. How should the team shrink that blast radius while keeping Azure RBAC inheritance behavior accurate?

Role assignments at a parent scope are inherited by child scopes. Azure RBAC does not offer a “block inheritance” switch on resource groups. When the municipal-water lab assigned Backup Contributor at the subscription, every child resource group correctly inherited that principal’s backup rights. To shrink blast radius while keeping inheritance behavior accurate, remove the subscription assignment and assign Backup Contributor only on the resource groups that actually need backup operations.

Keeping the subscription assignment and enabling a fictional block-inheritance switch fails because no such Azure RBAC inheritance block exists on child resource groups; the assignment would continue to flow downhill. Replacing Backup Contributor with an Azure Policy Deny effect fails by concept: Policy can deny specific resource operations or configurations, but it does not cancel or rewrite inherited RBAC the way people sometimes imagine, and Deny policy is not the correct tool to “undo” a parent role assignment. Moving the principal to Reader at subscription scope fails because that still inherits to every child and only changes the role—it does not confine backup rights to selected labs, and it removes needed backup capabilities where they were intended.

Exam caveat: AZ-500 often pairs inheritance questions with the myth of blocking RBAC inheritance; contrast this with Azure Policy and with management-group hierarchies. Operational check: remove the subscription-level Backup Contributor assignment, add it only on the needed resource groups, then verify a non-target resource group no longer lists the principal under inherited access for backup actions.