Practice the vocabulary of checking access at the level of an individual resource, not just a broad role.
0 / 5 completed
1 / 5
At standup, a dev mentions checking whether a specific user can access a specific individual resource, like one particular document, rather than only checking a broad role like 'editor' for the whole application. What is this authorization approach called?
Fine-grained authorization checks whether a specific user can access a specific individual resource, like one particular document or record, rather than only verifying a broad role such as 'editor' across the whole application. Coarse-grained role checking can't express a case where a user should access some documents but not others within the same role. This resource-level precision is what lets an authorization system express a realistic, detailed access policy.
2 / 5
During a design review, the team wants to express an access rule like 'a user can view a document if they're a member of the team that owns it,' evaluated dynamically rather than hardcoded per document. Which capability supports this?
A relationship-based access control, or ReBAC, model expresses an access rule like 'a user can view a document if they're a member of the team that owns it' as a relationship the system evaluates dynamically, rather than hardcoding a separate access list for every individual document. Hardcoding a fixed list per document doesn't scale and quickly becomes inconsistent as team membership changes. This relationship-based approach lets access naturally follow an underlying organizational structure instead of needing constant manual upkeep.
3 / 5
In a code review, a dev notices every service that needs to check a permission calls a single, centralized authorization service rather than each service implementing its own separate access-check logic. What does this represent?
A centralized policy decision point has every service call one shared authorization service to check a permission, rather than each service independently implementing its own separate access-check logic that could drift out of consistency over time. Independent, per-service logic risks one service enforcing a rule slightly differently than another for the same underlying resource. This centralization keeps an authorization policy consistent and auditable across an entire system.
4 / 5
An incident report shows a user retained access to a document for hours after being removed from the owning team, because a cached authorization decision wasn't invalidated when the underlying relationship changed. What practice would prevent this?
Invalidating or promptly refreshing a cached authorization decision whenever the underlying relationship it depends on changes prevents a user from retaining access well after they should have lost it. Caching indefinitely with no invalidation trades a real security gap for a performance shortcut. This cache-invalidation discipline is necessary because fine-grained, relationship-based authorization checks are often cached for performance, and that cache must stay honest about the current relationship.
5 / 5
During a PR review, a teammate asks why the team adopts fine-grained, relationship-based authorization instead of simply checking a broad application-wide role for every access decision. What is the reasoning?
A broad application-wide role check can't distinguish between two resources that should have different access outcomes for the same user under that same role. Fine-grained, relationship-based authorization expresses that distinction precisely, evaluated per resource. The tradeoff is the added system complexity of maintaining relationships and a centralized policy decision point instead of a simpler, coarser role check.