I85PREP
⌘ K
HFCP study materials
HFCP study resources

HFCP: Secrets Management with Vault

HFCP · Work through your exam, one topic at a time.

All guide sections

Secrets Management with Vault

Domain 4 - Secrets Management with Vault. This domain tests Vault's architecture and the operational choices that keep secrets short-lived: engines, auth methods, policies, leases, and audit. Expect questions that distinguish static from dynamic secrets and explain why an app should not hold a root token.

Core rules

  • Secrets engines are mounted at paths. KV version 2 is versioned; its API path includes data/ (for example secret/data/app), while the vault kv CLI hides that segment (vault kv get secret/app). Policies are written against the real request path.
  • Dynamic engines create credentials on demand. The database engine generates a database user per request; the PKI engine issues certificates; the transit engine performs encryption without storing plaintext.
  • Auth methods authenticate workloads and humans - token, AppRole, Kubernetes, OIDC - and return a Vault token bound to policies.
  • Policies are path-based and default-deny; a token can only act where a policy grants read, create, update, delete, or list.
  • Every secret has a lease with a TTL. Clients renew leases or request new credentials; revocation removes the credential at the source.
  • Vault starts sealed. Unsealing requires a quorum of unseal keys (or auto-unseal via a KMS). Audit devices record requests and responses; enable at least one.

Worked example

A Kubernetes-hosted API needs read-only database access. Configure the database secrets engine with a connection and a role whose creation statement grants SELECT. Enable Kubernetes auth and bind a service account to a policy allowing read on database/creds/api-readonly. At runtime the pod authenticates with its service-account token, receives a Vault token, reads a credential, and connects. Vault creates a unique database user with a short TTL; when the lease expires or is revoked, Vault drops the user. The reasoning: the pod never stores a static password, and revocation is centralized.

Traps

  • Using a root token in an application or CI job.
  • Writing a policy for secret/data/app when the mount or request path differs; test with vault token capabilities.
  • Assuming KV v2 automatically deletes old versions; versions and metadata are separate.
  • Confusing transit (encryption as a service) with a storage engine; transit does not persist your plaintext.
  • Forgetting that a dynamic credential's lease must be renewed before expiry, and that revocation is the point.