HashiCorp Vault Associate (003) Practice Exam

What the HashiCorp Vault Associate (003) exam covers

• Vault Architecture and Fundamentals175 questions
• Authentication Methods155 questions
• Policies123 questions
• Tokens and Leases126 questions
• Secrets Engines133 questions
• Encryption as a Service95 questions

Free 003 practice test questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 807.

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 FundamentalsSelect all that apply

   Which TWO of the following are valid auto-unseal seal types in Vault? (Choose TWO)

   • AawskmsCorrect
   • BgcpckmsCorrect
   • Cshamirkms
   • Dlocalseal
   • Eraftseal
   ✓ Correct answer: A, B

   Vault ships built-in auto-unseal seal types for the major cloud KMS providers - `awskms`, `azurekeyvault`, and `gcpckms` - plus `transit` (pointing at another Vault cluster's Transit engine) and `ocikms` for Oracle Cloud, each declared inside a `seal` stanza and used to wrap and unwrap the root key at startup. Shamir is the manual, default seal mechanism rather than a KMS integration, and Raft (Integrated Storage) is a storage backend for persisting data, not a seal type at all, so neither `shamirkms` nor `raftseal` names anything Vault actually recognizes.

   Why the other options are wrong

   • CNo `shamirkms` seal type exists; Shamir is Vault's built-in manual seal mechanism, not a cloud KMS integration.
   • D`localseal` is not a recognized Vault seal type name in any released version of the product.
   • ERaft is Integrated Storage's storage backend for persisting data, not a seal type; no `raftseal` type exists.
3. Question 3Vault Architecture and Fundamentals

   What ensures that data Vault persists to its storage backend cannot be read directly from that backend?

   • AThe cryptographic barrier encrypts all data before it is writtenCorrect
   • BThe storage backend is configured with filesystem permissions only
   • CVault stores secrets in plaintext but restricts the network port
   • DThe audit device redacts values before they reach storage
   ✓ Correct answer: A

   Every write Vault makes passes through its cryptographic barrier, which encrypts the data with a key derived from the unseal process before it is ever handed to the storage backend, so the backend, whether Raft, Consul, or a cloud database, only ever persists ciphertext and never sees plaintext secrets. The decryption key exists only in Vault's process memory while the server is unsealed, which is exactly why a compromised or stolen storage backend on its own reveals nothing usable. This is not achieved through filesystem permissions alone, which control access but do nothing to the data's format; Vault never stores secrets in plaintext at all regardless of network restrictions; and audit devices only log requests, playing no role in encrypting what is written to storage.

   Why the other options are wrong

   • BFilesystem permissions restrict who can read the storage files, but they do not encrypt the data itself; the barrier is what provides encryption.
   • CVault never persists secrets in plaintext under any configuration; restricting the network port does nothing to change how data is stored.
   • DAudit devices only log requests and responses; they play no role in encrypting or gating what Vault writes to its storage backend.
4. Question 4Authentication Methods

   In a jwt auth role, which parameter names the JWT claim used as the login's identity (the alias name)?

   • Abound_iam_principal_arn
   • Btoken_reviewer_jwt
   • Ckubernetes_host
   • Duser_claimCorrect
   ✓ Correct answer: D

   User_claim tells the jwt/oidc role which claim in the verified token - typically sub or email - becomes the login's alias name, the identifier Vault attaches to the entity. Roles also set bound_audiences to check the aud claim and can enforce bound_claims for extra restrictions, while groups_claim maps IdP group membership onto Vault identity groups. bound_iam_principal_arn is an aws iam auth role field for matching an assumed-role ARN, token_reviewer_jwt is the kubernetes method's own service-account token used to call the TokenReview API, and kubernetes_host is that method's cluster API endpoint setting - none apply to jwt/oidc.

   Why the other options are wrong

   • Abound_iam_principal_arn is an aws iam auth role parameter that matches the caller's assumed-role ARN, not a JWT claim mapping.
   • Btoken_reviewer_jwt is the kubernetes auth method's own service-account JWT used to call the TokenReview API, unrelated to alias naming.
   • Ckubernetes_host is the kubernetes method's cluster API server address configuration, not a claim-to-alias mapping parameter.
5. Question 5Policies

   What is the effect of `allowed_parameters` in an ACL path rule?

   • AIt restricts which request parameters a client may setCorrect
   • BIt lists which HTTP methods the path will accept
   • CIt sets the TTL applied to tokens using the path
   • DIt names child paths that are automatically granted
   ✓ Correct answer: A

   allowed_parameters is a fine-grained ACL control inside a path stanza that whitelists which request-body parameter keys (and optionally which specific values for those keys) a client may include when writing to that path; any parameter not on the list causes Vault to reject the request, while a bare * allows any parameter through. It works alongside denied_parameters, which blacklists specific keys and always takes precedence if the same key appears in both lists. Neither setting affects which HTTP methods a path accepts (that is governed by capabilities), nor does it touch token TTLs or automatically extend access to any child paths.

   Why the other options are wrong

   • BHTTP methods are governed by capabilities, not by allowed_parameters.
   • CParameter rules have nothing to do with token TTLs.
   • Dallowed_parameters controls request body keys, not path inheritance.
6. Question 6Policies

   A policy contains both rules below. What may the token do to secret/data/app/secret1? path "secret/data/app/*" { capabilities = ["read"] } path "secret/data/app/secret1" { capabilities = ["read", "update"] }

   • Aread only - the wildcard rule takes precedence over the exact match
   • Bnothing - the two conflicting rules cancel each other out entirely
   • Cread, update, and list - capabilities from all matching rules are unioned
   • Dread and update - the exact, most specific path match appliesCorrect
   ✓ Correct answer: D

   Because both rules here are ordinary grants (neither is a deny), Vault applies its specificity rule and selects the exact-path match over the wildcard: secret/data/app/secret1 matches its own dedicated rule granting read and update directly, so that rule governs the token's access to that path and the broader secret/data/app/* rule (granting only read) is not additionally consulted for it. Capabilities from a less-specific matching rule are not unioned on top of a more-specific one the way capabilities from separate policies at the same specificity would be, and two non-deny rules never simply cancel each other into no access.

   Why the other options are wrong

   • AAn exact-path match is more specific than a trailing wildcard, so the glob rule secret/data/app/* does not take precedence here.
   • BOverlapping non-deny rules of different specificity do not cancel into no access; Vault resolves the conflict by selecting the more specific rule.
   • CVault does not union capabilities across rules of differing specificity, nor does list appear in either rule at all; only the exact rule's read and update apply.
7. Question 7Tokens and LeasesSelect all that apply

   Which TWO operations can you perform using only a token's accessor? (Choose TWO)

   • AAuthenticate and read secrets as that token
   • BLook up the token's metadata and propertiesCorrect
   • CReveal the underlying token value (ID)
   • DRevoke the tokenCorrect
   • ERenew the token's lease using the accessor
   ✓ Correct answer: B, D

   An accessor supports exactly two management operations against Vault's token store: lookup, via `auth/token/lookup-accessor`, which returns the token's policies, TTL, and other metadata; and revoke, via `auth/token/revoke-accessor`, which revokes the token and its child tree. Both let an operator manage a token they cannot see the value of. By design an accessor can never be exchanged for the underlying token ID, cannot authenticate requests or read secrets, and has no renew-by-accessor operation - renewal always requires presenting the actual token value. This asymmetry is what makes it safe to record accessors in logs for later incident response.

   Why the other options are wrong

   • AAn accessor is not a credential - it cannot authenticate to Vault or be used to fetch secrets on the token's behalf.
   • CVault never reveals the underlying token ID through an accessor; that mapping is one-way by design.
   • EThere is no accessor-based renew operation; extending a lease or token's TTL requires the actual token value.
8. Question 8Secrets Engines

   A client requests `pki/issue/web`, but no engine is mounted at pki/. What does Vault return?

   • AA blank secret with a zero-length lease
   • BAn error stating there is no handler for the routeCorrect
   • CIt auto-enables the pki engine on first use
   • DThe request falls through to the default kv mount
   ✓ Correct answer: B

   Vault's router only dispatches a request when its path prefix matches an entry in the mount table, so pki/issue/web with no engine actually mounted at pki/ has nothing to match against and Vault returns an error - typically a 404 with a message like "no handler for route" - rather than any kind of placeholder response. Vault never fabricates an empty secret with a zero-length lease for an unmatched path, and it never auto-enables an engine just because a client requested a path under it; `vault secrets enable pki` must be run explicitly first by an operator with sufficient privileges. There is also no fall-through behavior where an unmatched request quietly gets handled by the default kv mount instead - unmatched paths simply fail outright with an error.

   Why the other options are wrong

   • AVault does not synthesize an empty secret with a zero-length lease for a path that matches no mount; unmatched requests return an error instead.
   • CEngines are never auto-enabled on first use; `vault secrets enable pki` must be run explicitly by an operator before pki/ paths will respond.
   • DThere is no fall-through to another engine, such as a default kv mount, for a request whose path matches no mount table entry.
9. Question 9Secrets Engines

   An orchestration system must deliver a database password to a newly provisioned application without the orchestrator itself ever being able to read the password. Which Vault feature directly addresses this secret-zero handoff problem?

   • AEnabling a second dedicated KV v2 mount to hold the application passwords
   • BGranting the orchestrator a root token to distribute secrets widely
   • CRaising the database secret's max_ttl so the password stays valid longer
   • DResponse wrapping, so the orchestrator relays a single-use token the app unwrapsCorrect
   ✓ Correct answer: D

   Response wrapping solves the secret-zero problem precisely because the orchestrator only ever handles a single-use wrapping token, not the plaintext database password itself: Vault creates the wrapping token and stores the password inside that token's cubbyhole, the orchestrator relays the token to the newly provisioned application, and the application, not the orchestrator, calls vault unwrap to retrieve the password. Because unwrapping is what actually reveals the secret and the orchestrator never performs that call, it structurally cannot read the password even if it wanted to, and any interception along the way is detectable since the token can only be unwrapped once. Standing up a second KV mount still requires the orchestrator to read the plaintext to relay it, a root token is the opposite of restricting access, and raising max_ttl changes only how long a secret stays valid, not who can read it.

   Why the other options are wrong

   • AA second KV mount still requires the orchestrator to read the plaintext password itself.
   • BA root token gives the orchestrator full read access - the opposite of hiding the secret.
   • CExtending max_ttl changes lifetime, not who can read the password; it does not hide it.
10. Question 10Encryption as a Service

    In envelope encryption, how does an application recover the plaintext data key it needs to decrypt stored data?

    • AIt calls transit/datakey/plaintext again to regenerate the same key
    • BIt sends the stored wrapped key to transit/decrypt/<key> to unwrap itCorrect
    • CIt reads the data key back from transit/keys/<key>
    • DIt rotates the key, which returns the previous data key
    ✓ Correct answer: B

    The stored wrapped key is nothing more than ordinary Transit ciphertext, produced by the same transit/datakey call that generated the plaintext key originally, so sending it to transit/decrypt/<key> returns the same plaintext data key that was used to encrypt the local data. The application uses that recovered key to decrypt its data and then discards the plaintext immediately, never persisting it. Calling transit/datakey/plaintext again would not help, because that endpoint always generates a brand-new random key on every invocation and has no way to reproduce a previously issued one from the same input.

    Why the other options are wrong

    • Atransit/datakey/plaintext produces a fresh, independently random key on every call; there is no input that makes it regenerate a specific prior key.
    • CReading transit/keys/<key> exposes configuration metadata such as versions and type, never raw key bytes usable for decrypting an application's local data.
    • DRotating the Transit key creates a new key version for future operations and returns no data key material at all, so it cannot recover anything.

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