TL;DR: RBAC grants permissions to roles; it is simple and fits organisation-wide privileges (admin, billing). ABAC evaluates attributes of user, resource and context; it fits rules like "same department, during business hours, non-confidential". ReBAC derives access from relationships (owner, editor of this document, member of the folder's team); it fits sharing models like documents. For a document product, use ReBAC for document access, RBAC for administrative functions, and ABAC conditions for policy overlays such as classification or device posture, all evaluated centrally on every request.
How to approach it
Start from the product's sharing model: who can share what with whom, and how access inherits through folders and teams. Show where pure RBAC breaks, then build the hybrid. Address performance and consistency, since that is where real systems struggle.
A strong answer
RBAC
Permission via role
- admin, billing, support
- Simple; explodes with fine-grained needs
ABAC
Rules over attributes
- Same department, business hours, data class
- Expressive; harder to audit
ReBAC
Access from relationships
- Owner of this doc, member of that folder
- Fits sharing models; needs a relationship store
Where RBAC breaks. Roles answer "what can editors do?" but not "is Alice an editor of this document?" Modelling per-document access with roles creates a role per document per permission, which explodes. RBAC still works well for global functions: workspace admin, billing admin, auditor.
Where ABAC fits. Rules over attributes: "confidential documents may not be opened from unmanaged devices", "contractors cannot export". Expressive, but hard to answer "who can see this document?" for audits, and policies can become opaque.
Where ReBAC fits. Access as a graph of relationships: Alice is an editor of doc-1; doc-1 is in folder-F; members of team-T are viewers of folder-F; Bob is a member of team-T. "Can Bob view doc-1?" is a graph walk. Google's Zanzibar paper (2019) described this model at scale, and open-source systems such as OpenFGA and SpiceDB implement it.
A hybrid design.
| Layer | Model | Example rule |
|---|---|---|
| Document and folder sharing | ReBAC | viewer if direct viewer, or editor, or viewer of parent folder, or member of a team with access |
| Administrative functions | RBAC | Workspace admins can manage members and policies |
| Policy overlays | ABAC | Confidential documents require a managed device; external users cannot download |
Engineering concerns.
- Central decision point. One authorization service or library answers
check(user, action, resource); every endpoint calls it, including search and export paths. - Search and listing. Filter results by permission inside the query or index, not after fetching, or you leak titles, counts and timing.
- Consistency. After a share is revoked, stale caches must not keep granting access; Zanzibar's approach uses consistency tokens so checks are at least as fresh as the change.
- Auditability. Support "who can access this?" and "why can Alice see this?" queries.
AI features. A RAG assistant over these documents must apply the same check at retrieval time with the requesting user's identity, or it becomes a way around the whole model.
What interviewers probe next
- "Link sharing: anyone with the link can view. How does that fit?" Model the link as a principal or a capability with its own relationship and expiry, revocable independently.
- "How do you keep check latency low?" Cache relationship lookups with bounded staleness, precompute group memberships, and colocate the authorization service.
- "How would you test this?" A matrix of principals and resources with expected outcomes, run on every change to policy code.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A document collaboration SaaS is outgrowing simple role-based permissions as customers ask for sharing, folders, teams and classification rules.
Start here
What does each model fit?
Which model describes 'shared with me'?
RBAC grants permissions to roles and fits organisation-wide privileges such as admin or billing. ABAC evaluates attributes of user, resource and context, fitting rules like 'same department, non-confidential'. ReBAC derives access from relationships, such as editor of this document or member of the folder's team, fitting sharing.
Carry it forwardRoles for privileges, attributes for context, relationships for sharing.
Weak answerForcing everything into roles.
Constraint changes
What goes wrong if sharing is modelled with roles?
How many roles would per-document sharing need?
You end up with a role per document or folder, thousands of roles, and nobody can answer who can see a file. Role explosion makes access reviews impossible and bugs likely.
Carry it forwardRole explosion signals the wrong model.
Weak answerCreating roles per resource.
Constraint changes
How would you combine the models?
Which rule belongs to which model?
ReBAC for document and folder access, RBAC for administrative functions, and ABAC conditions as policy overlays, such as blocking external sharing of confidential documents or requiring a managed device. All evaluated centrally on every request.
Carry it forwardCombine models, evaluated centrally.
Weak answerImplementing each model separately in each service.
Constraint changes
What if search or AI features list documents?
Do all read paths use the same checks?
They must apply the same permission checks before showing results or feeding content to a model. Many leaks happen when listing, search, export or retrieval paths bypass the main permission logic.
Carry it forwardEvery read path, including search and AI, uses the same checks.
Weak answerFiltering search results after retrieval in the UI.
Constraint changes
How do you keep it understandable for customers?
Can a customer see who has access to a file?
Provide clear sharing UIs, 'who has access' views per document, audit logs of permission changes, and access reviews for admins. Authorisation that customers cannot inspect leads to over-sharing.
Carry it forwardMake permissions visible and auditable.
Weak answerHiding the effective permissions.
Now defend it
What authorisation design would you recommend?
ReBAC for documents, folders and teams; RBAC for administrative functions; ABAC conditions for classification, external sharing and device posture; one central evaluation used by every read path including search, export and AI retrieval; and visibility through access views, audit logs and reviews.
How it's scored
Weak: Picks RBAC for everything, or defines the acronyms without a design.
Hire: Matches each model to the part of the product it fits, with a central check.
Strong Hire: Covers inheritance, search filtering, revocation consistency and auditability, and extends it to retrieval for AI features.
Common mistakes
- Filtering search results after retrieval.
- Role explosion from per-object roles.
- Caching authorization decisions without a revocation story.
- AI retrieval paths that bypass the authorization service.