Role-based access control in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Role Hierarchies in RBAC

In a microservices system using Role-Based Access Control (RBAC), which statement best describes the role hierarchy concept?

A Role hierarchy means roles are assigned randomly without any structure or inheritance.

B Roles are independent and do not share permissions; each role must be assigned permissions explicitly without inheritance.

C Higher roles inherit permissions from lower roles, allowing users with higher roles to access all resources of lower roles.

D Lower roles inherit permissions from higher roles, so users with lower roles can access resources of higher roles.

💡 Hint

Think about how managers have more access than employees in a company.

In RBAC, higher roles inherit permissions from lower roles, so users with higher roles automatically get all permissions of the roles below them.

❓ Architecture

intermediate

Designing RBAC in Microservices

Which architecture best supports centralized role management and decentralized permission enforcement in a microservices environment?

A Each microservice manages its own roles and permissions independently without a central authority.

B A central authorization service manages roles and permissions; each microservice queries it to enforce access control locally.

C Roles and permissions are hardcoded in each microservice's codebase with no external management.

D A central database stores user data but roles and permissions are managed by clients.

💡 Hint

Think about separating management and enforcement responsibilities.

Centralizing role management simplifies updates and consistency, while local enforcement in microservices reduces latency and dependency.

❓ scaling

advanced

Scaling RBAC for Millions of Users

When scaling RBAC for millions of users across many microservices, which approach best reduces latency and load on the central authorization service?

A Use short-lived access tokens containing user roles and permissions, validated locally by microservices without querying central service each time.

B Require every microservice to query the central authorization service for each user request to get fresh permissions.

C Store all user roles and permissions in each microservice's local database and sync daily with central service.

D Disable RBAC and rely on network firewalls to restrict access.

💡 Hint

Think about caching permissions securely to avoid repeated calls.

Embedding roles in short-lived tokens allows microservices to verify permissions quickly without frequent central queries, improving performance and scalability.

❓ tradeoff

advanced

Tradeoffs in RBAC Permission Granularity

What is a key tradeoff when choosing very fine-grained permissions in an RBAC system for microservices?

A Fine-grained permissions increase security but add complexity and overhead in managing many permissions.

B Fine-grained permissions reduce security risks and simplify management.

C Fine-grained permissions eliminate the need for roles entirely.

D Fine-grained permissions always improve system performance.

💡 Hint

Consider how many permissions you must track and update.

More detailed permissions improve control but require more effort to maintain and can slow down authorization checks.

❓ estimation

expert

Estimating Capacity for RBAC Authorization Service

You design a central RBAC authorization service for a system with 10 million users and 100 microservices. Each user makes on average 5 requests per second requiring authorization. Estimate the number of authorization checks per second the service must handle if all microservices query it directly.

A 1 million authorization checks per second

B 500 thousand authorization checks per second

C 5 million authorization checks per second

D 50 million authorization checks per second

💡 Hint

Multiply users, requests per second, and microservices.

Each user makes 5 requests/sec, 10 million users total = 50 million requests/sec. If each request queries the central service, it must handle 50 million checks/sec.

Practice

1. What is the main purpose of Role-Based Access Control (RBAC) in microservices?

easy

A. To encrypt data between microservices

B. To monitor network traffic for security threats

C. To assign permissions to users based on their roles

D. To deploy microservices automatically

Solution

1. Step 1: Understand RBAC concept

   RBAC assigns permissions to users based on their roles, simplifying access management.

2. Step 2: Identify RBAC purpose in microservices

   In microservices, RBAC controls who can access which service or API based on roles.

3. Final Answer:

   To assign permissions to users based on their roles -> Option C

4. Quick Check:

   RBAC = Role-based permission assignment [OK]

Hint: RBAC controls access by roles, not by encryption or deployment [OK]

Common Mistakes:

• Confusing RBAC with encryption
• Thinking RBAC monitors network traffic
• Assuming RBAC automates deployment

2. Which of the following is the correct way to represent a role in an RBAC system for microservices?

easy

A. {"service": "admin", "level": 5}

B. {"role": "admin", "permissions": ["read", "write"]}

C. {"user": "admin", "access": "full"}

D. {"permission": "admin", "role": "read"}

Solution

1. Step 1: Identify correct role structure

   A role should have a name and a list of permissions it grants.

2. Step 2: Match structure to options

   {"role": "admin", "permissions": ["read", "write"]} correctly shows a role with permissions as a list, matching RBAC design.

3. Final Answer:

   {"role": "admin", "permissions": ["read", "write"]} -> Option B

4. Quick Check:

   Role = name + permissions list [OK]

Hint: Roles have permissions list; user or service keys are incorrect here [OK]

Common Mistakes:

• Confusing user with role
• Using 'permission' as role name
• Assigning access level instead of permissions

3. Given this simplified RBAC check in a microservice:

def can_access(user_role, action):
    permissions = {
        "user": ["read"],
        "admin": ["read", "write", "delete"]
    }
    return action in permissions.get(user_role, [])

print(can_access("user", "delete"))

What is the output?

medium

A. None

B. True

C. KeyError

D. False

Solution

1. Step 1: Understand permissions dictionary

   The "user" role has only ["read"] permission, no "delete".

2. Step 2: Check if "delete" is in user permissions

   Since "delete" is not in ["read"], the function returns False.

3. Final Answer:

   False -> Option D

4. Quick Check:

   "delete" in user permissions = False [OK]

Hint: Check if action is in role's permission list [OK]

Common Mistakes:

• Assuming all actions allowed for user
• Expecting KeyError for missing keys
• Confusing True/False return values

4. A microservice uses this RBAC check:

def check_access(role, permission):
    role_permissions = {
        "editor": ["read", "write"],
        "viewer": ["read"]
    }
    return permission in role_permissions[role]

print(check_access("admin", "write"))

What is the problem and how to fix it?

medium

A. KeyError occurs; fix by using role_permissions.get(role, [])

B. SyntaxError due to missing colon; add colon after function

C. Returns False incorrectly; add "admin" role to dictionary

D. Returns True incorrectly; remove "write" from editor permissions

Solution

1. Step 1: Identify error cause

   Accessing role_permissions["admin"] causes KeyError because "admin" key is missing.

2. Step 2: Fix by safe dictionary access

   Use role_permissions.get(role, []) to return empty list if role missing, avoiding error.

3. Final Answer:

   KeyError occurs; fix by using role_permissions.get(role, []) -> Option A

4. Quick Check:

   Missing key causes KeyError; get() avoids it [OK]

Hint: Use get() to avoid KeyError on missing roles [OK]

Common Mistakes:

• Adding roles without permissions
• Confusing syntax errors with runtime errors
• Ignoring missing key errors

5. In a microservices architecture, where is the best place to enforce RBAC to ensure scalability and security?

hard

A. At the API Gateway before requests reach microservices

B. On the client side before sending requests

C. Only in the database layer with SQL permissions

D. Inside each microservice individually

Solution

1. Step 1: Consider scalability and security needs

   Enforcing RBAC centrally avoids duplication and reduces risk of inconsistent checks.

2. Step 2: Identify best enforcement point

   API Gateway is the central entry point, ideal for RBAC enforcement before microservices.

3. Final Answer:

   At the API Gateway before requests reach microservices -> Option A

4. Quick Check:

   Central RBAC at API Gateway = scalable & secure [OK]

Hint: Enforce RBAC centrally at API Gateway for best results [OK]

Common Mistakes:

• Enforcing RBAC only in microservices causes duplication
• Relying on client-side enforcement is insecure
• Using database permissions alone misses API-level control