Quiz: Authorization and Access Control

A 27-question self-check covering authentication vs. authorization, the four access-control models (DAC/MAC/RBAC/ABAC), role design, least privilege and privilege creep, the PDP/PEP split, the access control matrix, and segregation of duties. Questions tagged [Sec+] map to a CompTIA Security+ objective and [CISSP] to an (ISC)² CISSP domain. Answers and one-line explanations are at the end — attempt the whole quiz before checking.


Section 1 — Multiple choice (1 pt each)

1. [Sec+] Authorization is best defined as the process of: A. verifying a claimed identity B. determining what a verified identity is permitted to do C. recording what an identity did D. issuing credentials

2. [Sec+] A system has flawless multi-factor authentication but lets every authenticated user reach every database. The most accurate statement is: A. it is secure B. authentication is weak C. authentication is strong but authorization is weak D. it has no accounting

3. [CISSP] In discretionary access control (DAC), access decisions are made by: A. a central system policy B. the resource's owner C. the user's role D. evaluated attributes

4. [CISSP] The model in which a central, system-enforced policy assigns labels to objects and clearances to subjects, and which owners cannot override, is: A. DAC B. RBAC C. MAC D. ABAC

5. [Sec+] Role-based access control scales because permissions are assigned to: A. individuals directly B. roles, and users are assigned to roles C. resources by their owners D. attributes evaluated at runtime

6. The model that decides access by evaluating subject, resource, action, and environment attributes against rules at request time is: A. DAC B. MAC C. RBAC D. ABAC

7. [CISSP] Which condition can pure RBAC not express on its own? A. "tellers may open accounts" B. "managers may approve exceptions" C. "only from a managed device during business hours" D. "wire operators may initiate wires"

8. The proliferation of roles until there are nearly as many (or more) roles than users, mostly held by one or two people, is called: A. least privilege B. role explosion C. role hierarchy D. separation of duties

9. [Sec+] Defining a base role (All_Employees) that other roles inherit, so common access is not repeated, is an example of a: A. toxic combination B. role hierarchy C. policy enforcement point D. capability list

10. [Sec+] The gradual accumulation of access rights as an employee changes roles over time without old access being removed is: A. role mining B. privilege creep C. fail-safe default D. federation

11. [CISSP] Two individually-appropriate permissions that, held together by one identity, enable fraud (e.g., initiate and approve a wire) constitute a: A. role hierarchy B. capability C. toxic combination (SoD conflict) D. reference monitor

12. Which lifecycle event is the single biggest generator of privilege creep? A. joiner (hire) B. mover (internal transfer) C. leaver (termination) D. password reset

13. [CISSP] The component that evaluates a request against policy and returns permit/deny is the: A. policy enforcement point (PEP) B. policy decision point (PDP) C. policy information point (PIP) D. policy administration point (PAP)

14. The component that sits in the request path, intercepts the access, and imposes the verdict is the: A. PDP B. PEP C. PAP D. PIP

15. [CISSP] If the policy decision point is unreachable, a well-designed enforcement point should: A. permit the request (fail open) B. deny the request (fail closed) C. cache the last answer forever D. skip the check

16. [Sec+] The abstract component that is always invoked, tamper-proof, and small enough to verify, mediating every access, is the: A. firewall B. reference monitor C. directory service D. role catalog

17. [CISSP] An access control matrix has subjects on one axis and ____ on the other, with each cell holding the permitted operations: A. roles B. resources/objects C. attributes D. policies

18. Storing the matrix per resource ("who can touch this object") produces: A. capabilities B. access control lists (ACLs) C. roles D. ABAC policies

19. Storing the matrix per subject ("what can this subject touch") produces: A. capabilities B. ACLs C. labels D. a role hierarchy

20. [CISSP] Segregation of duties primarily defends against: A. weak passwords B. fraud and undetected error by requiring two people for a sensitive action C. denial-of-service D. network sniffing

21. [Sec+] A "maker-checker" wire workflow enforces segregation of duties at two layers. The runtime layer specifically prevents: A. weak ciphers B. a person approving a wire they themselves initiated (self-approval) C. role explosion D. phishing


Section 2 — True / False with justification (1 pt each)

