HashiCorp Vault Associate VA-003 VA-003 Questions 301–366 | Page 5/5

301

MCQmedium

A Vault cluster uses a Consul storage backend. During a maintenance window, the Consul cluster is taken offline for upgrades. Vault nodes remain running but become unresponsive. After Consul is restored, Vault nodes resume normal operation without manual intervention. Which Vault architectural property explains this behavior?

A.Vault uses the storage backend only for persistence and can operate independently once unsealed.

B.Vault caches all secrets in memory, so it can continue serving requests during a storage outage.

C.Vault treats the storage backend as a dependency and will resume normal operation once the backend is reachable again, without requiring a restart.

D.Vault automatically switches to a local file storage backend when the primary backend is unavailable.

AnswerC

Vault continuously interacts with the storage backend and will return errors when it is unavailable. Once the backend is restored, Vault can resume normal operation automatically because it reconnects and continues using the same storage. No restart is required, which matches the scenario.

Why this answer

Vault's architecture treats the storage backend as an external dependency. When the backend is unavailable, Vault cannot perform operations that require storage access, leading to unresponsiveness. Once the backend is restored, Vault reconnects and resumes without manual intervention, as long as the backend data is intact and Vault remains unsealed.

Exam trap

The trap here is thinking Vault can operate independently of its storage backend or that it fails over to another backend, when in fact it simply blocks until the backend is reachable.

Full explanation →

302

MCQhard

A security architect is designing a system where one microservice writes encrypted records and a separate reporting microservice reads them. The architect wants the writer to be unable to decrypt anything, while the reader can decrypt but cannot create new ciphertext. Which Vault policy design achieves this with the transit engine?

A.Grant both services a shared token with a policy allowing update on transit/encrypt/orders and transit/decrypt/orders.

B.Grant the writer update on transit/encrypt/orders and the reader update on transit/decrypt/orders.

C.Grant both services update on transit/keys/orders and let the application decide which operation to call.

D.Grant the writer read on transit/encrypt/orders and the reader read on transit/decrypt/orders.

AnswerB

Transit operations are authorized per endpoint path, so a policy granting update on transit/encrypt/orders lets the writer encrypt but not decrypt, and update on transit/decrypt/orders lets the reader decrypt but not encrypt. This creates the least-privilege split the architect wants, since neither identity can perform the other's operation on that key.

Why this answer

Transit authorizes each operation by path, so splitting update on the encrypt path for the writer and update on the decrypt path for the reader enforces the desired asymmetry. The writer can only produce ciphertext and the reader can only recover plaintext, neither gaining the other's ability. Managing keys or sharing a combined token would grant broader capability than the design intends.

Exam trap

The trap here is granting read instead of update on transit encrypt and decrypt paths, because these data operations are POST requests that require the update capability.

Full explanation →

303

MCQhard

A security engineer is comparing the AppRole and Kubernetes auth methods for a containerized application. The application runs in a Kubernetes cluster and needs to authenticate to Vault. The engineer wants to minimize the risk of secret leakage and avoid manual secret rotation. Which statement best describes the advantage of Kubernetes auth over AppRole in this scenario?

A.Kubernetes auth automatically rotates the Vault token every 24 hours without any configuration.

B.AppRole is always more secure because it supports CIDR binding, while Kubernetes auth does not.

C.Kubernetes auth uses a service account token that is automatically mounted and rotated by Kubernetes, eliminating the need to store a static secret_id.

D.Kubernetes auth requires a secret_id that is stored in a Kubernetes Secret and manually rotated.

AnswerC

Kubernetes auth leverages the pod's service account token, which Kubernetes automatically mounts and rotates. This eliminates the need to store a static secret_id as with AppRole. The application does not manage any long-lived secret, reducing leakage risk and manual rotation overhead. This directly addresses the engineer's goals.

Why this answer

Kubernetes auth uses the pod's service account token, which Kubernetes automatically mounts and rotates. This removes the need to store a static secret_id, reducing leakage risk and manual rotation. AppRole requires a secret_id that must be protected and rotated, making Kubernetes auth advantageous in this containerized scenario.

Exam trap

The trap here is assuming AppRole is always more secure due to CIDR binding, overlooking that Kubernetes auth eliminates static secrets entirely.

Full explanation →

304

MCQmedium

A cloud operations team needs to provide temporary, dynamically generated credentials for an AWS IAM user to a CI/CD pipeline. The credentials must be automatically revoked when the lease expires. They have configured the AWS secrets engine at 'aws/' with root credentials. Which configuration step is required to allow the pipeline to assume a specific IAM role and receive credentials?

A.Create a role with credential_type=federation_token and specify the role ARN in the policy document.

B.Create a role in the AWS secrets engine that specifies the credential type as 'assumed_role' and provides the ARN of the IAM role.

C.Create a role with credential_type=assumed_role and set the policy_arns parameter to the ARN of the IAM role.

D.Create a role with credential_type=iam_user and attach a policy that allows sts:AssumeRole.

AnswerB

For the AWS secrets engine to generate credentials that assume an IAM role, you must create a role with credential_type=assumed_role and provide the role_arns parameter. This allows Vault to call STS AssumeRole and return temporary credentials. The other options either use static credentials or incorrect parameters, and do not fulfill the dynamic credential requirement with automatic revocation.

Why this answer

To generate temporary credentials that assume a specific IAM role, the AWS secrets engine role must have credential_type set to 'assumed_role' and include the role_arns parameter with the ARN of the target role. This leverages AWS STS AssumeRole, producing credentials that automatically expire with the lease. Other credential types produce different kinds of credentials that do not meet the dynamic, role-assuming requirement.

Exam trap

The trap here is mixing up the parameters for specifying a role ARN versus attaching policies; the role_arns parameter is required to assume a role, while policy_arns is for attaching policies to generated users or sessions.

Full explanation →

305

Matchingmedium

Match each Vault policy capability to its permission.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Allow creating data at a path

Allow reading data at a path

Allow modifying existing data

Allow deleting data

Allow listing keys

Why these pairings

The correct matches are: create allows creating data, read allows reading data, update allows updating data, and delete allows deleting data. Common confusions involve swapping create and read capabilities.

Full explanation →

306

MCQmedium

A payment processing team needs an application to encrypt transaction payloads without ever handling the raw encryption key material. The application will call Vault over mTLS, and the security team insists that the plaintext never leave the application process. Which Vault capability best satisfies this requirement?

A.The kv secrets engine storing the encryption key as a versioned secret so the application can retrieve and use it locally.

B.The pki secrets engine issuing client certificates so the application can establish its own TLS session and encrypt payloads.

C.The transit secrets engine's encrypt endpoint, where Vault performs the cryptographic operation and returns ciphertext to the caller.

D.Vault's key/value version 2 engine with response wrapping, which protects the key while it is delivered to the application.

AnswerC

The transit engine is encryption as a service: the caller submits base64-encoded plaintext to the encrypt endpoint and receives ciphertext, while the key material stays inside Vault and is never exported. This matches the requirement that the application not handle raw keys, and because the operation happens server-side over mTLS, the plaintext is only in transit between the application and Vault.

Why this answer

Encryption as a service means the cryptographic operation happens inside Vault, so key material never leaves the trusted boundary. The transit engine's encrypt endpoint accepts plaintext, applies the named key, and returns ciphertext, letting the application satisfy the requirement without ever seeing the key. Static secret storage, certificate issuance, and response wrapping all leave the application responsible for the actual encryption step.

Exam trap

The trap here is assuming that storing the key in Vault and reading it back is equivalent to encryption as a service, when the defining property is that Vault performs the cryptographic operation and the key never leaves.

Full explanation →

307

Multi-Selecthard

Which THREE of the following are true statements about the AppRole authentication method? (Choose three.)

Select 3 answers

A.The Secret ID contains the token policies

B.Vault can generate a wrapped Secret ID for secure delivery

C.CIDR bindings can restrict which IP addresses can use the Secret ID

D.The Role ID is analogous to a username

E.The Secret ID can only be used once

AnswersB, C, D

Response wrapping lets Vault issue a single-use token carrying the Secret ID, so the credential is never exposed in transit or logs. This satisfies the stem's secure-delivery requirement: the wrapping token can be unwrapped only once, by the intended role, before the Secret ID is revealed.

Why this answer

Option B is correct because Vault's AppRole auth method supports response wrapping: the Secret ID can be returned as a wrapped response, and the single-use wrapping token is delivered to the target application so the Secret ID is never exposed in plaintext in transit. Option C is correct because a Secret ID can have CIDR bindings (secret_id_bound_cidrs) that restrict the source IP addresses allowed to use that Secret ID during login, adding a network-layer constraint. Option D is correct because the Role ID is a non-secret, stable identifier that the application presents at login, functioning much like a username, while the Secret ID acts as the corresponding secret credential.

Option A is not correct because token policies are attached to the AppRole role/token, not embedded in the Secret ID itself; the Secret ID is just a credential value. Option E is not correct because a Secret ID is not inherently single-use — it can be used multiple times unless it is created with the single-use property (e.g., via secret_id_num_uses) or is a wrapped response token, which is single-use.

Exam trap

HashiCorp often tests the misconception that the Secret ID is inherently single-use, when in fact its usage count is configurable via the `secret_id_num_uses` parameter, and by default it has unlimited uses.

Full explanation →

308

Multi-Selectmedium

Which THREE are benefits of using Vault response wrapping?

Select 3 answers

A.Reduces the risk of secret exposure in transit

B.Supports unlimited unwraps

C.Ensures the secret is used only once

D.Increases the TTL of the secret

E.Enables delegation of access without sharing the actual token

AnswersA, C, E

Response wrapping returns a single-use wrapping token instead of the secret itself, so interception during transit yields nothing usable. This satisfies the stem's benefit of reducing exposure of the actual secret while it travels between parties.

Why this answer

Option A is correct because Vault response wrapping returns a single-use wrapping token instead of the actual secret, so if the response is intercepted in transit the attacker only obtains a wrapping token that can be unwrapped once, reducing the risk of secret exposure. Option C is correct because a wrapping token is single-use: once it is unwrapped, the token is revoked and cannot be used again, which ensures the wrapped secret can be retrieved only once. Option E is correct because wrapping enables delegation of access without sharing the actual token — the wrapper can hand the wrapping token to another party (e.g., an app or trusted operator) who unwraps it to obtain a short-lived token with limited policy, without ever exposing the original token.

Option B is not correct because wrapping tokens support only a single unwrap, not unlimited unwraps. Option D is not correct because response wrapping does not extend the TTL of the underlying secret; the wrapping token itself has a short TTL and the wrapped secret retains its own lease/TTL.

Exam trap

HashiCorp often tests the misconception that response wrapping tokens can be unwrapped multiple times or that wrapping extends the secret's TTL, but the key trap is confusing the wrapping token's TTL with the secret's TTL—they are independent and wrapping does not alter the original secret's expiration.

Full explanation →

309

MCQmedium

An organization wants to encrypt sensitive fields in their database using Vault. They have multiple applications that need to encrypt different types of data. What approach should they take?

A.Use the PKI engine to issue certificates for each application

B.Use the KV engine to store encryption keys

C.Create a separate transit key per application

D.Use a single key for all applications to simplify management

E.Encrypt data in the database using a static key stored in Vault

AnswerC

Separate transit keys per application enforce cryptographic isolation: each key's material and rotation schedule stay independent, so one application's compromise cannot decrypt another's ciphertext. This satisfies the stem's requirement that multiple applications encrypt different data types, since Vault's transit engine never exposes key material and supports per-key rotation and policy scoping.

Why this answer

The Vault Transit Secrets Engine provides encryption-as-a-service, allowing each application to have its own named encryption key. This ensures cryptographic isolation: if one key is compromised, only the data encrypted with that specific key is at risk. Using separate keys per application also simplifies key rotation and access control, as each application can only use its designated key.

Exam trap

HashiCorp often tests the distinction between secret storage (KV engine) and encryption-as-a-service (Transit engine), leading candidates to incorrectly choose Option B because they confuse storing keys with performing encryption operations.

How to eliminate wrong answers

