Implement authorization as a governed decision system

Role-based access control assigns permissions to roles and assigns principals to those roles. Attribute-based access control evaluates policies over the principal, action, resource, and environment. RBAC is usually easier to explain for stable job functions; ABAC can express tenant, project, ownership, classification, time, network, and resource-state boundaries without creating a role for every combination. Production systems commonly use a hybrid: a role grants a coarse capability and attributes constrain where, when, and on which objects it applies.

In an interview, this topic is almost always asked as a design question: "How would you implement authorization for this multi-tenant service?" The interviewer is probing three things in sequence — whether you can choose a model on concrete criteria, whether you know where the decision is enforced, and whether you understand that administration, not the model, is where these systems fail. A weak answer picks RBAC or ABAC as an ideology, describes the policy language, and never mentions who issues attributes, what happens when one is missing, or which code paths actually call the check. A strong answer treats authorization as a governed decision system: a decision point, a policy set with defined precedence, an attribute supply chain, and an audit trail that can reconstruct any allow.

Choosing between the models on concrete criteria

Decide on the shape of the rules, not on preference. If access tracks job function and the resource set is coarse ("support engineers can read all tickets"), RBAC fits: permissions bundle into roles, roles get owners and review cadences, and the model is easy to explain to auditors. If access tracks relationships or context — owner, same tenant, same project, business hours, VPN-only, resource marked confidential — then RBAC needs a role per combination and ABAC fits. Where the resource graph dominates (parent folders, delegated editors, team membership), relationship-based rules (ReBAC) complement both.

The honest interview answer is the hybrid, and it is the default in real systems: a role grants the coarse capability ("can delete documents"), attributes constrain where it applies ("within her tenant, on documents she owns or that are marked internal"). Say this explicitly and then defend the split: the role keeps the permission set small and reviewable; the attributes keep the role count from exploding.

Role explosion: the failure mode to name early

Role explosion is what happens when RBAC meets context: every team × environment × data-class combination becomes its own role, and the role list grows faster than anyone can review it. Spot it early by counting roles against job functions — if roles outnumber distinct duty sets by a wide margin, or if role names contain conjunctions ("eng-prod-pii-temp"), the model is degrading. The costs are concrete: access reviews take longer than the review cycle, nobody knows who holds a role, provisioning requires a role-creation ticket, and an unused role still authorizes a write — standing privilege with no observed need.

The fix is to stop encoding context into roles and move it into attributes or relationships. Interviewers often probe this directly: "Your RBAC system has 400 roles and growing. What do you do?" The weak answer is tooling or cleanup. The strong answer is to identify which role dimensions are actually context (tenant, environment, classification), lift them into governed attributes, and collapse the role list back to genuine job functions.

Attribute governance: the hard part of ABAC

The model is only as trustworthy as its administration. Treat tags as security control-plane data: a department, tenant, clearance, project, or resource tag is security-sensitive. Give each attribute an authoritative issuer, schema, type, allowed values, freshness rule, and owner. Prevent a principal from changing its own privilege-bearing attributes or relabeling a resource to make a policy pass — the issuer of a privilege-bearing attribute must be more narrowly authorized than anyone whose access the attribute increases. Define whether missing, malformed, conflicting, or stale values deny, and test those cases explicitly. Free-form tags with no controlled vocabulary turn ABAC into self-service escalation.

This is the most common ABAC follow-up: "What happens when an attribute is missing?" Fail-closed for anything security-relevant — deny or return indeterminate per explicit policy, never infer the most privileged value to preserve availability. A weak answer hasn't considered the question; a strong one states the semantics and the test that covers it.

Enforcement architecture: where the decision is made

Keep policy decisions server-side at a trusted enforcement point. Build a canonical request containing authenticated principal identity, action, canonical resource identity, tenant, relevant resource attributes, and bounded environmental context. The policy decision point returns allow or deny plus a useful reason and policy version; the enforcement point must apply that decision to the exact resource and action. UI hiding is not authorization. Object-level checks remain necessary even when a route or role was already approved. A GraphQL resolver, a bulk export, and a background worker that skip the same check are additional enforcement paths, not one.

Interviewers probe enforcement coverage hard: "List every path by which a client can read a document object." If you can't enumerate the resolvers, bulk endpoints, exports, and async jobs, you can't claim the check is enforced. Centralized policy does not help if one enforcement path forgets to ask or applies the answer to a different object — resource-ID substitution inside an approved route is the classic exploit this catches.

