HashiCorp Vault Operations Advanced Practice Exam

What the HashiCorp Vault Operations Advanced exam covers

• Create a Working Vault Server Configuration154 questions
• Monitor a Vault Environment124 questions
• Employ the Vault Security Model154 questions
• Build Fault-Tolerant Vault Environments174 questions
• Harden Vault for Production114 questions
• Scale Vault for Performance116 questions

Free HashiCorp Vault Operations Advanced practice test questions

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

1. Question 1Create a Working Vault Server Configuration

   You are writing a Vault server configuration file for a new Integrated Storage node. Which parameter inside the storage "raft" stanza is required and specifies the filesystem directory where Vault stores its Raft data?

   • Anode_id
   • BpathCorrect
   • Cretry_join
   • Dcluster_addr
   ✓ Correct answer: B

   The correct answer is path, the required parameter in the storage "raft" stanza that tells Vault the filesystem directory where it stores Raft data: the raft.db bolt file holding the log store and stable store, plus a snapshots subdirectory for periodic FSM snapshots. Vault will not start without it because Integrated Storage has nowhere to persist cluster state, log entries, or the encrypted keyring. This differs from node_id, which only labels this server's identity, and from retry_join, which controls how a node finds peers rather than where it writes data on disk.

   Why the other options are wrong

   • Anode_id is optional and only labels this server's identity within the cluster; it plays no role in choosing where Raft data is written to disk.
   • Cretry_join is an optional convenience setting for automatically discovering and joining peers at startup; it does not control the storage location.
   • Dcluster_addr is a top-level listener/networking setting used for Raft transport addressing between nodes, not a field inside the storage stanza itself.
2. Question 2Create a Working Vault Server Configuration

   A pkcs11 seal stanza's generate_key field is set to true and no matching key currently exists in the HSM under the configured key_label. What does Vault do?

   • AVault creates the wrapping key inside the HSM automatically during initializationCorrect
   • BVault falls back to Shamir keys for that unseal attempt
   • CVault refuses to start until an operator manually creates the key
   • DVault reads the key from the local filesystem instead
   ✓ Correct answer: A

   Option A is correct: with generate_key set to true, if no key matching the configured key_label already exists in the HSM, Vault creates the wrapping key inside the HSM itself as part of initialization, sparing the operator from having to pre-provision that key through separate vendor-specific HSM tooling before Vault ever starts. This is a convenience specifically for first-time setup; Vault does not fall back to Shamir keys, refuse to start pending manual key creation, or read a wrapping key from the local filesystem in this scenario, since the entire purpose of the pkcs11 seal is to keep the wrapping key generated and held inside the hardware boundary, never outside it.

   Why the other options are wrong

   • BA missing HSM key with generate_key enabled triggers automatic key creation inside the HSM, not a fallback to Shamir unsealing.
   • Cgenerate_key exists precisely to avoid requiring a manually pre-created key, so Vault does not refuse to start in this case.
   • DThe pkcs11 seal always reads and writes its wrapping key inside the HSM itself, never from the local filesystem.
3. Question 3Monitor a Vault EnvironmentSelect all that apply

   Which two statements correctly describe how Vault audit devices HMAC sensitive data? (Choose TWO)

   • AEach audit device maintains its own salt, so hashed values differ between devices for the same input.Correct
   • BA keyed hash is used so that values written to the log are not directly reversible to plaintext.Correct
   • CThe same salt is reused across every audit device to enable cross-device correlation.
   • DOnly response payloads are hashed; request payload fields are always logged in plaintext.
   • EHMAC hashing can be permanently disabled per device using the mode parameter.
   ✓ Correct answer: A, B

   A and B are correct because they describe the two core mechanics underpinning Vault's audit HMAC design: each audit device is provisioned with its own independent salt, so identical input values hash differently across different devices, and the hash function itself is a keyed, one-way HMAC, meaning the resulting digest can never be reversed back into the original plaintext value no matter who reads the log. Together these properties let audit logs remain useful for confirming that operations occurred and correlating repeated values within one device's own entries, while guaranteeing the logs never function as a decryptable copy of the secrets that passed through Vault.

   Why the other options are wrong

   • CSalts are per-device by design, which is exactly why cross-device correlation of the same value is not possible; there is no shared salt.
   • DBoth request and response payload fields are HMAC'd by default; hashing is not restricted to one phase or the other.
   • Emode is a file-audit-device parameter controlling filesystem permission bits; it has no relationship to disabling HMAC hashing.
4. Question 4Monitor a Vault Environment

   In a Disaster Recovery replication setup, which /v1/sys/health status code specifically identifies a DR secondary cluster's node that is acting as the active node within that secondary?

   • A472Correct
   • B473
   • C429
   • D200
   ✓ Correct answer: A

   Correct because a DR secondary exists purely to receive replicated data and stand ready for a failover, it cannot serve normal client reads or writes the way a primary's active node or a standalone active node can, so Vault reports 472 for that node's own local active role rather than the plain 200 an active node would otherwise get. This distinct code lets monitoring and load balancers avoid mistakenly routing production traffic to a DR secondary. 473 instead marks a performance standby within performance replication, 429 marks a plain HA standby unrelated to DR, and 200 is reserved specifically for an active node that can actually serve normal traffic.

   Why the other options are wrong

   • B473 identifies a performance standby node within performance replication, an entirely different replication role from a DR secondary's active node.
   • C429 is the default code for a plain HA standby node, unrelated to Disaster Recovery secondary status.
   • D200 is reserved for a node that can actually serve normal client traffic, which a DR secondary's local active node cannot do.
