Role-Based Access Control (RBAC)

Role-Based Access Control assigns permissions to roles rather than to individual users. A role represents a job function (payroll clerk, database administrator), and users acquire permissions only by being placed into roles. Administrators manage a small set of role definitions instead of thousands of individual entitlements, which is why RBAC dominates in large organisations with well-defined job functions. Built properly, each role carries only the permissions the function needs, enforcing least privilege by design.

The model’s quiet strength shows at job transfer. When an employee moves departments, removing the old role and granting the new one strips the old entitlements in one step, which curbs privilege creep: the gradual accumulation of access that plagues discretionary access control, where owners grant access individually and rarely revoke it. RBAC is non-discretionary: a central authority defines the roles, and object owners do not hand out access on their own.

Exam relevance: if a scenario mentions job functions, departments, or cutting administrative overhead in a large organisation, the answer is RBAC. The classic trap is the shared acronym with rule-based access control: rules apply globally to everyone (firewall ACLs, time-of-day limits), while roles apply to job functions. Read the scenario for the words “job” or “position” versus a blanket condition applied to all users.