A ferry-terminal security desk re-creates the same Reader assignment for twelve individual users whenever a seasonal worker starts. What should the desk do instead so membership changes do not require new role assignments?

Azure role assignments can target users, groups, service principals, and managed identities. Assigning Reader once to a Microsoft Entra security group at the resource-group scope lets the ferry-terminal security desk manage seasonal workers by group membership instead of creating twelve individual role assignments every hiring cycle. When membership changes, Azure RBAC continues to evaluate the same group assignment, which is the durable least-privilege pattern for recurring human access.

Assigning Reader to each user at subscription scope fails the stated goal: it still requires per-user assignments for every seasonal worker and widens scope beyond the resource group. Storing each user’s object ID in an Azure Policy initiative fails by concept—Policy evaluates resource properties and effects; it is not the mechanism that grants Azure RBAC Reader to identities. Replacing Azure RBAC with a shared Reader service principal password fails on security and operations: shared passwords defeat individual accountability, complicate rotation, and misuse a service principal as a stand-in for interactive human Reader access.

Exam caveat: group-based Azure RBAC assignments are preferred over per-user sprawl; PIM can further gate standing group privileges when eligible assignments are required. Operational check: create or reuse an Entra security group, assign Reader once at the resource group, add a seasonal account to the group, confirm effective access, then remove the user from the group and confirm access ends without deleting a role assignment.