5. Question 5Employ the Vault Security Model

   Why would an operator deliberately create a monitoring agent's token as an orphan rather than a normal child token?

   • ASo the agent's token keeps working even if the token that provisioned it is later revokedCorrect
   • BSo the agent's token automatically gains root-equivalent policies regardless of what its role grants
   • CSo the agent's token is exempt from the mount's max TTL enforcement entirely
   • DSo the agent's token can bypass the audit logging requirements applied to other tokens
   ✓ Correct answer: A

   Answer A is correct because an orphan token has no parent recorded in Vault's hierarchy, so revoking the token that originally provisioned the agent, commonly an administrator's own session token used during setup, has no cascading effect whatsoever on the agent's independent, still-valid token. This is the standard reason long-running services are deliberately provisioned with orphan tokens: their credentials should depend only on their own explicit TTL and revocation, not on the lifecycle of whatever created them. Orphan status has no relationship to which policies the token is granted, whether it is subject to the mount's max TTL, or whether its requests are captured in audit logs, all of which apply exactly the same as for any non-orphan token.

   Why the other options are wrong

   • BOrphan status has nothing to do with policy grants; the agent's token receives only whatever policies its role or creation request actually specifies.
   • COrphan tokens remain bound by the same mount or role max TTL enforcement as any other token; orphan status does not exempt them from it.
   • DAudit logging captures requests from all tokens uniformly regardless of parentage; orphan status provides no exemption from audit capture.
6. Question 6Employ the Vault Security Model

   During a login MFA flow, a user completes primary authentication successfully but the login response indicates an additional factor is required before a token is issued. What must the client do to finish authenticating?

   • ASubmit the returned MFA request ID along with the required passcode to sys/mfa/validate to complete the login and obtain the tokenCorrect
   • BRetry the exact same primary login call a second time, since Vault issues the token automatically on the second attempt
   • CCall sys/wrapping/unwrap using the login response as the wrapping token
   • DWait for the auth method's TTL to elapse, after which the token is issued automatically without further input
   ✓ Correct answer: A

   Submitting the returned MFA request ID together with the required passcode to sys/mfa/validate is correct because a pending MFA login response includes an mfa_requirement carrying a request ID that identifies that specific login attempt, and only after the client successfully submits that ID plus the factor response to sys/mfa/validate does Vault actually issue the final token. Simply repeating the identical primary login call a second time does not satisfy the additional-factor requirement, Vault does not auto-issue a token on a retried attempt. The pending MFA response is not a wrapping token at all, so calling sys/wrapping/unwrap against it is unrelated and would not complete an MFA challenge. Waiting for the auth method's TTL to elapse also does not satisfy MFA, the token only appears after explicit successful validation.

   Why the other options are wrong

   • BSimply repeating the identical primary login call does not satisfy the pending MFA requirement; Vault does not auto-issue a token on a retried attempt.
   • CThe pending MFA login response is not a wrapping token; sys/wrapping/unwrap is unrelated and does not complete an MFA challenge.
   • DWaiting for a TTL to elapse does not satisfy an MFA requirement; the token is only issued after explicit successful validation, never through a timeout.
7. Question 7Build Fault-Tolerant Vault Environments

   What is the fundamental architectural difference between a DR secondary and a Performance secondary?

   • AA DR secondary is standby-only for failover; a Performance secondary serves local readsCorrect
   • BA DR secondary uses Raft while a Performance secondary always uses Consul storage
   • CA Performance secondary requires no license, while DR replication is licensed
   • DA DR secondary can only exist in the same datacenter as its primary
   ✓ Correct answer: A

   Option A is correct: the core architectural distinction is purpose, a DR secondary replicates state purely so it can be promoted during a genuine disaster, serving no client traffic in the meantime, while a Performance secondary is meant to be used continuously in production, serving reads locally and forwarding writes back to its performance primary to cut latency and offload the primary. Storage backend choice is independent of which replication mode is enabled and does not distinguish the two. Both DR and Performance replication are licensed Vault Enterprise features, not one free and one paid, and neither mode restricts a secondary to the primary's own datacenter.

   Why the other options are wrong

   • BStorage backend choice is independent of which replication mode is used; either can run on the same storage backend.
   • CBoth DR and Performance replication are licensed Vault Enterprise features, not one free and one requiring a paid license.
   • DDR secondaries are specifically intended to live in a geographically separate location, which is the whole point of disaster protection.
