Vault & secrets management interview questions

Centralized secrets management with identity-based access, auditing, leasing, and rotation — so credentials are not scattered in config files, env vars, and CI, and every access is authenticated and logged.

vault kv put secret/app db_pass=s3cr3t
vault kv get -field=db_pass secret/app

Vault exposes engines and auth methods as API paths (secret/, database/, auth/kubernetes/). You read/write those paths, and policies grant capabilities per path — so the access model and the API are the same thing.

vault secrets list           # mounted engines and their paths
vault kv get secret/app      # read == GET on a path

Both store static key/value secrets; v2 adds versioning (history and rollback), soft delete, and check-and-set writes. v2 is the default for new mounts and preferred unless you need the lighter v1 semantics.

vault kv put secret/app pass=v2         # creates version 2
vault kv get -version=1 secret/app      # read an old version
vault kv rollback -version=1 secret/app

Vault starts sealed with its master key split (Shamir) into shares; unsealing reconstructs the key in memory to decrypt storage. Auto-unseal delegates this to a cloud KMS/HSM so operators are not needed for every restart.

Sealed means the encryption key is not in memory, so storage is useless to an attacker who steals the disk. Shamir requires a quorum of key-holders to unseal by hand; auto-unseal hands that job to a KMS/HSM so restarts do not need humans, at the cost of trusting that KMS.

An auth method (Kubernetes, AppRole, OIDC, AWS IAM) verifies an identity and issues a token bound to policies and a TTL. The token — not a static password — is what a client presents for subsequent requests.

vault login -method=userpass username=alice
# returns a token bound to policies + TTL; used for later calls

Vault generates credentials on demand with a lease and TTL (e.g. a short-lived database user) and revokes them at expiry, so no long-lived shared credential exists and a leak is automatically time-bounded.

Nobody — not even the app — holds a permanent database password. The app asks Vault at startup, gets a unique user valid for, say, an hour, and Vault deletes it at expiry. A leaked credential is useless within the TTL, and every issue is tied to an identity in the audit log.

vault read database/creds/readonly
# -> unique username + password, lease_id, ttl=1h

Use dynamic wherever the backend supports it (databases, cloud IAM, SSH) so rotation is automatic and blast radius is bounded. Static KV is for things Vault cannot generate — third-party API keys, certificates you receive — which you then rotate on a schedule.

Encryption as a service — apps send plaintext and get ciphertext without ever holding the key, and Vault handles key rotation and rewrapping. It also does signing and HMAC, keeping key material inside Vault.

vault write transit/encrypt/orders plaintext=$(base64 <<< "hi")
# app never sees the key; rotate with: vault write -f transit/keys/orders/rotate

The PKI engine issues short-lived X.509 certs on request from a configured CA, enabling automated mTLS with certs that rotate frequently instead of long-lived, manually managed ones.

vault write pki/issue/web common_name=web.example.com ttl=72h
# returns cert + key + chain; renew before expiry

Every dynamic secret and token has a lease with a TTL; clients renew before expiry or the secret is revoked automatically. Operators can revoke a lease (or a whole tree) instantly during an incident — a key advantage over static secrets.

vault lease revoke -prefix database/creds/readonly
# kills every credential that engine issued, at once

The workload presents its projected ServiceAccount token; Vault validates it with the cluster’s TokenReview API and maps the SA/namespace to a Vault role and policies — no static Vault credential in the Pod.

The Pod already has an identity it did not choose — its ServiceAccount token. Vault trusts the cluster to vouch for it via TokenReview, then applies the policies bound to that SA. This is how you avoid the secret-zero problem inside Kubernetes.

vault write auth/kubernetes/role/app bound_service_account_names=app bound_service_account_namespaces=prod policies=app ttl=1h

The agent injector mutates Pods to add a sidecar that fetches and renews secrets to a file; the Secrets Store CSI driver mounts them as a volume; ESO syncs Vault secrets into native Kubernetes Secrets. Choice depends on whether apps read files, env, or k8s Secrets.

Injector needs no app change and auto-renews but adds a sidecar per Pod; CSI mounts secrets as files with no sidecar; ESO turns Vault into the source for ordinary k8s Secrets, which is simplest for apps that already read Secrets — but then the secret does land in etcd.

You annotate the Pod with the Vault role and which secret to fetch; the injector adds an init/sidecar agent that authenticates, writes the secret to a shared file, and keeps it renewed. The app just reads the file.

annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "app"
  vault.hashicorp.com/agent-inject-secret-db: "database/creds/app"

To get secrets you first need a credential to authenticate — the bootstrap secret. The answer is platform identity (Kubernetes SA token, cloud instance identity) that the environment already trusts, so no static secret is pre-planted.

You cannot hand out a secret to fetch secrets without an infinite regress. The way out is an identity the platform already issues — a Pod SA token, an EC2 instance identity document — that Vault can verify. There is nothing to plant because the environment vouches for the workload.

For automated, non-human clients (CI, apps outside k8s) that authenticate with a RoleID plus a Secret ID delivered out-of-band. It fits environments without a platform identity to leverage.

vault write auth/approle/role/ci token_policies=ci token_ttl=20m
vault read  auth/approle/role/ci/role-id       # long-lived id
vault write -f auth/approle/role/ci/secret-id  # short-lived secret

HCL policies grant capabilities (read/create/update/delete/list) on specific paths, deny-by-default and attached to tokens via auth roles. Least-privilege path scoping is the core of Vault access control.

# app can only read its own secrets
path "secret/data/app/*" {
  capabilities = ["read"]
}
path "database/creds/app" {
  capabilities = ["read"]
}

Integrated Storage (Raft) replicates across nodes with a leader for HA; Enterprise adds performance and DR replication across regions. Back up Raft snapshots and rehearse restore, and protect the unseal path.

Raft gives a self-contained HA cluster (odd number of nodes, one leader). The disaster you must rehearse is losing it entirely: take periodic snapshots, store them safely, and practice restore — and remember a restored Vault is sealed, so the unseal path must survive the disaster too.

Audit devices log every request and response (with sensitive values HMAC’d) to file/syslog/socket, giving a tamper-evident trail of who accessed what. Vault refuses requests if it cannot write audit logs — auditing is mandatory, not optional.

vault audit enable file file_path=/var/log/vault_audit.log
# secret values are HMAC-ed, so the log is safe to ship to a SIEM

Prefer dynamic secrets so rotation is automatic; for static ones use the rotate-root and versioned KV features on a schedule. Break-glass is a tightly-audited, high-privilege path with alerting, used only in emergencies and rotated after.

Dynamic secrets rotate themselves at every lease. For the unavoidable static ones, Vault can rotate the root/binding credential so even you never see it. Break-glass access is a separate, heavily-alerted role you assume only in an incident and revoke/rotate immediately after.