For each, mark T or F and give a one-sentence reason.

22. [Sec+] "Deploying strong MFA everywhere means our access control is secure."

23. [CISSP] "Because each individual permission on an account is appropriate for some role, the account's overall access must be appropriate."

24. "Separating roles so that initiate-wire and approve-wire are in different roles is sufficient to guarantee no one can both initiate and approve a wire."

25. [Sec+] "Reviewing access by reading down each resource column is the best way to catch privilege creep on an individual account."


Section 3 — Short answer (2 pts each)

26. [CISSP] In two or three sentences, explain the value of separating the policy decision point from the policy enforcement point when an organization runs many applications. Why is this split the architectural basis of zero trust (Chapter 32)?

27. [Sec+] Meridian's access review finds a long-tenured teller whose account can initiate and approve wires. (a) Name the underlying condition that produced this and the specific class of finding. (b) Give the two remediation actions needed — one static, one runtime — and explain why fixing only one leaves a gap.


Answer Key

Click to reveal answers and explanations 1. **B** — authorization determines what a verified identity may do. 2. **C** — strong authN, weak authZ; the well-authenticated user is over-permitted. 3. **B** — DAC = the owner decides. 4. **C** — MAC = central label/clearance policy owners cannot override. 5. **B** — RBAC assigns permissions to roles, users to roles (the scaling indirection). 6. **D** — ABAC evaluates attributes against rules at request time. 7. **C** — "managed device / business hours" are environmental attributes RBAC alone cannot express; ABAC can. 8. **B** — role explosion. 9. **B** — a role hierarchy (inheritance of common access). 10. **B** — privilege creep. 11. **C** — a toxic combination / segregation-of-duties conflict. 12. **B** — the mover (transfer); access is reliably removed on departure but forgotten on role change. 13. **B** — the PDP decides. 14. **B** — the PEP enforces in the request path. 15. **B** — fail closed (deny), per fail-safe defaults. 16. **B** — the reference monitor. 17. **B** — resources/objects on the other axis. 18. **B** — per-resource storage = ACLs. 19. **A** — per-subject storage = capabilities. 20. **B** — SoD prevents fraud/undetected error by requiring two people. 21. **B** — the runtime layer blocks self-approval (approver ≠ initiator). 22. **F** — MFA is an *authentication* control; it does nothing to ensure the authenticated user is restricted to appropriate access, so over-permissioning and SoD conflicts can coexist with perfect MFA. 23. **F** — toxic combinations are invisible per-permission; the danger lives in the *conjunction* of individually-fine permissions on one identity (e.g., initiate + approve wire). 24. **F** — static role separation prevents the conflicting *combination*, but a person could still come to hold both roles through error, emergency, or creep, so a *runtime* "approver ≠ initiator" check is also required. 25. **F** — reading down columns is the resource-owner view ("who can touch this?"); privilege creep on an account is found by reading *across the account's row* (what one identity can do everywhere). 26. Separating the PDP from the PEP lets one central policy be enforced consistently at many gates: the decision logic lives and changes in one place (the PDP) rather than being copied into — and drifting across — many application codebases, while a thin enforcement point in front of each resource imposes the verdict. It is the basis of zero trust because zero trust requires *every* request to *every* resource to be authorized against current context; that is only feasible with a central policy engine (PDP) and enforcement points (PEPs) at every resource, evaluating context on each request. 27. (a) The condition is *privilege creep* (accumulation across role changes without removal); the finding is a *toxic combination* / *segregation-of-duties conflict*. (b) Static: remove the accumulated/conflicting roles so the account no longer holds both wire permissions (restore role separation). Runtime: add a self-approval-prevention rule at the PDP so no account can approve a wire it initiated, even if it somehow holds both roles. Fixing only the static side leaves the gap that the next creep instance recreates the toxic combination; fixing only the runtime side leaves an over-permissioned account that violates least privilege and can abuse other powers — both are needed. **Topics to review by question:** missed 1–2, 22 → §17.1; 3–7, 12(model) → §17.2; 8–9, 14(roles) → §17.3; 10–12, 25 → §17.4; 13–16, 26 → §17.5; 17–21, 24, 27 → §17.6; 23 → §17.4/§17.6 (toxic combinations).