Deny by default and define combining semantics deliberately. Explicit deny, permissions boundaries, organization guardrails, role permissions, and resource policies may intersect or combine differently across platforms. A policy engine must not silently turn an evaluation error, unknown attribute, timeout, or stale cache into allow. Document precedence and create truth-table tests for overlapping allow and deny rules. The operational question is not just whether a policy reads correctly, but which complete policy set actually governs the request.

Designing the roles themselves

RBAC design starts from job tasks and resource actions, not organization-chart titles. Roles need an owner, purpose, permissions, eligible population, grant and approval path, review cadence, and retirement condition. Use role hierarchies sparingly because inherited permissions are easy to overlook. Enforce static separation of duty by preventing conflicting assignments and dynamic separation by preventing conflicting actions in the same transaction or session. Temporary elevation should be scoped, approved, time-bound, strongly authenticated, logged, and automatically removed. A role named after a team is usually a group; a role named after a task is usually a permission bundle.

ABAC helps control role explosion, but policy and attribute explosion are equivalent failure modes. Prefer a small governed vocabulary and reusable predicates. Avoid encoding volatile team names or one-off exceptions into global policy. Choose the model that mirrors the resource graph while keeping decisions explainable and reviewable.

Policy as versioned software

Treat policy as versioned software. Validate syntax and schemas, unit-test representative allows and denies, add adversarial cross-tenant and missing-attribute cases, measure coverage, review changes, stage them, and support rollback. Replay production-shaped requests against old and candidate policy to find privilege expansion and lockout before deployment. Separate policy authorship, approval, deployment, and emergency override for high-impact systems. A break-glass path must be narrow, expiring, monitored, and tested rather than a permanent superuser exception.

Caching must preserve authorization semantics. Include every decision-relevant input and policy or data version in the cache key, use short bounded lifetime, and invalidate on revocation or sensitive attribute changes. Never cache a decision solely by user and route when the resource, tenant, action, relationship, or context can differ. If revocation has a required maximum delay, the distribution and cache design must satisfy it. Define fail-open or fail-closed behavior per operation, with high-impact writes normally failing closed.

Audit and measurement

Audit the decision without leaking unnecessary personal or secret data. Record decision ID, principal and resource identifiers, action, outcome, policy version, matched rule or reason code, relevant attribute versions, enforcement point, latency, and error state. Redact or hash sensitive values and restrict access. Logs should answer both "why was this allowed?" and "who can access this resource?"; ABAC often needs inventory or simulation tooling because reading group membership alone is insufficient. When a reviewer cannot reconstruct the inputs that produced an allow, the decision is not auditable even if the log row exists.

Measure authorization safety through denied cross-tenant attempts, unexplained or indeterminate decisions, privilege-expansion diffs, stale grants, unused roles, emergency access, revocation latency, policy rollback, decision latency, cache correctness, and review completion. Test identity mix-up, resource-ID substitution, missing and attacker-controlled attributes, conflicting policies, stale replicas, engine outage, concurrent changes, bulk APIs, background jobs, exports, and every alternate protocol.

What interviewers probe, and the follow-ups to expect

The likely follow-up chain, in rough order:

1. Model choice — "RBAC or ABAC here?" Expect to justify the hybrid split and name the criteria: stability of job functions versus variability of context.
2. Missing data — "An attribute is missing or stale. Allow or deny?" Fail-closed semantics, stated explicitly, with the test that covers it.
3. Enforcement coverage — "What about the bulk export / the background job / the GraphQL resolver?" Enumerate the alternate paths; one missed path is the whole answer.
4. Precedence — "An allow from the role, a deny from the resource policy. Who wins?" Explicit deny wins in most engines, but the point is that you define and test the truth table rather than assume.
5. Revocation — "How fast does a fired employee lose access?" This drives the cache TTL and session design; give a number and the mechanism that meets it.
6. Scale — "Ten million documents, a policy decision per object in a list view. What's your latency budget?" Expect to discuss decision latency, batching, and caching without breaking revocation.

A weak answer sounds like a textbook comparison of the two acronyms. A strong answer sounds like someone who has operated one: it names the attribute issuer, the fail-closed rule, the enforcement paths, and the metric that would catch a regression.