System designHard~20 minCore Designs / 12 of 30

Interview question

Design an authorization model for a backend API with admins, editors, normal users, and resources owned by teams.

Design RBAC and resource ownership for a backend API

Designs authorization that combines roles, permissions, tenant context, resource ownership, and auditability.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would model roles and capabilities separately from resource ownership. A user may have a general role like editor, but access to a document or project still depends on team membership, tenant scope, or ownership. The API would enforce authorization server-side through policies and application-level checks, not through hidden UI buttons. Every endpoint that reads or mutates protected resources would check both the action and the target resource.

Full answer below

Practice focus

Role and permission modeling, resource ownership, policy checks, tenant scope, admin overrides, and security testing.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Authorization design is where many backend systems fail. The hard part is combining broad roles with resource-specific rules without scattering checks everywhere.
I would model roles and capabilities separately from resource ownership. A user may have a general role like editor, but access to a document or project still depends on team membership, tenant scope, or ownership. The API would enforce authorization server-side through policies and application-level checks, not through hidden UI buttons. Every endpoint that reads or mutates protected resources would check both the action and the target resource.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would define common permission questions: who can view, create, update, publish, delete, invite, export, or administer. Roles can bundle capabilities, while resource rules decide whether that capability applies to a specific tenant, team, or object. Admin override paths need audit logging and clear boundaries. I would also test negative cases: unauthenticated, authenticated but forbidden, wrong tenant, wrong owner, and stale membership.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make authorization observable and maintainable. Denied requests can be logged safely with actor, action, target type, and reason. Policy names and capability names need to be stable enough for code review and admin UI. I would avoid pushing business authorization entirely into identity-provider roles when the rule depends on application data. The mature design supports least privilege, admin recovery, auditability, and future role changes without rewriting every controller.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Checking only frontend visibility.
Treating role membership as enough for every resource.
Hard-coding authorization logic in many controllers.
No tests for forbidden and cross-tenant access.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot distinguish authentication from authorization.
Has no resource ownership check.
No audit trail for admin override actions.
Depends on client-supplied role or tenant values.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When are roles enough, and when do you need resource checks?
How would you test authorization failures?
How would admin override be audited?

Continue the section

Next in Core Designs: Feature Flag Backend

Step 13 of 30

Design a feature flag rollout backend

Opening drill

System designHard~20 minCore Designs / 12 of 30

Interview question

Design an authorization model for a backend API with admins, editors, normal users, and resources owned by teams.

Design RBAC and resource ownership for a backend API

Designs authorization that combines roles, permissions, tenant context, resource ownership, and auditability.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Role and permission modeling, resource ownership, policy checks, tenant scope, admin overrides, and security testing.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Authorization design is where many backend systems fail. The hard part is combining broad roles with resource-specific rules without scattering checks everywhere.
I would model roles and capabilities separately from resource ownership. A user may have a general role like editor, but access to a document or project still depends on team membership, tenant scope, or ownership. The API would enforce authorization server-side through policies and application-level checks, not through hidden UI buttons. Every endpoint that reads or mutates protected resources would check both the action and the target resource.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would define common permission questions: who can view, create, update, publish, delete, invite, export, or administer. Roles can bundle capabilities, while resource rules decide whether that capability applies to a specific tenant, team, or object. Admin override paths need audit logging and clear boundaries. I would also test negative cases: unauthenticated, authenticated but forbidden, wrong tenant, wrong owner, and stale membership.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make authorization observable and maintainable. Denied requests can be logged safely with actor, action, target type, and reason. Policy names and capability names need to be stable enough for code review and admin UI. I would avoid pushing business authorization entirely into identity-provider roles when the rule depends on application data. The mature design supports least privilege, admin recovery, auditability, and future role changes without rewriting every controller.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Checking only frontend visibility.
Treating role membership as enough for every resource.
Hard-coding authorization logic in many controllers.
No tests for forbidden and cross-tenant access.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot distinguish authentication from authorization.
Has no resource ownership check.
No audit trail for admin override actions.
Depends on client-supplied role or tenant values.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When are roles enough, and when do you need resource checks?
How would you test authorization failures?
How would admin override be audited?

Continue the section

Next in Core Designs: Feature Flag Backend

Step 13 of 30

Design a feature flag rollout backend

Design an authorization model for a backend API with admins, editors, normal users, and resources owned by teams.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Design an authorization model for a backend API with admins, editors, normal users, and resources owned by teams.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section