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.
What does the "Fine-Grained Authorization Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to fine-grained authorization vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 11 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.