RBAC vs ABAC for systems analyst interviews

Why interviewers ask

Every product with users eventually answers the same question: who is allowed to do what. As a systems analyst, you write that answer into the spec — permissions tables, role catalogs, policy rules. On the interview whiteboard, the prompt usually sounds innocent: "How would you design authorization for this app?" The candidates who improvise get crushed in the follow-up. The ones who name the model — ACL, RBAC, ABAC, ReBAC — and justify the trade-off get the loop.

The pain shows up about twelve months after launch. A system that started with three clean roles ends up with manager_emea_premium_active_readonly and forty-two variants of it. Engineers are afraid to touch the policy file. Auditors find ghost accounts. The fix is almost never "more roles" — it is picking a different model, or layering two of them. That is what this guide rehearses.

A second reason this question gets asked: it is one of the few security topics a non-security SA can actually own. You will not be designing the cryptography in JWT, but you will absolutely be writing the permissions matrix that the JWT carries.

ACL the baseline

Access Control List is the simplest model. For each object you store a list of (subject, permission) pairs. Unix file permissions, S3 bucket policies, and Google Docs link-sharing are all ACL underneath.

file: /reports/2026-q1.pdf
  - alice@stripe:    read, write
  - bob@stripe:      read
  - carol@stripe:    read, delete

The model is embarrassingly local — you can look at one object and see every grant. That locality is also its weakness. If your CISO says "revoke read access from anyone who left the EMEA legal team," you must scan every object. With ten million documents and a hundred thousand users, ACL becomes a combinatorial brick.

Where ACL fits: small object sets, ad-hoc sharing, low policy churn. The moment you find yourself writing a script to mass-update ACL entries, you have outgrown it.

RBAC role-based access

Role-Based Access Control is the workhorse of enterprise systems. Permissions attach to roles, users get roles. Standardized by NIST in 2004 and supported natively by Active Directory, Okta, every major SaaS admin console.

Roles:
  admin     — full access
  manager   — read, write own department
  analyst   — read all, no writes
  user      — read own profile

Assignments:
  alice  → admin
  bob    → manager
  carol  → analyst

Roles can inherit. admin ⊇ manager ⊇ user keeps the role graph compact. The audit story is clean: "who can approve refunds?" becomes "who has the refund_approver role?" — one SQL query.

The role explosion failure mode is the famous one. When the business adds "managers in EMEA can approve refunds under $500 only during business hours," you either invent manager_emea_refund_lt500_business_hours or you stop. RBAC stops gracefully when role count crosses roughly fifty and roles start encoding context.

This is why most large companies do not run pure RBAC for long — they layer ABAC on top once the role list crosses a few dozen.

In the spec, RBAC means: a permissions matrix, a role catalog with descriptions, an owner for each role, and a process for assignment and revocation.

ABAC attribute-based access

Attribute-Based Access Control decides each request by evaluating a policy over four attribute bags: subject, object, action, environment.

Policy: "Manager may read a contract if"
  subject.department == object.department
  AND object.status == "active"
  AND action == "read"
  AND environment.time IN business_hours
  AND environment.mfa == true

The attribute model is what makes ABAC expressive. Subject brings role, team, clearance, location. Object brings owner, sensitivity, tag, status. Action is the verb. Environment carries the things that change per request — time of day, IP, device posture, MFA freshness in minutes.

# Open Policy Agent (Rego)
package authz

default allow = false

allow {
  input.subject.department == input.object.department
  input.object.status == "active"
  input.action == "read"
  input.environment.mfa == true
}

Engines you will see named: OPA (Rego), AWS Cedar, AWS IAM JSON policies, and the historical XACML (XML-heavy, mostly dead outside government). Cedar and Rego are what shows up on modern architecture review docs.

The trade-off is debuggability. When a user reports "I cannot read this contract," you have to replay a four-tuple of attributes against the policy and figure out which condition failed. Without a decision-log and policy tests, ABAC turns into a black box. Plan for policy unit tests the same way you plan for API tests — that is a non-negotiable line item in the spec.

Hybrid models RBAC plus ABAC and ReBAC

Pure RBAC and pure ABAC are textbook constructs. Production systems blend them.

RBAC + ABAC is the default for enterprise SaaS. Roles do the coarse cut — "only managers can even see the refund console" — and ABAC handles the fine cut — "and only their own department, only during business hours, only with fresh MFA." The role gates the door; the policy gates the action.

ReBAC (Relationship-Based Access Control) is the model behind Google Drive and most social products. Authorization is a graph traversal: "Alice owns document X, Alice shared with Bob, therefore Bob can read X." The famous reference is Google's Zanzibar paper (2019); the open-source implementation is SpiceDB from AuthZed.

alice  -[owner]->     document_X
alice  -[shared]->    bob       (permission: viewer)
bob    -[can_read]->  document_X   (derived)

ReBAC handles things RBAC and ABAC stumble on: "folder permissions inherit to files," "team membership inherits to all team channels," "comment authors can edit their own comments but not others." Anywhere your access logic is naturally a graph, ReBAC is the cleaner abstraction.

PBAC (Policy-Based Access Control) is essentially ABAC with the marketing renamed to emphasize the policy artifact. In interviews, treat PBAC and ABAC as synonyms unless the company has a specific definition.

