Skip to content

Security Vault

← Back to all decks

12 cards — 🟢 3 easy | 🟡 5 medium | 🔴 4 hard

🟢 Easy (3)

1. What is HashiCorp Vault and what are its core use cases?

Show answer Vault is the industry standard for secrets management, providing centralized storage and access control for secrets. Core use cases include static secret storage (KV engine), dynamic credential generation (database, cloud IAM), encryption-as-a-service (transit engine), PKI certificate management, and audit logging of all secret access.

2. What is Vault Agent and what problem does it solve?

Show answer Vault Agent is a client daemon that runs alongside applications (often as a sidecar in Kubernetes). It handles automatic auth token renewal, secret caching, and template rendering (writing secrets to files the app can read). This removes the need for applications to implement Vault client logic, token lifecycle management, and re-authentication after token expiry.

3. What is a Vault token and what are root tokens used for?

Show answer Every authenticated request to Vault requires a token. Tokens have policies, TTLs, and can create child tokens. Root tokens have unlimited access and no TTL. They are generated during initialization (with the unseal keys) and should be revoked after initial setup. Use them only for emergency recovery or initial configuration -- never for application access.

🟡 Medium (5)

1. What does it mean for Vault to be sealed vs unsealed, and how does unsealing work?

Show answer When Vault starts, it is sealed -- it knows where encrypted data is stored but cannot decrypt it. Unsealing requires providing a threshold of key shares (Shamir's Secret Sharing, e.g., 3 of 5 shares). Once enough shares are provided, Vault reconstructs the master key, decrypts the encryption key, and becomes operational. Auto-unseal via cloud KMS is the production alternative.

2. What is AppRole auth and how do applications authenticate to Vault?

Show answer AppRole is Vault's machine-oriented auth method. An application authenticates using a role_id (like a username, relatively static) and a secret_id (like a password, often single-use and short-lived). The secret_id is typically delivered via a trusted broker or CI system. On successful auth, Vault returns a token with policies attached.

3. What is the difference between KV v1 and KV v2 secrets engines?

Show answer KV v1 is a simple key-value store with no versioning -- writes overwrite the previous value permanently. KV v2 adds versioning: every write creates a new version, and you can read, compare, or rollback to any previous version. KV v2 also supports check-and-set (CAS) to prevent accidental overwrites and metadata like creation time and deletion time.

4. What is a Vault lease and what happens when a lease expires?

Show answer Every dynamic secret and auth token has a lease with a TTL (time-to-live). Applications must renew the lease before expiry by calling the renew endpoint. If the lease expires without renewal, Vault automatically revokes the associated credential (e.g., drops the database user). Applications should handle renewal proactively to avoid sudden credential invalidation.

5. How does Vault audit logging work and why is it critical?

Show answer Vault can log every API request and response to one or more audit devices (file, syslog, socket). Every secret read, write, auth event, and policy change is recorded with the accessor identity, timestamp, and request path. At least one audit device must be enabled -- Vault blocks all operations if it cannot write to any configured audit backend.

🔴 Hard (4)

1. What is the transit secrets engine and when would you use it?

Show answer The transit engine provides encryption-as-a-service: applications send plaintext to Vault's API and receive ciphertext back (or vice versa) without ever handling encryption keys directly. Use it for application-level encryption (encrypting database fields, files) when you want centralized key management, key rotation, and audit logging without embedding crypto libraries in every app.

2. How do dynamic credentials work in Vault and why are they more secure than static secrets?

Show answer When an application requests dynamic credentials (e.g., a database login), Vault creates a unique, short-lived credential on demand with a TTL lease. Each application instance gets its own credential. When the lease expires, Vault automatically revokes the credential. This eliminates shared passwords, makes credential rotation automatic, and provides per-client attribution in audit logs.

3. What is Vault disaster recovery replication and how does it differ from performance replication?

Show answer DR replication creates a standby cluster in another region that receives a full copy of all data but does not serve requests until promoted. Performance replication creates read replicas that can serve read requests locally but forward writes to the primary. DR replication is for failover; performance replication is for geographic distribution and read scaling.

4. How do Vault policies control access and what is a path-based policy?

Show answer Vault policies are written in HCL and define which paths (secret engines, auth methods, system endpoints) a token can access and with which capabilities (create, read, update, delete, list, sudo). For example: path "secret/data/myapp/*" { capabilities = ["read", "list"] } grants read-only access to all secrets under myapp. Policies are attached to tokens and auth method roles.