Evaluate permissions across an inherited role graph with denial taking precedence over grants. Design traversal, cache versioning, revocation handling, and resource-aware checks without returning allow too early.
Design Deny-Priority Authorization over a Role Graph
Company: Apple
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
Design a role-based access-control system where roles may inherit or reference other roles through a directed graph. Roles can explicitly grant or deny permissions, and a denial must take priority when inherited decisions conflict. Support efficient permission checks and caching.
### Clarifying Questions
Define the direction of inheritance edges, assignment of roles to users, permission scope, and whether cycles are allowed. For the worked model, an edge R->S means R inherits S, a user can have multiple assigned roles, and a check denies if any reachable role explicitly denies the requested permission; otherwise it allows if any reachable role grants it, and denies by default. These edge and default conventions are explicit practice choices around the reported denial-priority rule.
### What a Strong Answer Covers
Graph traversal with a visited set, conflict resolution across all reachable roles, cache keys and invalidation, revocation behavior, and an authoritative permission-check boundary.
### Follow-up Questions
- Why is it unsafe to return allow immediately after finding one grant?
- How does changing an inherited role invalidate decisions for users of other roles?
Overview: Evaluate permissions across an inherited role graph with denial taking precedence over grants. Design traversal, cache versioning, revocation handling, and resource-aware checks without returning allow too early.
Design Deny-Priority Authorization over a Role Graph
Apple
Jul 25, 2026
mediumSoftware EngineerOnsiteSystem Design
0
0
Design a role-based access-control system where roles may inherit or reference other roles through a directed graph. Roles can explicitly grant or deny permissions, and a denial must take priority when inherited decisions conflict. Support efficient permission checks and caching.
Clarifying Questions Guidance
Define the direction of inheritance edges, assignment of roles to users, permission scope, and whether cycles are allowed. For the worked model, an edge R->S means R inherits S, a user can have multiple assigned roles, and a check denies if any reachable role explicitly denies the requested permission; otherwise it allows if any reachable role grants it, and denies by default. These edge and default conventions are explicit practice choices around the reported denial-priority rule.
What a Strong Answer Covers Guidance
Graph traversal with a visited set, conflict resolution across all reachable roles, cache keys and invalidation, revocation behavior, and an authoritative permission-check boundary.
Follow-up Questions Guidance
Why is it unsafe to return allow immediately after finding one grant?
How does changing an inherited role invalidate decisions for users of other roles?