Secrets Management
Where credentials, API keys and encryption keys live once you accept that they cannot sit in the repository or a config file: tooling for storing, issuing and rotating them. Interviewers raise it because secret sprawl and long-lived static keys are a finding on almost every security review.
on this pageshowhide
explore
- Vaultempty
- Auth Methodsempty
- Policies and ACLsempty
- Secret Enginesempty
- Seal, Unseal, and HAempty
- Secret Management Concepts220 questions
- The Nature of Secrets23 questions
- The Secret Store25 questions
- Proving Who Is Calling22 questions
- Policy & Least Privilege27 questions
- The Credential Lifecycle23 questions
- Rotating Credentials28 questions
- Protecting Key Material27 questions
- Reaching the Workload22 questions
- Catching & Containing Leaks23 questions
questions
220 · 1 sectionA secret store releases nothing until the caller authenticates, so what must already exist on a machine before its first fetch?
basics
~20 sSomething the store already accepts must be on the machine before it can fetch anything: the bootstrap credential. Moving secrets into a store does not remove that first one. It only decides where it comes from and how long it lives.
Why does a secret store treat an engineer signing in at a terminal differently from a service re-authenticating at restart?
basics
~20 sA person is present, can answer a prompt, and acts under a name the organisation already knows. A service authenticates with nobody watching, at any hour, so nothing in its path may wait for a human, and its name belongs to no individual.
What do read, write and list rights over a secret store each permit, and why is store-wide read-only still too much?
basics
~20 sRead returns one named value, write creates or replaces a value, and list returns the names under a branch without their contents. Store-wide read-only is still too much because one compromised caller then reaches every credential the estate holds.
A batch job is launched with its database password as a command-line argument — who on that host can read it?
basics
~20 sAny local account that can list processes, because the argument list is host-visible bookkeeping rather than private process memory. Copies also survive the run, in whatever records program executions and in the job definition that issued the line.
Your team commits the rendered configuration file, warehouse password included, so a deploy can be reproduced — how do you keep that reproducibility?
basics
~20 sCommit the template, the rendering step and the identity of the value — its name in the store and the version delivered — and render the value on the host at deploy time. Reproducing a release needs the inputs, not the secret itself.