skip to content

A team marks all twenty entries of a settings file as secrets, hostnames and page sizes included - what does that cost?

level: seniorimportance: nice to knowfreq 26%

answer

  1. classification selects the handling
  2. everything critical means nothing is
  3. reviewers stop reading the queue
  4. friction makes a more convenient copy
  5. keep a private-configuration class

basics

~20 s

Every entry inherits credential handling, so a page size earns an approval and a hostname earns a replacement runbook. Attention drains from the entries that genuinely grant authority, and the friction pushes people into keeping easier copies outside the process.

solid answer

~50 s

Classification decides handling, so marking everything a secret applies the expensive path to twenty entries that mostly do not need it: held in the store, fetched at start-up, an approval to change, a replacement runbook, a review queue entry. Three costs follow. Reviewers stop reading, because most of what crosses the queue is a timeout change - so the one credential change that mattered is approved with the rest. Engineers route around the friction and keep a more convenient copy somewhere the process does not reach. And the inventory loses its power to answer 'what do we hold that grants authority', because the answer becomes everything. The fix is not to classify less, it is to classify by the test and keep a lighter class - private configuration - for values that are not published but confer nothing.

go deeper

for a junior

Understand that calling something a secret is not free: it decides the handling the entry gets from then on, and handling costs time every time the value changes.

for a middle

Explain the mechanism by which excess degrades a working control - a review queue full of trivia trains reviewers to approve without reading - rather than just calling it overhead.

for a senior

Name the observable symptoms you would look for, and propose the middle class so the team is not choosing between strictness and volume.

for a principal

Own the default: what class a new entry starts in, who settles a disputed one, and how you keep the strict path cheap enough that teams do not build a shadow path around it.

## Why over-classifying is a real defect and not just excess caution Marking everything a secret feels free. It is not, because **classification is what selects the handling**, and credential handling is expensive by design: the value lives in a store instead of the artifact, a process fetches it rather than reading it locally, changing it needs an approval, exposing it needs a replacement runbook, and reading it may be recorded and reviewed. Applied to a database password, all of that is proportionate. Applied to a page size of 50, every item on the list is pure cost with no risk removed - because no risk was there. ## The three costs, in the order they show up 1. **Attention drains from the entries that matter.** A review queue whose contents are mostly timeout adjustments trains its reviewers to approve without reading. The credential change that genuinely needed a second pair of eyes arrives in the same queue and gets the same glance. The control still exists on paper and has stopped working in practice. 2. **Friction produces copies.** When changing a tuning value requires an approval and a store round-trip, people find the shorter route: a local override, a convenient copy, a value pasted where it is easier to reach. The process now reaches fewer values than it did before it was tightened. 3. **The inventory stops discriminating.** The single most valuable question a classification exercise answers is 'what do we hold that grants authority to a caller?' If the answer is 'all twenty entries', the inventory has the same information content as the settings file and cannot be used to prioritise anything. There is a fourth, less visible: **effort spent on the obvious entries is effort not spent finding the hidden ones.** A review that carefully files twenty entries into one bucket has, by construction, not looked hard at the callback link whose query value is the whole permission. ## The honest counterweight The failure in the other direction is worse per incident - a missed credential riding inside an artifact is how disclosures happen - so the conclusion is emphatically **not** 'classify less'. It is 'classify by the test, and give the arguable middle a home of its own': | class | what it means | handling it triggers | |---|---|---| | secret | disclosure transfers rights we hold | store, fetch, approval to change, replacement runbook | | private configuration | not published, but grants nothing | normal change control, no runbook, no read approval | | public configuration | grants nothing and may be published | ordinary change, no restriction | Most of the entries people over-classify are private configuration: internal hostnames, queue names, endpoint paths, the names of things. They are genuinely not for publication, and they are genuinely not credentials. Giving them a class of their own is what lets a team be strict about the first row without dragging the whole file into it. ## How to tell whether it has started hurting The symptoms are observable rather than a matter of opinion: - Replacement runbooks that have never been run, for entries nobody could replace because nothing would change. - Approvals granted in seconds, in volume, by the same person. - Entries in the store whose value has never changed since the day they were put there, sitting beside entries that change weekly. - Local overrides and convenience copies that exist precisely because the sanctioned path is slow. - An inventory that cannot answer which entries would matter in a disclosure, because none is distinguished from any other. When an external audit asks how often a value changes and who can prove it, an inventory of twenty undifferentiated secrets produces an answer about twenty values, most of which nobody should care about, and buries the four that the question was really about. ## What an interviewer is listening for The weak answer is that over-classifying is the safe default and costs nothing. The strong answer names a concrete mechanism by which the excess degrades a control that was working - reviewers who stop reading, or a sanctioned path people route around - and then refuses the false dichotomy by proposing the middle class. A candidate who can say 'the cost is measurable, here is the symptom I would look for' has done this on a real file.

  • What handling do you keep for entries that are confidential but grant nothing?
    A lighter class of its own - private configuration: not published, changed through ordinary change control, with no replacement runbook and no approval to read. The distinction is defined by the handling it triggers rather than by how careful anyone feels, which is what stops it collapsing back into the secret class.
  • How would you tell whether over-classification is actually hurting you yet?
    Look at what the handling produced: replacement runbooks never run, approvals granted in seconds in volume, stored entries whose value has never changed, and local overrides that exist to avoid the sanctioned path. Those are symptoms you can count, unlike an opinion about whether the process feels heavy.
  • Is the answer ever to classify a genuine credential as configuration to reduce friction?
    No - the test does not bend to convenience, and that direction is the one that produces incidents. If the friction on a real secret is unaffordable, the thing to change is the handling path so that the correct classification is cheap to live with, not the classification.

saying these in an interview costs you the question

  • Marking everything a secret is the safe default and costs nothing
  • If it is in the settings file at all, it belongs in the store
  • Nobody is harmed by one extra approval on a page size
  • Over-classification is harmless because reviewers still read every change
  • The only risk in classification is missing a real secret