8.4 Access Control Matrices and Scenario Decisions

Key Concepts

An access control matrix is a grid that visualizes authorization. One axis lists subjects (users, groups, roles, processes, or departments); the other lists objects (applications, files, databases, reports, or administrative functions). Each cell records the permitted actions for that subject-object pair. The matrix is rarely the live technology, but it is an excellent design and review lens.

Two derived structures matter on the exam. Reading one row across the matrix gives a capability list — everything a single subject is allowed to do. Reading one column down the matrix gives an access control list (ACL) — everyone allowed to touch a single object, and how. ACLs are the form most operating systems and cloud services actually store. Knowing that an ACL is "a column of the matrix" and a capability list is "a row" is a frequently tested distinction.

Consider a customer-support system:

The grid surfaces design questions. Does the analyst need full card numbers? No — masked view enforces least privilege and supports PCI-style data minimization. Should the manager approve unlimited refunds? No — cap it. Should anyone who approves refunds also delete audit logs? Never, because that would let a fraudster erase the evidence, collapsing separation of duties and accountability.

Production systems do not keep one giant live spreadsheet. They implement the matrix through groups, roles, policies, ACLs, claims, resource tags, and identity-provider rules. The matrix still earns its keep at review time: during an access recertification, an application owner reads the matrix and confirms each permission still matches current duties, revoking what no longer fits.

Exam Application

Decision tables shine on scenario items because they map conditions to outcomes:

This table blends role (RBAC), amount and device posture (ABAC), and the self-approval block (separation of duties). It also teaches that one favorable condition is not enough: a manager on an unmanaged personal laptop should not approve, and a manager approving a refund they personally requested is denied because request and approval must stay separate.

For any scenario question, run a repeatable six-step method:

1. Subject — employee, contractor, process, service account, or outside partner?
2. Object — file, record, application function, API endpoint, or admin console?
3. Action — read, modify, approve, delete, export, or administer?
4. Justification — why does this subject need this action right now?
5. Risk and constraints — is the data sensitive, the action privileged, the need temporary?
6. Control — choose the option that grants the needed access while minimizing exposure.

Apply it. A vendor must troubleshoot a production application. A poor answer hands over a shared administrator password — no attribution, no expiry, far too broad. A strong answer creates a named vendor account, requires MFA, grants temporary access to only the diagnostic tool, logs the session, and removes access when work ends; any production change routes through a separate employee-approved workflow. That single design stacks least privilege, accountability, time-bounding, and separation of duties — exactly the layered answer CC items reward.

The meta-lesson: matrices and decision tables convert vague access arguments into visible choices, exposing excessive permissions, missing approvals, conflicting duties, and unlogged privileged actions. On the exam they train the habit of matching the control to the scenario rather than reaching for the most technical-sounding distractor.

Reading a Matrix to Spot Toxic Combinations

The real power of a matrix during a review is exposing toxic combinations — pairs of permissions that are individually fine but dangerous together. Three classic pairs the exam likes:

• Approve payments + create vendors. One subject can invent a payee and pay it, defeating separation of duties.
• Modify records + delete audit logs. One subject can change data and erase the evidence, defeating accountability.
• Grant access + use that access. One subject can self-provision privileges and exercise them with no second pair of eyes.

When you scan a matrix row and find any of these pairs in a single subject, the corrective answer is to split the conflicting permissions across roles or require an independent approval step. This is exactly the reasoning an access recertification is meant to drive.

Tie matrices to the lifecycle. A periodic access review (recertification) walks each role's row and asks whether every permission still maps to a current duty. A joiner-mover-leaver process keeps the matrix honest over time: new hires inherit a role, transfers swap roles rather than stacking them, and departures trigger immediate revocation. Without that discipline, a matrix that was correct on day one quietly drifts into over-provisioned rows within months.

Finally, internalize how the six-step method and the models combine. The method tells you to name subject, object, action, justification, risk, and control; the models (DAC, MAC, RBAC, ABAC) and the principles (least privilege, need-to-know, separation of duties, dual control, split knowledge) supply the control you pick in step six.

A strong CC answer almost never selects a single technical gadget — it selects a layered design: a named identity (accountability), the minimum scope (least privilege), an independent approver (separation of duties), and a contextual or label-based guardrail (ABAC or MAC) where the data sensitivity demands it. Practicing on matrices and decision tables builds the reflex to assemble that layered answer quickly under exam time pressure.