HashiCorp Vault Associate

The certifications page covers three exams; this is the deep profile of a fourth, HashiCorp's other flagship associate credential. Where the Terraform Associate certifies that you can provision infrastructure with HCL, the Vault Associate certifies that you can operate the tool sitting next to it in the same vendor's stack: authentication methods, policies, tokens, leases, secrets engines, and Transit's encryption-as-a-service model. Below: what it is, the nine official domains straight from HashiCorp's own exam guide, the substance behind each one, real exam logistics, and how to prepare using the lessons already on this site — chiefly the HashiCorp Vault tool page, which this exam maps onto almost one-for-one.

What the Vault Associate is, and who it's for

☺ Like you're 10: A one-hour, closed-book, multiple-choice test about one specific tool's security model — no terminal, no real Vault cluster touched.

The HashiCorp Certified: Vault Associate is HashiCorp's entry-level credential for people who operate, configure, or build against Vault. Like the Terraform Associate and unlike the CKA, it is entirely knowledge-based — multiple choice, true/false, scenario-based items, and occasional UI-area-selection questions, delivered online and proctored remotely, with no live terminal and no cluster actually deployed during the exam. It certifies foundational knowledge of Vault itself: how identity and policy gate access, how secrets get issued and revoked, and how the server protects data at rest. It does not certify the vendor-neutral secrets-management thinking that sits one layer up — that's what Secrets & Credential Management covers, and this exam assumes you already hold it.

It targets anyone who configures Vault, writes or reviews its policies, or builds applications and pipelines that authenticate against it — platform and security engineers standing up the shared instance, and application engineers consuming secrets from it day to day. HashiCorp does not formally require anything before you sit it, but its own learning path lists three assumed baselines worth taking seriously: basic terminal skills, a basic understanding of on-premise or cloud architecture, and a basic level of security understanding. This is not the exam to attempt before you've run vault kv get against something real at least a few times.

↗ HashiCorp official page

003 vs. the retired 002: what changed, and why it matters if you're studying with old material

☺ Like you're 10: If your study notes never mention the Vault Agent or the Vault Secrets Operator, they were probably written for the older version of this test.

The exam you'll actually sit today is version 003 (HCVA0-003), tested against Vault 1.16. As with Terraform's 003-to-004 transition, HashiCorp does not leave the retired 002 version registerable, but plenty of study decks, flashcard sets, and old blog posts written against it are still circulating — and they are a common way candidates walk in with a blind spot. The core substance carries over largely intact: authentication, policies, tokens, leases, and secrets engines were the spine of 002 and remain the spine of 003. The clearest tell that material predates 003 is the domain this page calls Access management architecture — coverage of the Vault Agent and the Vault Secrets Operator. Both tools existed before 003 shipped, but a study guide that never mentions either of them by name is worth treating as stale until you've checked it against HashiCorp's current exam guide.

The official domain breakdown

☺ Like you're 10: Nine topics, and — like the Terraform Associate — HashiCorp doesn't publish a percentage weight for each one, so don't assume any single domain is "the big one."

HashiCorp's own exam content list groups the nine domains into four themes, which is also how its official learning path is organized — a useful map for study order even though the exam itself doesn't test in this sequence. Across the nine domains, HashiCorp publishes 40 individual sub-objectives (labeled 1a through 9b), unevenly distributed: the three domains under "Access Vault" alone account for 17 of the 40, more than the other six domains combined.

The full nine, in HashiCorp's own published order, with what each one actually asks you to know:

1. Authentication methods — why auth methods exist, choosing the right one for a use case, the difference between human and system (machine) authentication, the purpose of identities and groups, and authenticating and configuring auth methods through the API, CLI, and UI.
2. Vault policies — the value a policy provides, the path and capabilities syntax, choosing a policy shape for a stated requirement, and configuring policies through the UI and CLI.
3. Vault tokens — choosing between service and batch tokens for a use case, root token uses and lifecycle, the purpose of token accessors, the effect of time-to-live, what an orphaned token is, and creating a token that fits a specific need.
4. Vault leases — the purpose of a lease ID, and how to renew and revoke a lease.
5. Secrets engines — choosing an engine for a use case, static vs. dynamic secrets and when each applies, the uses of the Transit engine specifically, the general purpose of secrets engines, the use of response wrapping, the value of short-lived dynamic secrets, and enabling and reading secrets through the API, CLI, and UI.
6. Encryption as a Service — encrypting and decrypting data through Transit, and rotating the encryption key.
7. Vault architecture fundamentals — how Vault encrypts data at rest, how sealing and unsealing works, and Vault's environment variables.
8. Vault deployment architecture — cluster strategy for self-managed vs. HashiCorp-managed clusters, the uses of different storage backends, Shamir secret sharing and unsealing, disaster-recovery and performance replication, and the practical differences between self-managed and HCP-managed Vault.
9. Access management architecture — the Vault Agent, and the Vault Secrets Operator.

