Four access control models show up on the SY0-701 exam, and they blur together fast. DAC, MAC, RBAC, and ABAC. On paper they look like a list to memorize. In the exam they arrive as a scenario, and the scenario decides the answer. If you learned them as definitions, the question will still get you, because CompTIA rarely uses the model's name in the stem. It describes how access gets decided and waits for you to match that to a model.
Here is the way I finally got them to stick.
Discretionary Access Control (DAC)
The owner of the resource decides who gets in. That is all it means. If you create a file and you can share it, change its permissions, or hand access to a coworker, you are the discretion in discretionary. Windows NTFS permissions are the classic example. The file owner opens properties and adds a user.
The exam tells on DAC with words like "the owner grants access" or "the user who created the file sets permissions." The moment access lives with whoever owns the object, it is DAC. The tradeoff, and the exam likes this angle, is that DAC is flexible but easy to get wrong, because a careless owner can overshare.
Mandatory Access Control (MAC)
Now the owner has no say. Access is decided by labels and clearances that a central authority sets. Think classified documents. A file is labeled Secret. You get in only if your clearance is Secret or higher and you have a need to know. You cannot share it because you feel like it, and neither can the person who made it.
MAC scenarios almost always mention classification, labels, clearance levels, or a government or military setting. If the question says a system enforces access based on sensitivity labels and no user can override it, that is MAC. It is the most rigid model, which is exactly why sensitive environments use it.
Role-Based Access Control (RBAC)
Access follows the job, not the person. You define a role, attach permissions to that role, then assign people to roles. A new nurse joins and inherits the nurse role. When they transfer, you swap the role instead of hand editing dozens of permissions.
This is the one most companies actually run, so the scenarios read like a normal workplace. Watch for phrases like "based on their job function" or "members of the accounting group." If access is tied to a title or a group rather than to the individual or a label, lean RBAC.
Attribute-Based Access Control (ABAC)
This is the flexible one, and it is where people lose points because they read one attribute and stop. ABAC decides access using several attributes at once. User attributes, resource attributes, and often context like time of day, device, or location. Allow access if the user is in finance, and the request comes from a managed device, and it is during business hours.
The tell is a rule with multiple conditions stacked together, especially anything about context. If the scenario mentions device posture, location, or time as part of the decision, ABAC is almost certainly the answer, not RBAC. RBAC checks the role. ABAC checks the role and three other things.
The trap CompTIA sets
The exam loves to describe RBAC and dare you to pick DAC, or describe MAC in plain language so you miss the classification cue. The fix is not more definitions. It is one question you ask every stem: who or what decides access here?
Owner decides, DAC. Central labels and clearance decide, MAC. Your job decides, RBAC. A combination of attributes and context decides, ABAC.
Read the stem for that single fact and the four stop blurring.
How to drill this
Definitions do not survive the exam. Scenarios do. Work through a batch of questions where the model name never appears in the stem, then force yourself to name the decider before you look at the options. That habit is worth more than rereading the chapter.
If you want scenario style questions to practice on, that is the idea behind SecPlus Mastery. There is a free diagnostic at secplusmastery.com/diagnostic that shows you fast whether access control is actually solid or just feels solid, which for most people are two different things.
Get the decider right and these four models turn into some of the easiest points in the domain.
Top comments (1)
Great breakdown. Access control models are one of those areas where teams often mix concepts because the boundaries are not always obvious.
A practical way I’ve seen this handled in production is:
RBAC works well for stable organizational structures (roles like admin, manager, developer)
ABAC becomes valuable when decisions depend on context (user attributes, resource state, location, time, risk level)
DAC is useful for user-controlled sharing scenarios but can become difficult to govern at scale
MAC fits environments where strict policies and classification levels are required
The common mistake is choosing a model based on popularity instead of the actual authorization problem.
Modern systems often end up using a hybrid approach:
RBAC for baseline permissions
ABAC/policy engines for dynamic decisions
Audit logs for visibility and compliance
Especially with AI agents becoming more common, authorization is becoming even more important. An AI system that can call tools, access data, or execute workflows needs fine-grained permission boundaries — not just a simple user role check.
Great reminder that access control is not only a security feature; it is part of system architecture.