Domain 1: Vault Architecture and Fundamentals
- Vault solves secret sprawl by centralizing secrets behind identity-based access, an audit trail, dynamic (short-lived) credentials, and encryption as a service, replacing secrets scattered across config files and source code.
- All data is written to a storage backend encrypted; the barrier encrypts/decrypts data in transit to storage, and the encryption key itself is protected by the unseal process.
- Vault starts sealed. Unsealing reconstructs the master key from Shamir key shares - a configurable threshold of the total shares must be supplied (e.g., 3 of 5) before Vault can decrypt data.
- Unseal keys are distinct from the root token: unseal keys reconstruct the master key to unseal, while the root token is a superuser credential for authenticated operations and should be revoked after initial setup.
- Auto-unseal delegates the unseal step to a cloud KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS) or Transit, removing manual key-share entry - useful for automated restarts and HA.
- 'vault operator init' initializes a new Vault, returning the unseal key shares and the initial root token; 'vault status' shows sealed/unsealed state, HA mode, and version.
- Integrated Storage (Raft) is the built-in HA storage backend: nodes form a cluster with one active node and standbys; standbys forward requests to the active node, and raft snapshots back up state.
- Vault is used via the CLI, the HTTP API (requests carry the token in the X-Vault-Token header), and the UI; a dev server ('vault server -dev') is in-memory and auto-unsealed for testing only, never production.
- Audit devices (file, syslog, socket) record every request and response with sensitive strings HMAC'd, providing a tamper-evident log; at least one audit device is recommended in production.
- Environment variables VAULT_ADDR (server address) and VAULT_TOKEN (the auth token) configure the CLI; VAULT_NAMESPACE selects an Enterprise namespace.
Domain 2: Authentication Methods
- Authentication is the process of getting a token: a client proves identity via an auth method, and Vault returns a token carrying policies and a TTL that is used for all subsequent requests.
- Auth methods are pluggable and mounted at a path; human-oriented methods include userpass, LDAP, GitHub, and OIDC, while machine/platform methods include AppRole, Kubernetes, AWS, Azure, GCP, JWT, and TLS cert.
- AppRole authenticates applications and automation using a RoleID (like a username) plus a SecretID (like a password); it supports secret_id TTLs, use limits, and CIDR binding, and is preferred over embedding human credentials.
- The Kubernetes auth method lets pods authenticate with their service account JWT; a Vault role binds a service account and namespace to a set of policies.
- Manage methods with 'vault auth enable/disable/list'; mount at a custom path with -path, and tune default_lease_ttl / max_lease_ttl to control the TTL of tokens the method issues.
- The identity system models a user as an entity with aliases from each auth method, so one person authenticating through multiple methods is recognized as a single identity; identity groups apply shared policies.
- Login returns a token whose policies and TTL come from the method's role configuration; 'vault login -method=<type>' authenticates from the CLI.
Domain 3: Policies
- ACL policies grant capabilities on paths. Capabilities are create, read, update, delete, list, sudo, and deny; deny always takes precedence over any grant.
- Policies are written in HCL (or JSON) as path stanzas, e.g. path "secret/data/app/*" { capabilities = ["read", "list"] }; the glob * matches within a path segment level.
- Two policies always exist: the default policy (attached to most tokens, granting basic self-management like token lookup) and the root policy (implicit, unrestricted, held only by root tokens).
- Manage policies with 'vault policy write/read/list/delete'; a token's effective permissions are the union of all its attached policies, with any matching deny overriding.
- The most specific matching path wins when rules overlap, and sudo is required for certain root-protected API paths (for example some sys/ and auth/token/ endpoints).
- Fine-grained control uses allowed_parameters, denied_parameters, and required_parameters to constrain request data, plus min/max_wrapping_ttl for response wrapping.
- With KV v2, policies must target the API paths secret/data/<path> and secret/metadata/<path>, not the logical CLI path secret/<path>, because v2 rewrites the request path.
Domain 4: Tokens and Leases
- Service tokens are the default: they are persisted in storage, renewable, can have child tokens, and have accessors; batch tokens are lightweight encrypted blobs that are not persisted, cannot be renewed or have children, and suit high-volume ephemeral workloads.
- The root token has unlimited privileges and no expiration; regenerate it with 'vault operator generate-root' and revoke it after setup rather than using it day to day.
- Periodic tokens can be renewed indefinitely as long as they are renewed within each period; orphan tokens have no parent and are not revoked when a parent is revoked.
- Token attributes include ttl, max_ttl, explicit_max_ttl, num_uses (a use limit), attached policies, and an accessor used to look up or revoke the token without knowing its value.
- 'vault token revoke' revokes a token and its entire child tree; -mode=orphan revokes only the token and orphans its children, and -accessor revokes by accessor.
- Dynamic secrets and logins carry a lease (lease_id, lease_duration). Renew with 'vault lease renew' up to the max TTL, and revoke with 'vault lease revoke' (-prefix for many); revoking a lease invalidates the underlying secret (e.g., deletes the dynamic DB user).
- The effective TTL is the shortest of the applicable limits - system default/max, mount tune, role setting, and request value - and cannot exceed the max TTL.
Domain 5: Secrets Engines
- Secrets engines are mounted at a path and either store or dynamically generate secrets; manage them with 'vault secrets enable/disable/list/tune', and use -path to mount the same engine at multiple paths.
- The KV engine stores static key/value secrets. v1 is a simple overwrite store; v2 adds versioning, metadata, check-and-set (cas) writes, and soft delete vs. destroy, with API paths under data/ and metadata/.
- 'vault kv' commands operate the KV engine: get, put, delete (soft), undelete, destroy (permanent), and metadata; max-versions limits retained versions.
- Dynamic secrets are generated on demand with a lease and automatically revoked when the lease ends, so credentials are unique per client and short-lived.
- The database secrets engine configures a connection and roles with creation/revocation SQL statements; Vault creates a temporary DB user per request and can rotate the root credential so no human knows it.
- Other engines: PKI issues short-lived certificates from a CA, SSH signs keys or issues OTPs for access, cubbyhole stores per-token secrets cleared on token revocation, and TOTP manages one-time codes.
- Response wrapping returns a secret inside a single-use, TTL-limited token (stored in the creator's cubbyhole); the recipient runs 'vault unwrap' once, which solves secure secret handoff and the secret-zero problem.
Domain 6: Encryption as a Service
- The Transit secrets engine performs cryptographic operations without storing the data: applications send plaintext and receive ciphertext, so Vault manages the keys and the app never handles key material.
- Named encryption keys are created with 'vault write -f transit/keys/<name>'; supported types include aes256-gcm96, chacha20-poly1305 (symmetric) and rsa/ecdsa/ed25519 (asymmetric for sign/verify).
- Encrypt with 'vault write transit/encrypt/<key> plaintext=<base64>' and decrypt with transit/decrypt; ciphertext is returned in the versioned form vault:v1:... so Vault knows which key version produced it.
- Rotate keys with 'transit/keys/<name>/rotate'. Old ciphertext still decrypts until min_decryption_version is raised; min_encryption_version controls which version new encryptions use.
- 'transit/rewrap' re-encrypts existing ciphertext to the latest key version without exposing the plaintext, letting you upgrade data after a rotation.
- 'transit/datakey' returns a high-entropy data key (plaintext plus a wrapped copy) for envelope encryption, and convergent encryption makes identical plaintext produce identical ciphertext for equality search or dedup.
- Transit also provides sign/verify (with asymmetric keys) and HMAC; typical use cases are application-layer encryption, tokenization, and removing key-management burden from developers.
HashiCorp Vault Associate (003) exam tips
- Study by objective: architecture/fundamentals, auth methods, policies, tokens & leases, secrets engines, and encryption as a service map directly to the six exam domains.
- Know the difference pairs cold: unseal keys vs root token, service vs batch tokens, KV v1 vs v2, static vs dynamic secrets, and periodic vs orphan tokens.
- For policies, memorize the seven capabilities (create/read/update/delete/list/sudo/deny), that deny always wins, and that KV v2 policy paths use secret/data/ and secret/metadata/.
- Understand leases end to end: dynamic secrets get a lease, renew up to max TTL, and revoking a lease removes the underlying credential; the shortest applicable TTL always wins.
- Be comfortable with the Transit workflow (encrypt/decrypt with base64, versioned vault:v1: ciphertext, rotate + rewrap, datakey for envelope encryption) since encryption as a service is its own domain in 003.
Study guide FAQ
What is on the Vault Associate (003) exam and how is it delivered?
It is a 1-hour, online-proctored, multiple-choice exam tested on Vault 1.16. It covers Vault architecture and fundamentals, authentication methods, policies, tokens and leases, secrets engines, and encryption as a service (the Transit engine). It is a foundational exam aimed at people who use Vault regularly rather than deep operators.
How is Vault Associate (003) different from the older 002 version?
003 is the current version, refreshed for Vault 1.16, and it makes encryption as a service (Transit) a distinct objective alongside architecture, auth, policies, tokens/leases, and secrets engines. The core concepts are similar, but 003 reflects current Vault features and objective wording, so study against the 003 exam guide.
Do I need to memorize exact CLI commands?
Yes, to a point. You should recognize the common vault commands and API paths - operator init, auth enable, policy write, token create/revoke, lease renew/revoke, secrets enable, kv get/put, and transit/encrypt|decrypt|rotate|rewrap - and understand what each does and the flags that matter (for example -orphan, -period, cas, min_decryption_version).
What passing score does the exam require?
HashiCorp reports the Vault Associate exam as pass/fail on a scaled score rather than publishing a fixed percentage. CertGrid's practice mode reports a readiness score per objective so you can see which domains need more work before test day.