HashiCorp Vault Operations Advanced Practice Exam

What the HashiCorp Vault Operations Advanced exam covers

• Create a Working Vault Server Configuration153 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. A free account includes a fixed set of 20 practice questions for this exam, retryable anytime. Paid access unlocks the full 835-question bank.

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 includes an hmac_key_label field alongside key_label. What is this second key used for?

   • AVerifying integrity of HSM-wrapped values via a separate keyCorrect
   • BEncrypting the TLS listener's private key material at rest
   • CAuthorizing new Raft peers during a cluster join operation
   • DSigning audit log entries before they are persisted to disk
   ✓ Correct answer: A

   A pkcs11 seal stanza pairs the primary wrapping key, named by key_label, with a second independent key referenced by hmac_key_label. Vault uses that second key to compute and verify an HMAC over values wrapped through the HSM, confirming the ciphertext has not been tampered with - an integrity guarantee separate from and additional to the confidentiality the encryption key provides. Splitting encryption and integrity across two keys is a standard HSM pattern, following the general rule against reusing one key for two distinct cryptographic purposes.

   Why the other options are wrong

   • BProtecting the listener's TLS private key at rest is unrelated to the pkcs11 seal's separate HMAC integrity key.
   • CAuthorizing new Raft peers during a cluster join uses join tokens and TLS, not this seal-specific HMAC key.
   • DAudit log entries are hashed and secured through Vault's own audit device mechanism, independent of this pkcs11 HMAC key.
3. Question 3Monitor a Vault Environment

   By default, how does a Vault audit device treat a client token's accessor value when writing a log entry?

   • AIt HMACs the accessor just like other sensitive fields, since hmac_accessor defaults to true.Correct
   • BIt always writes the accessor value in plaintext regardless of how the device has been configured.
   • CIt omits the accessor value entirely from every audit entry that the device writes out to its log file for that mount.
   • DIt stores the accessor only in the response entry, and never in the matching request entry at all.
   ✓ Correct answer: A

   hmac_accessor defaults to true, meaning Vault treats a client token's accessor value as sensitive by default and hashes it in audit entries using the same per-device HMAC mechanism applied to the token value itself and other sensitive fields, keeping the default posture consistently protective across everything an audit entry might expose. An operator only sees a plaintext accessor in the log if they have explicitly opted out by setting hmac_accessor=false on that particular device, which is a deliberate, narrow exception rather than the out-of-the-box behavior most Vault deployments will actually run with.

   Why the other options are wrong

   • BPlaintext accessor output only happens when an operator explicitly disables hashing for that field; it is not the always-on behavior.
   • CThe accessor field is present by default in relevant entries; it is hashed, not omitted from the log entirely.
   • DThe accessor appears in whichever entries are relevant to the request, not restricted to response entries only.
4. Question 4Monitor a Vault Environment

   Which /v1/sys/health status code identifies a performance standby node, a Vault Enterprise HA standby that serves read-only requests locally rather than forwarding them to the active node?

   • A473Correct
   • B472
   • C429
   • D501
   ✓ Correct answer: A

   Performance standby is a Vault Enterprise HA feature, independent of replication: a standby node in the same cluster processes read-only requests locally and forwards any request that would write to storage over the cluster port to the active node. That role is distinct enough from a plain HA standby that Vault gives it its own default status code, 473, rather than reusing 429, which lets monitoring and load balancers tell a node that can answer reads from a standby that forwards every request. 472 instead marks any node, active or standby, of a DR secondary cluster, 429 marks a plain unsealed standby, and 501 marks a node that was never initialized.

   Why the other options are wrong

   • B472 marks any node, active or standby, of a DR secondary cluster, which is a replication role rather than a performance standby.
   • C429 is the default code for a plain unsealed HA standby that forwards requests to the active node instead of serving reads itself.
   • D501 identifies an uninitialized node, an unrelated lifecycle state that has nothing to do with standby roles.