Option A is wrong because the PKI engine is used for issuing X.509 certificates for TLS/mTLS authentication, not for encrypting data fields in a database. Option B is wrong because the KV (Key-Value) engine is designed for static secret storage, not for performing encryption operations; it cannot encrypt data on demand. Option D is wrong because using a single key for all applications violates the principle of least privilege and creates a single point of failure; if that key is compromised, all encrypted data is exposed.

Option E is wrong because storing a static key in Vault and using it outside Vault for encryption defeats the purpose of Vault's encryption-as-a-service; the Transit engine should perform the encryption/decryption operations, not just store a key.

Full explanation →

310

MCQhard

An administrator needs to securely provide a one-time use token to a remote service using Vault response wrapping. Which CLI flag or command should they use?

A.Use 'vault write -response-wrap auth/token/create'

B.Use 'vault unwrap' on the remote service

C.Use 'vault write -wrap-ttl=5m auth/token/create'

D.Use 'vault wrap auth/token/create'

AnswerC

Using `-wrap-ttl` instructs Vault to return a single-use wrapping token instead of the actual secret, satisfying the one-time use constraint. The wrapped response can be unwrapped only once by the remote service, and the five-minute TTL limits exposure. This is the correct flag for response wrapping via the CLI.

Why this answer

`vault write -wrap-ttl=5m auth/token/create` creates a one-time use token wrapped in a response-wrapping envelope with a specified TTL. The remote service can then unwrap the token using `vault unwrap` with the wrapping token, ensuring secure delivery without exposing the actual token in transit.

Exam trap

HashiCorp often tests the distinction between the `-wrap-ttl` flag used during `vault write` to create a wrapped response versus the `vault unwrap` command used to retrieve the secret, leading candidates to confuse the creation step with the retrieval step.

How to eliminate wrong answers

Option A is wrong because `-response-wrap` is not a valid flag; the correct flag is `-wrap-ttl` to set the TTL for the wrapping token. Option B is wrong because `vault unwrap` is the command used on the remote service to retrieve the original token, but it is not the CLI flag or command used to create the wrapped token. Option D is wrong because `vault wrap` is not a valid command; the correct approach is to use `vault write` with the `-wrap-ttl` flag to generate a wrapped response.

Full explanation →

311

MCQeasy

An organization wants to encrypt data in transit and at rest using a centralized key management system. Which secrets engine is designed for encryption/decryption operations without storing data?

A.KV secrets engine

B.PKI secrets engine

C.Database secrets engine

D.Transit secrets engine

AnswerD

The transit secrets engine performs cryptographic operations on data supplied by clients, returning ciphertext without persisting it, satisfying the requirement for encryption in transit and at rest via centralized key management. Keys remain inside Vault, so applications never handle raw key material directly.

Why this answer

The Transit secrets engine performs encryption/decryption operations on data in transit without storing the data itself. It is designed for centralized key management, allowing applications to send plaintext for encryption or ciphertext for decryption via API calls, while the keys remain securely managed within Vault. This makes it ideal for encrypting data in transit and at rest without persisting the data.

Exam trap

HashiCorp often tests the distinction between storing data (KV) and encrypting data (Transit), where candidates mistakenly choose KV because they associate 'encryption at rest' with storage, but Transit is the correct engine for performing encryption operations without storing the data.

How to eliminate wrong answers

Option A is wrong because the KV secrets engine stores secrets as key-value pairs and is not designed for encryption/decryption operations; it stores data at rest but does not provide cryptographic operations. Option B is wrong because the PKI secrets engine generates and manages X.509 certificates for TLS/SSL, not for generic encryption/decryption of data. Option C is wrong because the Database secrets engine generates dynamic database credentials (e.g., usernames/passwords) and does not perform encryption/decryption of arbitrary data.

Full explanation →

312

MCQmedium

A security analyst discovers that a token used by a legacy application is still active long after the application was decommissioned. Which Vault feature should have been used to automatically expire tokens when the application is no longer running?

A.Enable token renewal to keep it alive

B.Use a periodic token and revoke it manually

C.Set a TTL on the token

D.Use a batch token to limit its lifetime

AnswerC

A token TTL enforces a maximum lifetime, after which Vault automatically revokes the token regardless of whether the legacy application still runs. This directly satisfies the requirement to expire credentials without manual intervention, closing the exposure window left when a decommissioned application's token remained active indefinitely.

Why this answer

Setting a Time-To-Live (TTL) on the token ensures it automatically expires after a specified duration, even if the application is decommissioned. This prevents orphaned tokens from remaining active indefinitely, which is a security risk. Vault's TTL mechanism is designed to enforce token lifetime limits without requiring manual intervention.

Exam trap

The trap here is that candidates confuse token renewal (which extends lifetime) with TTL-based expiration, or they assume manual revocation is sufficient for automated lifecycle management, missing the need for automatic expiry via TTL.

How to eliminate wrong answers

Option A is wrong because enabling token renewal keeps the token alive indefinitely by renewing its lease, which is the opposite of what is needed to automatically expire the token. Option B is wrong because a periodic token has no fixed TTL and requires manual revocation, which does not provide automatic expiration when the application stops running. Option D is wrong because batch tokens are designed for high-throughput, non-renewable workloads but still require an explicit TTL or explicit revocation; they do not inherently limit lifetime based on application lifecycle.

Full explanation →

313

MCQhard

An administrator is evaluating Kubernetes auth for workloads running in a cluster. A developer asks whether a pod can authenticate by presenting a service account token directly to Vault without Vault contacting the Kubernetes API. Which statement best describes how the Kubernetes auth method actually validates a login?

A.Vault forwards the service account token to the Kubernetes TokenReview API and checks that the returned identity matches the role's bound service account names and namespaces.

B.Vault compares the token against a static list of service account tokens stored in the role definition at configuration time.

C.Vault decodes the service account token as a JWT and trusts its claims without contacting the cluster, provided the issuer matches the configured value.

D.Vault verifies the service account token locally using a public key cached during configuration, so no API call is needed.

AnswerA

During login, Vault calls the Kubernetes TokenReview endpoint using its configured reviewer credentials, then compares the authenticated identity against the role's bound_service_account_names and bound_service_account_namespaces. This design means Vault must reach the API server, and it also means the reviewer token must retain permission to create tokenreviews resources for logins to succeed.

Why this answer

Kubernetes auth validates a login by presenting the supplied service account token to the cluster's TokenReview API and then checking the confirmed identity against the role's bound service account name and namespace. This keeps the cluster authoritative about token validity and requires Vault to reach the API server and hold a reviewer token with tokenreviews permissions.

Exam trap

The trap here is assuming Vault validates service account tokens offline like a JWT, when it actually delegates validation to the Kubernetes TokenReview API on every login.

Full explanation →

314

MCQmedium

Refer to the exhibit. A developer tries to renew a token and receives this error. The token was created using 'vault token create -type=batch'. What is the most likely cause of this error?

A.The token is a service token and has expired

B.The token is a batch token

C.The token is a periodic token and its period has expired

D.The token is an orphan token

AnswerB

Batch tokens in HashiCorp Vault are not renewable: they carry a fixed, pre-computed lifetime and cannot be renewed via the renew-self endpoint, unlike service tokens. Since the stem specifies creation with `-type=batch`, the renewal attempt fails because that token type inherently lacks renewal capability.

Why this answer

Batch tokens are non-persistent and do not have associated lease IDs, so they cannot be renewed. The error occurs because the developer attempted to renew a batch token using 'vault token renew', which is only valid for service tokens that have a lease and can be extended. The exhibit shows a renewal failure, and since the token was created with 'vault token create -type=batch', the most likely cause is that batch tokens are inherently non-renewable.

Exam trap

HashiCorp Vault often tests the distinction between batch and service tokens by presenting a renewal error, and the trap here is that candidates may assume all tokens can be renewed or confuse batch tokens with periodic tokens, which are a subtype of service tokens that do support renewal.

How to eliminate wrong answers

Option A is wrong because service tokens can be renewed even after expiration if within the grace period, and the error is specific to batch token behavior, not expiration. Option C is wrong because periodic tokens are a type of service token that can be renewed indefinitely as long as the token is still valid, and their period expiration does not prevent renewal. Option D is wrong because orphan tokens are a property related to parent-child relationships, not renewability; orphan tokens can be service or batch tokens, and the error is due to the batch type, not the orphan status.

Full explanation →

315

MCQeasy

An organization needs to automatically issue X.509 certificates for internal services. Which secrets engine should they use?

A.SSH secrets engine

B.Cert secrets engine

C.Transit secrets engine

D.PKI secrets engine

AnswerD

The PKI secrets engine generates X.509 certificates on demand, signing them against a configured CA or intermediate, so internal services receive short-lived certificates automatically rather than through manual issuance. This directly satisfies the requirement for automatic certificate issuance, unlike static key-value storage or transit encryption, which cannot produce certificates.

Why this answer

The PKI secrets engine is specifically designed to generate X.509 certificates for internal services. It acts as a certificate authority (CA), handling certificate signing requests (CSRs), issuing certificates with configurable lifetimes, and managing revocation via CRLs or OCSP. This directly meets the requirement for automated certificate issuance.

Exam trap

HashiCorp often tests the distinction between the Transit secrets engine (encryption operations) and the PKI secrets engine (certificate issuance), leading candidates to confuse 'encryption' with 'certificate generation'.

How to eliminate wrong answers

Option A is wrong because the SSH secrets engine is designed to manage SSH credentials (client and host keys) and automate SSH access, not to issue X.509 certificates. Option B is wrong because the Cert secrets engine is a deprecated alias for the PKI secrets engine in older Vault versions; the current and correct name is PKI, and using 'Cert' implies an incorrect or outdated reference. Option C is wrong because the Transit secrets engine performs encryption/decryption operations as a service (encryption as a service) and does not generate or manage X.509 certificates.

Full explanation →

316

MCQeasy

Which authentication method in Vault uses a shared secret (Role ID) and a dynamic secret (Secret ID) to authenticate machines or applications?

A.LDAP

B.Username & password (userpass)

C.AppRole

D.Okta

AnswerC

AppRole authenticates machines via a Role ID (shared, non-secret identifier) paired with a Secret ID (dynamically generated, single-use credential). This two-part split satisfies the stem's requirement for a shared secret plus a dynamic secret for machine authentication.

Why this answer

AppRole is the correct authentication method because it is specifically designed for machine-to-machine or application-to-application authentication in Vault. It uses a static Role ID (like a username) combined with a dynamically generated Secret ID (like a password) that can be created, revoked, or have a time-to-live, providing a secure and flexible way for non-human entities to obtain a Vault token.

Exam trap

HashiCorp often tests the distinction between human-oriented authentication methods (like userpass or LDAP) and machine-oriented methods (like AppRole), so the trap here is assuming that any method using a 'secret' or 'password' is equivalent, when AppRole's unique two-part structure (static Role ID + dynamic Secret ID) is the key differentiator.

How to eliminate wrong answers

Option A is wrong because LDAP authentication in Vault relies on an external LDAP directory service (like Active Directory) to validate user credentials, not on a shared Role ID and dynamic Secret ID. Option B is wrong because the username & password (userpass) method uses a static username and password stored in Vault's internal database, intended for human users, not a two-part system with a dynamic secret. Option D is wrong because Okta authentication uses OAuth/OIDC flows to delegate authentication to the Okta identity provider, and does not involve a Role ID or Secret ID mechanism.

Full explanation →

317

MCQhard

After a security incident, the Vault administrator needs to change the encryption key used to encrypt data at rest. They have already rekeyed the unseal keys. What additional step is required to ensure new secrets are encrypted with a new key?

A.Reinitialize Vault with new unseal keys.

B.Run 'vault operator rotate' to rotate the encryption key.

C.Migrate all secrets to a new mount and delete the old one.

D.Run 'vault operator rekey' again with different parameters.

AnswerB

Rekeying the unseal keys only re-wraps the root key; it does not change the key encrypting stored data. Running 'vault operator rotate' generates a new encryption key in the keyring, so subsequent writes to the barrier are encrypted with it, satisfying the requirement that new secrets use a new key.