8. Question 8Build Fault-Tolerant Vault EnvironmentsSelect all that apply

   Which TWO statements about Vault's recovery mode (vault server -recovery) are correct? (Choose TWO)

   • AIt is intended for direct, low-level repair of storage or Raft state when a cluster cannot start or reach quorum normallyCorrect
   • BIt exposes a narrow API surface and does not serve normal secrets-engine or auth-method trafficCorrect
   • CIt automatically restores the most recent automated snapshot on startup without operator action
   • DIt permanently converts the node into a performance secondary once repairs are complete
   • EIt requires the cluster to have already reached quorum before it can be started
   ✓ Correct answer: A, B

   Recovery mode exists specifically for the scenario where a cluster cannot start normally or cannot reach quorum, giving an operator a deliberately narrow set of tools to inspect and directly repair underlying storage or Raft configuration, such as removing a bad peer, rather than exposing the ordinary Vault API. It does not automatically restore the most recent automated snapshot on startup; any remediation performed in this mode is a manual, deliberate action the operator chooses to take. No conversion into a performance secondary or any other replication role happens as a side effect of using recovery mode, and recovery mode exists precisely because the cluster cannot reach quorum through normal means, so requiring quorum as a precondition to enter it would defeat its entire purpose.

   Why the other options are wrong

   • CRecovery mode does not auto-restore anything; any remediation is a deliberate, manual operator action
   • DNo such conversion happens; recovery mode does not change a node's replication role
   • ERecovery mode exists precisely because normal quorum cannot be reached; requiring quorum first would defeat its purpose
9. Question 9Harden Vault for Production

   Compared to Shamir unseal, what is a key operational advantage of auto-unseal for a fleet of Vault servers that restart frequently, such as in an autoscaling group?

   • ANodes unseal themselves through the external key management service, with no humans supplying key sharesCorrect
   • BAuto-unseal removes the need for any TLS encryption between Vault nodes and connecting clients entirely
   • CAuto-unseal eliminates the need to ever back up the storage backend since the KMS retains all data
   • DAuto-unseal automatically replicates every stored secret to each namespace configured in the cluster
   ✓ Correct answer: A

   A is correct because in an autoscaling group nodes are created and destroyed frequently and unpredictably, and requiring a human to manually supply Shamir key shares every single time would be operationally impossible at that cadence; auto-unseal instead lets each new node contact the configured KMS at boot and unwrap its key entirely on its own. This removes the human bottleneck from the restart path while still keeping the barrier key protected by an external, access-controlled key management service rather than storing it in plaintext. Option C is a common but incorrect assumption, since the KMS only ever wraps the encryption key itself, never the actual stored secrets data.

   Why the other options are wrong

   • BAuto-unseal only changes how the barrier key is unwrapped at startup; it has no relationship to TLS configuration between Vault and connecting clients.
   • CThe KMS only wraps the barrier encryption key, never the actual stored data, so storage backend backups remain just as necessary as before.
   • DNamespace-to-namespace secret replication is a separate Enterprise feature entirely unrelated to how an individual node unseals itself at startup.
10. Question 10Scale Vault for PerformanceSelect all that apply

    Which TWO statements accurately describe how a Vault Enterprise performance standby node keeps its local reads both fast and correct? (Choose TWO)

    • AIt may briefly wait for its local WAL replay to catch up to a required index before answering a read, rather than returning stale dataCorrect
    • BIt always answers every single read instantly, no matter how far behind its own local replicated state currently happens to be
    • CIts local response cache gets written directly into the shared Raft log so that every other node inherits it too
    • DIt keeps a local cache of recently-served read responses so repeated hot reads do not have to redo the same catch-up check every timeCorrect
    • EThe local response cache entirely replaces the need for any WAL streaming from the active node at all times
    ✓ Correct answer: A, D

    A and D are correct: when a performance standby's own applied state has not yet caught up to what a given read requires, it briefly waits for WAL replay to reach the necessary index rather than returning a stale answer, and separately it keeps a bounded local cache of recently-served read responses so that repeated hot lookups do not have to redo the same catch-up check on every request. Neither mechanism involves writing anything into the shared Raft log, the cache is purely local to that node, nor does the cache eliminate the need for WAL streaming, which still keeps the standby's state current.

    Why the other options are wrong

    • BAnswering instantly while behind is precisely the stale read the catch-up check exists to prevent.
    • CThe response cache is local to the node, not part of the shared consensus storage in the Raft log
    • EWAL streaming is still what keeps the standby's underlying state current; the cache only speeds up repeat hits on top of that

Who this HashiCorp Vault Operations Advanced practice exam is for

This practice set is for anyone preparing for the HashiCorp Vault Operations Advanced exam at the advanced 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 Operations Advanced 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. Treat your readiness score as knowledge readiness, then validate it with hands-on practice in a real environment before booking the HashiCorp Vault Operations Advanced exam.

Related HashiCorp resources

• HashiCorp Vault Operations Advanced 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 Terraform Associate (004) practice examRelated
• HashiCorp Terraform Authoring and Operations Advanced practice examRelated
• HashiCorp Vault Associate (003) practice examRelated

HashiCorp Vault Operations Advanced practice exam FAQ