Domain wording above is a close, study-oriented paraphrase of HashiCorp's own published objectives, not a verbatim quote — check the exact current sub-bullet text on HashiCorp's own exam content list before treating any single phrase as exam-verbatim.

What you actually need to know cold

☺ Like you're 10: Here's the real substance behind each domain — the facts your instincts need to reach for without looking anything up.

Authentication and identity (domain 1)

Every auth method answers the same question — "is this really who it claims to be" — with different proof depending on who's asking. The exam-relevant distinction is human vs. system authentication: Userpass, LDAP, and OIDC/SSO prove a person is who they say they are; AppRole, the Kubernetes auth method, and the cloud auth methods (AWS, Azure, GCP) prove a machine or workload is who it says it is, usually by trusting a platform-native identity rather than a standing shared secret. Every successful login — regardless of method — ends in a token, and Vault's identity subsystem can link multiple auth-method aliases (a Kubernetes service account, an LDAP username) back to one canonical entity, which is what makes group-based policy assignment possible across more than one login path. Full method-by-method detail, including the AppRole RoleID/SecretID split, lives on the Vault tool page's auth methods section.

Policies: path and capabilities (domain 2)

A policy is an HCL document naming paths and the capabilities allowed on each: create, read, update, delete, list, plus the special sudo and explicit deny. Vault is deny-by-default — a path with no matching statement is unreachable, not silently open — which is the exam's favorite trap to test in reverse: give a policy that looks permissive and ask what it actually denies.

path "secret/data/checkout/prod/*" {
  capabilities = ["read"]
}

path "database/creds/checkout-readonly" {
  capabilities = ["read"]        # mints a fresh, TTL-bound DB user on every read
}

# everything else: denied, by omission — deny-by-default, not deny-by-exception