When to choose what

The heuristic that wins interviews: start with RBAC, layer ABAC when roles cross 50, switch to ReBAC if your model is naturally a graph. Say that out loud on the whiteboard.

Naming a concrete trigger (the 50-role threshold, the graph shape) signals you have shipped this, not just read about it.

Common pitfalls

Role explosion without a layering plan. The first failure mode of any RBAC system is roles named like manager_west_premium_readonly_v2. Each new business rule births a new role, and within two years no one can describe what any role does. The fix is not "be more disciplined" — discipline always loses to deadline pressure. The fix is to plan the ABAC layer before the role count crosses thirty, so the next business rule becomes a policy line, not a new role.

Hardcoding policies in application code. When the authorization logic lives in if user.role == "manager" and item.status == "active" scattered across a hundred files, every rule change is a deploy. Worse, the auditor cannot answer "what are the rules" without reading the entire codebase. Externalize authorization into a policy engine (OPA, Cedar) or at minimum a single dedicated module. Treat it as a separate service with its own SLO.

Leaving authorization out of the spec. "Auth by roles" is not a spec. A real authorization section in a systems-analyst document lists every role, every permission, the assignment owner, the revocation process, and the audit cadence. Without that, engineering invents it, security reviews it six months later, and someone has to retrofit compliance evidence.

No audit trail or insufficient logs. When a breach happens, the first thing the regulator asks is "who accessed what, when, under which role." A system without per-request authorization decision logs — including the policy version evaluated — cannot answer. Logging the decision is the difference between a one-day incident and a six-month investigation.

A single root account for everything. If one admin role can do every action, the compromise of one credential is total. The countermeasure is least privilege (each role gets the minimum) plus 4-eyes (two independent admins required) on destructive operations. Cloud providers ship break-glass procedures for exactly this reason; build the equivalent in any system above toy size.

Time-bound permissions with no expiry. Contractor onboarded for a three-month engagement gets a role, the engagement ends, the role does not. Two years later they still have access. Every elevated permission needs a TTL and a periodic access review — usually quarterly for sensitive roles, annual for the rest. Tools like Okta Lifecycle and AWS Access Analyzer help, but the process belongs in the spec.

Confusing authentication and authorization on the whiteboard. The classic interview trap: candidate hears "authentication" and starts drawing roles. Authentication answers who are you (passwords, MFA, OAuth). Authorization answers what can you do (RBAC, ABAC). They are layered, not interchangeable. See the authentication vs authorization guide for the full distinction.

Related reading

• Authentication vs authorization for systems analysts
• JWT for systems analyst interviews
• OAuth for systems analyst interviews
• OWASP Top 10 for systems analyst interviews
• 2FA and MFA for systems analyst interviews

If you want to drill authorization scenarios like this every day, NAILDD ships 500+ systems-analyst questions across exactly this pattern — RBAC vs ABAC trade-offs, policy debugging, and whiteboard auth flows.

FAQ

What does Active Directory actually use?

Active Directory is RBAC with nested groups. A user belongs to groups, groups can belong to groups, and permissions attach to groups. The nesting gives you inheritance without the formal role hierarchy. At enterprise scale, AD usually pairs with an external policy engine for the fine-grained rules — group membership decides the role, the policy engine decides the action.

Can I use RBAC and ABAC at the same time?

Yes, and it is the most common production pattern. RBAC handles coarse gating ("manager role required to reach this endpoint"); ABAC handles the conditional layer ("and the contract must be in your department"). Most modern policy engines, including OPA and Cedar, model both natively. The role becomes one of the attributes the policy reads.

Is OAuth scope a form of RBAC?

Close, but not identical. An OAuth scope is a coarse-grained permission attached to a token — read:contracts, write:invoices. Scopes are not bound to roles by the OAuth spec; they describe what the token can do, not who the bearer is. In practice teams layer RBAC on top: roles decide which scopes get issued, and the API treats scopes as the actual authorization check.

Is AWS IAM RBAC or ABAC?

AWS IAM is ABAC under the hood. Policies are JSON documents with Effect, Action, Resource, and a Condition block that reads attributes — tags, regions, MFA status, time of day. IAM "roles" are bundles of policies you assume, not RBAC roles in the classical NIST sense. The 2018 launch of IAM tags-as-conditions made the ABAC nature explicit and is the recommended pattern for multi-account environments.

How do I unit-test ABAC policies?

Treat the policy file like source code. Write tests that pass a (subject, object, action, environment) tuple to the engine and assert the decision. OPA ships opa test, Cedar has a formal verification tool, and AWS Verified Permissions has a built-in tester. Cover the obvious positives, the boundary cases (status changes, MFA expired), and fuzz the corner cases — wrong tenant, stale token, missing attribute. Policy regressions are the kind of bug that ships silently and surfaces in an audit.

Is this guidance considered authoritative?

No — treat it as interview prep. The references behind the model definitions are the NIST RBAC standard (2004), the NIST ABAC guide (SP 800-162, 2014), Google's Zanzibar paper (2019) for ReBAC, and the public docs for OPA, Cedar, and AWS IAM. For production design always consult your security team and the current vendor documentation.