Cascade Regional Airlines' cloud administrator assigns the Contributor role to the maintenance-records support team at the resource group scope that holds their virtual machines and storage account. A new storage account is then created in a different resource group in the same subscription. What can the maintenance-records team do with the new storage account?
Select an answer to reveal the explanation.
Short Explanation
Think of an RBAC assignment like a keycard programmed for one floor of a building: it opens every door on that floor and any room built inside it later, but it does nothing on a different floor entirely. The team's Contributor keycard was cut for one resource group, so a sibling resource group stays locked to them.
Full Explanation
Azure RBAC role assignments are scoped, and scope defines a hierarchy: management group, subscription, resource group, then resource. A role granted at a given scope is inherited by every child scope beneath it, but it never reaches upward to a parent or sideways to an unrelated branch of the hierarchy. Because the new storage account lives in a separate resource group, it is not a descendant of the scope where the assignment was made, so none of the inherited permissions apply there. The idea that Contributor "spreads" across a subscription confuses scope inheritance with subscription-wide assignment; the same role assigned at the subscription instead of the resource group really would cover it. Azure Policy is a compliance and guardrail mechanism, not an access-granting one, so it cannot substitute for a role assignment. User Access Administrator is a separate built-in role that manages who has access; Contributor never carries it implicitly. To verify this in practice, open Access control (IAM) on the new storage account and check its role assignments list directly rather than assuming inheritance from elsewhere in the subscription.