Design a tenant-and-role authorization test matrix.

Example Answer

I would cross each of the four authenticated users with both fixture documents and both operations, then add anonymous read and update checks for each document. That gives 16 authenticated checks plus four anonymous checks, or 20 total. The matrix contains six allowed outcomes and 14 denials.

I would keep sessions separate and verify fixture identity before each case. For allowed reads, I would compare the returned content with the expected tenant marker; for allowed updates, I would use a reversible unique value and verify the intended stored document changed. For denials, I would check the specified status, absence of document content, and unchanged stored state using an authorized verification session. A 403 response alone is insufficient if the update still occurred.

I would run these checks against the service boundary because a disabled UI action does not prove authorization. I would also retain a small UI check for the expected controls. All objects and identities are controlled fixtures; there is no need to search for real customer identifiers.

Complete authorization matrix

What the interviewer is assessing

Core checks (1 point each):

• Covers both documents for all four roles and anonymous read/update.
• Produces six allowed and 14 denied outcomes under the supplied contract.
• Checks no data disclosure or update on denial.

Stronger (+1 after all core checks): Enumerates all 20 checks with six allowed outcomes, verifies session identity and stored state independently, and separates service enforcement from UI behavior.

Acceptable alternatives: A matrix or parameterized API suite works; UI hiding is insufficient.

Red flags: Checks only menu visibility, tests real customer records, or treats a denial status as proof that no side effect occurred.

Follow-up

The implementation returns 404 for cross-tenant requests instead of 403. Is that automatically a security failure?

Example response: It differs from the stated API contract, so I would record the mismatch and ask whether the team intentionally wants existence-hiding behavior. A consistent 404 can be a defensible design, but changing the status does not remove the requirement to reveal no content and perform no update. I would align the documented contract and tests after the owner’s decision.

Pressure test

A batch-update endpoint is added. The contract says any forbidden item rejects the whole batch with 403 and changes nothing. What new case matters?

Example response: I would submit one permitted fixture A1 and one forbidden fixture B1 in the same batch as A-editor, then verify 403 and that both documents are unchanged. I would repeat with the item order reversed to detect partial work before a late authorization check. A batch containing only A1 is the positive control. Testing each single-item request separately would not prove atomic authorization for the combined operation.