skip to content

Reviewing an admin tool's settings file, what single test tells you which entries are secrets and which are configuration?

level: juniorimportance: must knowfreq 74%

answer

  1. authority, not embarrassment
  2. one question, asked of every entry
  3. what could a stranger do with it
  4. aims or tunes the process, grants nothing
  5. classify the value, not the key name

basics

~20 s

If disclosing a value lets someone act with rights you hold, it is a secret; if it only tells the process where to go or how to behave, it is configuration. Being sensitive is not the test.

solid answer

~50 s

Ask one question of every entry: could a stranger who learned this value act with the rights we hold? A database account password, a bearer token for a scoring service, a signing key and a data encryption key all fail that question - each one either is the proof of authority or unlocks it. A hostname, a queue name, a page size and a timeout pass it: they aim the process or tune it, and knowing them grants nothing by itself. The test is about **authority**, not embarrassment, and it is applied to the value rather than to the key name, because a compound value such as a connection string can carry a credential inside it. Where an entry is arguable, say out loud what an attacker could do with it; if that sentence starts 'they could act as us', it is a secret.

code

pseudocode · 13 lines
pseudocode
for each entry in settings_file:
    if knowing entry.value lets a stranger act with our rights:
        entry.class = SECRET
    else if entry.value only aims or tunes the process:
        entry.class = CONFIG
    else:
        entry.class = UNDECIDED       # settle by naming the attacker's action

classify('db_password',    'hunter-8f2a')          -> SECRET   # opens the account
classify('db_host',        'reports-db.internal')  -> CONFIG   # names a target only
classify('page_size',      '50')                   -> CONFIG   # tunes behaviour only
classify('scoring_token',  'tok-9c14')             -> SECRET   # presented as whole proof
classify('report_footer',  'Internal use')         -> CONFIG   # grants nothing

go deeper

for a junior

Be able to state the test in one sentence and apply it to four entries out loud. Knowing that a password and a token are secrets is the floor; saying why a hostname is not is what the question is actually checking.

for a middle

Explain that the test runs against the value rather than the key name, and show where a credential hides inside a compound value such as a connection string or a callback link. Name what handling each class then triggers.

for a senior

Show judgment on the arguable entries and on both failure directions. Say what under-classifying costs in one incident and what over-classifying costs continuously, and describe the lighter class you keep for confidential-but-powerless values.

for a principal

Frame classification as the thing that sets the cost of everything downstream, and be ready to defend where you drew the line for other teams to follow - what the default class is for a new entry, and who settles a disputed one.

## The one question that does the work A settings file for an internal admin tool might hold twenty entries: a database account password, a hostname, a queue name, a page size, a third-party scoring token, a signing key, a data encryption key, a handful of timeouts and some labels. Before any of it moves into a store, someone has to say which entries are **secrets** and which are **configuration**, because that call decides the handling every entry gets for the rest of its life. The test is one sentence: **if someone who learned this value could act with rights we hold, it is a secret.** A secret is a value whose *disclosure transfers authority*. Configuration is a value that tells a process where to go, what to call something, or how to behave, and transfers nothing. Two properties make that test usable on a real file: - It is applied to the **value**, not to the key name. An entry called `reports_db_url` can carry an account password inside it, and an entry called `signing_note` can be a comment. - It is applied to **what the value grants**, not to who can currently reach it. An internal-only credential is still a credential; the network is a control wrapped around the value, not a property of the value. ## Applying it entry by entry | entry | what a stranger gains by learning it | class | |---|---|---| | database account password | opens that account outright, with all its rights | secret | | bearer token for a scoring service | the service accepts the caller on presentation alone | secret | | signing key for the tool's own links | can produce values the tool treats as genuine | secret | | data encryption key for stored records | can read any copy of that ciphertext they hold | secret | | read-only reporting key | can read what that key is permitted to read | secret | | database hostname | somewhere to aim a request that still needs a credential | configuration | | queue name | a name; publishing still needs a credential the broker accepts | configuration | | page size, timeout, retry count | different behaviour, no access of any kind | configuration | Two edges account for most of the arguments a real review produces: 1. **A compound value can hide a credential.** A connection string with the password inside it, a callback link whose query value is the entire permission, a header template with a token in it - the entry looks like an address and behaves like a key. 2. **'Read-only' is still authority.** The test asks whether rights transfer, not which rights. A credential that can only read is a credential, and a caller who gains it gains reads nobody granted them. ## What the test is not - **Not 'is it sensitive?'** A value can be kept private without conferring anything. That is a real category, and it deserves its own lighter handling rather than the credential path. - **Not 'does it look random?'** Randomness describes how a value was generated. A short, guessable shared password is a secret; a long random request identifier is not. - **Not 'is it production?'** Environment changes what a disclosure costs, not whether the value grants authority. - **Not 'could an attacker use it somewhere in a chain?'** Almost any fact helps an attacker eventually. The test asks whether the value *is* the authority, not whether it assists someone who is hunting for one. ## Why the call is made first Classification decides handling. An entry classified as a secret earns the expensive path: held in a store rather than shipped inside the artifact, fetched by the process that needs it, replaced when someone leaves or when it is exposed, readable by as few callers as possible. An entry classified as configuration earns ordinary change control and nothing more. Both wrong calls are expensive, in different ways. Under-classify and a credential rides inside an artifact that everyone with the artifact can read. Over-classify and the expensive path fills with page sizes and hostnames until the people meant to review credential changes are reviewing tuning parameters, and stop reading. ## What a strong answer sounds like A weak answer is a list: *passwords, API keys, certificates*. A list cannot classify the entry nobody thought of. The strong answer is the test itself, applied out loud to two or three entries with the reason attached, plus an honest account of how arguable entries get settled: name the action an attacker could take. If the best sentence available is 'they could act as us', it is a secret; if the best sentence is 'it tells them where we are', it is configuration that you may still choose to keep private.

  • An entry is genuinely arguable and the team cannot agree. How do you settle it without a meeting?
    Make each side finish the sentence 'an attacker who learned this could...'. If the sentence names an action taken with our rights, it is a secret. If the strongest available sentence is that it helps someone find us or understand us, it is configuration you may still keep private. Write the decided class and the sentence beside the entry so the same argument is not had twice.
  • Does the answer change if the value is only reachable from inside the network?
    No. The test asks what the value grants, not who can currently reach it. Network position is a control placed around a secret, not a property of it - anything that gets inside, including every other process on that network, inherits whatever the value confers. Reachability changes how likely disclosure is, never whether the entry is a secret.
  • A value is confidential but grants nothing. What do you do with it?
    Give it a lighter class of its own - private configuration: not published, changed through normal change control, with no replacement runbook and no approval gate to read it. Collapsing it into 'secret' buys no protection and adds process to an entry that cannot be used against you.

A key opens the door; a street address only tells you which door. Both can be written in the same notebook, but only one of them lets a stranger in.

saying these in an interview costs you the question

  • Everything in a settings file is sensitive, so mark it all secret
  • It is a secret if the value looks long and random
  • Internal-only values are not secrets because outsiders cannot reach them
  • A hostname is a secret because it helps an attacker find the database
  • A read-only key is configuration, since it cannot change anything