RBAC vs ABAC: when do you reach for each in practice?
Short answer
RBAC grants permissions through roles assigned to users — simple to reason about but prone to role explosion as edge cases multiply. ABAC evaluates policies over attributes of the user, resource, action, and environment, so it scales to fine-grained, context-aware decisions at the cost of complexity. Most mature systems layer them: roles for coarse grants, attributes and policy for the conditional details.
Access control models decide who may do what to which resource. RBAC and ABAC are the two you will be asked to compare, and the strong answer is rarely "pick one."
RBAC: roles as the unit of grant
In role-based access control, permissions are bundled into roles, and roles are assigned to users. A billing-admin role carries the permissions to read invoices and issue refunds; anyone in that role inherits them. This is easy to audit ("who is in billing-admin?") and maps cleanly to job functions.
The failure mode is role explosion. Every "but this group of users needs almost the same thing, except..." spawns a new role. A few hundred users can end up behind thousands of overlapping roles that nobody fully understands, which quietly defeats least privilege.
ABAC: policies over attributes
Attribute-based access control evaluates a policy at request time over attributes: the subject (department, clearance, employment status), the resource (classification, owner, region), the action, and the environment (time of day, device posture, source IP). A rule like "allow read if user.department == resource.department and device.compliant == true" expresses what would take many RBAC roles in one statement.
The cost is complexity: you need a trustworthy source for every attribute, policies become harder to reason about, and "why was this denied?" can be non-obvious.
In practice: combine them
Most mature systems use roles for coarse-grained grants and attributes/policy for the conditional details — sometimes called PBAC or policy-as-code (e.g. OPA/Rego, AWS IAM conditions). RBAC answers "what job do you do," ABAC answers "in this specific context, is it allowed."
What interviewers look for: you can name role explosion and attribute trust as the real trade-offs, and you propose layering rather than treating it as a religious choice.
Likely follow-ups
- What is 'role explosion' and how does ABAC help avoid it?
- How would you combine RBAC and ABAC in one system?
- Where do you store and trust the attributes ABAC depends on?