Role-Based Access Control with Accounts, Parent-User Inheritance and Reverse Lookups

Build the access-control logic for a system in which users hold roles on accounts. Each user has one or more accounts, and on each account the user holds one or more roles. The question came in four parts that build on one another. The candidate remembers the overall shape but not the exact wording, so the data format below is an assumption to confirm with the interviewer. Assume the data arrives as plain records that you load into structures of your choice: ```text grants (user, account, role) parents (user, parent user) u1 a1 admin u2 -> u1 u1 a2 viewer u3 -> u2 u2 a1 viewer u3 a3 billing ``` The parent links matter only from Part 2 on. The first two questions in the report were simple lookups that a single loop answers; their wording was not preserved, so Part 1 states them as the two direct lookups this data supports. Parts 2 and 3 are the third and fourth questions as reported. Write clean, runnable code and extend the same code from part to part. ### Clarifying Questions - Does a role belong to one account, so that `admin` on one account says nothing about another, or are role names global? - Can the same grant appear twice in the input, and can a user appear with no grants at all? - Should results come back in a fixed order? - Will the data change between queries, and how many queries are expected compared with the size of the data? ### Part 1 — Direct roles Given a user and an account, return the roles the user holds on that account. Given a user, return all the roles the user holds across all of their accounts. Neither query involves parent users. ```hint Pick the shape first Decide how you store the grants so that both lookups read only the user's own records instead of the whole input. ``` #### What This Part Should Cover - A data model for users, accounts and roles, and the index built from the input - Behavior for an unknown user, an unknown account and duplicate grants - The output format and its ordering ### Part 2 — Roles inherited from a parent user Now each user may have a parent user, and a user inherits every role of their parent. Given a user, return all of the user's roles, including inherited ones. ```hint Follow the chain Ask what a parent's own parent contributes, and what your code does if the parent links ever lead back to a user already visited. ``` #### Clarifying Questions for this Part - Is inheritance transitive, so that a user also receives a grandparent's roles? - Does an inherited role keep its account, so that the child gains the parent's role on the parent's account? - Can a user have more than one parent, and can the input contain a cycle of parent links? #### What This Part Should Cover - Correct transitive resolution of inherited roles - Protection against cycles in the parent links - Complexity in terms of the chain length and the grants along it ### Part 3 — Users who can access given roles Given some roles, return the users who can access those roles, counting both direct and inherited roles. ```hint Turn the question around Part 2 starts from a user and walks to roles. Ask what you would need in order to start from a role instead, and in which direction inheritance carries a role from one user to others. ``` #### Clarifying Questions for this Part - When several roles are given, must a user have all of them, or is any one enough? - Are the roles given as role names, or as roles on specific accounts? - Is this query run once, or many times on the same data? #### What This Part Should Cover - Clear semantics for a request with several roles - An approach that avoids recomputing every user's roles from scratch, or a reasoned case for doing so - Inclusion of users who receive a role only through inheritance ### What a Strong Answer Covers - Asks about the ambiguous semantics before coding instead of guessing silently - Data structures that fit each query, including an index in the reverse direction where a part needs it - Correct, cycle-safe inheritance - Code that grows from part to part without a rewrite, with small tests for each part - The complexity of each query, and when precomputing pays off ### Follow-up Questions - Grants and parent links change often while queries keep arriving. Do you precompute effective roles or compute them on demand, and how do you keep a cache correct? - How would you support a user with more than one parent? - How would you add explicit deny rules that override an inherited role? - How would you show an administrator why a user has a particular role?