Why this answer

The `vault operator rotate` command rotates the encryption key used by Vault's keyring to encrypt data at rest. After rekeying the unseal keys, the administrator must rotate the encryption key so that new secrets written to the storage backend are encrypted with a fresh key, while existing data remains decryptable with the old key until it is rewritten.

Exam trap

HashiCorp often tests the distinction between rekeying unseal keys (which affects how the master key is split) and rotating the encryption key (which changes the key used to encrypt data at rest), and the trap here is that candidates confuse `vault operator rekey` with `vault operator rotate`, assuming both affect data encryption when only the latter does.

How to eliminate wrong answers

Option A is wrong because reinitializing Vault with new unseal keys would destroy all existing secrets and configuration, which is unnecessary and destructive; the goal is to change the encryption key for new data, not to wipe the entire Vault. Option C is wrong because migrating secrets to a new mount and deleting the old one does not change the underlying encryption key used by the storage backend; it only moves data between mounts, and the new mount would still use the same keyring unless the key is rotated. Option D is wrong because `vault operator rekey` changes the unseal keys (shares and threshold), not the encryption key used for data at rest; rekeying with different parameters would only affect how the master key is split, not the encryption of stored data.

Full explanation →

318

MCQmedium

A security audit requires tracking token usage without exposing the token value itself. Which token attribute should be logged?

A.Token value

B.Creation TTL

C.Token accessor

D.Policy list

AnswerC

The token accessor is a unique, non-secret identifier that references a token without revealing its value, allowing audit logs to correlate token usage while keeping the credential confidential. Logging the token itself would expose it to anyone reading the audit trail.

Why this answer

The token accessor is a non-sensitive reference to a Vault token that can be used for token lifecycle operations (e.g., lookup, renewal, revocation) without exposing the actual token value. Logging the accessor satisfies audit requirements for tracking token usage while maintaining security, as the accessor cannot be used to authenticate requests.

Exam trap

HashiCorp Vault often tests the distinction between a token's sensitive value and its non-sensitive metadata, and the trap here is that candidates confuse the token accessor with the token value itself or assume that any attribute like TTL or policy list can serve as a tracking identifier.

How to eliminate wrong answers

Option A is wrong because logging the token value directly would expose the secret credential, violating the security audit's requirement to avoid exposing the token value. Option B is wrong because the Creation TTL (time-to-live) is a configuration parameter that indicates the token's initial lifetime, not a unique identifier for tracking individual token usage. Option D is wrong because the policy list defines the token's associated access policies but does not provide a unique, non-sensitive identifier for tracking token usage across operations.

Full explanation →

319

MCQmedium

A security engineer is building an application that must encrypt records before writing them to an external SaaS ticketing system. The application must never receive or store the encryption key material, and the same plaintext must always produce the same ciphertext so records can be looked up by their encrypted value. Which transit engine configuration should be used?

A.Create a transit key with `derived=true` and supply a per-tenant context on every encrypt and decrypt call.

B.Create a standard transit key and call the `datakey` endpoint for every record before encrypting it.

C.Create a transit key with `type=aes256-gcm96` and set `exportable=true` so the application can perform its own encryption.

D.Create a transit key with `convergent_encryption=true` and enable `derived` so a context is required.

AnswerD

Convergent encryption makes identical plaintext produce identical ciphertext, which is exactly what enables lookup by encrypted value. Vault requires derived mode to be enabled when convergent encryption is used, and the supplied context scopes the convergence so different tenants do not collide. This combination meets both the deterministic and key-isolation requirements.

Why this answer

Deterministic ciphertext for lookup is provided by convergent encryption, and Vault requires derived mode to be enabled alongside it so that a context scopes the convergence. This keeps each tenant's converged values separate while still allowing exact-match searches on ciphertext. Derived mode without convergence, envelope data keys, or exportable keys all fail either the determinism requirement or the requirement that key material never leave Vault.

Exam trap

The trap here is assuming that derived mode alone produces deterministic ciphertext, when convergence is a separate setting that must also be enabled.

Full explanation →

320

MCQmedium

A platform team enables the transit engine and creates a key named orders. After several months the team rotates the key. A batch job that had stored ciphertext produced before the rotation now needs to read the original data. What must happen for the batch job to recover the plaintext?

A.The ciphertext must be decrypted using the old key version, which requires exporting that version first.

B.The batch job should call transit/decrypt with the ciphertext, and Vault will use the key version encoded in the ciphertext prefix.

C.The key must be rotated back to the previous version so the batch job can decrypt the stored ciphertext.

D.The batch job must first call transit/rewrap on each record to convert it to the new key version before decrypting.

AnswerB

Transit ciphertext carries a vault:vN prefix identifying the key version used. Decrypt reads that prefix and applies the matching retained version, so pre-rotation ciphertext still decrypts without any re-encryption. This is why rotation does not break existing data, and why decrypt alone is sufficient for the batch job.

Why this answer

Rotation in the transit engine adds a new key version while retaining older versions. Ciphertext records the version that produced it, and decrypt automatically selects the correct version. Applications therefore keep working across rotations without re-encrypting data, and rewrap is only needed when the goal is to migrate stored ciphertext to the newest version for policy or performance reasons.

Exam trap

The trap here is believing rotation invalidates old ciphertext or requires exporting keys, when Vault retains prior versions and reads the version from the ciphertext.

Full explanation →

321

Multi-Selecthard

Which THREE of the following are correct about using the Vault API to read a secret from KV v2 engine?

Select 3 answers

A.The response JSON contains a 'data' key with the secret values

B.The HTTP method used is GET

C.The API path is /v1/secret/mysecret

D.The HTTP method used is POST

E.The API path is /v1/secret/data/mysecret

AnswersA, B, E

Correct; the secret data is nested under 'data.data'.

Why this answer

The KV v2 engine returns secret data nested under a 'data' key in the JSON response. This is a deliberate design to separate metadata (e.g., version, created_time) from the actual secret values, which are placed under 'data.data'. The Vault API always uses GET for reading secrets from KV v2, making option B correct.

Option E is correct because the KV v2 engine requires the path to include '/data/' after the mount point (e.g., /v1/secret/data/mysecret) to distinguish read operations from metadata or delete operations.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 API paths, and the trap here is that candidates assume the bare path /v1/secret/mysecret works for both versions, forgetting that KV v2 requires the '/data/' segment for read operations.

Full explanation →

322

MCQmedium

A DevOps engineer is configuring Vault to encrypt data in transit for a microservice. They create a key in the transit engine and want to encrypt a base64-encoded plaintext. Which API path and operation should they use?

A.POST /v1/transit/encrypt/{key_name} with ciphertext in payload

B.GET /v1/transit/encrypt/{key_name} with query param

C.POST /v1/transit/encrypt/{key_name} with plaintext in payload

D.POST /v1/transit/sign/{key_name}

E.POST /v1/transit/hmac/{key_name}

AnswerC

The transit engine's encrypt endpoint accepts a base64-encoded plaintext value in the JSON payload and returns the resulting ciphertext. POST to /v1/transit/encrypt/{key_name} is the documented path, satisfying the requirement to encrypt data using the named key.

Why this answer

The Vault Transit Secrets Engine exposes a POST endpoint at `/v1/transit/encrypt/{key_name}` that accepts a JSON payload containing the `plaintext` field, which must be base64-encoded. This operation encrypts the provided plaintext using the named encryption key and returns the ciphertext. The POST method is required because the operation modifies state (encrypts data) and the plaintext is sent in the request body, not as a query parameter.

Exam trap

HashiCorp often tests the distinction between the input field names (`plaintext` vs `ciphertext`) and the correct HTTP method (POST vs GET) for state-changing operations, leading candidates to confuse the encrypt endpoint with the decrypt endpoint or to incorrectly assume a GET request can be used.

How to eliminate wrong answers

Option A is wrong because the payload should contain `plaintext`, not `ciphertext`; the ciphertext is the output of the encryption operation, not an input. Option B is wrong because the encrypt operation requires a POST request, not a GET; GET requests are idempotent and cannot carry a request body for the plaintext. Option D is wrong because `/v1/transit/sign/{key_name}` is used for digital signing, not encryption; it computes a signature over the input data.

Option E is wrong because `/v1/transit/hmac/{key_name}` is used for HMAC-based message authentication, not encryption; it produces a hash-based message authentication code.

Full explanation →

323

Drag & Dropmedium

Drag and drop the steps to enable AppRole authentication in Vault into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First enable the auth method, then create the role, then retrieve the RoleID, generate a SecretID, and finally login.

Full explanation →

324

MCQeasy

In a Vault HA cluster, which node is responsible for handling all write requests?

A.All nodes

B.The active node only

C.Standby nodes

D.The node that receives the request

AnswerB

Vault's integrated storage and HA design route all writes through a single leader. Standby nodes forward client requests to the active node, which alone holds the write lock on the barrier. This ensures consistency, so only the active node handles write requests.

Why this answer

In a Vault HA cluster, only the active node can handle write requests. This is because the active node holds the storage backend lock and is the only node that can modify the underlying data store. Standby nodes forward write requests to the active node, ensuring data consistency and preventing split-brain scenarios.

Exam trap

HashiCorp often tests the misconception that all nodes in an HA cluster can handle writes equally, but the key is that only the active node can process writes to maintain data integrity and avoid conflicts.

How to eliminate wrong answers

Option A is wrong because not all nodes handle write requests; only the active node can process writes, while standby nodes are read-only and forward writes to the active node. Option C is wrong because standby nodes do not handle write requests; they only serve read requests and forward writes to the active node. Option D is wrong because the node that receives the request may be a standby node, which cannot process writes locally and must forward the request to the active node.

Full explanation →

325

MCQeasy

A Vault operator runs 'vault secrets list' and sees 'cubbyhole/' mounted. What is the purpose of this engine?

A.Store secrets encrypted by the Transit engine

B.Store secrets that are isolated per token

C.Store secrets that are replicated across clusters

D.Store secrets with high availability

AnswerB

The cubbyhole secrets engine stores data scoped strictly to the token that wrote it; no other token, even with identical policies, can read those secrets. This satisfies the scenario by providing per-token isolated storage that is destroyed when the token expires.

Why this answer

The cubbyhole secrets engine creates a private, ephemeral storage space that is scoped to a single Vault token. Secrets written to cubbyhole are only readable by the same token that wrote them and are automatically destroyed when the token expires or is revoked, making it ideal for token-specific secrets like a one-time password or a temporary key.

Exam trap

HashiCorp often tests the distinction between cubbyhole and the KV (Key-Value) engine, where candidates mistakenly think cubbyhole provides replication or persistence, but the trap is that cubbyhole is purely token-scoped and ephemeral, not a general-purpose secrets store.

How to eliminate wrong answers

Option A is wrong because the Transit engine handles encryption as a service (encrypt/decrypt data without storing it), while cubbyhole stores raw secrets per token. Option C is wrong because cubbyhole is explicitly not replicated across clusters; it is local to the token and does not participate in Performance or DR replication. Option D is wrong because cubbyhole provides no high availability guarantees; it is a single-token, non-durable store that vanishes with the token.

Full explanation →

326

MCQhard

A DevOps engineer needs to create a token with a specific policy attached using the Vault API. Which API endpoint and request should they use?

A.POST /v1/auth/token/create with JSON body {"policies":["my-policy"]}

B.POST /v1/auth/token/create-orphan with JSON body {"policies":["my-policy"]}

C.POST /v1/token/create with JSON body {"policy":"my-policy"}

D.POST /v1/sys/token with JSON body {"policy":"my-policy"}

AnswerA

POST /v1/auth/token/create accepts a JSON body whose "policies" array binds named policies directly to the issued token, satisfying the stem's requirement for a token with a specific policy attached. The token auth method's create endpoint is the documented mechanism for policy-scoped token issuance via the Vault API.

Why this answer

The Vault API endpoint for creating tokens with specific policies is POST /v1/auth/token/create, and the JSON body must include the 'policies' key as an array of strings. This endpoint is part of the token auth method and allows attaching policies at token creation time.

