Per-resource grants break on every new resource while broader grants stay true — how do you decide where your organisation draws that line?
answer
- narrowest is not most durable
- express as a rule, not a list
- prefix or attribute, enforced at creation
- strictness where loss is unrecoverable
- watch for a wildcard reappearing
basics
~20 sDecide by how the grant is expressed and where the consequence is. Grants scoped by a rule the new resource automatically satisfies stay narrow without maintenance; strictness is then spent on the places where a mistake is unrecoverable, and relaxed where it is not.
solid answer
~50 sA standard that requires enumerating every resource by name is a standard that produces wildcards, because the first time it pages someone at night the enumeration gets replaced with `*` and never comes back. So the lead's decision is less "how narrow" than "expressed how": scope by a **rule** that new resources satisfy automatically — a naming prefix, an attribute the resource carries, an ownership marker — so the narrow grant maintains itself. Then spend strictness unevenly: tightest where a mistake is unrecoverable, such as durable customer data and anything that can change what other principals may do; looser in disposable environments where the worst case is rebuilding. Finally, measure the standard by whether it survives contact with delivery, because a rule every team routes around is worse than a softer rule every team keeps.
go deeper
Recall that a grant can name specific resources or match a pattern, and that the pattern keeps working when new resources appear.
Explain why an enumerated grant tends to be replaced by a wildcard over time, and what a prefix or attribute-based scope changes about that.
Show how you would implement rule-shaped scoping in practice, including who controls the attribute or naming convention the grant depends on.
Own the trade-off across teams: where strictness is spent, what the convention costs, and which signal tells you the standard is being routed around.
## The decision is not a slider Asked "how narrow should our grants be", the tempting answer is "as narrow as possible". That answer is what produces wildcards. A grant that must be hand-edited whenever a team adds a resource has a predictable life: it is correct at review, it blocks a release six weeks later, someone widens it under time pressure at an awkward hour, and the wide version is permanent because nothing ever forces it back. The organisation ends up **less** scoped than one that asked for something slightly looser and achievable. So the real decision has three parts: how grants are **expressed**, where strictness is **spent**, and how decay is **detected**. ## Part one: scope by a rule, not by a list | Style | Holds up when a resource is added? | Failure mode | |---|---|---| | Enumerate each resource by name | no — needs an edit every time | quietly replaced with a wildcard under pressure | | Scope by a naming prefix | yes, if names are governed | a badly named resource silently falls outside or inside | | Scope by an attribute the resource carries | yes, if the attribute is applied at creation | an unmarked resource is invisible to the grant | | Wildcard | yes | no scoping at all | The middle two rows are where a maintainable standard lives, and both have a prerequisite that is really the lead's decision: **the convention has to be enforced at creation time**, not audited afterwards. A prefix or an attribute that is optional produces a grant with a silent hole in it, which is a worse outcome than an honest enumeration, because everyone believes the scoping works. This also reframes the cost. Narrow grants are not expensive because narrowing is hard; they are expensive when the scoping mechanism has no relationship to how resources are created. Fix the second and the first becomes cheap. ## Part two: spend strictness where the consequence is Not everything deserves the same rigour, and pretending otherwise is how a standard loses credibility. 1. **Unrecoverable first.** Durable customer data, anything that can alter what other principals may do, anything whose destruction is not undone by a redeploy. Here the strictest available scoping is worth real friction, including grants that need a change request. 2. **Recoverable next.** Compute that can be rebuilt, caches, derived indexes. Rule-shaped scoping, reviewed on a rhythm, no per-change ceremony. 3. **Disposable last.** Isolated experimentation environments, where the worst case is rebuilding the environment. Broad grants are an acceptable, explicit decision here — and saying so out loud is what buys compliance in tier one. The common mistake is spreading effort evenly, which spends the organisation's entire appetite for friction on the environments where a mistake costs nothing. ## Part three: detect decay, because it is guaranteed A standard is not a document, it is a trend. Two signals are usually enough: - **Wildcard reintroduction.** A grant that was rule-scoped and now contains a wildcard on any axis is the single highest-value alert, because it marks the exact moment the standard lost to a deadline. Treat it as a conversation about why, not as a violation. - **Grants that no traffic exercises.** Breadth that nothing uses is the residue of past widenings. Both should be attributed to an owning team and read as a trend, not a score. ## What a lead actually signs up for - **The convention has a cost somebody pays.** Governed names or mandatory attributes at creation are a tax on every team, justified by making narrow grants self-maintaining. Someone has to own and enforce it. - **The standard must be shippable by a team at 4pm on a Friday.** If following it requires a person who is not on call, it will be bypassed. - **Widening must be cheaper to do openly than secretly.** If the open route is slow, the secret route is a wildcard nobody reviews. - **The tiering must be stated.** Teams comply with strictness they understand the reason for; unexplained uniform strictness reads as ritual. The honest summary for an interviewer: the failure mode of least privilege at organisational scale is not grants that are too wide on day one — it is grants that were narrow on day one and were widened, once, by someone who had no cheaper option. The lead's job is to make sure that person always has a cheaper option.
- A team argues that scoping by an attribute is unsafe because someone can add the attribute to a resource that should not be covered. Are they right?They are identifying the real cost of the approach. Rule-shaped scoping moves the security decision to whoever controls the rule's input, so the ability to set that attribute becomes as sensitive as the grant itself. The answer is to control who may apply it and to record changes to it — not to retreat to enumeration, which fails in a more damaging way by inviting a wildcard.
- Which signal would you watch to know the standard is losing?A wildcard reappearing on a grant that was previously rule-scoped. It marks the moment a team had no cheaper option than widening, and it is far more informative than the absolute count of wide grants. Handled as a question about what blocked them, it usually points at a missing convention or a review path too slow to use under deadline.
- Is it defensible to allow broad grants in an isolated experimentation environment?Yes, if it is an explicit decision rather than neglect: the environment holds no customer data, its worst case is being rebuilt, and it is isolated so that access there reaches nothing else. Stating that exemption openly is also what makes the strict tier credible — a standard that demands identical rigour everywhere spends its whole budget where a mistake is cheap.
saying these in an interview costs you the question
- Answers only as narrow as possible, with no account of who maintains it
- Enumerates resources by name and calls the result a durable standard
- Applies identical strictness to customer data and to a disposable sandbox
- Treats a reintroduced wildcard as a violation to punish rather than a signal to read
- Adopts attribute-based scoping without controlling who may set the attribute