skip to content

A second approver, a ticket reference and a quorum are three ways to gate a credential read — what does each actually control?

level: seniorimportance: should knowfreq 44%

answer

  1. judgment, evidence, no single person
  2. a reference decides nothing by itself
  3. approver neither requester nor chosen by them
  4. quorum multiplies the wait
  5. approving a request that states nothing

basics

~20 s

A second approver buys judgment, a reference to an existing work item buys evidence, and a quorum removes the assumption that any single approver is honest and awake. They are not substitutes, and each fails differently.

solid answer

~50 s

A second approver is the only one that can refuse a request that is well formed but wrong — a scope far wider than the work needs, a duration of a week for a twenty-minute investigation, a requester whose team has no business with that material. It holds only while the approver is neither the requester nor chosen by them. A work-item reference supplies no judgment at all; it supplies evidence that exists outside the requester's sentence, it can be checked automatically at request time, and it is what makes the read explainable a year later. It is defeated the moment a requester can open the work item themselves. A quorum drops the assumption that one approver is enough, at the cost of a longer wait and one more way to stall. Most estates want the reference on everything and the human judgment on the reads that warrant it.

code

yaml · 21 lines
yaml
request:
  requestedBy: person/e-harlow
  ticketRef: support-48213
  scope: customer-records/decryption-credential
  rights: [read]
  reason: reproduce reported decryption fault for one account
  durationRequested: 90m

approval:
  approverPool: support-leads
  requiredApprovers: 2
  approverMustDifferFromRequester: true
  approverChosenByRequester: false
  approvedBy:
    - person/n-okafor
    - person/d-vance
  durationApproved: 45m

grant:
  grantedAt: 2026-09-19T13:20:00Z
  expiresAt: 2026-09-19T14:05:00Z

go deeper

for a junior

Recall that the three are different: one person judging, a link to real work, or several people having to agree. They are stacked, not chosen from a menu.

for a middle

Explain what each one can and cannot refuse, and list what a request has to state — requester, scope, rights, reason and duration — before any of them is more than a signature.

for a senior

Show the failure modes you would design against: the self-created work item, the hand-picked approver, the shared role identity, and a quorum drawn from one team.

for a principal

Decide where each gate is worth its response time across an estate, and defend reserving the quorum for the values whose misuse would be unrecoverable.

## Three gates, three different purchases All three sit between *I need to read this credential* and the read itself, and teams routinely install one while describing the benefit of another. A second approver buys **judgment**. A reference to a piece of work buys **evidence**. A quorum buys **the removal of any single trusted individual**. ## A second approver: judgment at the moment Someone who is not the requester looks at the request and decides. What that catches is the request that is wrong on its face: - a scope far wider than the described work needs; - a requester whose team has no business with that material; - a duration of a week for a twenty-minute investigation; - a third request this shift from somebody who made none last month. This is the only one of the three that can refuse something technically well formed. Its strength rests on two conditions that are easy to lose. The approver must not be the requester — including through a second account, a shared role, or a service identity both people can drive. And the approver must not be **chosen by** the requester, or the gate degrades into a search for the most agreeable colleague; the pool is named in advance and the request is routed into it. ## A work-item reference: evidence, checkable now and later Pointing the request at work that exists independently of the requester's sentence is what makes the record reviewable long after everyone has forgotten the incident. It also supports checks nobody has to make by hand: does the referenced item exist, is it open, is the requester the person assigned to it, does the customer or system named in it match the scope being asked for. A reference supplies no judgment whatsoever. It is defeated the moment a requester can open a work item themselves for the purpose. What it buys is that the read stops being a bare event: when an external audit asks who could have read this value last Tuesday and why, the answer is a join rather than an investigation. ## A quorum: nobody is sufficient alone Requiring several of a named pool to agree drops the assumption that any single approver is honest, awake and paying attention. For the highest-value material the pool is deliberately drawn from different teams or reporting lines, so that collusion has to cross a boundary somebody would notice. The cost is not linear: each additional required approver multiplies the wait and adds another way for the request to stall at the hour it is most likely to be needed. ## What the request must carry for any of this to mean anything 1. **Who is asking** — a named human identity, never a shared role. 2. **What scope** — the narrowest set of names that completes the work, not the whole branch the requester happens to be eligible for. 3. **Which rights** — reading a value and being able to list what exists are different asks and should be separately granted. 4. **Why** — a sentence plus the reference to the work. 5. **For how long** — a duration the approver is expected to shorten, with the shorter of requested and approved winning. An approval on a request that does not say what is being approved is a signature on a blank page, and it is the most common way this control gets installed without being implemented. ## Choosing between them | gate | what it controls | what defeats it | what it costs | |---|---|---|---| | work-item reference | attaches the read to independent evidence | a requester who can create the item | almost nothing; it is checkable automatically | | second approver | whether this request is proportionate | an approver the requester picks, or their own second account | one person's response time | | quorum | reliance on any single person's judgment | a pool drawn from people who all answer to the requester | response time multiplied, and more stalls | The usual arrangement is the reference on every request because it is cheap, the human judgment on the reads whose blast radius justifies a person's response time, and the quorum reserved for the small set of values whose misuse would be unrecoverable. ## The direction to keep straight Approval governs whether the read happens. It says nothing about the value afterwards, it does not shorten the validity of anything the read produced, and it is not an emergency route: a design where the approvers may themselves be the unreachable people needs a separate mechanism with its own alarm. Keep those apart in the answer and the interviewer can tell you have operated one of these rather than read about it.

  • The approver narrowed the requested ninety minutes to forty-five. Why is that more valuable than a refusal?
    Refusals are rare because most requests are legitimate. Narrowing is the everyday form of judgment: it halves the window at no cost to the work, and it is visible proof that someone read the request. A gate whose approvers never shorten anything is a gate nobody is reading.
  • Why does the pool for a quorum get drawn from different teams for the most valuable material?
    So that agreement has to cross a boundary. A quorum of three people who sit together, report to the same lead and cover for each other is one judgment wearing three names. Spreading the pool also keeps it non-empty across time zones, which is the availability half of the same choice.
  • Can the work-item check be automated, and what does that leave for the human?
    Yes: existence, open state, assignee matching the requester, and the named subject matching the requested scope are all mechanical. That leaves the human the judgment a machine cannot supply — whether this scope is proportionate to this work, and whether this pattern of requests is normal for this person.

saying these in an interview costs you the question

  • Treats a ticket reference as a substitute for someone exercising judgment
  • Lets the requester pick which colleague reviews their own request
  • Says a quorum speeds approvals up by offering more reviewers
  • Approves requests that never state scope, rights or duration
  • Counts an approver who shares a role identity with the requester as a second person