The access rules say which identities may read a shared warehouse credential — why is that not the list you rotate against?
answer
- permission is not use
- two lists, not one
- grants overstate and understate
- one identity can front many holders
- rotate against holders, not rights
basics
~20 sA grant list names who may read the value; rotation needs who actually holds it. Permissions overstate it with idle standing grants and understate it with copies taken once, fleets behind one identity, and holders that never call the store.
solid answer
~50 sTwo different lists get confused here. The **permission list** answers "who would the store serve if they asked". The **consumer list** answers "what is currently holding this value and presenting it to the system that accepts it" — and that is the list a replacement is sequenced against. Permissions overstate it, because a standing grant survives the service that needed it and a group grant can sit in front of many things or none. They also understate it, because a value read once and kept in a process, pasted into a team's own configuration, or handed to a supplier never shows up as a grant at all. So a useful entry names the holder, where it reads the value from, who owns it, and whether it can take a new value without restarting. Removing a grant stops future reads from the store; it does not withdraw a copy already taken.
code
json · 31 lines{
"credential": "warehouse-read-only",
"owner": "reporting-platform-team",
"downstreamSupportsManyAccounts": false,
"consumers": [
{
"consumerId": "nightly-aggregation",
"readsFrom": "store",
"identity": "job-aggregation",
"lastReadAt": "2026-09-14T02:04:11Z",
"takesNewValueWithoutRestart": true,
"owner": "reporting-platform-team"
},
{
"consumerId": "quarterly-finance-extract",
"readsFrom": "store",
"identity": "job-extract",
"lastReadAt": "2026-07-01T23:12:40Z",
"takesNewValueWithoutRestart": false,
"owner": "finance-data-team"
},
{
"consumerId": "analyst-desktop-tooling",
"readsFrom": "ownConfiguration",
"identity": null,
"lastReadAt": null,
"takesNewValueWithoutRestart": false,
"owner": "analytics-guild"
}
]
}go deeper
Remember the distinction itself: a permission says who is allowed to ask for a value, while a consumer is something that already holds it and uses it.
Be able to explain both directions of error — idle grants that inflate the list, and copies, fleets and intermediaries that never appear on it — and name the fields an entry needs to be actionable.
Show how you would build the list from evidence rather than memory, decide which entries block withdrawal, and say plainly that removing a grant is not withdrawal.
Frame it as a property to buy at issuance: decide what your estate requires of a new credential so that its holders are observable by default, and what you accept where they cannot be.
## Two lists that look like one A credential held in a store has a **permission list**: the identities the store will answer if they ask for this value. Somewhere else — usually nowhere — there is a **consumer list**: the running things that hold the value and present it to the system that accepts it. A replacement is a change planned against the second list. The first describes the door; the second describes who already walked through carrying a copy. The distinction is not pedantic, because the two lists disagree in both directions, and each disagreement costs something different on the day of the change. ## Why permissions overstate the consumers - A **standing grant outlives the thing that needed it**. The service was decommissioned; nobody removed its right to read. It appears on your list and there is nothing to move. - A grant is often held by a **group or a role** rather than by one workload, so one line can front thirty machines, or zero. - Some grants exist for a **human path** — an on-call route, an investigation route — that has never been exercised. They are permissions, not consumers. - A grant can be a **duplicate**: two identities for the same workload, one of which was replaced during a migration nobody finished. Planning against an overstated list is merely wasteful: you chase owners of things that do not read. Planning against an understated list is what breaks production. ## Why permissions understate the consumers - **A copy taken once is still a holder.** A process that read the value at start-up nine months ago holds it now and has no reason to read again until it restarts. - **A copy outside the store has no grant at all.** A value pasted into a team's own configuration, or written into a downstream system's own settings by a person, reads nothing and appears nowhere. - **A fleet behind one identity is one grant and many holders.** The grant count tells you nothing about how many processes must move. - **An intermediary hides its callers.** Where one component reads the value and hands it to others, the grant names the fetcher, not the things that end up holding it. ## What the two lists answer | Question on replacement day | The grant list | The consumer list | |---|---|---| | Who may ask the store for this value? | answers it exactly | does not answer it | | What is holding the value right now? | guesses, in both directions | answers it, within its blind spots | | Who do I negotiate the change window with? | names identities, not owners | names an owner per holder | | Can this holder take a new value without a restart? | silent | records it | | After withdrawal, who broke? | cannot attribute | narrows it to one entry | ## What an entry has to carry 1. **The holder** — the concrete thing that runs, not the role it authenticates as. 2. **Where it reads the value from** — the store, or its own configuration. This one field decides whether writing a new value into the store reaches it at all. 3. **The last time it was observed reading**, so you know how fresh the evidence is. 4. **The owner** — the person or team who can actually schedule its change. 5. **Whether it takes a new value without a restart**, because that sets how long the move takes and whether it can be done inside a change window. ## The trap that catches people Two instincts feel equivalent and are not. **Removing a grant is not withdrawal.** Taking an identity's read right away stops it fetching the value in future; it does nothing to the copy it already holds, and the system that accepts the credential goes on accepting it. Likewise **rotation is not revocation**: writing a new value puts a new credential in place, while stopping the old one working is a separate action against the downstream system. A change that did the first and forgot the second leaves the old value live, in the hands of whoever was not on either list. The second trap is treating an unused grant as proof of no consumer. It is proof that this identity has not read recently, and nothing more. The holder you are looking for may be the one that stopped reading precisely because it already has what it needs. ## Why an interviewer asks it Answering this well shows that the candidate has planned a change rather than executed a ticket. The weak answer exports the store's permission list and calls it done; the strong one says out loud that permissions are a right and consumers are holders, names the two directions of error, and describes the list it would build instead — knowing that the list will still be incomplete, which is why the change is sequenced rather than flipped.
- An identity holds read rights but no record shows it reading in a year — can you drop it from the plan?You can drop it from the list of parties to coordinate with, but not from the risk. Absence of reads means it has not fetched recently, which is also exactly what a holder that read once and kept the value looks like. Treat it as unresolved until an owner confirms the thing is gone, and expect withdrawal — not the grant removal — to be what finally tests it.
- If you remove an identity's read permission, what has actually changed for the credential?Only future fetches from the store. The copy that identity already holds keeps authenticating, because the system that accepts the credential never consults the store's rules. Ending the old value's usefulness is a separate action against that downstream system, and it is the one that produces the breakage you should be sequencing for.
- Where does the owner field come from, given nobody could name the consumers to begin with?It is derived, not remembered: start from observed reads, attribute each identity to the team that deploys the thing running as it, and record the answer as you get it. The register is worth having only because it is re-derived from evidence each time; a document maintained by hand goes stale between replacements.
A building's access badge list tells you who may enter; it does not tell you who is already inside holding a key they cut years ago.
saying these in an interview costs you the question
- Exports the store's permission list and calls it the consumer list
- Assumes every granted identity is exactly one running consumer
- Thinks removing a grant withdraws copies already taken
- Treats an unused standing grant as proof nothing holds the value
- Counts a fleet behind one shared identity as one holder