Cyber Security Quiz: Rbac Vs Abac
10 questions · exam conditions
0:00
Rbac Vs AbacQuestion 1 of 10

A document service uses the policy: permit reading when the user's department matches the document's department and the user's employment status is active. Mateo transfers from Finance to Legal. The identity source updates his department immediately, and the service retrieves current attributes for every request.

What should occur on Mateo's next request under this ABAC policy?

He retains Finance access until an administrator removes his Finance role from the document service
He receives both Finance and Legal access because prior attribute values remain cumulative after a transfer
He loses Finance access and can access matching Legal documents while his active status remains true
He loses all access because ABAC requires permissions to be reassigned whenever an attribute changes
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Rbac Vs Abac

Practice Rbac Vs Abac in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Rbac Vs Abac, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A document service uses the policy: permit reading when the user's department matches the document's department and the user's employment status is active. Mateo transfers from Finance to Legal. The identity source updates his department immediately, and the service retrieves current attributes for every request.

What should occur on Mateo's next request under this ABAC policy?

  1. He retains Finance access until an administrator removes his Finance role from the document service
  2. He receives both Finance and Legal access because prior attribute values remain cumulative after a transfer
  3. He loses Finance access and can access matching Legal documents while his active status remains true (correct answer)
  4. He loses all access because ABAC requires permissions to be reassigned whenever an attribute changes
Explanation: 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.

Question 2

A hospital first checks whether a clinician has the Physician role, which grants permission to view patient records. It then denies the request unless the clinician is assigned to the patient's care team or an active emergency declaration exists. Care-team membership and emergency status are evaluated at request time.

Which description most accurately characterizes the hospital's authorization design?

  1. It is purely RBAC because the Physician role grants the initial permission to view records
  2. It is purely ABAC because any contextual check eliminates the role-based portion of the decision
  3. It is discretionary access control because emergency declarations transfer ownership of patient records
  4. It combines RBAC permission assignment with ABAC-style contextual conditions on the final decision (correct answer)
Explanation: 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.

Question 3

A company replaces department roles with ABAC policies that rely on department, employment type, and device-compliance attributes. The policies are correct, but help-desk staff can modify all three attributes without approval. The company assumes least privilege is therefore stronger because ABAC is more granular than ABAC.

Which assessment best addresses the company's assumption?

  1. The assumption is incomplete because control of authoritative attributes can indirectly control many authorization outcomes, making attribute governance as critical as policy design (correct answer)
  2. The assumption is valid because granular ABAC rules constrain what attribute administrators can do, preventing them from expanding a user's access beyond policy boundaries
  3. The assumption is valid because attributes are descriptive data values tied to identity records and cannot themselves function as directly assignable privileges
  4. The assumption is incomplete because ABAC policies must always be compiled into role definitions before the policy engine can enforce access decisions at runtime
Explanation: 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.

Question 4

An application uses only RBAC. The Investigator role has permission to read case files, while the Trainee role does not. Priya is assigned both roles. A case file is marked "restricted," but the application has no policy that interprets that marking and no separate permission for restricted files.

Under the stated authorization design, what is the most accurate result when Priya requests to read the file?

  1. Access is denied because any assigned role lacking the read permission overrides a role that grants it
  2. Access is denied because a resource attribute automatically takes precedence over role permissions
  3. Access is granted because one assigned role provides the read permission and the marking is not evaluated (correct answer)
  4. Access is granted only if Priya's user attributes independently match the file's restricted marking
Explanation: 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.

Question 5

An authorization rule permits an action when the requester has role-name "manager," the requester's department equals the resource's department, and the request originates from a managed device. The rule engine evaluates all three values for every request.

How should this authorization mechanism be classified?

  1. Pure RBAC, because mentioning a role anywhere in a rule makes the entire decision role-based
  2. ABAC, because the engine evaluates role-name alongside subject, resource, and device attributes (correct answer)
  3. Pure RBAC, because department equality is equivalent to assigning a department-specific manager role
  4. Discretionary access control, because the resource's department determines who may approve access
Explanation: 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.

Question 6

A security operations center grants analysts access to incident records. Access depends on the analyst's current shift, whether the analyst is using a managed device, the record's assigned region, and whether the analyst's clearance equals or exceeds the record's classification. These values may change without the analyst changing jobs.

Which access-control design most directly implements the requirements while minimizing the need to create new permission groupings?

  1. RBAC, with a separate role for every permitted combination of shift, device state, region, and clearance
  2. ABAC, with policy rules evaluating subject, resource, and environmental attributes at the time of access (correct answer)
  3. RBAC, with one analyst role and discretionary approval by each record's current owner
  4. ABAC, with permissions permanently assigned to each analyst after the analyst's initial attribute review
Explanation: 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.

Question 7

A consulting company assigns employees to changing client projects. A consultant may open a repository only when the consultant's current project identifier matches the repository's project identifier and the consultant's clearance meets the repository's sensitivity level. Project membership changes weekly.

Which implementation most directly supports least privilege with the lowest risk of project-specific role proliferation?

  1. Create one consultant role that grants access to every repository at or below the consultant's maximum clearance
  2. Create a separate consultant role for every project and sensitivity combination, then retain old roles for auditing
  3. Use ABAC to compare current project and clearance attributes with repository attributes for each request (correct answer)
  4. Use RBAC to assign a permanent clearance role and let repository names imply current project membership
Explanation: 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.

Question 8

A company uses roles named Sales-East, Sales-West, Support-East, and Support-West. It plans to add five product lines and three customer-sensitivity levels. Administrators propose creating a distinct role for every valid combination of job function, region, product line, and sensitivity level.

Which analysis best identifies the access-control issue and the most appropriate conceptual response?

  1. The design creates role explosion; ABAC could evaluate the independent characteristics without representing every combination as a role (correct answer)
  2. The design creates attribute staleness; RBAC could evaluate each characteristic dynamically whenever a resource is requested
  3. The design violates role hierarchy; ABAC would require every senior role to inherit all junior-role attributes
  4. The design violates least privilege; RBAC requires each user to receive exactly one role across the organization
Explanation: 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.

Question 9

A finance organization must prevent the same employee from both creating and approving a payment. One architect proposes mutually exclusive Creator and Approver roles. Another proposes an attribute policy that denies approval when the requester is the payment's creator.

Which statement best compares the two proposals?

  1. Only the RBAC proposal can enforce separation of duties because ABAC policies lack the ability to compare requester identity against resource-level creator attributes at decision time
  2. Only the ABAC proposal can enforce separation of duties because RBAC systems have no mechanism to define conflicting or mutually exclusive role assignments for a single user
  3. Neither can enforce separation of duties unless every payment transaction is assigned its own unique transaction-specific role that identifies the creator at provisioning time
  4. 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 (correct answer)
Explanation: 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.

Question 10

A small accounting firm has stable job duties: clerk, reviewer, manager, and auditor. Each duty maps to a well-defined permission bundle that rarely changes. During quarterly reviews, management wants a concise report showing which employees can perform each business function.

Which approach best aligns with both the operational pattern and the review requirement?

  1. ABAC, because environmental conditions must still be evaluated at request time even when job-function permissions are stable
  2. RBAC, because stable job functions can map to permission bundles that are straightforward to audit and review (correct answer)
  3. ABAC, because stable permission bundles must be decomposed into subject and resource classification attributes before enforcement
  4. RBAC, because it natively evaluates contextual conditions such as device posture and location without additional policy rules
Explanation: 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.