Exam trap

HashiCorp often tests the exact API path and JSON key naming conventions, tricking candidates who confuse 'policy' (singular) with 'policies' (array) or omit the 'auth' segment in the endpoint path.

How to eliminate wrong answers

Option B is wrong because POST /v1/auth/token/create-orphan creates an orphan token (not parented by the requesting token), but the question does not specify orphan behavior; the standard create endpoint suffices and the -orphan variant is not required. Option C is wrong because the correct path is /v1/auth/token/create, not /v1/token/create; the 'auth' segment is mandatory for the token auth method, and the JSON key must be 'policies' (array), not 'policy' (string). Option D is wrong because /v1/sys/token is not a valid endpoint; token creation is under /v1/auth/token/, and the JSON body must use 'policies' as an array, not 'policy' as a string.

Full explanation →

327

Drag & Dropmedium

Drag and drop the steps to configure Vault's audit logging to a file into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence for configuring Vault's audit logging to a file is: first enable the audit device (e.g., 'vault audit enable file file_path=...'), then perform operations (e.g., read/write secrets) to generate audit log entries, and finally verify the log file to confirm entries are being recorded. Common mistakes include enabling after generating logs, verifying too early, or skipping the generation step.

Full explanation →

328

Multi-Selecteasy

Which TWO of the following actions can reduce the number of active leases in Vault? (Select two.)

Select 2 answers

A.Reducing the default lease TTL

B.Revoking a lease

C.Creating a new lease

D.Increasing the max lease TTL

E.Renewing a lease

AnswersA, B

Leases expire when their TTL elapses, so lowering the default lease TTL causes leases to be revoked sooner and reduces how many remain active at any moment. This directly decreases the count of outstanding leases Vault must track.

Why this answer

Option A is correct because reducing the default lease TTL shortens the lifetime of newly issued leases, so they expire and are revoked sooner, decreasing the count of active leases at any given time. Option B is correct because revoking a lease explicitly invalidates it, immediately removing it from the set of active leases tracked by Vault. Option C is incorrect because creating a new lease adds another active lease rather than reducing the count.

Option D is incorrect because increasing the max lease TTL allows leases to live longer, which tends to keep more leases active. Option E is incorrect because renewing a lease extends its lifetime, keeping it active instead of reducing the number of active leases.

Exam trap

HashiCorp often tests the misconception that increasing TTL values or renewing leases reduces active leases, but both actions actually prolong lease lifetimes and can increase the active count if new leases are created concurrently.

Full explanation →

329

MCQeasy

A startup wants to use Vault to manage MySQL database credentials for their development environment. They have a single MySQL database and require that each application gets unique, short-lived credentials that are automatically rotated. The operations team enabled the database secrets engine, configured the MySQL connection, and created a role with a TTL of 1 hour. However, when an application requests credentials using the role, Vault returns an error: 'No more available leases on this role'. The team checks the role's configuration and sees that the 'max_ttl' is set to 1 hour and 'default_ttl' is also 1 hour. What is the most likely cause of this error?

A.The database secrets engine is not enabled at the expected path; the role is pointing to a different engine.

B.The application is not using a valid token to authenticate to Vault, so the request is rejected.

C.The role has a 'max_leases' parameter set to a low value (e.g., 5) that has been exceeded. Increase the 'max_leases' on the role.

D.The TTL values are too short; applications are requesting new credentials too frequently and exhausting a hidden limit. Increase the TTL.

AnswerC

The role's `max_leases` parameter caps how many concurrent leases the database secrets engine will issue for that role. With a low value such as 5, each application's credential request consumes a lease until the cap is hit, producing "No more available leases on this role". Raising `max_leases` restores issuance; TTL settings are irrelevant here.

Why this answer

The error 'No more available leases on this role' indicates that the role has a finite number of leases it can issue, controlled by the 'max_leases' parameter. When this limit is reached, Vault refuses to issue new credentials until existing leases expire or are revoked. The role's TTL and max_ttl being both 1 hour does not cause this error; rather, the exhaustion of the lease count does.

Exam trap

HashiCorp often tests the distinction between TTL-based limits and lease-count limits; the trap here is that candidates confuse 'max_ttl' (maximum duration of a lease) with 'max_leases' (maximum number of concurrent leases), leading them to incorrectly adjust TTL values instead of the lease count parameter.

How to eliminate wrong answers

Option A is wrong because if the secrets engine were not enabled at the expected path, the error would be something like 'path not found' or 'no handler for route', not a lease exhaustion error. Option B is wrong because an invalid token would result in a 'permission denied' or 'token not found' error, not a lease-specific error. Option D is wrong because increasing TTL would actually reduce the frequency of lease creation, not solve the exhaustion of a fixed lease count; the error is about a limit on the number of concurrent leases, not their duration.

Full explanation →

330

MCQeasy

An administrator creates a token with the following parameters: `vault token create -ttl=1h -explicit-max-ttl=2h`. The token is then renewed once for 1 hour. What is the maximum remaining time the token can be renewed for after this first renewal?

A.3 hours

B.1 hour

C.2 hours

D.0 hours (token cannot be renewed further)

AnswerB

The token's explicit max TTL is 2 hours. After the initial creation, the token has 1 hour of TTL. When renewed for 1 hour, the total elapsed time becomes 1 hour, leaving 1 hour until the explicit max TTL is reached. Therefore, the maximum remaining renewal time is 1 hour.

Why this answer

The explicit max TTL is a hard limit on the total lifetime of a token from its creation. After the token is created with a TTL of 1 hour, it is renewed for another hour, making the total elapsed time 1 hour. The remaining time before hitting the explicit max TTL of 2 hours is 1 hour.

Thus, the token can be renewed for at most 1 more hour.

Exam trap

The trap here is confusing the explicit max TTL with the initial TTL and assuming that renewals can extend the token beyond the explicit max TTL.

Full explanation →

331

MCQhard

A Vault cluster is sealed. An operator attempts to renew a lease but gets an error. What is the most likely error?

A.Vault is sealed

B.Upstream error

C.Permission denied

D.Lease not found

AnswerA

A sealed Vault node cannot service any API requests, including lease renewal, because the barrier is active and the storage backend is inaccessible. The operator receives a "Vault is sealed" error, directly reflecting the stem's constraint that the cluster is sealed. Unsealing restores lease operations.

Why this answer

When Vault is sealed, it cannot process any operations, including lease renewal. The error would indicate the sealed state.

Full explanation →

332

Multi-Selectmedium

Which THREE are appropriate use cases for Vault's Transit secrets engine?

Select 3 answers

A.Providing cryptographic offloading for applications running in untrusted environments

B.Generating and managing TLS certificates for internal services

C.Storing and retrieving static secrets like API keys

D.Performing signing and verification operations (e.g., for digital signatures)

E.Encrypting sensitive fields in a database without exposing encryption keys to the application

AnswersA, D, E

Vault's Transit secrets engine performs encryption and decryption operations centrally, so plaintext keys never leave Vault. Applications in untrusted environments send data to Vault for cryptographic processing, satisfying the offloading requirement without exposing key material locally. This directly addresses the constraint of operating where local key storage cannot be trusted.

Why this answer

Option A is correct because the Transit secrets engine performs encryption/decryption as a service, so applications in untrusted environments can offload cryptographic operations to Vault without ever handling or storing the encryption keys themselves. Option D is correct because Transit supports signing and verification operations, allowing Vault to hold the signing key while the application submits data to be signed or verified. Option E is correct because Transit's encrypt/decrypt endpoints let an application encrypt sensitive database fields while the key material remains inside Vault, so the application never sees the encryption key.

Option B is not a Transit use case; generating and managing TLS certificates is handled by the PKI secrets engine. Option C is not a Transit use case; storing and retrieving static secrets such as API keys is the role of the KV (Key/Value) secrets engine.

Exam trap

HashiCorp often tests the distinction between Transit (encryption as a service) and other secrets engines like PKI (certificates) and KV (static secrets), so candidates mistakenly associate Transit with any cryptographic task, including certificate management or secret storage.

Full explanation →

333

MCQhard

A user receives 'permission denied' when running 'vault write secret/data/myapp value=123'. The user's token has a policy that includes 'path "secret/data/*" { capabilities = ["read", "list"] }'. What is the most likely cause?

A.The user is not authenticated.

B.The path requires create or update capability.

C.The secret engine is not mounted.

D.The token is expired.

AnswerB

Writing to secret/data/myapp creates or updates data, which requires the create or update capability. The token's policy grants only read and list on that path, so Vault denies the write despite the path matching correctly.

Why this answer