5. Question 5Employ the Vault Security Model

   A caller whose policy grants create and update on auth/token/create, without sudo, runs `vault token create -orphan`. What is the result?

   • ARejected, since the CLI sets no_parent on auth/token/create, which needs root or sudoCorrect
   • BSuccess, since any authenticated caller may create orphan tokens simply by passing the -orphan flag on the line
   • CSuccess, but the resulting token is silently created as a non-orphan child token instead
   • DRejected, but only because the caller's own token is itself a child token
   ✓ Correct answer: A

   The CLI's -orphan flag sends no_parent = true to auth/token/create, and the token store only honors no_parent for a caller with root or sudo on that path; otherwise it answers that root or sudo privileges are required to create an orphan token. Orphans exist outside the parent-based cascading revocation that lets administrators clean up a tree of tokens, which is why that path is guarded. A caller without sudo can still get an orphan through write access to auth/token/create-orphan or through a token role with orphan = true, and Vault never silently downgrades the request to a child token.

   Why the other options are wrong

   • BOrphan creation through auth/token/create needs root or sudo; it is not open to any authenticated caller.
   • CVault does not silently downgrade a denied orphan request into a non-orphan token; the request is rejected outright rather than substituted.
   • DThe rejection comes from the missing root or sudo privilege, not from whether the caller's own token is a child token.
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 in the sequence
   • CCall sys/wrapping/unwrap using the pending login response as though it were a wrapping token, which then returns the issued client token to the caller
   • DWait for the auth method's configured TTL to elapse, after which the token is issued automatically without further input from the user
   ✓ 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. The request ID binds the passcode to that one pending login, which is discarded if it is not validated within its short validity window.

   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

   DR replication ships data asynchronously from primary to secondary. What is the direct operational consequence of this design if the primary is suddenly lost?

   • AAny writes committed on the primary but not yet streamed to the secondary can be lost after failoverCorrect
   • BThe primary will refuse to acknowledge any client write until the secondary confirms it has received that entry too
   • CClient write latency is always equal to the full network round-trip time to the secondary's datacenter
   • DNo data loss is possible under any circumstances at all, because DR replication is guaranteed to be synchronous end to end
   ✓ Correct answer: A

   The primary commits a write locally as soon as its own Raft peers reach quorum, then streams the change to the secondary afterwards instead of waiting for the secondary to acknowledge first. That opens a genuine recovery-point gap: anything that had not yet reached the secondary when the primary was lost is unrecoverable through DR replication alone. The gap is the deliberate price of the design. Asynchronous shipping is what keeps cross-region DR practical: the primary never waits on a distant datacenter before it can commit.

   Why the other options are wrong

   • BWaiting for the secondary to acknowledge every write before committing would describe synchronous replication, which is not how DR replication works.
   • CClient write latency reflects the primary's own local Raft quorum round trip, not the round trip to the secondary's distant datacenter.
   • DAsynchronous replication explicitly does not guarantee zero data loss; that tradeoff is exactly what keeps primary write latency low.
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 when Vault cannot start up normallyCorrect
   • BIt exposes only a narrow API surface without 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 for the case where Vault will not start up normally. It gives an operator direct access to storage through sys/raw, authorized by a recovery token, rather than exposing the ordinary secrets-engine and auth-method API. Everything it does is a deliberate operator action: nothing is restored automatically at startup, and nothing about the node's replication role changes as a side effect. Nor does it need quorum; with Integrated Storage it resizes the Raft cluster to a single node precisely because Raft will not allow changes without a quorum.

   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 resizes the Raft cluster to one node so it can make changes without a quorum; quorum is not a precondition for starting it.
9. Question 9Harden Vault for ProductionSelect all that apply

   Which two operational risks should be planned for when relying on a cloud KMS for auto-unseal? (Choose TWO)

   • ALoss of network connectivity or IAM permission changes to the KMS key can prevent nodes from unsealing on restartCorrect
   • BPermanent deletion of the KMS key leaves the cluster's data unrecoverable even from backupsCorrect
   • CAuto-unseal removes the requirement to ever rotate the Vault barrier encryption key going forward
   • DCloud KMS auto-unseal requires disabling all audit devices for compliance purposes across the cluster
   • EAuto-unseal automatically extends every issued lease TTL to be non-expiring by default
   ✓ Correct answer: A, B

   Both describe genuine failure modes of relying on an external KMS. If network connectivity drops or IAM permissions to the KMS key are changed, restarting nodes cannot unwrap their key and stay sealed until access is restored, which is recoverable once the underlying issue is fixed; a key that is merely disabled falls in the same recoverable category once it is enabled again. Permanent deletion of the KMS key is far more serious: HashiCorp states that if the seal mechanism or its keys are permanently deleted, the cluster cannot be recovered, even from backups, and recovery keys cannot decrypt the root key to help. This asymmetry is why production deployments protect the KMS key with deletion safeguards and monitor IAM changes to it closely.

   Why the other options are wrong

   • C`vault operator rotate` remains a distinct, still-necessary operation for the barrier's data encryption key regardless of which seal type, Shamir or auto-unseal, is configured.
   • DThere is no requirement to disable audit devices when adopting cloud KMS auto-unseal; audit logging operates completely independently of the chosen seal mechanism.
   • EAuto-unseal governs only how the barrier key is unwrapped at startup and has no effect whatsoever on issued lease TTL behavior.
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 returns a retryable 412, or forwards, when a read presents an X-Vault-Index state it does not yet holdCorrect
    • BIt always answers every single read instantly, no matter how far behind its own local replicated state currently happens to have fallen at the time
    • CIts in-memory storage read cache gets written directly into the shared Raft log so that every other node inherits it too
    • DIt serves repeat reads of hot storage entries from the in-memory read cache kept by the physical storage layerCorrect
    • EThe in-memory storage read cache entirely replaces the need for any WAL streaming from the active node at all times
    ✓ Correct answer: A, D

    A performance standby answers reads from its own replicated state, so correctness depends on that state being current enough for the read in hand. Since Vault Enterprise 1.7, a write returns an X-Vault-Index header; when a later read presents it and the node does not yet hold that state, the node returns HTTP 412 so the client retries, or forwards the request to the active node when the client sends X-Vault-Inconsistent: forward-active-node and allow_forwarding_via_header is enabled. Speed on hot keys comes from a separate mechanism: Vault's physical storage subsystem keeps an in-memory read cache on each node, which disable_cache switches off. That cache is local to the node and sits below the request path, on top of the WAL stream rather than in place of it.

    Why the other options are wrong

    • BWhen a read presents an X-Vault-Index the node does not hold, it returns 412 or forwards rather than answering, so it does not answer every read instantly.
    • CThe storage read cache is local to each node, not part of the shared consensus log.
    • EWAL streaming is still what keeps the standby's underlying state current; the read cache only speeds up repeat reads 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