HashiCorp Vault Associate (003) Practice Exam

What the HashiCorp Vault Associate (003) exam covers

• Vault Architecture and Fundamentals207 questions
• Authentication Methods176 questions
• Policies130 questions
• Tokens and Leases135 questions
• Secrets Engines139 questions
• Encryption as a Service102 questions

Free 003 practice test questions

A sample of 10 questions with answers and explanations. A free account includes a fixed set of 20 practice questions for this exam, retryable anytime. Paid access unlocks the full 889-question bank.

1. Question 1Vault Architecture and Fundamentals

   In secrets management, what does the term 'secret sprawl' describe?

   • AEncrypting secrets with layered ciphers for defense in depth
   • BRotating one master key across every environment on a schedule
   • CCredentials scattered across code, configs, CI logs, and wikisCorrect
   • DOne secret safely shared among many trusted microservices
   ✓ Correct answer: C

   Secret sprawl describes credentials leaking into source code, .env files, CI/CD logs, chat messages, and wikis instead of living in one governed system. Because no owner tracks every copy, sprawled credentials are rarely rotated, hard to revoke completely, and nearly impossible to audit after an incident, since no one can enumerate every place a password was pasted. Vault fixes this by acting as a single source of truth: apps authenticate and read secrets on demand, so each credential exists in one controlled location with a policy and audit trail, rather than dozens of untracked plaintext copies scattered everywhere.

   Why the other options are wrong

   • ALayering multiple ciphers for defense in depth is an encryption technique; it says nothing about credentials being scattered and untracked across systems.
   • BRotating a single master key on schedule is a mitigation practice, not the underlying problem of credentials duplicated everywhere with no owner.
   • DSafely sharing one secret among trusted services is the opposite of sprawl, which describes uncontrolled, duplicated, unrotated copies, not controlled sharing.
2. Question 2Vault Architecture and Fundamentals

   What does the 'HA Mode' field in the output of vault status indicate?

   • AWhether the node is currently active or standbyCorrect
   • BThe number of unseal key shares configured
   • CThe version of the Raft protocol in use
   • DThe percentage of storage disk currently used
   ✓ Correct answer: A

   When Vault is running with high availability enabled, `vault status` includes an `HA Mode` field reporting `active` or `standby` for the node being queried, along with related fields such as `HA Cluster` and, on a standby, the active node's address - letting an operator quickly confirm a specific node's current role without having to query a separate API endpoint or dig through logs. On a backend that does not support HA, such as the plain file backend, these HA-related fields are omitted from the output entirely rather than showing a meaningless default value.

   Why the other options are wrong

   • BConfigured unseal key share counts appear in the Seal/unseal-related fields of the output, not in `HA Mode`.
   • C`vault status` does not report a Raft protocol version number anywhere in its output, including the `HA Mode` field.
   • DDisk usage percentage is not part of `vault status` output at all; it belongs to OS-level monitoring instead.
3. Question 3Authentication Methods

   Which command creates an AppRole role api with the api-policy policy and a 10-minute SecretID TTL?

   • Avault write approle/role/api token_policies=api-policy secret_id_ttl=10m
   • Bvault write auth/approle/role/api token_policies=api-policy secret_id_ttl=10mCorrect
   • Cvault policy write auth/approle/role/api secret_id_ttl=10m
   • Dvault write auth/approle/api token_policies=api-policy secret_id_ttl=10m
   ✓ Correct answer: B

   A new AppRole role is created by writing to its full endpoint: vault write auth/approle/role/api token_policies=api-policy secret_id_ttl=10m. The path must include both the auth/ mount prefix, since AppRole is an auth method and not a secrets engine, and the /role/ path segment that separates individual role definitions from the mount's other endpoints. Any field left unspecified simply falls back to its documented default, for example bind_secret_id still defaults to true even though it was not explicitly set here. Omitting the auth/ prefix, the /role/ segment, or using vault policy write instead all target the wrong object entirely.

   Why the other options are wrong

   • AThis option omits the required auth/ mount prefix; because AppRole is mounted under auth/, the correct path is auth/approle/role/api.
   • Cvault policy write creates or updates ACL policy documents themselves; it does not create or configure an AppRole role.
   • DThe role endpoint requires the /role/ path segment between the mount and the role name, so it must read auth/approle/role/api.
