RBAC vs direct user grants

WHAT THIS TESTS Whether you understand that adding a role layer between users and permissions turns per-user maintenance into per-role maintenance, which is the scalability win.

A GOOD ANSWER COVERS With direct user grants, each permission is assigned to an individual user. For a handful of users this is fine, but in a large organization it becomes unmanageable: granting a new permission to the analyst team means editing every analyst's grants, and forgetting one creates inconsistency. Auditing who can do what requires inspecting every user. Role-based access control inserts an indirection: you define roles such as analyst, developer, or admin, attach the relevant permissions to each role, and assign users to roles. A user inherits all permissions of their roles. To change what analysts can do, you edit the analyst role once and every member inherits the change instantly. Onboarding becomes assigning roles, and offboarding or role changes become reassigning roles.

COMMON WRONG ANSWERS Claiming RBAC and direct grants are equivalent, missing that direct grants scale with users times permissions, or conflating roles with individual accounts.

LIKELY FOLLOW-UPS Role explosion and how attribute-based access control addresses it; least privilege within roles; separation of duties; how groups relate to roles.

ONE CONCRETE EXAMPLE A company needs to give 200 analysts read access to a new reporting schema. With direct grants that is 200 edits, error-prone and slow. With RBAC, you grant the new permission to the analyst role once, and all 200 inherit it immediately. When an analyst becomes a manager, you swap their role rather than auditing and rewriting dozens of individual grants.