One fact worth memorizing outright because it's a classic wrong-answer trap: KV version 2's real HTTP paths nest under a data/ segment that the vault kv CLI adds for you automatically. A hand-written policy for secret/checkout/* silently matches nothing against a KV v2 mount — it needs to read secret/data/checkout/*.

Tokens: service vs. batch, accessors, TTL, orphans (domain 3)

Every authenticated request carries a token, and domain 3 tests the vocabulary around it precisely.

$ vault token create -policy=checkout-prod-deploy -ttl=1h
$ vault token create -policy=checkout-prod-deploy -orphan          # no parent, survives its creator's revocation
$ vault token create -policy=checkout-ci -type=batch -ttl=15m      # batch: cheap, non-renewable, no children
$ vault token lookup -accessor                           # inspect without touching the secret value
$ vault token revoke -accessor                           # revoke the same way
$ vault token revoke                                        # revokes this token AND its whole child tree

Leases and secrets engines: static vs. dynamic (domains 4–5)

Every dynamic secret Vault hands out is attached to a lease — an ID that tracks how long that specific secret is valid and who's responsible for renewing or revoking it. The two operations domain 4 tests are exactly the two verbs: vault lease renew extends a lease up to its role's max_ttl, and vault lease revoke — with an optional -prefix — ends it (and everything under that prefix) immediately.

Domain 5's central distinction is static vs. dynamic secrets. A static secret (KV v2) is a value a human or system wrote in; Vault stores and versions it but doesn't generate it. A dynamic secret (the database, PKI, and cloud engines) is generated by Vault on the spot, scoped to a role, and bound to a lease — which is what makes "the value of short-lived, dynamic secrets" its own tested sub-objective: a credential that's minted per request and expires on its own is a credential an attacker has a much smaller window to make use of, even if it leaks. Response wrapping is the exam's answer to the bootstrap problem every auth method eventually hits — how do you hand someone their very first credential safely — by returning a single-use wrapping token that fails loudly if anyone other than the intended recipient tries to unwrap it first.

$ vault read database/creds/checkout-readonly     # dynamic: a brand-new DB user, own lease, own TTL
$ vault lease renew database/creds/checkout-readonly/2f3a9c...
$ vault lease revoke -prefix database/creds/checkout-readonly     # kill every lease under this role, now

Full engine-by-engine depth — KV v2, the database engine, PKI, and the cloud engines, each with working examples — lives on the Vault tool page's secret engines section; this exam expects you to recognize the pattern across all of them, not just recite one.

Transit: encryption as a service (domain 6)

Transit is the one engine that stores nothing of the caller's: an application sends plaintext, Vault encrypts it with a named key it manages entirely server-side, and hands back ciphertext — the key material never leaves Vault in either direction. Domain 6 is narrow and mechanical: encrypt, decrypt, and rotate.

$ vault write -f transit/keys/checkout-pii
$ vault write transit/encrypt/checkout-pii plaintext=$(base64 <<< "4111-1111-1111-1111")
$ vault write transit/decrypt/checkout-pii ciphertext="vault:v1:8SDd3WHDOjf7..."
$ vault write transit/rotate/checkout-pii     # new writes use the new key version; old versions still decrypt

The fact worth holding onto: rotating a Transit key does not invalidate data encrypted under the previous version — old ciphertext keeps decrypting against the version it was written with, and a min_decryption_version setting is what actually retires an old version once nothing needs it anymore.

Architecture, sealing, and deployment (domains 7–8)

Domain 7 is the barrier, in order: every value Vault writes is encrypted with an AES-256-GCM encryption key, which is itself encrypted at rest by a root key. vault operator init generates the root key once and splits it via Shamir's Secret Sharing into N shares, any threshold of which reconstruct it — never written to disk, only ever held in memory on an unsealed node. A restarted server comes up sealed until vault operator unseal is run once per share up to the threshold, or until auto-unseal — an external KMS (AWS KMS, Azure Key Vault, GCP KMS, or another Vault's Transit engine) — unwraps it automatically. Domain 7 also expects the core environment variables cold: VAULT_ADDR (the server URL every CLI command needs), VAULT_TOKEN (the credential the CLI sends), VAULT_CACERT / VAULT_SKIP_VERIFY (TLS trust, and the flag that dangerously disables checking it), and VAULT_NAMESPACE (Vault Enterprise's tenant-scoping header).

Domain 8 zooms out to the cluster: storage backends — Raft integrated storage (the default and recommended choice since Vault 1.4) versus Consul (legitimate if you're already running Consul for service discovery); replication — Performance Replication for read scaling across regions and Disaster Recovery Replication for a warm standby cluster, both Enterprise features; and the practical line between self-managed Vault (you run the cluster, you hold the unseal keys) and HCP Vault Dedicated (HashiCorp runs the cluster for you, on your cloud account, unsealing handled for you). Full depth on the barrier and the storage-backend tradeoffs, with a diagram of the exact reconstruct-decrypt-decrypt chain, lives on the Vault tool page.

Vault Agent and the Vault Secrets Operator (domain 9)

The newest domain covers two tools that sit at Vault's edge rather than inside it. Vault Agent is a client-side daemon (or sidecar) that handles authentication on an application's behalf — it logs in using an auto-auth method, caches and renews the resulting token, and can template secrets straight to a file on disk, so the application itself never has to speak Vault's API or hold a Vault token at all. The Vault Secrets Operator (VSO) does the equivalent job natively for Kubernetes: it's a controller that watches custom resources like VaultStaticSecret and VaultDynamicSecret, and syncs whatever they name into ordinary native Kubernetes Secret objects — so a Pod mounts a normal Secret and never talks to Vault directly, while VSO keeps that Secret's contents current as the underlying value rotates or a dynamic lease renews. The two solve the same integration problem — "give an app secrets without teaching it to be a Vault client" — for two different runtimes: Agent for a VM or a non-Kubernetes host, VSO for anything already running on a cluster.

How to prepare using this site

☺ Like you're 10: One page here covers almost the entire exam — the map below points you at the exact section for each domain.

A workable shape for most candidates: start with Secrets & Credential Management to lock in the vendor-neutral model, spend most of the remaining time inside the Vault tool page actually typing every CLI example rather than reading it, run Timmy's workshop above at least twice, and finish with the nine-domain list further up this page recited from memory, out loud, without looking anything up.

Exam logistics — verify these yourself before you register

☺ Like you're 10: Prices, proctoring vendors, and question counts drift over time — read HashiCorp's own page the week you plan to book, not a page like this one from months ago.

Where it sits, and who should take it

☺ Like you're 10: It's the narrow, fast half of a two-certification HashiCorp résumé — provisioning is the other half, and together they cover most of what the toolchain actually does.

The Vault Associate is, structurally, the Terraform Associate's twin: same vendor, same knowledge-based format, same one-hour closed-book exam, same absence of a live terminal. The two are also the natural pairing for anyone building a HashiCorp-specific résumé, because they cover the two halves of the toolchain that show up together constantly in this course — infrastructure as code provisions the systems, and secrets management is what those systems need at runtime to actually talk to anything. Holding both signals you can operate the provisioning tool and the secrets tool most likely to sit next to it in a real HashiCorp-shop stack.

Take it if: you configure Vault, write or review its policies, or build services that authenticate against it, and want that knowledge externally checked; or you already hold the Terraform Associate and want the matching secrets-management half of a HashiCorp-stack résumé. Consider skipping it if: your organization runs a cloud-native secrets manager exclusively (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) and has no near-term Vault adoption plan — study the vendor-neutral concepts instead, which transfer regardless of which product you end up operating; or your actual gap is provisioning rather than secrets, in which case Terraform Associate or the performance-based CKA is the better use of your study time first.