4. Question 4Authentication MethodsSelect all that apply

   Which TWO are direct benefits of Vault's identity system? (Choose TWO)

   • AUnifies a user's policies across multiple auth methodsCorrect
   • BEncrypts data without storing it (crypto as a service)
   • CProvides Shamir-based unseal key sharing
   • DLets you manage a person or team once, not per auth mountCorrect
   • EGenerates dynamic database credentials on demand
   ✓ Correct answer: A, D

   Vault's identity system links every login alias (LDAP, AppRole, userpass, and so on) that belongs to the same real user or service to one entity, so policies unify across auth methods no matter which mount was used to log in. It also lets administrators manage a person's or team's access once, at the entity or group level, instead of re-configuring the same grants separately on every auth mount they might use. Both are administrative and access-unification benefits, distinct from encryption, unsealing, or secret generation features that live in entirely different Vault subsystems.

   Why the other options are wrong

   • BEncrypting data without storing it is the Transit (encryption as a service) engine, not identity.
   • CShamir unseal key sharing is part of Vault's seal/unseal process, unrelated to identity.
   • EDynamic database credentials come from the database secrets engine, not the identity system.
5. Question 5Policies

   A token holds two policies. Policy kv-read: `path "secret/data/*" { capabilities = ["read","list"] }`. Policy prod-deny: `path "secret/data/prod/*" { capabilities = ["deny"] }`. Can the token read secret/data/prod/db?

   • ANo - an explicit deny overrides all granted capabilities, regardless of policy orderCorrect
   • BYes - the broader read grant in kv-read takes precedence over the deny in prod-deny
   • CYes - the deny clause only removes list access, so read still applies
   • DNo - but only because prod-deny happens to be evaluated after kv-read
   ✓ Correct answer: A

   Vault evaluates a request against the highest-priority matching path across all of a token's policies, and on that matched rule the deny capability takes precedence over any grant, whatever order the policies were listed in at token creation. So the deny on secret/data/prod/*, the more specific and therefore higher-priority pattern, blocks the read even though the other policy grants read and list on the broader secret/data/*. That precedence is exactly what makes deny useful for carving a protected subtree out of an otherwise broad grant.

   Why the other options are wrong

   • BThe deny on the more specific secret/data/prod/* is the matching rule for this path, so the broader read grant in kv-read does not apply to it.
   • Cdeny blocks every capability on the matched path rather than selectively removing list, so the read is refused along with everything else.
   • DThe order in which prod-deny and kv-read are attached or evaluated has no bearing; a matching deny wins whichever policy is processed first.
6. Question 6Tokens and Leases

   Which values are valid for the `-mode` flag of `vault token revoke`?

   • A`orphan` and `self`
   • B`tree` and `path`
   • C`orphan` and `path`Correct
   • D`child` and `accessor`
   ✓ Correct answer: C

   `vault token revoke` recognizes exactly two `-mode` values: `orphan`, which revokes only the named token while detaching its children into orphans, and `path`, which treats the argument as an auth mount path prefix and revokes every token issued under it. Leaving `-mode` unset performs Vault's default behavior of recursively revoking the entire subtree. Self-targeting and accessor-targeting are handled by their own dedicated flags, `-self` and `-accessor`, and are not values you pass to `-mode` at all - so options combining `self`, `tree`, `child`, or `accessor` with `-mode` describe flags and modes that simply do not exist in the CLI.

   Why the other options are wrong

   • A`self` is its own separate `-self` flag, never a value accepted by `-mode`.
   • B`tree` is not a recognized mode name - default (unset) behavior already performs full tree revocation without needing this value.
   • DNeither `child` nor `accessor` is a valid `-mode` value; accessor targeting instead uses the standalone `-accessor` flag.
7. Question 7Secrets Engines

   Why is rotating the root credential (rotate-root) after configuring the database engine recommended?

   • AIt converts the connection so Vault uses dynamic credentials for its own admin access
   • BIt is required before any database role is able to issue dynamic credentials
   • CIt invalidates the operator's initial password so no human keeps admin accessCorrect
   • DIt backs up the current admin password to Vault's audit log for later recovery
   ✓ Correct answer: C

   When you first configure database/config/<name>, you must supply the admin username and password directly in the connection fields, so at least one operator has necessarily seen that password. Running vault write database/rotate-root/<connection> has Vault generate a new random password and set it on the database account itself, then store only that new value internally, so no human ever learns it afterward. The admin account and its username stay exactly the same; only the password material becomes Vault-exclusive. This step does not touch how Vault issues dynamic credentials to roles, which already works without any prior rotation.

   Why the other options are wrong

   • Arotate-root still uses a static admin credential for Vault; it does not make Vault's own access dynamic.
   • BRoles can issue credentials without rotating root; rotate-root is a hardening step, not a prerequisite.
   • DAudit logs hash sensitive strings by default and are not a recovery store, so rotate-root backs nothing up there.
8. Question 8Encryption as a ServiceSelect all that apply

   Which TWO responsibilities belong to the calling application when using transit? (Choose TWO)

   • ABase64-encoding plaintext before calling transit/encryptCorrect
   • BGenerating and storing the raw encryption key locally
   • CRotating the underlying key material by hand on each node
   • DStoring the returned vault:v1:... ciphertextCorrect
   ✓ Correct answer: A, D

   Because transit treats all data as opaque and persists nothing itself, the calling application carries two specific responsibilities: base64-encoding the plaintext before sending it to transit/encrypt so it survives the JSON transport intact, and durably storing the vault:v1:... ciphertext that comes back, since Vault does not keep a copy anywhere. Everything about the actual key material is Vault's job, not the app's: Vault normally generates, and always stores, the raw key for a named key, and rotation is performed inside Vault through the transit/keys/<name>/rotate endpoint. There is no manual, per-node process where an application generates its own key or hand-rotates key material on individual servers.

   Why the other options are wrong

   • BGenerating and holding the raw key locally is not the application's role; Vault normally generates the named key and always stores its material itself.
   • CRotation happens inside Vault via the transit/keys/<name>/rotate endpoint; it is not a manual task performed by the application on each node.
9. Question 9Vault Architecture and Fundamentals

   Which HTTP header directs an API request to the "engineering" namespace?

   • AX-Vault-Namespace, carrying the namespace pathCorrect
   • BX-Vault-Token, with the namespace prefixed to the token
   • CAuthorization, using the namespace as the bearer scheme
   • DX-Vault-Request, set to the name of the target namespace
   ✓ Correct answer: A

   Either form works and they are equivalent: send X-Vault-Namespace: engineering with a normal path, or leave the header off and request /v1/engineering/secret/data/... directly. The CLI does the same thing through the VAULT_NAMESPACE environment variable or the -namespace flag.

   Why the other options are wrong

   • BX-Vault-Token carries the client token; the target namespace is selected by X-Vault-Namespace or the request path, not by altering the token value.
   • CVault does not use the Authorization header for namespace selection.
   • DX-Vault-Request is a marker header that a Vault Proxy configured with require_request_header expects; it does not name a namespace.
10. Question 10Authentication Methods

    The github auth method is configured for the organization example-org, which enforces SAML single sign-on. The team Platform Engineering is mapped with the command below. A member of that team logs in with a new personal access token that has the read:org scope. The login succeeds, but the resulting token carries only the default policy. ```bash vault write auth/github/map/teams/platform-engineering value=platform ``` What is the most likely cause?

    • ATeam mappings must use the display name, so the entry needs to be written as Platform Engineering
    • BTeam policies are attached only from a user's second login, after Vault has recorded the team
    • CThe mapping needs the organization prefix, so it has to be written as example-org/platform-engineering
    • DThe access token was never authorized for SSO, so GitHub gave Vault no team membership for itCorrect
    ✓ Correct answer: D

    Two facts have to be held together. First, team mappings must use the slugified team name, so platform-engineering is the correct form for a team displayed as Platform Engineering, and the mapping itself is fine. Second, the GitHub method's documentation warns that when the team belongs to an organization with SSO enabled, the user must authorize the personal access token; otherwise the token provides no identity information and the token Vault issues is assigned only the default policy. That matches the symptom exactly: the login succeeds, because the token is valid and carries read:org, yet no team is resolved, so no mapped policy is added. The fix is on the user's side: authorize the token for the organization's SSO in GitHub and log in again, with nothing changed in Vault. The trap is editing a mapping that is already correct, either back to the display name or by adding the organization, which is configured once on the mount and is not part of the team path. Vault also resolves teams afresh on every login rather than learning them over time.

    Why the other options are wrong

    • AThe documentation says team names must be slugified, so platform-engineering is already the correct key for this team.
    • BTeams are resolved from GitHub at each login; there is no learning step that delays the mapping to a later login.
    • CThe organization is set once in auth/github/config; team mappings are written under map/teams by team slug alone.

Who this HashiCorp Vault Associate (003) practice exam is for

This practice set is for anyone preparing for the HashiCorp Vault Associate (003) exam at the intermediate level - from first-time candidates building a foundation to experienced HashiCorp practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this HashiCorp Vault Associate (003) practice exam

1. Start with the free sample questions above to gauge your current baseline.
2. Read the full explanation on every question, including why each wrong option is wrong.
3. Track your weak domains and focus your study where you are losing the most marks.
4. Once you are scoring consistently well, take a timed, full-length mock exam.
5. Use your readiness score to decide when you are ready to book the real HashiCorp Vault Associate (003) exam.

Related HashiCorp resources

• HashiCorp Vault Associate (003) study guideKey concepts
• HashiCorp practice examsAll HashiCorp
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• How these questions are written and reviewedMethodology
• Report a problem with a questionCorrections
• HashiCorp Vault Operations Advanced practice examRelated
• HashiCorp Terraform Associate (004) practice examRelated
• HashiCorp Terraform Authoring and Operations Advanced practice examRelated

HashiCorp Vault Associate (003) practice exam FAQ