HashiCorp Vault Associate (002) Study Guide
The HashiCorp Vault Associate (002) exam validates foundational knowledge of secrets management with Vault: its architecture and seal model, authentication methods, ACL policies, secrets engines, and the token/lease lifecycle. It targets cloud engineers, DevOps practitioners, and security professionals who deploy or operate Vault, and it is a 60-minute, multiple-choice exam scored on a scaled basis with 700 as the passing mark.
Domain 1: Vault Architecture
- Vault starts in a sealed state and cannot decrypt any stored data until it is unsealed; sealing is also the safety mechanism that locks Vault down during a compromise.
- The default Shamir unseal splits the master key into key shares (e.g., 5 shares with a threshold of 3); unsealing requires reassembling enough shares to reconstruct the key.
- vault operator init -key-shares=5 -key-threshold=3 initializes Vault, returning the unseal key shares and the initial root token exactly once.
- Vault encrypts all data with a barrier key before writing to storage, so the storage backend only ever holds ciphertext and never sees plaintext.
- Auto-unseal delegates protection of the master key to a cloud KMS or HSM (AWS KMS, Azure Key Vault, GCP KMS), removing the need to manually enter unseal key shares at startup.
- An auto-unseal seal stanza looks like: seal "awskms" { region = "us-east-1" kms_key_id = "..." }.
- Integrated Storage (Raft) is Vault's built-in, self-contained backend that provides high availability without an external system such as Consul; data is stored on each node's local disk.
- Raft is sensitive to storage write latency, so provision low-latency, high-IOPS disks (fast SSD/NVMe) and take periodic snapshots (vault operator raft snapshot save) for backups.
- Raft uses log truncation/compaction so the log does not grow unbounded; periodic snapshots support this and enable disaster recovery.
- Vault Enterprise Performance Standby nodes serve read-only requests locally and forward writes to the active node, scaling read throughput within a cluster.
- Performance Replication (Enterprise) lets secondary clusters serve reads locally and proxy writes to the primary, reducing latency for geographically distributed clients.
- Audit devices log every request and response with sensitive strings HMAC-hashed; if no enabled audit device can record, Vault blocks requests, so configure multiple devices for reliability.
- All listeners should use TLS; a listener stanza looks like: listener "tcp" { address = "0.0.0.0:8200" tls_cert_file = "..." tls_key_file = "..." }.
- The sys/health endpoint returns different HTTP status codes for active, standby, sealed, and uninitialized states so load balancers can route traffic to the correct node.
Domain 2: Authentication
- Auth methods authenticate clients (humans or machines) and, on success, issue a Vault token with attached policies and a TTL that is used for all subsequent requests.
- AppRole is purpose-built for machine/application auth using a RoleID (like a username) and a SecretID (like a password); the SecretID is decoupled and rotatable for automated workflows.
- Enable and configure AppRole with: vault auth enable approle, then vault write auth/approle/role/web token_policies="web-policy", read the role-id with vault read auth/approle/role/web/role-id, and generate a secret-id with vault write -f auth/approle/role/web/secret-id.
- Log in with AppRole using: vault write auth/approle/login role_id="..." secret_id="...", which returns a token.
- The Kubernetes auth method validates a pod's ServiceAccount JWT (against the cluster's TokenReview API or via local JWT validation using the cluster's public keys/issuer) and maps it to a role and policies, so no static secrets are distributed to pods.
- The root token has unrestricted access and no TTL; use it only for initial setup, then revoke it and operate with scoped, least-privilege tokens.
- Vault Agent auto-auth lets a client authenticate once and reuse/renew the resulting token, with caching, instead of logging in per request, which reduces auth load.
- For stateless/batch jobs, configure the role to issue batch tokens (token_type=batch) so logins do not persist a token entry in storage.
- A rate-limit (resource) quota scoped to a path or namespace caps requests per second and protects Vault from auth-storm overload.
- Common auth methods include token, AppRole, Kubernetes, and cloud methods (AWS, Azure, GCP); each is enabled at a path and configured with role-to-policy mappings.
- The token auth method is always enabled by default and cannot be disabled, since tokens are the core Vault credential.
- Running a local Vault Agent per node lets workloads share a single authenticated, renewed token and cached responses rather than each performing its own login.
- An auth method is enabled with vault auth enable <type> and mounted under the auth/ path prefix (e.g., auth/approle/).
- Best practice is decoupled, rotatable credentials (such as AppRole SecretIDs or platform identities) rather than embedding long-lived static secrets in application code.
Domain 3: Policies
- Vault policies are deny by default: a token has no access to any path unless a policy explicitly grants capabilities on it.
- Policies grant capabilities on paths; valid ACL capabilities are read, create, update, delete, list, sudo, deny, and patch.
- An explicit deny always overrides any grant, regardless of how the access was granted on other matching paths.
- When multiple policy rules match a request, the most specific matching path wins, and an explicit deny on that path overrides grants.
- Write a policy from a file with vault policy write app policy.hcl, where the file contains stanzas like path "secret/data/app/*" { capabilities = ["read", "list"] }.
- Use the '+' wildcard to match a single path segment and '*' to match a suffix; '*' only matches at the end of a path, not in the middle.
- Templated (parameterized) policies use identity metadata to avoid one policy per user, e.g., path "secret/data/{{identity.entity.metadata.team}}/*" or {{identity.entity.name}}.
- Policies are attached to tokens via auth method roles, entities, or directly at token creation; you do not assign a policy to a path.
- For KV v2, the data path is secret/data/<path> (not secret/<path>), so policies must target the data/ prefix to grant read/write of the secret value.
- To let a token manage its own lifecycle, grant update on auth/token/renew-self and read on auth/token/lookup-self.
- Follow least privilege: scope capabilities to the exact paths a workload needs, and grant read (and list where required) rather than full capabilities.
- Prefer a single path glob (e.g., secret/data/app/*) with the needed capabilities over enumerating every individual key.
- An entity in Vault's identity system represents a single user or application across multiple auth methods via aliases, enabling consistent policy application.
- The built-in default policy is attached to most tokens and provides a minimal baseline (such as token self-management), while the root policy grants unrestricted access.
Domain 4: Secrets Engines
- The KV (Key/Value) secrets engine stores arbitrary key-value data; KV v2 adds versioning, metadata, and soft delete, while KV v1 performs immediate, irreversible deletes with no history.
- Enable KV v2 with vault secrets enable -path=myapp kv-v2 (or vault secrets enable -version=2 kv, or vault secrets enable kv-v2).
- Write and read KV data with vault kv put secret/myapp foo=bar and read a specific version with vault kv get -version=3 secret/myapp.
- On a KV v2 mount, set max_versions to cap retained versions per secret and delete_version_after to auto-delete versions after a duration, bounding storage growth.
- The transit secrets engine provides encryption as a service: applications send plaintext to be encrypted/decrypted, but Vault never stores the data, only manages and rotates the keys.
- Transit supports batch input, letting you submit many plaintext items in one transit/encrypt request, and batch operations on transit/verify for multiple input/signature pairs.
- The database secrets engine generates dynamic, short-lived, unique credentials on demand and automatically revokes them when the lease expires, eliminating static database passwords.
- Configure a database connection with vault write database/config/mydb plugin_name=postgresql-database-plugin allowed_roles="*" connection_url="...".
- Set max_open_connections on the database connection config to bound the concurrent connections Vault opens to the database.
- The database engine can rotate its own root credential so the configured admin password is known only to Vault after setup.
- The PKI secrets engine turns Vault into a certificate authority that dynamically issues, renews, and revokes X.509 certificates; issuing short-lived certs lets them expire naturally rather than relying on the CRL.
- Dynamic secrets engines (database, AWS, Azure, GCP, etc.) issue per-request, leased credentials that Vault revokes automatically on lease expiry, reducing standing secrets and blast radius.
- Prefer fewer mounts with structured path hierarchies and policies to separate teams, rather than proliferating many mounts.
- Use Vault Agent templating to fetch, cache, and re-render secrets only when they change, instead of having applications poll Vault for each read.
Domain 5: Tokens and Leases
- A token is the primary credential used to authenticate to Vault and carries the policies and TTL that govern what the holder can do and for how long.
- Every dynamic secret and most tokens have a lease with a TTL that defines how long it remains valid before expiring or needing renewal; expiry triggers automatic revocation.
- Revoking a lease immediately invalidates the associated secret (e.g., deletes the dynamic database credential) before its TTL would naturally expire.
- Create a token with policies and a TTL using vault token create -policy=app -ttl=1h.
- Renew a lease with vault lease renew <lease_id> and revoke with vault lease revoke <lease_id>; revoke a token with vault token revoke <token>.
- vault lease revoke -prefix <mount-path> revokes all leases under that prefix at once, useful for invalidating every credential from an engine.
- Service tokens are persisted to storage, can be renewed and create child tokens, and are the default; batch tokens are self-contained encrypted blobs not written to storage.
- Batch tokens have low overhead and reduce storage and replication load, but cannot be renewed, cannot create child tokens, and are not tracked individually.
- A renewable token can have its TTL extended up to its max TTL without re-authenticating; once max_ttl is reached it can no longer be renewed and expires regardless of further attempts.
- A periodic token renews within its period and can live indefinitely while remaining revocable, which suits long-running services; increasing the period grants a longer window between renewals.
- Response wrapping passes a secret to a recipient via a single-use wrapping token that they unwrap once, ensuring the secret is seen by exactly one party in transit.
- A lease count quota limits the number of active leases for a scope and rejects new ones beyond the cap, protecting against lease explosion.
- Right-size default and max TTLs so leases live just long enough for the workload, then expire and are purged; lowering a role's TTL reduces the number of tracked leases.
- Have clients cache a token's known TTL and renew proactively near expiry rather than polling lookup-self on a tight loop, which reduces unnecessary load.
HashiCorp Vault Associate (002) exam tips
- Memorize the exact CLI verbs and paths: vault auth enable, vault secrets enable, vault policy write, vault kv put/get, vault lease renew/revoke, vault token create/revoke - the exam tests precise command syntax.
- Know the KV v2 path quirk cold: the secret data lives at secret/data/<path>, so policies and API calls must include the data/ segment that the kv CLI hides for you.
- When a policy question shows conflicting rules, apply the precedence order: most specific path wins and an explicit deny always beats any grant.
- Distinguish service vs. batch tokens by their properties (persistence, renewability, child tokens, replication cost) - several questions hinge on these differences.
- For 'best practice' or scenario questions, favor least privilege, dynamic short-lived secrets, auto-unseal/TLS/audit-on, and revoking the root token after setup.
Study guide FAQ
How long is the exam and what score do I need to pass?
The Vault Associate (002) exam is 60 minutes long and is delivered as multiple-choice and multiple-select questions. It is scored on a scaled basis, and a score of 700 is required to pass.
What is the difference between KV v1 and KV v2?
KV v1 stores a single value per key and deletes are immediate and irreversible with no history. KV v2 adds versioning (so you can recover prior values), metadata, and soft delete before permanent destruction, and its data is accessed under the secret/data/ path with options like max_versions and delete_version_after to bound retention.
What is the difference between a service token and a batch token?
Service tokens are persisted to Vault storage, can be renewed, can create child tokens, and are replicated - they are the default. Batch tokens are self-contained encrypted blobs not written to storage, which makes them lightweight and ideal for high-volume stateless workloads, but they cannot be renewed and cannot create child tokens.
What is the difference between sealing/unsealing and authentication?
Sealing controls whether Vault can decrypt its own data at all: Vault starts sealed and must be unsealed (via Shamir key shares or auto-unseal with a KMS) before it can serve any request. Authentication happens after Vault is unsealed and verifies a client's identity through an auth method, issuing a token with policies and a TTL for ongoing access.