The user's policy grants only 'read' and 'list' capabilities on the path 'secret/data/*'. The 'vault write' command requires either 'create' or 'update' capability (or both) on the path. Since the policy lacks these capabilities, Vault returns a 'permission denied' error, even though the token is valid and the secret engine is mounted.

Exam trap

HashiCorp often tests the distinction between capabilities required for different operations (read/list vs. create/update/delete), leading candidates to assume that any valid token with any capabilities on the path can write, when in fact the policy must explicitly include 'create' or 'update'.

How to eliminate wrong answers

Option A is wrong because the user received a 'permission denied' error, not an 'authentication required' error; the token is present and valid, but lacks the necessary capabilities. Option C is wrong because if the secret engine were not mounted, the error would be 'no secret engine mounted at secret/' or 'path not found', not 'permission denied'. Option D is wrong because an expired token would return an 'invalid token' or 'token expired' error, not a 'permission denied' error.

Full explanation →

334

MCQmedium

A company uses Vault to issue tokens for short-lived tasks. They have configured a token role with 'period' set to 30 minutes and 'explicit_max_ttl' set to 24 hours. Tokens are created using the role and are expected to be renewed every 30 minutes by the tasks. However, after a few renewals, the Vault audit logs show that a token was renewed but then immediately expired. The task that was using the token failed. What is the most likely reason for this behavior?

A.The token reached its 'explicit_max_ttl' of 24 hours, and renewal is no longer possible.

B.The token was created by a root token and root tokens are not subject to periodic renewal.

C.The token was a batch token and batch tokens cannot be renewed at all.

D.The token was an orphan token and cannot be renewed more than a few times.

AnswerA

The token's explicit_max_ttl caps its total lifetime at 24 hours regardless of periodic renewal. Once cumulative renewals exhaust that ceiling, Vault permits one final renewal but sets the token's TTL to zero, so it expires immediately afterwards. This matches the audit log showing a successful renewal followed by instant expiry, satisfying the 24-hour constraint.

Why this answer

The token role has an 'explicit_max_ttl' of 24 hours, which sets an absolute hard limit on the token's lifetime regardless of the shorter 'period' of 30 minutes. When the token is renewed, its total lifetime cannot exceed the explicit_max_ttl. Once that limit is reached, Vault rejects any further renewal, causing the token to expire immediately and the task to fail.

Exam trap

Vault often tests the distinction between 'period' (renewal interval) and 'explicit_max_ttl' (absolute lifetime cap), leading candidates to mistakenly think that periodic renewal can continue indefinitely as long as the token is renewed within the period.

How to eliminate wrong answers

Option B is wrong because root tokens are not subject to most TTL restrictions, but the token in question was created using a token role, not by a root token directly, and the issue is about explicit_max_ttl enforcement, not root token behavior. Option C is wrong because batch tokens cannot be renewed at all, but the audit logs show the token was successfully renewed several times before failing, indicating it was a service token, not a batch token. Option D is wrong because orphan tokens have no parent and can be renewed indefinitely up to their TTL limits; there is no restriction on the number of renewals for orphan tokens.

Full explanation →

335

MCQhard

Refer to the exhibit. An application uses this policy to access Vault. The application is able to read database credentials from `database/creds/my-role`. However, attempts to list all roles at `database/roles/` fail. What is the most likely cause?

A.The path `database/roles/` is not a valid path for listing roles

B.The database secrets engine is not enabled

C.The policy does not allow the 'list' capability on the path `database/roles/`

D.The application needs the 'sudo' capability to list roles

AnswerC

Reading credentials at `database/creds/my-role` requires only the `read` capability, which the policy grants. Listing `database/roles/` is a distinct operation requiring the `list` capability on that exact path; Vault denies it because no policy rule grants `list` there, regardless of `read` access elsewhere.

Why this answer

The policy grants 'read' capability on `database/creds/my-role` but does not include the 'list' capability on `database/roles/`. In Vault, listing requires an explicit 'list' capability in the policy, even if 'read' is allowed on sub-paths. Without 'list', the API call to `LIST database/roles/` returns a permission denied error.

Exam trap

HashiCorp often tests the distinction between 'read' and 'list' capabilities, trapping candidates who assume that read access on sub-paths implies the ability to list the parent path.

How to eliminate wrong answers

Option A is wrong because `database/roles/` is a valid path for listing roles when the database secrets engine is enabled; Vault uses a standard endpoint for listing. Option B is wrong because the application can read credentials from `database/creds/my-role`, which proves the database secrets engine is enabled and mounted. Option D is wrong because the 'sudo' capability is not required for listing roles; 'sudo' is used for privileged operations like modifying policies or enabling engines, not for standard listing.

Full explanation →

336

MCQhard

A company requires that Vault data be continuously replicated from a primary data center to a secondary data center for disaster recovery. The secondary data center must be able to become writable in the event of a primary failure. Which Vault feature should they use?

A.Performance Replication

B.Consul as storage backend

C.Performance Standby

D.Disaster Recovery Replication

AnswerD

Disaster Recovery Replication continuously ships data to a secondary that can be promoted to a writable primary, satisfying the stem's requirement for failover writability. Performance Replication secondaries remain read-only for most operations, so they cannot meet that constraint.

Why this answer

Disaster Recovery (DR) Replication is the correct choice because it provides asynchronous replication of Vault data (including configuration, policies, and secrets) from a primary cluster to a secondary cluster. In the event of a primary failure, the secondary cluster can be promoted to become writable, ensuring business continuity. This feature is specifically designed for disaster recovery scenarios where the secondary site must be able to take over write operations.

Exam trap

HashiCorp often tests the distinction between Performance Replication and Disaster Recovery Replication, where candidates mistakenly choose Performance Replication because they confuse read scaling with disaster recovery failover capabilities.

How to eliminate wrong answers

Option A is wrong because Performance Replication is designed for low-latency read scaling across geographically distributed clusters, but the secondary cluster remains read-only and cannot be promoted to writable in a disaster. Option B is wrong because Consul as a storage backend is a storage configuration, not a replication feature; it does not provide built-in continuous replication or failover to a writable secondary. Option C is wrong because Performance Standby nodes are read-only and intended to offload read requests from the active leader, not to serve as a writable disaster recovery target.

Full explanation →

337

MCQhard

An application uses a periodic token with period=24h. The application renews every 12h. After 48h, the token is still valid. After 72h, the token is still valid. What is the maximum lifetime of this periodic token?

A.Unlimited (as long as it keeps renewing)

B.72h

C.48h

D.24h

AnswerA

Periodic tokens have no fixed maximum lifetime; each renewal resets the validity window rather than counting toward an absolute expiry. Because the application renews every 12h against a 24h period, the token stays valid indefinitely, so the lifetime is effectively unlimited while renewals continue.

Why this answer

A periodic token with a defined period (e.g., 24h) has no maximum lifetime; it remains valid indefinitely as long as it is renewed before the period expires. In this scenario, the token is renewed every 12h (well within the 24h period), so after 48h and 72h it is still valid because each renewal resets the token's lifetime, effectively giving it an unlimited lifespan. This behavior is inherent to periodic tokens in Vault, which are designed for long-lived sessions with regular re-authentication.

Exam trap

The trap here is that candidates confuse the token's period (the renewal window) with a maximum lifetime, assuming the token expires after the period even if renewed, when in fact periodic tokens can be renewed indefinitely as long as the renewal occurs before the period ends.

How to eliminate wrong answers

Option B (72h) is wrong because it assumes a fixed maximum lifetime, but periodic tokens have no hard upper limit—they can be renewed indefinitely. Option C (48h) is wrong because it incorrectly interprets the renewal interval as the token's maximum lifetime, whereas the token's validity depends on the period (24h) and renewal before expiry. Option D (24h) is wrong because it confuses the token's period (the window for renewal) with a maximum lifetime; the token does not expire after 24h if renewed within that window.

Full explanation →

338

Multi-Selectmedium

A security engineer needs to authenticate a CI pipeline to Vault using the AppRole auth method from the CLI without a pre-existing token. The engineer has the role_id and a wrapped secret_id. Which TWO commands are required to complete the login and obtain a usable token? (Choose two.)

Select 2 answers

A.vault unwrap <wrapping_token>

B.vault token renew -self

C.vault login -method=approle role_id=<role_id>

D.vault write -wrap-ttl=120s auth/approle/role/web/secret-id

E.vault write auth/approle/login role_id=<role_id> secret_id=<secret_id>

AnswersA, E

The wrapped secret_id must be unwrapped to reveal the actual SecretID value before it can be used in a login. `vault unwrap` consumes the single-use wrapping token and returns the SecretID. Without this step the login payload would contain the wrapping token instead of the SecretID, causing authentication to fail. This is a required step when SecretIDs are delivered wrapped.

Why this answer

Authenticating with a wrapped SecretID requires two distinct actions: first, `vault unwrap` consumes the single-use wrapping token to reveal the real SecretID; second, `vault write auth/approle/login` submits the role_id and the unwrapped SecretID to receive a client token. Skipping the unwrap step sends the wrapping token as the SecretID, which the AppRole backend rejects because it does not match any stored SecretID.

Exam trap

The trap here is assuming the wrapped SecretID can be passed directly to the login endpoint, when it must be unwrapped into the real SecretID first.

Full explanation →

339

MCQhard

A security engineer is comparing two machine-oriented auth methods for workloads running outside Kubernetes. The workloads cannot use cloud instance identity and must not store a long-lived credential on disk. The engineer wants a method where the workload proves possession of a one-time-use credential that can be issued with a very short TTL and limited use count. Which auth method best fits?

A.Userpass, with each workload assigned a dedicated username and a randomly generated password rotated weekly.

B.Token auth, by pre-generating a periodic token with a long period and distributing it to each workload.

C.AppRole, using a secret ID with num_uses set to 1 and a short secret_id_ttl, paired with the role ID.

D.Cert auth, by issuing each workload a client certificate from the organization's internal CA with a one-year validity.

AnswerC

AppRole splits authentication into a role ID (semi-public identifier) and a secret ID (sensitive, one-time-use credential). Setting num_uses to 1 makes the secret ID invalid after a single login, and a short secret_id_ttl bounds its lifetime. This lets a workload retrieve the secret ID at runtime without persisting a long-lived secret, satisfying the possession-of-one-time-credential requirement.

Why this answer

AppRole is the only listed method that separates a non-sensitive role ID from a sensitive secret ID and supports one-time-use semantics via num_uses plus a short secret_id_ttl. The alternatives all require a persistent credential (password, periodic token, or long-lived certificate), which the scenario explicitly rules out.

Exam trap

The trap here is treating token auth as inherently short-lived, when a pre-issued periodic token is effectively a long-lived credential that renews indefinitely.

Full explanation →

340

MCQmedium

A developer has a policy that grants 'create' capability on path 'secret/data/team/*'. They successfully create a new secret using 'vault kv put secret/data/team/db', but when they try to update the same secret with new data, they get a permission denied error. What is the most likely cause?

A.The developer does not have the 'create' capability on the parent path.

B.The policy does not include the 'update' capability, which is required for modifying existing secrets.

C.The policy needs the 'list' capability on the path.

D.The developer's token lacks the 'sudo' capability for updates.

AnswerB

Vault's key-value v2 secrets engine treats creation and modification as distinct operations. The 'create' capability permits the initial write to a new path, but updating an existing secret requires the separate 'update' capability, which the policy omits, causing the permission denied error.

Why this answer

In Vault, the 'kv put' command performs a 'create' operation when the secret does not exist, but an 'update' operation when it does. The policy only grants 'create' capability on 'secret/data/team/*', which allows the initial write but not subsequent modifications. To update an existing secret, the policy must also include the 'update' capability on the same path, as Vault's ACL system enforces separate capabilities for creating and updating secrets.

Exam trap

A common misconception in Vault is that 'kv put' is a single operation, when in fact Vault treats the first write as 'create' and subsequent writes as 'update', requiring separate capabilities in the policy.

How to eliminate wrong answers

Option A is wrong because the developer successfully created the secret, which requires 'create' capability on the exact path 'secret/data/team/db' — the parent path 'secret/data/team/*' is irrelevant since the policy already covers the child path. Option C is wrong because the 'list' capability is only needed for listing secrets under a path (e.g., 'vault kv list'), not for updating an existing secret. Option D is wrong because Vault does not require 'sudo' capability for updates; 'sudo' is a special capability for certain privileged operations (e.g., writing to 'sys/') and is unrelated to KV secret updates.

Full explanation →

341

MCQhard

After rotating the 'payment-key', Vault successfully decrypts data encrypted with the old key (v1). What is the most likely reason the decryption succeeded?

A.The old key version is retained and used for decryption when the ciphertext references that version.

B.The old key version is automatically deleted after rotation, but the ciphertext contains the key version and is decrypted by the new key.

C.The ciphertext contains the original plaintext, so decryption simply extracts it.

D.The plaintext is stored in Vault during encryption, so decryption retrieves the stored plaintext.

AnswerA

Vault's key ring retains prior key versions after rotation. Ciphertext stores the version used at encryption, so decryption retrieves that retained version rather than the new key, which is why data encrypted under v1 still decrypts successfully.

Why this answer

A is correct because Vault uses key versioning: when a key is rotated, the old key version (v1) is retained for decryption purposes. The ciphertext includes metadata referencing the key version used for encryption, so Vault automatically selects the correct old key version to decrypt data encrypted before rotation. This ensures backward compatibility without re-encrypting existing data.

Exam trap

HashiCorp often tests the misconception that key rotation invalidates old ciphertext, but the trap here is that candidates assume the old key is deleted or replaced, when in fact Vault retains it for decryption based on ciphertext metadata.

How to eliminate wrong answers

Option B is wrong because Vault does not automatically delete the old key version after rotation; it retains it for decryption, and the new key cannot decrypt data encrypted with the old key due to different cryptographic material. Option C is wrong because ciphertext does not contain the original plaintext; it contains encrypted data that requires the correct key and algorithm to decrypt. Option D is wrong because Vault does not store plaintext during encryption; it only stores ciphertext and metadata, and decryption is a cryptographic operation, not a retrieval of stored plaintext.

Full explanation →

342

MCQhard

A Vault policy includes the following statement: path "secret/data/+/app" { capabilities = ["read"] }. Which paths would match this policy? (Assume KV v2)

A.secret/data/team-a/app/db

B.secret/data/team-a/team-b/app

C.secret/data/app

D.secret/data/team-a/app

AnswerD

In Vault KV v2, the API path inserts data/ between the mount and the key. The single + wildcard matches exactly one path segment, so secret/data/team-a/app satisfies secret/data/+/app, while deeper or shallower paths do not.

Why this answer

In Vault KV v2, the path structure is `secret/data/<path>`, and the `+` glob matches a single path segment. The policy `secret/data/+/app` matches exactly one segment between `data/` and `/app`. Option D, `secret/data/team-a/app`, has a single segment `team-a` before `app`, so it matches.

Options with additional segments (A, B) or missing the required segment (C) do not match.

Exam trap

The glob pattern `+` matches exactly one path segment. In KV v2, the path must include the `data/` prefix. Candidates may mistakenly believe that `+` can match multiple segments (like `*`) or that the `data/` prefix is not required, but this question tests both concepts.

How to eliminate wrong answers

Option A is wrong because `secret/data/team-a/app/db` has two segments after `data/` (`team-a/app/db`), and the `+` glob matches only one segment, so the extra `/db` segment causes a mismatch. Option B is wrong because `secret/data/team-a/team-b/app` has three segments after `data/` (`team-a/team-b/app`), exceeding the single-segment match of `+`. Option C is wrong because `secret/data/app` has zero segments between `data/` and `app`; the `+` requires exactly one segment, so this path does not match.

Full explanation →

343

MCQhard

An organization uses the AWS secrets engine to generate IAM users for each application. They want to ensure that if a Vault server is compromised, the attacker cannot use the AWS secrets engine configuration to gain access to the AWS account. Which additional security measure should be implemented?

A.Enable Vault's seal wrapping to encrypt the engine configuration

B.Store the AWS access key used by the engine in a separate Vault instance

C.Use a dedicated Vault server for the AWS engine

D.Use a non-root IAM user with minimal privileges for the engine and restrict the engine's role policies to the minimum needed

AnswerD

The engine's own AWS credentials define the blast radius if Vault is compromised. Using a non-root IAM user with minimal privileges, plus tightly scoped role policies, limits what an attacker could do with the engine configuration.

Why this answer

The core principle of least privilege ensures that even if the Vault server is compromised, the attacker can only perform actions allowed by the minimal IAM policy attached to the non-root user. This limits the blast radius, preventing the attacker from gaining full administrative access to the AWS account. The AWS secrets engine uses the configured IAM credentials to create temporary IAM users, so restricting those credentials to only the necessary permissions is the most effective mitigation.

Exam trap

HashiCorp often tests the misconception that encryption or isolation (seal wrapping, separate instances) is sufficient to protect against credential abuse, when in reality the underlying IAM permissions are the critical control.

How to eliminate wrong answers

Option A is wrong because seal wrapping encrypts the engine configuration at rest and in transit, but it does not limit the permissions of the underlying AWS credentials; if the Vault server is compromised, the attacker can still use the decrypted credentials to perform any action allowed by the IAM policy. Option B is wrong because storing the AWS access key in a separate Vault instance does not prevent an attacker who compromises the primary Vault server from using the engine's configuration to call the AWS API; the attacker would still have access to the credentials via the engine's storage backend. Option C is wrong because using a dedicated Vault server for the AWS engine does not reduce the risk; if that dedicated server is compromised, the attacker still has full access to the AWS credentials configured in the engine.

Full explanation →

344

MCQhard

A Vault cluster has several policies. One policy, "app-policy", contains: path "secret/data/app/*" { capabilities = ["create", "update"] }. Another policy, "admin-policy", includes: path "secret/data/app/db" { capabilities = ["deny"] }. A token is attached with both policies. Can the token write to "secret/data/app/db"?

A.No, because the paths conflict.

B.No, because deny takes precedence over allow.

C.Yes, because policies are additive.

D.Yes, because the first policy allows create/update.

AnswerB

Deny capabilities override any granted capabilities in Vault's policy evaluation, regardless of policy order or token attachment. Because "admin-policy" explicitly denies "secret/data/app/db", the token cannot write there even though "app-policy" grants create and update on the wildcard path. The explicit deny constraint in the stem therefore blocks the write.

Why this answer

B is correct because in Vault, the 'deny' capability takes precedence over all other capabilities. When a token has multiple policies attached, Vault evaluates all matching paths and applies the most restrictive result. Since 'admin-policy' explicitly denies access to 'secret/data/app/db', the token cannot write to that path, regardless of the 'create' and 'update' capabilities granted by 'app-policy'.

Exam trap

A common pitfall in Vault is assuming that policies are purely additive, overlooking that a 'deny' capability in any matching policy overrides all other capabilities.

How to eliminate wrong answers

Option A is wrong because path conflicts are resolved by capability precedence, not by blocking the operation outright; Vault uses a most-restrictive model where 'deny' overrides all allows. Option C is wrong because while policies are additive for non-conflicting capabilities, 'deny' is not additive—it is an absolute override that negates any allow on the same path. Option D is wrong because the first policy's 'create' and 'update' capabilities are overridden by the explicit 'deny' in the second policy; Vault does not use a first-match or additive model when 'deny' is present.

Full explanation →

345

MCQhard

A financial services company uses Vault's PKI secrets engine to issue short-lived TLS certificates to internal services. An administrator configured the PKI role with default_ttl=24h and max_ttl=72h. A service requests a certificate with an explicit TTL of 120h. What will Vault do in this situation?

A.Vault rejects the request with an error because the requested TTL exceeds max_ttl.

B.Vault issues the certificate with a TTL of 120h because the requested TTL overrides the role's max_ttl.

C.Vault issues the certificate with a TTL of 24h, the role's default_ttl, ignoring the requested value entirely.

D.Vault issues the certificate with a TTL capped at 72h, the role's max_ttl.

AnswerD

When a requested TTL exceeds the role's max_ttl, Vault caps the issued lease at max_ttl. The certificate will be valid for 72 hours rather than the requested 120 hours. This enforces the administrator-defined upper bound on credential lifetime, which is the core purpose of max_ttl.

Why this answer

The max_ttl on a PKI role establishes the absolute maximum lifetime for any certificate issued by that role. When a client requests a TTL beyond that value, Vault clamps the issued lease to max_ttl, so the certificate is valid for 72 hours. The default_ttl only applies when no TTL is specified.

Exam trap

The trap here is assuming a client-requested TTL can override max_ttl, or that exceeding max_ttl causes an error rather than a silent cap.

Full explanation →

346

MCQmedium

A platform team runs a Vault cluster with a transit secrets engine mount at transit/. An application holds a token with a policy granting only "update" on transit/encrypt/orders and "read" on transit/keys/orders. The application's token has a TTL of 1h with a max_ttl of 4h, and it renews itself every 30 minutes using the token renewal endpoint. After roughly four hours of continuous operation, the application's API calls begin failing with a permission denied error even though the token was renewed successfully each time. Which Vault behavior explains this failure?

A.The transit secrets engine automatically revoked the token when the application exceeded its allowed number of encrypt operations per hour.

B.The policy attached to the token expired at the same time as the token's initial TTL and had to be reattached before further API calls could succeed.

C.The token reached its max_ttl, so renewal requests stopped extending its lifetime and the token expired, invalidating all requests made with it.

D.Renewing a token more than once silently converts it into a periodic token whose capabilities are stripped until it is re-authenticated.

AnswerC

Vault tokens carry both a TTL and a max_ttl. Each successful renewal extends the token only up to the max_ttl ceiling; once that absolute lifetime is reached, Vault no longer extends the token and it expires. When the token expires, every request authenticated with it fails, which matches the permission denied errors appearing after roughly four hours of renewals.

Why this answer

Service tokens are bounded by both a renewable TTL and an absolute max_ttl. Each renewal extends the token's lifetime only until the max_ttl ceiling is reached; beyond that point Vault refuses to extend it, and the token expires. Expiration invalidates the token immediately, so subsequent API calls authenticated with it fail with permission denied, exactly as the application observes after about four hours.

Exam trap

The trap here is assuming that a successfully renewed token can be renewed forever, when in fact renewals stop extending the token once its max_ttl ceiling is reached.

Full explanation →

347

Multi-Selectmedium

Which TWO of the following are valid use cases for the Transit secrets engine? (Select exactly 2.)

Select 2 answers

A.Signing and verifying data

B.Encrypting data in transit without exposing the encryption key

C.Storing encryption keys

D.Storing encrypted data at rest

E.Managing X.509 certificates

AnswersA, B

The Transit secrets engine performs cryptographic operations on data in transit without storing it, so signing and verifying data is a core capability. It satisfies the stem's requirement for a valid use case by handling signing and verification through named encryption keys, keeping plaintext outside Vault entirely.

Why this answer

Option A is correct because the Transit secrets engine provides cryptographic operations as a service, including signing and verifying data via endpoints such as /transit/sign/:name and /transit/verify/:name, so applications can perform signature operations without handling raw signing keys. Option B is correct because Transit supports encryption and decryption through endpoints like /transit/encrypt/:name and /transit/decrypt/:name, allowing data to be encrypted in transit while the encryption key never leaves Vault. Option C is not the intended use case because Transit does not serve as a general-purpose key store; key storage is handled by other engines such as KV or by Vault's key management features, and Transit keys are used for cryptographic operations rather than being retrieved.

Option D is incorrect because Transit does not store encrypted data at rest; it only performs encryption/decryption operations, while data storage belongs to engines like KV. Option E is incorrect because X.509 certificate management is handled by the PKI secrets engine, not the Transit secrets engine.

Exam trap

HashiCorp often tests the distinction between 'performing cryptographic operations' (Transit) and 'storing secrets or keys' (KV), so the trap here is that candidates confuse the Transit engine's ability to store keys internally with the use case of storing keys for external retrieval.

Full explanation →

348

MCQeasy

A Vault cluster uses Consul for HA. After a brief network partition, a standby node loses contact with the active node. What does the standby node do after a timeout?

A.It becomes the active node.

B.It seals itself.

C.It continues to serve requests.

D.It replicates data from the storage backend.

AnswerB

When a standby node cannot reach the active node within the configured timeout, it seals itself, discarding the unwrapped master key from memory. This prevents serving requests with stale state and forces re-authentication against the new active node after the partition heals.

Why this answer

In a Vault cluster using Consul for high availability, only the active node serves requests. When a standby node loses contact with the active node due to a network partition, it cannot verify the active node's health or its own leadership status. After a configurable timeout (default 10 seconds), the standby node seals itself to prevent serving stale or inconsistent data, ensuring data integrity and security.

Exam trap

The trap here is that candidates assume a standby node will automatically take over as active during a partition, but Vault prioritizes safety over availability by sealing the standby to avoid split-brain scenarios.

How to eliminate wrong answers

Option A is wrong because Vault uses a leader election mechanism via Consul; a standby node cannot become active without confirming the previous active node is down, and during a network partition it cannot safely assume leadership. Option C is wrong because only the active node serves client requests; standby nodes are passive and do not handle any API or unseal operations. Option D is wrong because replication from the storage backend is a background process handled by the active node; standby nodes do not initiate replication and sealing halts all operations, including replication.

Full explanation →

349

MCQmedium

A Vault cluster uses performance replication. A performance standby node is not responding to read requests. What is the most likely cause?

A.Performance replication is not configured on this cluster.

B.The firewall is blocking inbound traffic to the standby node.

C.The performance standby node is sealed.

D.the performance standby node cannot connect to the primary for writes.

AnswerC

A sealed performance standby node cannot serve read requests because its barrier is active and its storage and API access are locked. Unsealing it restores read serving, which is the specific condition preventing responses here.

Why this answer

The performance standby node is sealed. In Vault, a sealed node cannot serve any requests, including read requests. Since the cluster uses performance replication, the standby node should be able to serve reads if it is unsealed.

The fact that it is not responding indicates it is likely sealed. Other options are less likely: A is false because the cluster uses performance replication; B, a firewall blocking inbound traffic would cause no response but is less common; D, inability to connect for writes would affect write forwarding but reads should still work from local data.

Exam trap

Candidates often overlook that performance standby nodes must be unsealed to serve any requests, assuming they can serve reads even when sealed because they hold replicated data. In reality, Vault requires a node to be unsealed to perform any operation.

How to eliminate wrong answers

Option B is wrong because a firewall blocking inbound traffic would prevent all requests to the standby node, not just read requests, and the question specifies only read requests are failing. Option C is wrong because if the performance standby node were sealed, it would not respond to any requests (reads or writes), and the question only mentions read requests failing. Option D is wrong because performance standby nodes do not handle writes; they only serve read requests from the primary's replicated data, so an inability to connect to the primary for writes is irrelevant to read request failures.

Full explanation →

350

MCQmedium

Refer to the exhibit. What seal mechanism is configured for this Vault instance?

A.AWS KMS auto-unseal

B.HSM seal via PKCS#11

C.Shamir seal with default shares

D.No seal; Vault is in insecure mode

AnswerA

The exhibit shows a seal stanza of type awskms with a KMS key ID and region, which is the auto-unseal configuration. Vault uses that AWS KMS key to decrypt the root key automatically at startup, removing the need for manual unseal keys.

Why this answer

The exhibit shows a Vault instance configured with `seal "awskms"` and a `region` and `kms_key_id` specified. This indicates that AWS KMS is used as the auto-unseal mechanism, where Vault delegates the unsealing process to AWS Key Management Service, eliminating the need for manual Shamir key shares.

Exam trap

HashiCorp often tests the distinction between default Shamir sealing and external auto-unseal mechanisms; the trap here is that candidates see a Vault configuration and assume it uses the default Shamir seal, missing the explicit `seal "awskms"` directive that overrides it.

How to eliminate wrong answers

Option B is wrong because HSM seal via PKCS#11 requires a hardware security module and configuration with `seal "pkcs11"`, not the `awskms` seal shown in the exhibit. Option C is wrong because Shamir seal with default shares is the default seal mechanism when no external seal is configured, but the exhibit explicitly shows `seal "awskms"`, overriding the default. Option D is wrong because Vault never runs in an insecure mode; it always requires a seal mechanism, and the exhibit confirms a seal is configured.

Full explanation →

351

MCQmedium

Refer to the exhibit. What is the purpose of the -field=ciphertext flag in this command?

A.It sets the ciphertext field for encryption.

B.It enables field-level encryption.

C.It specifies the encryption key name.

D.It outputs the command result to a file named ciphertext.

E.It instructs Vault to only return the ciphertext field from the response.

AnswerE

The `-field=ciphertext` flag filters Vault's JSON response to return only the ciphertext value, suppressing metadata such as key version and lease details. This satisfies the scenario's requirement for extracting the encrypted payload directly, enabling clean scripting without parsing the full response structure.

Why this answer

The `-field=ciphertext` flag in a Vault command instructs the CLI to extract and return only the value of the `ciphertext` key from the JSON response object. This is a standard Vault output filtering mechanism that allows users to isolate a specific field without parsing the full response, which is especially useful in scripting and automation.

Exam trap

HashiCorp often tests the distinction between output filtering (`-field`) and actual encryption configuration, leading candidates to confuse the flag with setting encryption parameters or enabling field-level encryption.

How to eliminate wrong answers

Option A is wrong because the flag does not set or configure the ciphertext field for encryption; it filters the output to show only that field. Option B is wrong because field-level encryption is a separate concept involving encrypting individual data fields within a record, not a CLI output filter. Option C is wrong because the encryption key name is specified via a different parameter (e.g., `-key` or `key_name`), not the `-field` flag.

Option D is wrong because the `-field` flag does not redirect output to a file; file output is achieved with shell redirection (`>`) or the `-output` flag.

Full explanation →

352

MCQeasy

A security engineer wants to ensure that all requests to Vault are logged for compliance. Which component must be configured?

A.Secrets Engine

B.Storage Backend

C.Audit Device

D.Auth Method

AnswerC

Configuring an audit device satisfies the compliance logging requirement, since Vault only records requests once at least one audit device is enabled. Each device receives every request and response, writing them to its configured destination, such as a file or syslog. Without an enabled audit device, Vault logs nothing, so no other component fulfils this mandate.

Why this answer

An audit device is the Vault component responsible for logging all requests and responses to a specified destination (e.g., syslog, file, socket). It must be enabled and configured to meet compliance requirements for recording every interaction with Vault. Without an audit device, Vault does not generate any persistent logs of API calls.

Exam trap

HashiCorp often tests the distinction between components that perform actions (secrets engines, auth methods) versus components that record actions (audit devices), leading candidates to confuse a functional component with a logging component.

How to eliminate wrong answers

Option A is wrong because a secrets engine (e.g., KV, AWS, database) manages the lifecycle of secrets but does not log requests; it is a target for operations, not a logging mechanism. Option B is wrong because a storage backend (e.g., Consul, Raft, file) persists Vault's encrypted data and configuration but does not capture request/response audit trails. Option D is wrong because an auth method (e.g., token, LDAP, OIDC) authenticates users or machines but does not produce compliance logs of subsequent Vault operations.

Full explanation →

353

Multi-Selectmedium

Which THREE are required for Vault to encrypt data at rest? (Choose three.)

Select 3 answers

A.Audit device

B.Barrier encryption key

C.Storage backend

D.Seal mechanism

E.Authentication method

AnswersB, C, D

The barrier key encrypts Vault's root key, which in turn protects every data encryption key, so no data at rest can be decrypted without it. This satisfies the stem's requirement for encryption at rest, since the barrier is the foundational cryptographic layer underpinning Vault's storage backend.

Why this answer

Vault requires a storage backend (C) because all encrypted data — secrets, tokens, and configuration — must be persisted somewhere, and Vault itself never stores plaintext there. The barrier encryption key (B) is the root cryptographic material used by Vault's barrier to encrypt and decrypt everything written to that storage backend, so without it no data-at-rest encryption is possible. A seal mechanism (D) is also required because Vault starts in a sealed state and the seal/unseal process protects the barrier key (typically via Shamir secret sharing or an auto-unseal KMS), controlling access to the encryption key.

An audit device (A) only logs requests and responses for compliance and is not needed to encrypt data at rest, and an authentication method (E) only verifies client identity to issue tokens, so neither is required for encryption at rest.

Exam trap

HashiCorp often tests the misconception that authentication methods or audit devices are involved in data encryption at rest, when in fact they serve orthogonal purposes (identity verification and logging, respectively) and are not part of the encryption pipeline.

Full explanation →

354

MCQeasy

An administrator wants to write a secret 'myapp' with value 'password=pass123' to the KV v2 secret engine mounted at 'secret/'. Which command should they use?

A.vault kv write secret/myapp password=pass123

B.vault kv create secret/myapp password=pass123

C.vault kv put secret/myapp password=pass123

D.vault write secret/myapp password=pass123

AnswerC

Writing to the KV v2 engine requires the `vault kv put` subcommand, which targets the versioned API rather than the legacy `vault write` path. Specifying `secret/myapp` places the secret at the mount point named in the stem, and the `password=pass123` pair supplies the key-value data correctly.

Why this answer

`vault kv put` is the proper command to write or update a secret in the KV v2 secrets engine. The KV v2 engine requires the `put` subcommand to create or overwrite a secret at the specified path, and the syntax `vault kv put secret/myapp password=pass123` correctly writes the key-value pair to the path `secret/myapp` under the mounted engine at `secret/`.

Exam trap

HashiCorp often tests the distinction between KV v1 (`vault write`) and KV v2 (`vault kv put`) commands, and the trap here is that candidates mistakenly use the generic `vault write` command (which works for KV v1 but not for KV v2) or invent non-existent subcommands like `write` or `create` under `vault kv`.

How to eliminate wrong answers

Option A is wrong because `vault kv write` is not a valid subcommand; the KV v2 engine uses `put` for writing secrets, not `write`. Option B is wrong because `vault kv create` is not a valid subcommand; the KV v2 engine does not have a `create` subcommand—secrets are written with `put` and optionally checked for existence with `get` or `metadata`. Option D is wrong because `vault write` targets the generic Vault API endpoint (used for KV v1 or other backends) and does not use the KV v2-specific subcommand structure; for KV v2, the correct CLI approach is `vault kv put`.

Full explanation →

355

MCQhard

A team has set up automatic key rotation on a transit key. After rotation, encrypted data that was encrypted with the previous key version can no longer be decrypted. What is the most likely cause?

A.The key was deleted

B.The key's min_decryption_version is set too high

C.The key's min_encryption_version is set too high

D.The team used the 'rewrap' operation incorrectly

E.The key is not exportable

AnswerB

Setting min_decryption_version above the previous key version's number causes the transit engine to refuse decryption with older versions. Vault retains old versions but enforces this floor, so raising it past the version that encrypted the data blocks access, matching the stem's post-rotation decryption failure.

Why this answer

The `min_decryption_version` setting on a transit key in Vault's transit secrets engine controls the minimum key version that can be used to decrypt ciphertext. If this value is set too high (e.g., to the current version), older key versions are effectively disabled for decryption, causing any data encrypted with a previous key version to become undecryptable. This is a common misconfiguration when automating key rotation without properly managing version policies in Vault.

Exam trap

Vault often tests the distinction between `min_encryption_version` and `min_decryption_version` in the transit engine, trapping candidates who confuse the two or assume that key rotation automatically invalidates old decryption capabilities.

How to eliminate wrong answers

Option A is wrong because deleting the key would make all data encrypted with any version of that key permanently undecryptable, not just data encrypted with the previous version. Option C is wrong because `min_encryption_version` controls which key version can be used for new encryption operations, not decryption of existing ciphertext. Option D is wrong because the `rewrap` operation (e.g., `ReEncrypt` in AWS KMS) is used to re-encrypt data under a new key version without exposing plaintext; using it incorrectly would not cause decryption failures for data encrypted with the previous version.

Option E is wrong because the exportability of a key affects whether the key material can be exported from the service, not whether ciphertext can be decrypted using the key versions stored within the service.

Full explanation →

356

Multi-Selecteasy

Which TWO of the following are features of the AWS secrets engine compared to the Azure secrets engine?

Select 2 answers

A.Supports federation via SAML with Azure AD

B.Provides native integration with Azure Key Vault for key management

C.Allows connection to AWS via IAM instance profiles

D.Can generate IAM users with custom policies

E.Can generate STS temporary credentials for cross-account access

AnswersD, E

The AWS secrets engine can mint IAM users, attaching custom policies that scope permissions per credential. The Azure secrets engine issues service principals and role assignments instead, so per-request custom policy generation is unique to AWS.

Why this answer

Option D is correct because the Vault AWS secrets engine can dynamically create IAM users and attach custom IAM policies to them, giving fine-grained, per-credential permissions that the Azure secrets engine (which issues service principals/roles) does not provide in the same IAM-user form. Option E is correct because the AWS secrets engine can issue STS temporary credentials via AssumeRole, including cross-account access through role ARNs, a capability specific to AWS's STS model and not offered by the Azure secrets engine. Option A is incorrect because SAML federation with Azure AD is an Azure/identity-provider feature, not a capability of the AWS secrets engine.

Option B is incorrect because native Azure Key Vault integration belongs to the Azure secrets engine, not the AWS one. Option C is incorrect because IAM instance profiles are used by EC2 instances to obtain credentials from the instance metadata service, not a connection method exposed as a feature of the Vault AWS secrets engine.

Exam trap

HashiCorp often tests the distinction between the AWS and Azure secrets engines, and the trap here is confusing the AWS engine's ability to generate IAM users and STS tokens with Azure-specific features like SAML federation or Key Vault integration.

Full explanation →

357

MCQmedium

An organization uses Kubernetes pods to access Vault. They want to avoid hardcoding any secrets in the pod definition. Which authentication method should they use?

A.LDAP

B.Kubernetes

C.Username & Password

D.AppRole

AnswerB

Vault's Kubernetes auth method validates the pod's projected service account token against the Kubernetes TokenReview API, mapping it to a Vault role and policy. No static credentials are embedded in the pod definition, satisfying the no-hardcoded-secrets constraint.

Why this answer

The Kubernetes authentication method is correct because it allows pods to authenticate to Vault using their service account token, which is automatically mounted into the pod. This eliminates the need to hardcode any secrets in the pod definition, as Vault verifies the token against the Kubernetes API server and issues a temporary Vault token based on the pod's identity.

Exam trap

HashiCorp often tests the misconception that AppRole is the best choice for automated workloads, but the trap here is that AppRole still requires a SecretID to be stored somewhere (e.g., a Kubernetes Secret), whereas Kubernetes auth uses the pod's own identity to eliminate any hardcoded secrets entirely.

How to eliminate wrong answers

Option A is wrong because LDAP authentication requires a username and password or LDAP bind credentials, which would still need to be stored in the pod definition or an external secret store, defeating the purpose of avoiding hardcoded secrets. Option C is wrong because Username & Password authentication requires embedding static credentials in the pod definition or environment variables, directly violating the requirement to avoid hardcoding secrets. Option D is wrong because AppRole requires a RoleID and a SecretID; while the RoleID can be injected via annotations, the SecretID is a sensitive credential that must be stored securely (e.g., in a Kubernetes secret), which still involves hardcoding or managing secrets outside Vault's native pod identity integration.

Full explanation →

358

Multi-Selecteasy

A DevOps team is setting up a Vault cluster for the first time. They plan to use AWS KMS for auto-unseal and Consul as the storage backend. As part of the architecture, which TWO components are essential for the Vault server to start and serve requests?

Select 2 answers

A.A public CA certificate

B.A storage backend

C.A configured seal mechanism

D.A 4096-bit encryption key

E.A load balancer

AnswersB, C

Consul provides durable, highly available storage for Vault's encrypted data, and Vault cannot initialise or unseal without a configured storage backend. The stem specifies Consul as that backend, making it essential for the server to start and serve requests.

Why this answer

Option B (a storage backend) is essential because Vault persists all data — secrets, policies, tokens, and configuration — in its storage backend, and here that is Consul; without a working storage backend Vault cannot initialize or serve requests. Option C (a configured seal mechanism) is essential because Vault must be able to unseal its master key to decrypt the barrier and become active; in this scenario the seal mechanism is AWS KMS auto-unseal, which is required for the server to reach a serving state. Option A is not required because Vault can use an internal/self-signed certificate or none at all for basic operation; a public CA cert is only needed for trusted TLS clients.

Option D is incorrect because Vault generates its own encryption keys internally (e.g., the master key and barrier key) rather than requiring an externally supplied 4096-bit key. Option E is not essential because a load balancer is only for distributing traffic across multiple Vault nodes, not for a single server to start and serve requests.

Exam trap

A common misconception is that the seal mechanism alone is sufficient for Vault to start, but the storage backend is equally essential because it holds the encrypted master key and all persistent data.

Full explanation →

359

MCQeasy

Refer to the exhibit. A user wants to write a secret 'db_password' with value 's3cret' to this secrets engine. Which CLI command should be used?

A.vault write shared/db_password value=s3cret

B.vault write shared/data/db_password value=s3cret

C.vault write shared/metadata/db_password value=s3cret

D.vault write shared/config/db_password value=s3cret

AnswerB

This is correct because in Vault's KV v2 secrets engine, secrets are written to the 'data' sub-path. The command 'vault write shared/data/db_password value=s3cret' targets the data endpoint for the secret 'db_password' under the 'shared' mount.

Why this answer

In Vault's KV v2 secrets engine, secrets are stored under the 'data' path. The correct CLI command to write a secret is 'vault write shared/data/db_password value=s3cret', which targets the data endpoint for the secret 'db_password' in the 'shared' mount.

Exam trap

HashiCorp often tests the distinction between KV v1 and v2 paths, and the trap here is that candidates assume the secret can be written directly to the mount path (e.g., 'shared/db_password') without the '/data/' prefix, which only works in KV v1.

How to eliminate wrong answers

Option A is wrong because 'vault write shared/db_password' targets the root of the mount, not the data path, and KV v2 requires the '/data/' prefix to write secret data. Option C is wrong because 'vault write shared/metadata/db_password' is used for metadata operations (like configuring versions or deletion settings), not for writing the secret value itself. Option D is wrong because 'vault write shared/config/db_password' is not a valid path; 'config' is used for engine configuration (e.g., max versions), not for individual secrets.

Full explanation →

360

Multi-Selectmedium

A security team is evaluating the Vault transit secrets engine as an encryption-as-a-service platform for several applications. They want to understand which capabilities the transit engine actually provides. (Choose two.)

Select 2 answers

A.It can validate the integrity of data by generating and verifying HMAC signatures.

B.It can perform cryptographic operations on data without persisting that data.

C.It can serve as a transparent proxy that encrypts traffic between microservices on the network.

D.It can generate and manage database credentials for PostgreSQL and MySQL.

E.It can dynamically issue X.509 certificates from an internal certificate authority.

AnswersA, B

Transit keys can produce HMACs through the `hmac` endpoint and verify them through `hmac/verify`, allowing applications to detect tampering without exposing key material. This supports integrity checks alongside encryption, which is a documented capability of the transit engine.

Why this answer

The transit engine provides cryptographic services over its API without persisting the data it processes, and it can generate and verify HMACs in addition to encrypting and decrypting. Dynamic database credentials, X.509 certificate issuance, and network traffic proxying belong to other secrets engines or external components, so they are outside the transit engine's scope.

Exam trap

The trap here is conflating the transit engine with other secrets engines, assuming it issues credentials or certificates because it lives inside the same Vault server.

Full explanation →

361

MCQeasy

An organization wants to encrypt data at rest in a cloud storage bucket. They plan to use Vault's transit engine to generate a data key and then encrypt the data locally. Which transit endpoint should they use to get a data key?

A.POST /v1/transit/datakey/plaintext/my-key

B.POST /v1/transit/encrypt/my-key

C.POST /v1/transit/decrypt/my-key

D.POST /v1/transit/datakey/ciphertext/my-key

AnswerA

The datakey endpoint returns a newly generated plaintext data key plus its wrapped ciphertext, letting the caller encrypt data locally while Vault retains the wrapping key. This satisfies the requirement to obtain a data key for local encryption.

Why this answer

The correct endpoint to retrieve a data key that can be used for local client-side encryption is POST /v1/transit/datakey/plaintext/my-key. This endpoint returns both the plaintext data key (for local encryption) and the ciphertext version of the key (for secure storage alongside the encrypted data). The 'plaintext' in the path indicates that the response includes the key in plaintext form, which is necessary for performing encryption locally.

Exam trap

HashiCorp often tests the distinction between 'datakey/plaintext' and 'datakey/ciphertext' endpoints, where candidates mistakenly choose the ciphertext-only endpoint thinking it provides the key for local encryption, but it actually omits the plaintext key required for that purpose.

How to eliminate wrong answers

Option B is wrong because POST /v1/transit/encrypt/my-key is used to encrypt an existing piece of data using Vault's transit engine, not to generate a new data key. Option C is wrong because POST /v1/transit/decrypt/my-key is used to decrypt ciphertext that was previously encrypted by the transit engine, not to generate a data key. Option D is wrong because POST /v1/transit/datakey/ciphertext/my-key returns only the ciphertext version of the data key, not the plaintext key needed for local encryption; this endpoint is used when the client only needs to store the key and does not need to perform local encryption.

Full explanation →

362

MCQhard

A Vault cluster has a token with the following policy: path "secret/data/dev/*" { capabilities = ["read", "list"] }. The token is used to read a secret at "secret/data/dev/password". The read succeeds. Later, the token tries to read "secret/data/prod/password". What happens?

A.Fails with a system error.

B.Succeeds because token has read capability on all secrets.

C.Succeeds because the token can list and read any path.

D.Fails because the token needs an explicit policy for "secret/data/prod/".

AnswerD

Vault policies are deny by default, so the token's capabilities apply only to paths matching `secret/data/dev/*`. Reading `secret/data/prod/password` falls outside that glob, and no other policy grants access, so the request is denied. The stem's constraint — a single dev-scoped policy — makes the prod read fail.

Why this answer

Vault policies are path-based and deny by default. The token's policy only grants 'read' and 'list' capabilities on paths matching 'secret/data/dev/*', so any attempt to access 'secret/data/prod/password' is not covered by that policy. Without an explicit policy allowing access to the 'prod' path, the request is denied by Vault's default deny behavior.

Exam trap

A common misconception is that a token with read capability on one path can read any secret, but Vault's policy model requires explicit path matching for each access attempt.

How to eliminate wrong answers

Option A is wrong because a denied request due to missing policy does not produce a system error; Vault returns a permission denied response (HTTP 403). Option B is wrong because Vault tokens do not have implicit read capability on all secrets; capabilities are strictly defined by attached policies. Option C is wrong because the token's 'list' and 'read' capabilities are scoped only to the 'secret/data/dev/*' path, not to any arbitrary path.

Full explanation →

363

MCQmedium

A security engineer is enabling the Transit secrets engine at the path 'transit/'. They need to encrypt data without ever exposing the plaintext key material to the application, and they want the ciphertext to be safely stored in an external database. They also require the ability to rotate the encryption key periodically without re-encrypting existing data. Which command correctly configures a new encryption key named 'orders' for this purpose?

A.vault write -f transit/keys/orders

B.vault write transit/encrypt/orders plaintext=$(base64 <<< "my secret")

C.vault write transit/keys/orders type=rsa-2048

D.vault secrets enable -path=orders transit

AnswerA

This command creates a named encryption key in the Transit secrets engine at the path transit/keys/orders. The -f flag forces the write without requiring data, which is appropriate because the key is generated by Vault. The key can then be used for encrypt/decrypt operations, and Vault manages the key material internally, supporting rotation and versioning without exposing plaintext.

Why this answer

The Transit secrets engine centralizes encryption as a service, allowing applications to encrypt data without managing keys. To create a new named encryption key, the correct command is 'vault write -f transit/keys/orders', which generates a key of the default type (aes256-gcm96) and enables encryption, decryption, and rotation. This satisfies the requirement of not exposing key material and supporting future rotation.

Exam trap

The trap here is confusing the command to enable a secrets engine with the command to create a key within an already enabled engine.

Full explanation →

364

Multi-Selectmedium

Which THREE are valid operations in the Vault transit secrets engine? (Choose three.)

Select 3 answers

A.issue

B.revoke

C.rewrap

D.decrypt

E.encrypt

AnswersC, D, E

Rewrap decrypts ciphertext with an existing key version and re-encrypts it under the latest version, without exposing plaintext to the caller. This satisfies the stem's requirement for a valid transit operation, alongside encrypt and decrypt, by enabling key-version upgrades.

Why this answer

The Vault transit secrets engine is a cryptographic service that performs encryption/decryption operations on data in transit without storing the data itself, so option E (encrypt) is valid because it lets clients submit plaintext and receive ciphertext using a named encryption key, and option D (decrypt) is valid because it reverses that operation to recover plaintext from ciphertext. Option C (rewrap) is also valid: it decrypts ciphertext with an older key version and re-encrypts it with the latest key version in a single operation, which is useful for key rotation without exposing plaintext to the client. Options A (issue) and B (revoke) are not transit operations; issuing and revoking credentials are functions of secrets engines such as PKI (issue/revoke certificates) or the various dynamic secrets engines (e.g., database, AWS), not the transit engine, whose API endpoints are encrypt, decrypt, rewrap, datakey, hmac, sign, verify, and related key-management paths.

Exam trap

HashiCorp often tests candidates by mixing terms from different Vault secrets engines (e.g., PKI 'issue/revoke' with transit 'encrypt/decrypt') to see if you can distinguish the specific operations each engine supports.

Full explanation →

365

MCQmedium

A security administrator wants to create a policy that allows a service to renew its own token and list its own token capabilities, but not create new tokens. Which policy statements should be included?

A.path "auth/token/renew-self" { capabilities = ["update"] }; path "auth/token/capabilities-self" { capabilities = ["read"] }

B.path "auth/token/renew-self" { capabilities = ["create"] }; path "auth/token/lookup-self" { capabilities = ["read"] }

C.path "auth/token/renew-self" { capabilities = ["update"] }; path "auth/token/capabilities-self" { capabilities = ["update"] }

D.path "auth/token/renew" { capabilities = ["update"] }; path "auth/token/capabilities" { capabilities = ["read"] }

AnswerA

Renewing a token maps to the update capability on `auth/token/renew-self`, while listing capabilities requires read on `auth/token/capabilities-self`. Both paths are self-scoped, so the service acts only on its own token, satisfying the constraint that it must not create new tokens.

Why this answer

It uses the correct endpoints and capabilities: update for renew-self and read for capabilities-self. Option B uses create for renew-self, which is incorrect (renew-self requires update). Option C uses update for capabilities-self, which is wrong (capabilities-self requires read).

Option D uses non-self endpoints (renew and capabilities) which would allow renewing or checking capabilities of any token, granting broader privileges than intended.

Full explanation →

366

Drag & Dropmedium

Drag and drop the steps to perform a Vault disaster recovery using the replication feature into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Initialize clusters, enable primary replication, generate token, enable secondary, promote if needed.

Full explanation →

HashiCorp Vault Associate VA-003 (VA-003) — Questions 301–366