- Which analysis best identifies the access-control issue and the most appropriate conceptual response?
Answer: The design creates role explosion; ABAC could evaluate the independent characteristics without representing every combination as a role
When a question describes a role-naming scheme that multiplies across several independent dimensions, your first instinct should be to calculate the total number of roles and ask whether that number is manageable — then identify which access-control model would handle those dimensions more elegantly.
Here, the company already has 2 job functions × 2 regions = 4 roles. Adding 5 product lines and 3 sensitivity levels produces 2 × 2 × 5 × 3 = 60 distinct roles. As the organization grows, every new dimension multiplies that count again. This is the classic role explosion problem in Role-Based Access Control (RBAC): the number of roles becomes unworkable because each combination must be explicitly defined and maintained. Attribute-Based Access Control (ABAC) solves this by treating job function, region, product line, and sensitivity level as independent attributes evaluated at access time — no pre-built combination role required. That makes A the correct answer.
Choice B misuses terminology. "Attribute staleness" is not a recognized RBAC problem, and RBAC does not dynamically evaluate characteristics — that description actually fits ABAC, making the answer internally contradictory.
Choice C confuses role explosion with role hierarchy violations. Role hierarchies are about inheritance between senior and junior roles, which is not the issue described. Additionally, ABAC does not require senior roles to inherit junior attributes — that framing doesn't apply to ABAC at all.
Choice D misidentifies the problem as a least-privilege violation. Least privilege concerns excessive permissions, not an excessive number of roles. RBAC also does not restrict users to exactly one role — that's a fabricated constraint.
Study tip: Whenever you see role counts multiplying across independent dimensions, immediately think "role explosion → ABAC." That pairing appears frequently on security exams.
- Which access-control design most directly implements the requirements while minimizing the need to create new permission groupings?
Answer: ABAC, with policy rules evaluating subject, resource, and environmental attributes at the time of access
When you see an access-control question listing conditions that change dynamically and independently — shift schedules, device posture, regional assignments, clearance levels — you should immediately think about whether a role-based or attribute-based model fits better. The core question is: can you define stable, manageable roles, or do you need real-time policy evaluation?
ABAC (Attribute-Based Access Control) grants access by evaluating attributes of the subject, resource, and environment at the moment of the request. Here, the scenario describes exactly that: an analyst's shift (environmental), device state (environmental), region assignment (subject/resource), and clearance (subject) all fluctuate without a job change. A well-written ABAC policy handles all four in a single rule — no new permission groups needed when values change. That's why B is correct.
A falls into the combinatorial explosion trap. If you create one RBAC role per valid combination of shift × device × region × clearance, you'd need potentially hundreds of roles. RBAC works well when roles are stable and few; it breaks down when conditions are numerous and dynamic.
C misapplies RBAC by offloading decisions to record owners — that's closer to DAC (Discretionary Access Control). It introduces inconsistency and doesn't systematically enforce the shift or device requirements described.
D describes ABAC in name but defeats its purpose. Permanently assigning permissions after an initial review means the system can't respond to attribute changes — you've essentially built a static assignment model, not a dynamic one.
A useful exam tip: when a scenario lists multiple independent, changing conditions, ABAC is almost always the answer — roles are for stable job functions, not fluctuating contextual states.
- A contractor's access is denied after 6 p.m. and stops entirely once her contract end date passes, with no admin action. What explains this?
Answer: Attributes are evaluated at each access request
Time of day and contract end date are attributes checked on every request, so access changes automatically, which is ABAC. A contractor role is tempting, but role membership persists until someone removes it.
- Which statement best compares the two proposals?
Answer: Both can enforce a form of separation of duties, but they express the restriction through different decision inputs — RBAC through conflicting role assignments and ABAC through attribute comparison
When you see access control questions comparing RBAC and ABAC, your first instinct should be to think about what information each model uses at decision time — not which model is "more powerful." Both are legitimate, mature frameworks capable of enforcing separation of duties (SoD); they simply take different paths to get there.
RBAC enforces SoD structurally: by making Creator and Approver mutually exclusive roles, the system prevents any single user from holding both simultaneously. The restriction lives in the role assignment layer — no attribute lookup required. ABAC enforces SoD dynamically: a policy engine evaluates the requesting user's identity against an attribute on the payment resource (its creator field) and denies access when they match. The restriction lives in the policy logic, resolved at request time. Both approaches achieve the same security outcome, making D correct — they differ in decision inputs, not in capability.
A is wrong because modern ABAC engines absolutely can compare subject attributes (like user ID) against resource attributes (like creator ID) at decision time — that comparison is one of ABAC's defining strengths, not a limitation.
B is wrong because RBAC systems do support mutually exclusive role constraints; this is a foundational concept in Role-Based Access Control, explicitly defined in the RBAC standard (NIST RBAC model, static separation of duty).
C is wrong because assigning a unique transaction-specific role per payment would be an operational nightmare and is not required. Both proposals described are practical, proven mechanisms — no per-transaction role provisioning is needed.
Your study tip: on access control questions, never assume one model is categorically superior. Ask yourself how each model enforces the requirement, and you'll avoid the trap of false exclusivity.
- A firm uses RBAC. It must now deny finance data to Finance role holders whenever they connect from an unmanaged device. What is the best approach?
Answer: Add a device-compliance attribute check to the policy
Device posture changes with each request, so it should be evaluated as an attribute at access time, an ABAC-style condition. A separate role is tempting, but role membership is static and cannot reflect which device the user is on right now.
- How should this authorization mechanism be classified?
Answer: ABAC, because the engine evaluates role-name alongside subject, resource, and device attributes
When you see a question about access control models, ask yourself: what inputs does the policy engine evaluate to make its decision? That distinction separates RBAC from ABAC at a fundamental level.
In this scenario, the engine checks three things: a role-name attribute ("manager"), a subject-to-resource attribute comparison (department equality), and an environmental attribute (managed device). Because the decision depends on evaluating multiple attributes drawn from the subject, resource, and environment simultaneously, this is textbook Attribute-Based Access Control (ABAC). ABAC is defined precisely by its use of arbitrary attribute combinations — role-name is just one attribute among many, not the controlling mechanism. B is correct.
A is wrong because it commits a common trap: assuming that the presence of a role label anywhere in a rule makes the system RBAC. Pure RBAC grants access based solely on role membership — period. The moment department equality and device state also influence the decision, you've left pure RBAC behind.
C is wrong because "department equality" is not equivalent to pre-assigning a department-specific role. RBAC requires roles to be explicitly defined and assigned in advance. Dynamic attribute comparison at evaluation time is an ABAC feature, not RBAC shorthand.
D is wrong because Discretionary Access Control (DAC) means the resource owner personally controls who gets access — think file permissions set by a user. Nothing in this scenario involves owner-delegated permissions; it's a policy engine applying organization-wide rules.
Study tip: In access control questions, always identify what the engine evaluates — role membership alone = RBAC; attributes from subject, resource, or environment = ABAC.
- Which approach best aligns with both the operational pattern and the review requirement?
Answer: RBAC, because stable job functions can map to permission bundles that are straightforward to audit and review
When a question pairs a stable, role-based organizational structure with an audit or reporting requirement, your instinct should immediately jump to Role-Based Access Control (RBAC). The core idea of RBAC is simple: permissions are assigned to roles (like "clerk" or "auditor"), and users inherit those permissions by being assigned to a role. This makes both enforcement and reporting straightforward — to answer "who can do what," you just list roles and their permission bundles.
In this scenario, the accounting firm has fixed job duties that map directly to well-defined permission sets that rarely change. That's a textbook fit for RBAC. Quarterly reviews become easy: management can pull a role-permission matrix and immediately see which employees hold which capabilities. Answer B is correct for exactly these reasons — stable job functions map cleanly to roles, and those roles are inherently auditable.
Answer A is wrong because it mischaracterizes ABAC. While ABAC does evaluate environmental conditions at request time, that's a reason to use it when context matters (e.g., time of day, device posture) — not a reason to use it when permissions are stable and context is irrelevant. C is similarly flawed; decomposing permissions into subject/resource attributes adds unnecessary complexity when simple role bundles already exist. D is a trap that attributes ABAC capabilities to RBAC — native evaluation of device posture and location is an ABAC strength, not RBAC's.
Study tip: On access-control questions, match the complexity of the decision to the model. Stable roles → RBAC. Dynamic, context-sensitive decisions → ABAC. If a wrong answer assigns one model's strengths to the other, it's almost certainly a distractor.
- What should occur on Mateo's next request under this ABAC policy?
Answer: He loses Finance access and can access matching Legal documents while his active status remains true
When you see a question about ABAC (Attribute-Based Access Control), focus on one core principle: access decisions are made dynamically based on current attribute values at the time of the request. Unlike role-based systems where permissions are statically assigned and must be manually revoked, ABAC evaluates policies against live attributes every single time.
In Mateo's case, the policy requires two conditions: department match AND active employment status. After his transfer, his department attribute is immediately "Legal," not "Finance." When he submits his next request, the system pulls his current attributes, evaluates the policy fresh, and finds no match for Finance documents — but does find a match for Legal documents. His active status remains true, so Legal access is granted. This makes C the correct answer.
A is wrong because it describes a role-based access control (RBAC) model, where permissions persist until an administrator explicitly removes them. ABAC doesn't work that way — no manual cleanup is needed because permissions aren't "assigned" in the first place.
B reflects a fundamental misunderstanding: ABAC does not accumulate historical attribute values. Only the current snapshot matters. Prior department values are simply irrelevant once updated.
D is a tempting trap. Yes, an attribute changed — but that doesn't wipe all access. The policy still evaluates remaining valid attributes. Mateo's active status still satisfies part of the policy for Legal documents, so access isn't zeroed out.
A useful study tip: when comparing ABAC to RBAC questions, ask yourself who enforces access revocation. In RBAC, an admin does. In ABAC, the policy engine does it automatically through real-time evaluation.
- Under the stated authorization design, what is the most accurate result when Priya requests to read the file?
Answer: Access is granted because one assigned role provides the read permission and the marking is not evaluated
When a question involves RBAC (Role-Based Access Control), your focus should be on a single guiding principle: access decisions are made by evaluating what permissions a user's assigned roles collectively grant, not by finding reasons to deny. RBAC is permissive by union — if any one of a user's roles grants a permission, the user has it.
Here, Priya holds both the Investigator role (which grants read access to case files) and the Trainee role (which does not). The system only needs one role to authorize the action. The Investigator role provides that authorization, so Priya can read the file. The "restricted" marking is metadata on the resource, but the application has no policy that interprets it and no separate permission tied to it — meaning it is invisible to the authorization engine. C is correct: access is granted because one role supplies the needed permission and the marking goes unevaluated.
A reflects a common misconception — that roles "cancel each other out" or that a denying role overrides a granting one. Pure RBAC doesn't work this way; it takes the union of permissions across all assigned roles. B describes how Attribute-Based Access Control (ABAC) might behave, where resource attributes like "restricted" can directly influence decisions. But the scenario explicitly states RBAC only, with no ABAC-style policy in place. D also smuggles in ABAC logic by suggesting user attributes could match resource attributes — again, a concept outside the stated design.
Your study tip: watch for questions that mix RBAC with resource labels or markings. If the system has no policy interpreting those attributes, they are decorative — RBAC sees only roles and permissions.
- Which implementation most directly supports least privilege with the lowest risk of project-specific role proliferation?
Answer: Use ABAC to compare current project and clearance attributes with repository attributes for each request
When a question involves dynamic, multi-condition access control, ask yourself: does the access model evaluate conditions at the time of the request, or does it rely on pre-assigned static permissions? That distinction is the heart of this question.
The scenario has two moving parts — project membership that rotates weekly and a clearance level — and both must be satisfied simultaneously. Attribute-Based Access Control (ABAC) handles this naturally by evaluating a consultant's current attributes (project ID, clearance) against a repository's attributes at request time. No roles need to be created, maintained, or retired. This is why C is correct: it enforces least privilege dynamically, granting access only when all conditions align right now, and it eliminates the overhead of managing project-specific roles entirely.
A fails least privilege immediately — giving a consultant access to every repository at or below their max clearance ignores project boundaries entirely, effectively granting far more access than the job requires at any moment.
B represents the "role explosion" anti-pattern ABAC was designed to solve. Multiplying roles across every project-sensitivity combination is administratively expensive, and retaining old roles "for auditing" is a particularly dangerous trap — those stale roles can be exploited or accidentally reassigned, increasing attack surface rather than preserving security.
D conflates two separate controls. Clearance and project membership are distinct attributes; encoding project membership implicitly in repository names is opaque, error-prone, and doesn't actually enforce separation — it just obscures the lack of it.
Your study tip: when access decisions depend on multiple dynamic attributes that change independently, ABAC is almost always the right model. Static role systems (RBAC) struggle with combinations.
- A company must ensure no single employee can both create a payment and approve it. Which control best enforces this?
Answer: Make Creator and Approver mutually exclusive roles
Mutually exclusive roles are an RBAC separation-of-duties constraint: no user can hold both Creator and Approver. MFA is tempting, but it only proves identity and does not prevent one person from having both rights.
- Which description most accurately characterizes the hospital's authorization design?
Answer: It combines RBAC permission assignment with ABAC-style contextual conditions on the final decision
When you see an access control question describing multiple layers of checks — a role check followed by contextual conditions — your job is to identify whether those layers belong to different access control models working together, or to just one model.
Here, the hospital uses a two-stage decision. First, it checks whether the clinician holds the Physician role, which is textbook Role-Based Access Control (RBAC): permissions are assigned to roles, and users inherit them through role membership. But holding that role alone isn't sufficient. The system then evaluates runtime context — care-team membership and active emergency declarations — before granting access. Evaluating dynamic, real-world attributes at request time is the hallmark of Attribute-Based Access Control (ABAC). Because both mechanisms actively shape the final decision, D is correct: the design combines RBAC permission assignment with ABAC-style contextual conditions.
A is wrong because it ignores the second layer entirely. The role check is necessary but not sufficient — the contextual conditions are not cosmetic; they can block an otherwise role-permitted request. B commits the opposite error, claiming that any contextual check "eliminates" the role component. In reality, the role check still gatekeeps who can even reach the contextual evaluation; removing RBAC would change the system fundamentally. C is wrong because Discretionary Access Control (DAC) means resource owners control permissions. An emergency declaration doesn't transfer record ownership to the clinician — it modifies a system-level policy condition, which is not DAC.
A useful study rule: hybrid models are extremely common in real systems. When you see a role check plus contextual or attribute-based conditions, resist the urge to label it as purely one model — real authorization designs frequently layer RBAC and ABAC together.
- A rule grants access only if the user's role is Auditor, the file's region matches the user's region, and it is business hours. Which model is this?
Answer: Attribute-based access control
The decision combines a user attribute (role), a resource attribute (region), and an environmental attribute (time), which makes it ABAC. RBAC is tempting because role appears, but RBAC cannot evaluate region matching or time of day.
- Which assessment best addresses the company's assumption?
Answer: The assumption is incomplete because control of authoritative attributes can indirectly control many authorization outcomes, making attribute governance as critical as policy design
When evaluating access control models, you need to think beyond policy design and consider who controls the inputs those policies depend on. ABAC derives all authorization decisions from attributes — so whoever can freely modify those attributes effectively controls access outcomes, regardless of how sophisticated the policies are.
This is exactly what makes A correct. If help-desk staff can change department, employment type, and device-compliance attributes without approval, they can manipulate the very values the ABAC engine reads to make decisions. A policy that says "grant access if department = Finance AND device-compliant = true" is only as strong as the integrity of those attribute values. Unrestricted attribute modification is functionally equivalent to unrestricted privilege assignment — it just looks less obvious. The company's assumption fails because attribute governance is inseparable from policy governance.
B is wrong because it misunderstands the threat. ABAC policies don't constrain attribute administrators — they constrain users. If an administrator sets your department attribute to "Executive," the policy engine will grant you executive access, exactly as designed. The policy is working perfectly; the problem is the corrupted input.
C is wrong because it treats attributes as passive metadata. Attributes are passive in structure but active in effect — changing them directly changes what the policy engine authorizes. Calling them "descriptive data values" doesn't neutralize their power.
D is wrong because it describes a fictional technical requirement. ABAC policies do not need to be compiled into roles before enforcement; that would defeat the purpose of ABAC entirely.
Remember: in access control questions, always trace the full chain — policies, inputs, and who controls each.
- Under role-based access control, how does a newly hired accountant get access to the payroll system?
Answer: She is assigned the Accountant role holding those rights
In RBAC, permissions attach to roles and users gain them by role assignment, so she gets payroll access by being given the Accountant role. Per-request attribute evaluation is tempting but describes ABAC, not RBAC.
