HashiCorp Vault — Introduction Exercises

4 minute read

Test your understanding of Vault’s core concepts, architecture, and design philosophy with these practice exercises.

Exercise 1 — Identify the Components

Question: Match each Vault component to its function:

Component Function
A. Barrier 1. Verifies client identity
B. Auth Method 2. Logs every operation
C. Secrets Engine 3. Encrypts data before storage
D. Audit Device 4. Generates or stores secrets
E. Storage Backend 5. Persists encrypted data
Show Answer
Component Function
A. Barrier 3. Encrypts data before storage
B. Auth Method 1. Verifies client identity
C. Secrets Engine 4. Generates or stores secrets
D. Audit Device 2. Logs every operation
E. Storage Backend 5. Persists encrypted data

The barrier sits between Vault’s core and the storage backend, ensuring all data is encrypted with AES-256-GCM before being persisted.

Exercise 2 — Seal/Unseal Scenarios

Question: Your organization initializes Vault with 7 key shares and a threshold of 4. Answer the following:

  1. How many unseal keys are generated?
  2. How many keys must be provided to unseal Vault?
  3. If 2 key holders are unavailable, can you still unseal Vault?
  4. If 4 key holders are unavailable, can you unseal Vault?
  5. Where should the unseal keys be stored?
Show Answer
  1. 7 unseal keys are generated (one for each share)
  2. 4 keys must be provided (the threshold)
  3. Yes — you have 5 available key holders, which exceeds the threshold of 4
  4. No — you only have 3 available key holders, which is below the threshold of 4
  5. Unseal keys should be:
    • Distributed to different trusted individuals
    • Stored in separate secure locations (e.g., different password managers, physical safes in different offices)
    • Optionally encrypted with PGP/GPG keys belonging to each holder
    • Never all stored in the same location or system

Exercise 3 — Dev vs Production Comparison

Question: For each scenario, indicate whether you should use dev mode or production mode, and explain why:

  1. Testing a new Vault policy before deploying
  2. Running Vault for your staging environment
  3. Following along with this tutorial
  4. Storing production database credentials
  5. Running a quick demo for your team
Show Answer
  1. Dev mode — Policies can be tested safely in dev mode. Use vault server -dev to iterate quickly.
  2. Production mode — Staging should mirror production. Use persistent storage, TLS, and proper auth methods.
  3. Dev mode — Perfect for learning. Most tutorial commands work against a dev server. We’ll note when production mode is needed.
  4. Production mode — Real credentials require persistent storage, TLS, audit logging, proper policies, and HA.
  5. Dev mode — Quick demos don’t need persistence. Use a custom root token for reproducibility: vault server -dev -dev-root-token-id="demo-token".

Exercise 4 — Vault vs Alternatives Decision

Question: For each scenario, recommend the best secrets management solution and justify your choice:

  1. An AWS-only startup with 5 engineers and no DevOps team
  2. A multi-cloud enterprise with AWS, Azure, and on-premises data centers
  3. A team that needs to encrypt config files in their Git repository
  4. A Kubernetes-native company that needs dynamic database credentials
  5. A financial institution requiring HSM-backed encryption with FIPS compliance
Show Answer

  1. AWS Secrets Manager — Fully managed, no operational overhead, integrates natively with AWS services. A small team shouldn’t spend time operating Vault.

  2. HashiCorp Vault — The only solution that provides a single API across all clouds. Dynamic secrets, Transit encryption, and PKI work regardless of the cloud provider.

  3. Mozilla SOPS or git-crypt — These are purpose-built for encrypting files in repositories. Vault is overkill if you only need to encrypt config files.

  4. HashiCorp Vault — Dynamic database secrets with automatic lease management is Vault’s core strength. The Agent Injector provides seamless Kubernetes integration.

  5. HashiCorp Vault Enterprise with HSM seal wrap, or CyberArk — Vault Enterprise supports PKCS#11 HSM integration and seal wrap for FIPS 140-2 compliance. CyberArk is also strong in regulated industries.

Exercise 5 — Architecture Diagram

Question: Draw (or describe) the flow of a client reading a secret from Vault. Include these components in order:

  • Client
  • HTTP API listener
  • Auth (token validation)
  • Policy check
  • Secrets engine
  • Barrier
  • Storage backend
  • Audit device(s)
Show Answer 
Client → HTTP API (8200)
           │
           ├──→ Audit Device (log request)
           │
           ├──→ Auth: Validate token
           │       └── Token Store (check TTL, policies)
           │
           ├──→ Policy Check
           │       └── Does token have "read" on "secret/data/myapp"?
           │
           ├──→ Route to Secrets Engine (KV v2 at "secret/")
           │       └── Secrets Engine asks Barrier for data
           │               └── Barrier decrypts data from Storage Backend
           │
           ├──→ Audit Device (log response)
           │
           └──→ Return secret to Client

Key points:

  • Audit happens twice — once for the request, once for the response
  • The barrier decrypts data read from the storage backend
  • The storage backend only stores ciphertext
  • Policy evaluation happens before the secrets engine is invoked
  • If any audit device fails and no other audit device is available, the request is denied

What’s Next?

You now understand Vault’s purpose, architecture, and how it compares to alternatives. Next, we’ll install Vault and get hands-on.

Next Chapter: Installation & Setup

You may also enjoy