Home / cybersecurity / HashiCorp Certified: Vault Associate (003) / Cheat Sheet
HashiCorp Certified: Vault Associate (003)

Vault Associate Cheat Sheet

Vault Associate Tests Tokens, Paths and Lease Lifecycles — Not Vault Server Tuning

Vault Associate (003) is for engineers who consume and operate Vault day to day. Answers turn on exact path syntax, token properties and which object holds which key, so precision beats broad security theory.

Check Your Readiness →
Among the harder certs
Avg: Not published by HashiCorp
Pass: 750 / 1000
Most candidates understand HashiCorp Certified: Vault Associate (003) concepts — and still fail. This exam tests how you apply knowledge under pressure.

Vault Associate (003) Content List

Tested against Vault 1.19 per HashiCorp's certification page. Items are short multiple choice, often showing a vault CLI command, an HCL policy or a curl call and asking what it does or what is missing. HashiCorp publishes no domain weights or passing score.

  1. 01
    Authentication methods (weight not published) — human vs. machine methods, AppRole, Kubernetes, cloud IAM, entities, aliases, groups
  2. 02
    Vault policies (weight not published) — deny by default, * vs. +, most specific match, KV v2 data/ and metadata/, sudo
  3. 03
    Vault tokens (weight not published) — service vs. batch, root lifecycle, accessors, TTL, periodic and orphan tokens
  4. 04
    Vault leases (weight not published) — lease IDs, renew increments, max TTL, revoke and revoke -prefix
  5. 05
    Secrets engines (weight not published) — static vs. dynamic, KV v2, database, PKI, cubbyhole, response wrapping
  6. 06
    Encryption as a service (weight not published) — transit encrypt/decrypt, key versions, rewrap, min_decryption_version
  7. 07
    Architecture fundamentals (weight not published) — barrier, keyring, root key, Shamir vs. auto-unseal, VAULT_* variables
  8. 08
    Deployment architecture (weight not published) — integrated storage, quorum, DR vs. performance replication, HCP Vault Dedicated
  9. 09
    Access management architecture (weight not published) — Vault Agent auto-auth, sinks, templates, Vault Secrets Operator

Wrong instinct vs correct approach

Microservices on EC2 must authenticate without any long-lived credential stored on the instances
✕ Wrong instinct

Use AppRole and bake the SecretID into the AMI

✓ Correct approach

Use the AWS auth method: Vault verifies the instance's IAM identity, so nothing static is distributed. AppRole is for automation with no platform identity, and its SecretID should be short-lived and delivered by a trusted party.

Every credential issued by database/creds/orders may be exposed; other roles must keep working
✕ Wrong instinct

Loop through each lease ID and revoke them one by one

✓ Correct approach

Run vault lease revoke -prefix database/creds/orders, which needs sudo on that endpoint. Vault revokes every lease under the role and the engine drops the matching database users. Avoid -force unless the database is unreachable.

After rotating transit key payments to v3, rows still hold vault:v1: and vault:v2: ciphertext
✕ Wrong instinct

Decrypt every row in the app and encrypt it again

✓ Correct approach

Call transit rewrap on each ciphertext: Vault re-encrypts with the latest version and never returns plaintext. Only after all rows show vault:v3: should you raise min_decryption_version, then optionally trim.

A deploy tool hands a SecretID to a new instance but must never read it itself
✕ Wrong instinct

Store the SecretID in a shared KV path for the instance

✓ Correct approach

Use response wrapping: the tool passes only a single-use wrapping token. The instance unwraps it once and checks the creation path; a failed unwrap signals someone else retrieved it first.

Know these cold

  • ▸ Explicit deny beats any allow; otherwise the most specific matching path rule applies
  • ▸ * glob works only at the path end; + matches exactly one segment anywhere
  • ▸ read never implies list; sudo is added to a normal capability for root-protected endpoints
  • ▸ Policy edits apply to existing tokens immediately; no reissue needed
  • ▸ Revoking a parent token revokes its children and their leases unless created with -orphan
  • ▸ Periodic token has no max TTL; orphan only removes the parent link, not the TTL
  • ▸ Default TTL and max TTL are both 768 hours; root tokens have no TTL
  • ▸ Shamir init defaults — key shares, threshold 3; rekey changes shares, rotate changes the barrier key
  • ▸ Raft clusters — or 5 nodes; every node starts sealed after restart
  • ▸ Agent sink holds the token; templates render secrets; VSO syncs into native Kubernetes Secrets

Can you answer these without checking your notes?

In this scenario: "Microservices on EC2 must authenticate without any long-lived credential stored on the instances" — what should you do first?
Use the AWS auth method: Vault verifies the instance's IAM identity, so nothing static is distributed. AppRole is for automation with no platform identity, and its SecretID should be short-lived and delivered by a trusted party.
In this scenario: "Every credential issued by database/creds/orders may be exposed; other roles must keep working" — what should you do first?
Run vault lease revoke -prefix database/creds/orders, which needs sudo on that endpoint. Vault revokes every lease under the role and the engine drops the matching database users. Avoid -force unless the database is unreachable.
In this scenario: "After rotating transit key payments to v3, rows still hold vault:v1: and vault:v2: ciphertext" — what should you do first?
Call transit rewrap on each ciphertext: Vault re-encrypts with the latest version and never returns plaintext. Only after all rows show vault:v3: should you raise min_decryption_version, then optionally trim.

Common Exam Mistakes — What candidates get wrong

Writing KV v2 policies against the CLI path instead of data/ and metadata/

vault kv get secret/team-a/x hits secret/data/team-a/x under the hood; listing uses secret/metadata/. A policy on secret/team-a/* matches neither. Direct API calls must include data/ too, because only the CLI adds it automatically.

Expecting batch tokens to renew, carry an accessor or create children

Batch tokens (hvb.) are unpersisted with a fixed lifetime, ideal for high-volume short jobs and usable on performance secondaries. Service tokens (hvs.) are the default and support renewal, accessors and child tokens.

Treating the renewal increment as time added to the remaining TTL

vault lease renew -increment requests a TTL counted from now, and the result is capped by the max TTL from system, mount or role. Once max TTL is reached, the client must fetch a new dynamic secret.

Believing unseal keys or recovery keys encrypt or unlock the data

The keyring's encryption key encrypts data at the barrier; the root key protects the keyring; Shamir shares or auto-unseal protect the root key. Recovery keys authorise generate-root and rekey but can never unseal Vault.

Choosing DR replication to cut read latency for distant applications

A DR secondary replicates tokens and leases but serves no client requests until promoted. Performance secondaries serve local reads with their own tokens and leases, which are not replicated, and forward writes to the primary.

Resources to help you pass HashiCorp Vault Associate on your first attempt

Vault Associate rewards exact token, policy and lease mechanics. Measure your precision now.