Access control PBQs test your ability to configure user permissions, implement role-based access control (RBAC), and apply the principle of least privilege. This guide teaches you how to build permission matrices that meet security requirements.
Interactive simulation — no account required
Access control PBQs present you with a scenario describing job roles, data sensitivity levels, and security requirements, then ask you to configure who can access what. You'll typically work with a matrix or permission interface where you assign access rights based on roles or individual users.
These questions test whether you can translate security policies into practical access configurations. You might be asked to:
Every access control question centers on one principle: users should have the minimum permissions necessary to perform their job—nothing more. If someone doesn't need access, they shouldn't have it. Excessive permissions are always the wrong answer.
Approach permission configuration systematically:
The exam tests different access control models. Know how each works:
Permissions assigned to roles, users assigned to roles. Most common in enterprises.
User → Role (HR Manager) → Permissions (Read employee records)Resource owners control access. The owner decides who can access their files.
File owner grants read access to specific usersSystem-enforced based on security labels. Used in government/military.
TOP SECRET file can only be read by TOP SECRET cleared usersAccess based on attributes: user department, time of day, location, device type.
IF department=Finance AND time=BusinessHours THEN allowA company has three departments and needs access configured for their shared file server. Configure the permission matrix to meet all business requirements while following least privilege:
| Role | /HR/ | /Finance/ | /Development/ |
|---|---|---|---|
H HR Staff | Read/Write | No Access | No Access |
F Finance Staff | Read | Read/Write | No Access |
D Developers | No Access | No Access | Read/Write |
A Auditors | Read | Read | Read |
I IT Admin | Modify ACL | Modify ACL | Modify ACL |
HR Staff: Read/Write to /HR/ for managing employee records. No access to Finance or Development—they have no business need for this data.
Finance Staff: Read/Write to /Finance/ for financial operations. Read-only to /HR/ because payroll requires viewing (not modifying) employee salary data. No access to Development.
Developers: Read/Write to /Development/ for code management. No access to HR or Finance—sensitive business data is completely isolated from engineering.
Auditors: Read-only across all folders. This allows compliance review without any risk of data modification. Auditors can verify but cannot change.
IT Admin: "Modify ACL" permission only—can change who has access, but cannot read file contents. This is separation of duties: admins manage access but can't exploit it to view sensitive data.
Key insight: Finance getting Read (not Read/Write) access to HR demonstrates least privilege—they need to view salary info for payroll but have no business reason to modify employee records.
Build RBAC matrices and configure permissions in interactive scenarios.
Understand the standard permission levels you'll see in PBQs:
No Access — Cannot see or interact with the resource at all. This is the default for least privilege.
Read — Can view contents but not modify. Appropriate for reference data or audit access.
Read/Write — Can view and modify contents. Standard access for data owners.
Read/Write/Delete — Can view, modify, and remove. Usually restricted to data managers.
Full Control — All permissions including the ability to change permissions. Reserved for administrators.
When configuring access, always start from "No Access" and add only what's required. Never grant Full Control unless the role specifically needs to manage permissions.
These role separations frequently appear in PBQs:
Watch for these errors that violate security principles:
Group membership creep — User accumulates permissions from multiple role changes. Former HR employee now in IT still has HR access.
Excessive inherited permissions — Adding user to "Domain Admins" when they only needed one specific permission.
Shared accounts — Multiple users sharing one login. Destroys accountability and audit trails.
No access reviews — Permissions granted years ago never reviewed. Former contractors still have access.
Emergency access not revoked — Temporary elevated access for incident response never removed.
All users in same group — Flat permission structure where everyone has the same access. No segmentation.
An access control PBQ presents you with job roles and security requirements, then asks you to configure who can access what resources. You might build an RBAC matrix, identify over-permissioned accounts, or troubleshoot permission issues. The focus is on applying least privilege and separation of duties.
Least privilege means giving users the minimum permissions necessary to perform their job—nothing more. A payroll clerk needs access to salary data but not engineering systems. By limiting access, you reduce the damage from compromised accounts and insider threats.
Separation of duties divides critical tasks between multiple people so no single person can complete a sensitive action alone. For example, one person requests a payment and a different person approves it. This prevents fraud and catches errors.
RBAC (Role-Based Access Control) assigns permissions to roles, then assigns users to roles. A user's access is determined by their role membership. ABAC (Attribute-Based Access Control) makes access decisions based on attributes like department, time, location, or device—offering more granular, context-aware control.
Apply these concepts with an interactive Access Control simulation.