Courseiva

HashiCorp Vault Associate VA-003 (VA-003) — Questions 226–300

498 questions total · 7pages · All types, answers revealed

Take a mock examExam hub
Page 3

Page 4 of 7

Page 5
226
MCQmedium

A DevOps team generates a large number of short-lived tokens for automated deployments. They want to minimize storage overhead and avoid the need for token revocation. Which token type should they use?

A.Periodic tokens
B.Orphan tokens
C.Service tokens
D.Batch tokens
AnswerD

Batch tokens are not stored and have no revocation, ideal for short-lived automated tasks.

Why this answer

Batch tokens are the correct choice because they are designed for high-frequency, short-lived workloads where storage overhead and revocation are concerns. They are created by a parent token, have a configurable TTL (often minutes), and are never stored in Vault's storage backend, eliminating the need for revocation and reducing storage footprint.

Exam trap

The trap here is that candidates confuse 'batch tokens' with 'service tokens' or assume all tokens require revocation, but the exam tests the specific understanding that batch tokens are stateless and avoid storage overhead, a key differentiator for high-volume automation scenarios.

How to eliminate wrong answers

Option A is wrong because 'Periodic tokens' are not a standard Vault token type; the correct term is 'periodic service tokens' which are long-lived and require explicit renewal, not suited for short-lived automated deployments. Option B is wrong because 'Orphan tokens' are tokens that have lost their parent relationship but still exist in storage and can be revoked, offering no storage or revocation benefit. Option C is wrong because 'Service tokens' are the default token type in Vault, which are stored in the backend and require revocation, thus increasing storage overhead and management complexity.

Full explanation →
227
MCQhard

Refer to the exhibit. A developer reports that a token they created using `vault token create -policy=my-policy -ttl=2h` is no longer working after 1 hour. The token lookup output shows the token details. What is the most likely cause?

A.The token's max_ttl was set to 1h when created, and the token reached its max_ttl.
B.The token has num_uses set to 0, meaning it can only be used once.
C.The token is a service token and cannot be renewed.
D.The token is an orphan token and requires the parent token to be valid.
AnswerA

If max_ttl is less than the requested TTL, the token will expire at max_ttl, causing it to stop working after 1 hour.

Why this answer

The token was created with a `-ttl=2h` but the token lookup output shows `max_ttl=1h`. The `max_ttl` is an upper limit enforced by the token's configuration or the system's maximum TTL setting. Even though the requested TTL was 2 hours, the token's effective lifetime is capped by the lower of the two values, so it expired after 1 hour.

Exam trap

HashiCorp often tests the distinction between `ttl` and `max_ttl`, where candidates mistakenly assume the token will last for the full `ttl` value without checking the overriding `max_ttl` limit.

How to eliminate wrong answers

Option B is wrong because `num_uses` set to 0 means the token has unlimited uses, not that it can be used only once. Option C is wrong because service tokens can be renewed unless explicitly configured with `explicit_max_ttl` or a non-renewable flag; the issue here is TTL expiration, not renewability. Option D is wrong because orphan tokens do not depend on a parent token for validity; they are standalone tokens that are not revoked when the parent is revoked.

Full explanation →
228
MCQeasy

What is the primary purpose of the Vault transit secrets engine?

A.Encryption and decryption as a service
B.Token generation
C.Certificate management
D.Dynamic database credentials
E.Secure storage of secrets
AnswerA

Transit engine is designed for cryptographic operations.

Why this answer

The Vault transit secrets engine is designed to provide encryption and decryption as a service, allowing applications to encrypt and decrypt data without managing cryptographic keys directly. It offloads the cryptographic operations to Vault, which securely stores and rotates the encryption keys, ensuring that plaintext data never leaves the application unencrypted. This enables centralized key management and policy-based access control for encryption operations.

Exam trap

HashiCorp often tests the distinction between 'encryption as a service' (transit engine) and 'secure storage of secrets' (KV engine), leading candidates to mistakenly choose Option E because they conflate encrypting data at rest with storing secrets.

How to eliminate wrong answers

Option B is wrong because token generation is the primary function of Vault's token authentication method or the token helper, not the transit secrets engine. Option C is wrong because certificate management is handled by the Vault PKI secrets engine, which issues and manages X.509 certificates, not the transit engine. Option D is wrong because dynamic database credentials are provided by the database secrets engine, which generates temporary credentials for databases, not encryption services.

Option E is wrong because secure storage of secrets is the core purpose of Vault's generic KV (Key-Value) secrets engine or the overall Vault platform, while the transit engine specifically focuses on cryptographic operations.

Full explanation →
229
Multi-Selecthard

Which TWO of the following scenarios require the use of a periodic token?

Select 2 answers
A.A token that never expires and has a TTL of 0.
B.A human operator who needs a token that can be used for multiple sessions.
C.A batch job that must continue running even if the parent token is revoked.
D.A token that should not be revoked when the token that created it is revoked.
E.A long-running application that needs a token that can be renewed indefinitely.
AnswersC, E

Periodic tokens are not children of a parent token; they are created by sudo users and are independent.

Why this answer

A periodic token is designed to allow a child token (e.g., for a batch job) to continue operating even after its parent token is revoked. This is achieved by setting the token's period to a finite duration, which decouples the child token's lifecycle from the parent's, enabling the batch job to run to completion without interruption.

Exam trap

HashiCorp often tests the distinction between periodic tokens and renewable tokens, trapping candidates who think periodic tokens are for multi-session human use or that they require a TTL of 0, when in fact periodic tokens are for automated, long-lived processes that must outlive their parent.

Full explanation →
230
MCQeasy

A new Vault administrator unseals Vault using a single unseal key, but the Vault remains sealed. What is the most likely cause?

A.The storage backend is misconfigured, preventing key retrieval.
B.The administrator did not provide enough unseal keys to meet the threshold.
C.The administrator forgot to provide a valid token.
D.Vault needs to be re-initialized after the first unseal.
AnswerB

Shamir seal requires a threshold number of unseal keys.

Why this answer

Vault uses a threshold-based unsealing mechanism where a minimum number of unseal keys (the threshold) must be provided to reconstruct the master key and decrypt the storage backend. Providing only a single key, even if it is valid, leaves the Vault sealed because the threshold has not been met. The administrator must continue providing distinct unseal keys until the threshold count is reached.

Exam trap

HashiCorp often tests the misconception that a single unseal key is enough to unseal Vault, confusing the concept of a single key with the threshold requirement, or conflating unsealing with authentication via tokens.

How to eliminate wrong answers

Option A is wrong because a misconfigured storage backend would typically cause Vault to fail to start or to lose data, but it does not prevent the unseal process from accepting keys; the error here is specifically about the number of keys provided. Option C is wrong because tokens are used for authentication and authorization after Vault is unsealed, not during the unseal process itself; unsealing only requires unseal keys. Option D is wrong because Vault does not need to be re-initialized after the first unseal; initialization is a one-time process that generates the unseal keys and root token, and subsequent unseals use those same keys.

Full explanation →
231
Multi-Selecteasy

A company wants to encrypt sensitive data at rest in its application using HashiCorp Vault. They need to ensure that each application instance uses a unique encryption key without storing keys locally. Which TWO actions should the security team take to meet these requirements?

Select 2 answers
A.Create a separate transit key for each application instance.
B.Enable key derivation on the transit key.
C.Enable automatic key rotation on the transit key.
D.Store encryption keys in the KV secrets engine.
E.Use the transit secrets engine to encrypt data.
AnswersB, E

Allows deriving unique keys per context without storing them.

Why this answer

Enabling key derivation on a transit key allows each application instance to derive a unique encryption key from a single master key using a context value. This ensures that each instance uses a distinct key without storing keys locally, as the derived key is never persisted and is computed on-the-fly during encryption and decryption operations.

Exam trap

The VA-003 exam often tests the distinction between key derivation (which creates unique per-instance keys from a single master key) and key rotation (which changes the key over time but does not provide uniqueness per instance), leading candidates to mistakenly select automatic key rotation as the solution.

Full explanation →
232
MCQeasy

An administrator has created a policy file named 'app-policy.hcl'. Which command should they use to upload this policy to Vault?

A.vault write sys/policy/app-policy @app-policy.hcl
B.vault create policy app-policy app-policy.hcl
C.vault set policy app-policy app-policy.hcl
D.vault policy write app-policy app-policy.hcl
AnswerD

This is the correct CLI command to write a policy.

Why this answer

The `vault policy write` command is the standard Vault CLI command to create or update a policy from a file. The syntax `vault policy write <name> <path>` reads the HCL or JSON policy definition from the specified file and writes it to Vault's policy storage.

Exam trap

HashiCorp often tests the exact CLI syntax for Vault policy management, and the trap here is that candidates confuse the generic `vault write` API call with the dedicated `vault policy write` command, or they invent non-existent commands like `vault create policy` or `vault set policy`.

How to eliminate wrong answers

Option A is wrong because `vault write sys/policy/app-policy @app-policy.hcl` uses the raw API endpoint but the correct CLI command for policy management is `vault policy write`, not a direct write to the sys/policy path. Option B is wrong because `vault create policy` is not a valid Vault CLI command; the correct command uses `vault policy write`. Option C is wrong because `vault set policy` does not exist in the Vault CLI; the correct verb is `write` for policy operations.

Full explanation →
233
Multi-Selecteasy

Which TWO of the following are valid uses of a token accessor? (Select exactly 2 options.)

Select 2 answers
A.Wrap the token
B.Create a child token
C.Renew the token
D.Lookup token properties
E.Revoke the token
AnswersD, E

The accessor can be used to lookup token metadata.

Why this answer

A token accessor is a non-sensitive reference to a Vault token that allows certain operations without exposing the token ID itself. The `lookup` and `revoke` operations are valid uses of a token accessor because they can be performed using the accessor via the Vault API or CLI (e.g., `vault token lookup -accessor <accessor>` and `vault token revoke -accessor <accessor>`). These operations do not require the actual token value, preserving security while enabling token management.

Exam trap

Candidates often mistakenly think that a token accessor can be used for all token management operations, when in reality it is strictly limited to lookup and revocation, and cannot be used for wrapping, renewal, or child token creation.

Full explanation →
234
MCQmedium

An organization uses Vault to manage SSH access via the SSH secrets engine. They have a large number of servers, each with a unique host key. The admin configures the SSH secrets engine with a one-time password (OTP) type. Users report that sometimes they cannot authenticate to some servers because the OTP is not accepted. The admin reviews the logs and finds that the server's SSH daemon is not contacting Vault to verify the OTP. The SSH daemon is configured with the Vault SSH helper. What is the most likely cause?

A.The SSH secrets engine's default TTL is too short.
B.The Vault server is under high load and dropping requests from SSH helpers.
C.The SSH helper's client certificate is expired or not properly configured.
D.The Vault server's IP address has changed and the SSH helper is using the old address.
AnswerC

Certificate issues prevent authentication to Vault.

Why this answer

The SSH helper is a client-side component that must authenticate to Vault using a client certificate (mTLS) before it can verify OTPs. If this certificate is expired or misconfigured, the SSH daemon cannot establish a trusted connection to Vault, causing OTP verification to fail silently. This directly explains why the server is not contacting Vault despite the helper being installed.

Exam trap

HashiCorp often tests the distinction between network connectivity failures (wrong IP, high load) and authentication/authorization failures (expired certificates, misconfigured tokens) — the trap here is assuming a connectivity issue when the root cause is a TLS handshake failure due to an expired client certificate.

How to eliminate wrong answers

Option A is wrong because a short TTL would cause the OTP to expire before use, but the logs show the SSH daemon is not contacting Vault at all — not that the OTP is valid but expired. Option B is wrong because high load on Vault would result in delayed or dropped responses, but the SSH helper would still initiate the connection; the logs indicate no contact is made, not that requests are being dropped. Option D is wrong because if the Vault server IP changed, the SSH helper would fail to connect with a network error (e.g., connection refused or timeout), but the logs would show an attempted connection; the issue is that no contact is made, implying a TLS authentication failure rather than a network reachability problem.

Full explanation →
235
Multi-Selecteasy

Which TWO statements about Vault's Storage Backend are correct?

Select 2 answers
A.It stores encrypted data
B.It logs all requests
C.It is abstracted and can be swapped
D.It handles authentication of clients
E.It is responsible for encrypting data
AnswersA, C

Data is encrypted by the barrier before storage.

Why this answer

Vault's Storage Backend is responsible for persisting encrypted data. Vault encrypts all data at the application layer before writing it to the storage backend, ensuring that the backend itself never sees plaintext secrets. This design means the storage backend is a 'sealed box' that only stores ciphertext, providing defense in depth even if the backend is compromised.

Exam trap

HashiCorp often tests the misconception that the storage backend handles encryption or authentication, when in fact it is a passive, abstracted layer that only stores encrypted data and can be swapped without affecting Vault's core operations.

Full explanation →
236
MCQhard

A company has multiple Vault clusters in different regions. They want to use the replication feature to synchronise secrets across clusters. However, they want to exclude a specific secrets engine from replication for compliance reasons. What should they do?

A.Create a separate Vault cluster for that secrets engine.
B.Disable replication on that specific mount.
C.Use disaster recovery (DR) replication and exclude the mount.
D.Use performance replication and configure a mount filter.
AnswerD

Performance replication supports mount filtering with path_filter.

Why this answer

Performance replication in Vault allows you to replicate secret data across clusters while using mount filters to include or exclude specific secrets engines. This is the correct approach because mount filters are designed precisely for this use case, enabling selective replication to meet compliance requirements without creating separate infrastructure.

Exam trap

HashiCorp often tests the distinction between performance replication (which supports mount filters) and DR replication (which does not), leading candidates to incorrectly choose DR replication when the requirement is selective exclusion.

How to eliminate wrong answers

Option A is wrong because creating a separate Vault cluster for a single secrets engine adds unnecessary operational complexity and cost, and does not leverage the built-in replication filtering capabilities. Option B is wrong because disabling replication on a mount is not a supported operation; replication operates at the cluster level, not per mount, and you cannot disable it for individual mounts without using mount filters. Option C is wrong because disaster recovery (DR) replication is designed for failover and does not support mount filters; it replicates all data and cannot exclude specific mounts.

Full explanation →
237
Drag & Dropmedium

Drag and drop the steps to configure Vault's PKI secrets engine to issue certificates into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The correct sequence to configure Vault's PKI secrets engine for issuing certificates is: first enable the PKI secrets engine, then generate a root certificate (self-signed CA), then create a role that defines certificate parameters, and finally issue a certificate using that role. Enabling the engine mounts it at a path, generating the root CA establishes the trust anchor, the role configures certificate properties, and the issuance step produces the actual certificate. Common mistakes include attempting to generate the root or create a role before enabling the engine, or creating the role before generating the root CA, which leads to errors or missing configurations.

Full explanation →
238
MCQmedium

An operator wants to enable the database secrets engine at a custom path 'db-creds'. Which command should be used?

A.vault secrets enable database
B.vault secrets enable -path=db-creds database
C.vault write sys/mounts/db-creds type=database
D.vault secrets tune -path=db-creds database
AnswerB

This correctly enables the database secrets engine at the 'db-creds' path.

Why this answer

The `vault secrets enable` command with the `-path` flag allows you to mount the database secrets engine at a custom path. The syntax `vault secrets enable -path=db-creds database` correctly specifies the custom path and the engine type, enabling the database secrets engine at the desired location.

Exam trap

HashiCorp often tests the distinction between enabling a secrets engine (`vault secrets enable`) and tuning an existing mount (`vault secrets tune`), trapping candidates who confuse the two or think `vault write` can be used to enable engines directly.

How to eliminate wrong answers

Option A is wrong because `vault secrets enable database` mounts the engine at the default path (`database/`), not at the custom path `db-creds`. Option C is wrong because `vault write sys/mounts/db-creds type=database` is not a valid command; the correct API endpoint for enabling a secrets engine is `sys/mounts/<path>` with a POST request, but the CLI does not use `vault write` for this purpose—it uses `vault secrets enable`. Option D is wrong because `vault secrets tune` is used to modify configuration of an existing mount, not to enable a new secrets engine; it cannot create a new mount at a custom path.

Full explanation →
239
MCQmedium

Refer to the exhibit. A user has a token with a policy that grants 'read' on 'secret/*'. The user attempts to read the secret at 'secret/data/app' using `vault kv get secret/data/app` but receives a '404 Not Found' error. The user can successfully list the engine at 'secret/' with `vault secrets list`. What is the most likely cause of the 404 error?

A.The secrets engine is KV v1, but the user is using the KV v2 path format with '/data/'.
B.The user's policy does not cover the sub-path 'secret/data/app'.
C.The secret path is mistyped; it should be 'secret/application'.
D.The secret engine at 'secret/' is not enabled.
AnswerA

KV v1 secrets are accessed without '/data/'; KV v2 uses '/data/'. The exhibit confirms v1.

Why this answer

The KV v2 secrets engine requires the path format `secret/data/<path>` for reading secret data, while KV v1 uses `secret/<path>` directly. The user is using `vault kv get secret/data/app`, which is the correct command for KV v2, but the error indicates the engine is actually KV v1. Since KV v1 does not have a `/data/` prefix, the path `secret/data/app` does not exist, resulting in a 404 Not Found error.

The successful `vault secrets list` confirms the engine is enabled at `secret/`, ruling out option D.

Exam trap

HashiCorp Vault often tests the distinction between KV v1 and KV v2 path formats, and the trap here is that candidates assume a 404 error always means the secret doesn't exist or permissions are wrong, rather than recognizing the `/data/` prefix is only valid for KV v2 engines.

How to eliminate wrong answers

Option B is wrong because the policy grants 'read' on 'secret/*', which covers all sub-paths including 'secret/data/app', so the 404 is not a permissions issue. Option C is wrong because the error is not about a mistyped path name; the user's path 'secret/data/app' is syntactically valid for KV v2 but fails due to engine version mismatch. Option D is wrong because the user can list the engine with `vault secrets list`, proving the engine is enabled at 'secret/'.

Full explanation →
240
MCQhard

An administrator wants to audit token usage without exposing the actual token IDs to auditors. Which approach should they use?

A.Enable audit logging without any modifications
B.Use token accessors in audit logs
C.Use the token lookup API for each audit event
D.Use response wrapping to encapsulate tokens
AnswerB

Token accessors are safe for logging and can be used to revoke or look up metadata without the token ID.

Why this answer

Token accessors are non-sensitive, randomly generated identifiers that are mapped one-to-one with actual Vault tokens. By logging the accessor instead of the token ID, administrators can audit token usage (e.g., lookup, renewal, revocation) without exposing the token itself, which could be used to authenticate. This approach satisfies the requirement of auditing without compromising security.

Exam trap

The trap here is that candidates confuse token accessors with response wrapping, thinking both are used to 'hide' tokens, but response wrapping is a delivery mechanism, not an audit anonymization feature.

How to eliminate wrong answers

Option A is wrong because enabling audit logging without modifications logs the actual token IDs, which directly exposes sensitive credentials to auditors. Option C is wrong because using the token lookup API for each audit event would require the token ID to be present in the audit context, defeating the purpose of hiding it, and it is not a scalable or real-time auditing mechanism. Option D is wrong because response wrapping is used to securely deliver secrets or tokens to a client via a one-time unwrap operation, not to anonymize token IDs in audit logs.

Full explanation →
241
MCQeasy

A token with the above policy attempts to look up its own token by calling the accessor endpoint. What will happen?

A.The operation succeeds because the token can read its own token
B.The operation fails with a permission denied error
C.The operation succeeds because sudo allows all accessor operations
D.The operation fails because the token lacks any capabilities
AnswerB

The policy does not cover the accessor endpoint.

Why this answer

The policy grants sudo on 'auth/token/lookup', but the endpoint for lookup by accessor is 'auth/token/lookup-accessor', which is a different path. Therefore, this policy does not allow that operation. Option A is wrong because the path is different.

Option C is wrong because the policy does not have read or create on the correct path. Option D is wrong because the token has capabilities, just not on the required path.

Full explanation →
242
MCQeasy

A company runs Vault in a single cluster with three nodes using the Raft storage backend. The nodes are behind a load balancer that distributes traffic to all nodes. The operations team notices that occasionally, write operations (e.g., writing a secret or creating a policy) fail with a '502 Bad Gateway' error, while read operations succeed. The Vault audit logs show no errors. The load balancer health checks are configured to check the /v1/sys/health endpoint with a 200 response expected. The Vault nodes are all unsealed and the cluster is healthy. Which of the following is the most likely cause of the intermittent write failures?

A.The Raft storage backend does not support write operations.
B.The load balancer is sending write requests to standby nodes, which cannot handle writes.
C.The load balancer is not configured to use the /v1/sys/leader endpoint for routing.
D.One of the Vault nodes is sealed, causing write requests to fail.
AnswerB

Only the active node can process writes; standby nodes return a 502.

Why this answer

In a Vault cluster with Raft storage, only the elected leader node can handle write operations (e.g., writing secrets, creating policies). Standby nodes serve read requests and forward writes to the leader. If the load balancer distributes traffic to all nodes without considering leadership, write requests sent to a standby node will fail with a 502 Bad Gateway error because the standby cannot process the write locally and the load balancer may not properly handle the forwarded response or timeout.

Exam trap

HashiCorp often tests the misconception that all Vault nodes in a cluster can handle writes equally, but in reality only the leader node processes write operations; the trap here is assuming that a healthy, unsealed node can always accept writes.

How to eliminate wrong answers

Option A is wrong because the Raft storage backend fully supports write operations; it is a consensus-based backend that requires writes to go through the leader. Option C is wrong because while the /v1/sys/leader endpoint can be used for routing, the load balancer's health check on /v1/sys/health with a 200 response is not the root cause; the issue is that the load balancer sends writes to non-leader nodes, not the specific endpoint used for health checks. Option D is wrong because the scenario explicitly states all nodes are unsealed and the cluster is healthy, so a sealed node is not the cause.

Full explanation →
243
Multi-Selectmedium

Which TWO of the following are benefits of using dynamic secrets engines (e.g., database, AWS) over static secrets?

Select 2 answers
A.Provides automatic rotation of credentials upon lease expiry
B.Simplifies the management of service accounts because credentials never change
C.Secrets are persistent and do not expire
D.Secrets are stored in plaintext in the Vault data store
E.Reduces the risk of credential leakage since secrets are short-lived
AnswersA, E

Dynamic secrets are automatically revoked or rotated when leases expire.

Why this answer

Dynamic secrets engines generate credentials on-demand with a predefined Time-To-Live (TTL). When the lease expires, Vault automatically revokes the credentials, forcing the client to request new ones. This automatic rotation eliminates the need for manual credential rotation and reduces the window of exposure if a credential is compromised.

Exam trap

HashiCorp often tests the misconception that dynamic secrets are persistent or that Vault stores secrets in plaintext, tempting candidates to select options C or D, but the core benefit is the automatic, short-lived nature of credentials that reduces leakage risk.

Full explanation →
244
MCQmedium

A company uses Vault to manage database credentials for its applications. The applications request a one-hour TTL for database secrets, but the database engine's default lease TTL is set to 24 hours. The Vault administrator wants to ensure that leases are revoked promptly after the applications finish using them, to minimize the window of exposure. Which approach best achieves this goal?

A.Set the default lease TTL on the database mount to 1 hour.
B.Configure the database role with a TTL of 1 hour and an explicit max TTL of 2 hours.
C.Increase the system's default lease TTL to 48 hours to give applications more flexibility.
D.Manually revoke leases after each application finishes using them.
AnswerB

This ensures each lease expires after 1 hour, and the explicit max TTL prevents any renewal beyond 2 hours, minimizing exposure.

Why this answer

Configuring the database role with a TTL of 1 hour and an explicit max TTL of 2 hours allows the application to request a 1-hour lease while ensuring that the lease cannot exceed 2 hours, even if the application fails to renew or release it. This minimizes the exposure window by capping the lease duration, and the Vault administrator can rely on automatic lease revocation at TTL expiry rather than manual intervention. The database engine's default lease TTL of 24 hours is overridden by the role-level TTL, which is the proper way to enforce shorter-lived credentials for specific applications.

Exam trap

The trap here is that candidates often confuse the mount-level default lease TTL with the role-level TTL, assuming that changing the mount default is sufficient, when in fact the role-level TTL and explicit max TTL are required to enforce a strict upper bound on credential lifetime.

How to eliminate wrong answers

Option A is wrong because setting the default lease TTL on the database mount to 1 hour would affect all roles and secrets under that mount, potentially breaking applications that need longer leases, and it does not provide a separate max TTL to cap the absolute lifetime. Option C is wrong because increasing the system's default lease TTL to 48 hours would make the exposure window even larger, directly contradicting the goal of minimizing it. Option D is wrong because manually revoking leases is impractical, error-prone, and does not scale; Vault is designed to automate lease lifecycle management via TTLs and revocation on expiry.

Full explanation →
245
MCQhard

An administrator configures AppRole with a RoleID and SecretID. They want to ensure that each SecretID can be used only once. Which configuration should they use?

A.Set token_num_uses=1 in the role.
B.Set bound_cidr_list to a specific IP.
C.Set secret_id_ttl=1s in the role.
D.Set secret_id_num_uses=1 in the role.
AnswerD

secret_id_num_uses limits the number of times a SecretID can be used.

Why this answer

Setting `secret_id_num_uses=1` in the AppRole role configuration ensures that each SecretID can be used only once to obtain a token. Once the SecretID is used for login, it is automatically revoked and cannot be reused. This directly satisfies the requirement of single-use SecretIDs.

Exam trap

HashiCorp often tests the distinction between `secret_id_num_uses` (controls SecretID reuse) and `token_num_uses` (controls token reuse), leading candidates to confuse the two and incorrectly select Option A.

How to eliminate wrong answers

Option A is wrong because `token_num_uses=1` limits the number of times the resulting token can be used, not the SecretID itself; the SecretID could still be reused to generate multiple tokens. Option B is wrong because `bound_cidr_list` restricts the source IP addresses allowed to use the SecretID, but does not enforce single-use behavior. Option C is wrong because `secret_id_ttl=1s` sets a time-to-live of 1 second for the SecretID, which may expire quickly but does not guarantee single-use; a SecretID could still be used multiple times within that second.

Full explanation →
246
MCQmedium

A team is using Vault's KV v2 secrets engine to store API keys for multiple microservices. They have enabled versioning and need to ensure that when a secret is deleted, it can be recovered within 30 days. Additionally, they want to keep a history of all versions for compliance. The team has noticed that some secrets are being permanently removed immediately instead of moving to a deleted state. Which configuration change should they make to enforce this behavior?

A.Enable 'check-and-set' on the secrets path to prevent unintended overwrites
B.Set the 'delete_version_after' parameter to 30 days on the KV v2 mount
C.Write a custom script that calls the 'undelete' endpoint immediately after deletion
D.Set 'max_versions' to 1 to limit the number of retained versions
AnswerB

This ensures that after soft-deletion, versions are kept for 30 days before permanent removal.

Why this answer

The 'delete_version_after' parameter on a KV v2 secrets engine mount specifies the time window (in seconds or as a duration like '30d') during which a deleted version remains in a soft-deleted state and can be recovered via the 'undelete' endpoint. Setting this to 30 days ensures that when a secret is deleted, it is not permanently removed until after that period, preserving the ability to restore it and maintaining a full version history for compliance.

Exam trap

HashiCorp often tests the distinction between parameters that control version retention ('max_versions' and 'delete_version_after') versus those that control write safety ('check-and-set'), and the trap here is that candidates confuse 'max_versions' (which limits total versions) with the soft-delete retention period, leading them to pick option D instead of B.

How to eliminate wrong answers

Option A is wrong because 'check-and-set' (CAS) prevents overwrites of a secret when the provided version number does not match the current version; it does not affect deletion behavior or the soft-delete/undelete lifecycle. Option C is wrong because writing a custom script to call the 'undelete' endpoint immediately after deletion would undo the deletion, not enforce a 30-day recovery window; it also adds unnecessary complexity and does not address the root cause of permanent removal. Option D is wrong because setting 'max_versions' to 1 limits the total number of retained versions (older versions are automatically deleted when a new version is written), but it does not control the soft-delete retention period; it would actually reduce the history available for compliance.

Full explanation →
247
Multi-Selecthard

Which TWO of the following are valid reasons for a token renewal to fail with a 'lease not found' or 'token not found' error? (Select exactly 2 options.)

Select 2 answers
A.The token has expired
B.The token has num_uses set to 0
C.The token has exceeded its max TTL
D.The token is an orphan token
E.The token is a batch token
AnswersA, E

An expired token will return token not found.

Why this answer

A Vault token that has expired is no longer valid for renewal. When a token's lease expires, the auth backend or secret engine removes the lease entry, so any renewal attempt returns 'lease not found' or 'token not found'. Option E is correct because batch tokens are designed to be non-renewable; they have no associated lease, so any renewal attempt results in a 'token not found' error.

This is a fundamental behavior of Vault's lease lifecycle: expired tokens and batch tokens cannot be renewed and must be re-authenticated.

Exam trap

HashiCorp Vault exams often test the distinction between token expiration (which removes the lease) and other token properties like num_uses or orphan status, leading candidates to incorrectly select options that describe valid tokens that are still renewable.

Full explanation →
248
Multi-Selecteasy

Which TWO of the following are valid secrets engines in Vault? (Select exactly 2.)

Select 2 answers
A.Active Directory
B.AWS
C.SSH
D.LDAP
E.Transit
AnswersA, C

Correct. Active Directory is a valid secrets engine that rotates and manages AD service account passwords.

Why this answer

Options A (Active Directory) and C (SSH) are both valid secrets engines in Vault. Option B (AWS) is also a secrets engine but not one of the two required answers. Option D (LDAP) is an auth method, not a secrets engine.

Option E (Transit) is also a valid secrets engine, but the question expects the two that are most directly related to credential management, hence A and C are correct.

Exam trap

HashiCorp often tests the distinction between 'auth methods' and 'secrets engines' — candidates confuse LDAP (an auth method) with a secrets engine, or assume SSH is not a secrets engine because it is commonly used for authentication, but SSH is indeed a valid secrets engine for credential management.

Full explanation →
249
MCQmedium

An administrator configured the database secrets engine with PostgreSQL. When an application requests credentials, Vault returns a username and password. However, the application reports that the credentials are not working. What is the most likely cause?

A.The TTL on the role is set too low.
B.The database user used by Vault does not have sufficient privileges to create users.
C.The connection string provided to Vault is incorrect.
D.The generated credentials were revoked by Vault before the application used them.
AnswerB

Vault needs CREATE USER privilege; if missing, credentials won't work.

Why this answer

The most likely cause is that the database user configured in Vault lacks the necessary privileges to create new database users. When Vault generates dynamic credentials, it uses its own database connection (the root or management user) to execute `CREATE USER` and `GRANT` statements. If that user does not have the `CREATEROLE` or `SUPERUSER` attribute (or equivalent `CREATE USER` privilege in PostgreSQL), the credential creation fails silently or produces unusable credentials, even though Vault returns a username and password.

Exam trap

HashiCorp often tests the misconception that credential generation failures are always due to network or connectivity issues (like an incorrect connection string), when in reality the root cause is often a privilege misconfiguration on the database side that Vault does not surface as an obvious error.

How to eliminate wrong answers

Option A is wrong because a low TTL would cause credentials to expire quickly, but the application would still be able to use them initially; the reported issue is that credentials are not working at all, not that they stop working after a short time. Option C is wrong because if the connection string were incorrect, Vault would fail to configure the database secrets engine entirely or would return an error when testing the connection, not silently generate non-functional credentials. Option D is wrong because Vault does not automatically revoke credentials before the application uses them; revocation occurs only when the lease expires or is explicitly revoked, and the application reports the credentials are not working immediately, not after a delay.

Full explanation →
250
Multi-Selecteasy

Which TWO of the following are valid uses of the Vault transit secrets engine?

Select 2 answers
A.Signing arbitrary data for verification
B.Encrypting data using a managed key
C.Generating random bytes for cryptographic salt
D.Exporting the encryption key for use outside Vault
E.Storing static secrets like API keys
AnswersA, B

Transit supports signing and verification operations.

Why this answer

The Vault transit secrets engine can sign arbitrary data using a managed key, allowing verification of the signature's authenticity without exposing the key. This is a core encryption-as-a-service feature, enabling data integrity and non-repudiation for external systems.

Exam trap

HashiCorp often tests the distinction between the transit engine's cryptographic operations (encrypt, decrypt, sign, verify) and the KV engine's static storage, leading candidates to mistakenly select 'storing static secrets' as a valid use.

Full explanation →
251
MCQhard

A Vault instance was upgraded from version 1.9 to 1.13. After the upgrade, a secrets engine mounted at 'transit/' is unresponsive and returns an error. The engine type is transit. What is the most likely cause?

A.The engine was accidentally disabled during the upgrade
B.The namespace was changed during the upgrade
C.The transit engine can only be mounted at the default path 'transit/'
D.The plugin version is incompatible with the new Vault version
AnswerA

This is correct because the upgrade process may have accidentally disabled the engine due to configuration conflicts or changes in engine management code.

Why this answer

During a Vault upgrade, there is a possibility that the upgrade process inadvertently disables certain secrets engines if there are configuration conflicts or if the engine was enabled using deprecated methods. This is especially likely in major version jumps like from 1.9 to 1.13, where significant changes in the engine management code could lead to such issues. Options B, C, and D are incorrect: namespaces are not altered during upgrades, the transit engine can be mounted at any path, and since transit is built-in, plugin incompatibility does not apply.

Exam trap

Candidates often mistakenly think that secrets engines are tied to specific mount paths or that upgrades cause plugin incompatibilities, but the real issue after a major version jump is that built-in engines may be inadvertently disabled if the upgrade process modifies default configurations.

How to eliminate wrong answers

Option A is wrong because Vault upgrades do not automatically disable mounted secrets engines; the engine remains mounted unless explicitly removed. Option B is wrong because namespaces are not altered during a Vault upgrade; they are a configuration element that persists across versions. Option C is wrong because the transit engine can be mounted at any valid path, not only 'transit/'; the default path is 'transit/' but it is not a requirement.

Full explanation →
252
MCQmedium

A healthcare company uses Vault Transit to encrypt patient records before storing them in a database. Each request to encrypt a small field (e.g., SSN) takes about 200ms due to network latency and cryptographic overhead. The application needs to encrypt millions of records daily, causing performance bottlenecks. The team wants to reduce latency per encryption operation. After reviewing the Vault documentation, they consider the following options: A. Use the batch encryption endpoint to encrypt multiple plaintexts in a single API call. B. Deploy a local caching proxy on each application server to intercept encryption calls. C. Enable Vault's built-in encryption result caching. D. Use a dedicated, high-performance Vault cluster with more resources. Which option most directly reduces per-operation latency?

A.Deploy a local caching proxy
B.Use a dedicated, high-performance Vault cluster
C.Use the batch encryption endpoint
D.Enable Vault's built-in encryption result caching
AnswerC

Batch encryption combines multiple plaintexts into one request, significantly reducing average latency per encryption.

Why this answer

The batch encryption endpoint in Vault Transit allows multiple plaintexts to be encrypted in a single API call, amortizing the fixed overhead of network latency and cryptographic setup across all records in the batch. This directly reduces per-operation latency because the 200ms cost is incurred once per batch rather than once per individual encryption. Options that address caching or cluster performance do not reduce the per-call overhead of the encryption operation itself.

Exam trap

HashiCorp often tests the misconception that caching encryption results is effective, but encryption outputs are unique per plaintext and key version, making caching useless for distinct data; the correct answer is always about reducing the number of API calls.

How to eliminate wrong answers

Option A is wrong because deploying a local caching proxy would cache encryption results, but since each SSN is unique, cache hits are extremely rare; it does not reduce latency for new encryption operations. Option B is wrong because using a dedicated, high-performance Vault cluster improves throughput and reduces server-side latency, but the dominant factor is the per-request network round-trip and cryptographic overhead, which remains unchanged per operation. Option D is wrong because Vault does not have a built-in encryption result caching feature; this is a distractor that misleads candidates into thinking Vault caches encryption outputs, which it does not for security reasons.

Full explanation →
253
MCQhard

Refer to the exhibit. A user attempts to renew the token after 20 hours. What will happen?

A.The renewal will fail because the token has exceeded its explicit max TTL.
B.The token will be renewed for another 12h and can be renewed indefinitely.
C.The token will be renewed for 12h, but the total lifetime cannot exceed 24h.
D.The token will be renewed for another 4h, after which it will expire.
AnswerD

The remaining time until max TTL is 4h, so renewal grants a 4h TTL.

Why this answer

The explicit max TTL is 24h. After 20h, the remaining time until max TTL is 4h. Renewal will set the token duration to the minimum of the requested TTL (12h) and the remaining max TTL (4h), resulting in a 4h TTL.

After that, the token expires.

Full explanation →
254
MCQmedium

A developer needs to manually revoke a token but only knows its accessor. Which Vault API endpoint can be used to revoke the token using only the accessor?

A.auth/token/accessors
B.auth/token/renew-accessor
C.auth/token/revoke-accessor
D.auth/token/revoke
AnswerC

This endpoint revokes the token associated with the accessor.

Why this answer

The `auth/token/revoke-accessor` endpoint is specifically designed to revoke a token when only its accessor is known. The accessor is a non-sensitive identifier that Vault uses to perform token operations without exposing the actual token ID, making this endpoint the appropriate choice for revocation by accessor.

Exam trap

HashiCorp Vault often tests the distinction between endpoints that operate on the token ID versus those that operate on the accessor, and the trap here is that candidates might confuse `auth/token/revoke` (which needs the token ID) with `auth/token/revoke-accessor` (which uses the accessor), or think that listing accessors (Option A) is sufficient for revocation.

How to eliminate wrong answers

Option A is wrong because `auth/token/accessors` is used to list token accessors, not to revoke a token. Option B is wrong because `auth/token/renew-accessor` is used to renew a token's lease using its accessor, not to revoke it. Option D is wrong because `auth/token/revoke` requires the actual token ID or a token's accessor via a different endpoint, and using it with only an accessor would fail or require additional parameters.

Full explanation →
255
MCQeasy

A Vault user wants to check the capabilities of their token on a specific path. Which command should they use?

A.vault token list
B.vault token capabilities <path>
C.vault policy capabilities <policy_name> <path>
D.vault token lookup <token>
AnswerB

This shows what actions the current token can perform on the path.

Why this answer

The `vault token capabilities` command is specifically designed to check what operations (e.g., read, create, update, delete, list) a given token is allowed to perform on a particular path. It evaluates the token's attached policies against the path and returns the effective capabilities, making it the correct tool for this task.

Exam trap

HashiCorp often tests the distinction between commands that inspect token metadata (`vault token lookup`) versus commands that evaluate policy-based permissions on a specific path (`vault token capabilities`), and candidates may confuse `vault policy capabilities` (which does not exist) with the correct command.

How to eliminate wrong answers

Option A is wrong because `vault token list` displays all tokens that exist in the token store (for tokens with appropriate permissions), not the capabilities of a specific token on a path. Option C is wrong because `vault policy capabilities` is not a valid Vault command; the correct command to check a policy's effect on a path is `vault token capabilities` (which uses the token's policies), and `vault policy read` is used to view policy rules. Option D is wrong because `vault token lookup` shows metadata about a token (such as creation time, TTL, and attached policies), but does not evaluate or display capabilities on a specific path.

Full explanation →
256
MCQhard

Refer to the exhibit. A Vault policy is defined as shown. A user presents a token with this policy. Which operation will be permitted?

A.List secret/data/finance
B.Delete secret/data/finance/budget
C.Create secret/data/engineering/config
D.Read secret/data/finance
AnswerC

The glob secret/data/engineering/* grants create capability.

Why this answer

The policy grants `create` and `update` capabilities on `secret/data/engineering/*`, which allows creating secrets under that path. Option C is correct because the `create` capability permits writing a new secret at `secret/data/engineering/config`, as the path matches the glob pattern and the operation is a write (POST/PUT).

Exam trap

HashiCorp often tests the nuance that a policy with only `deny` on a path does not grant any capabilities, so operations like `list` or `read` on that path are implicitly denied, leading candidates to mistakenly assume a `deny` entry implies some form of access.

How to eliminate wrong answers

Option A is wrong because `list` requires the `list` capability, which is not granted on `secret/data/finance` (only `deny` is implied by absence). Option B is wrong because `delete` requires the `delete` capability, which is not granted on `secret/data/finance/budget` (the policy only allows `deny` on `secret/data/finance/*`). Option D is wrong because `read` requires the `read` capability, which is not granted on `secret/data/finance` (the policy only allows `deny` on `secret/data/finance/*` and no capabilities on the exact path).

Full explanation →
257
MCQmedium

A company runs a microservices application on Kubernetes. Each service authenticates to Vault using the Kubernetes auth method and obtains a short-lived token with a TTL of 15 minutes. The services use these tokens to read secrets from the KV v2 secrets engine. Recently, the operations team noticed that Vault's lease count has been steadily increasing, and some services are experiencing 'lease not found' errors when trying to renew their tokens. Investigation reveals that the services are not renewing tokens before they expire because the token TTL is too short to complete some long-running tasks. The team wants to fix the issue without compromising security. They are considering the following actions: A. Increase the default lease TTL for the KV v2 mount to 1 hour. B. Increase the token TTL for the Kubernetes auth role to 1 hour. C. Implement a renewal loop in each service to renew tokens every 10 minutes. D. Use periodic tokens with a period of 1 hour for all services.

A.Increase the default lease TTL for the KV v2 mount to 1 hour.
B.Increase the token TTL for the Kubernetes auth role to 1 hour.
C.Implement a renewal loop in each service to renew tokens every 10 minutes.
D.Use periodic tokens with a period of 1 hour for all services.
AnswerB

Token TTL directly addresses the token expiration issue.

Why this answer

Increasing the token TTL for the Kubernetes auth role to 1 hour directly addresses the root cause: the current 15-minute TTL is too short for long-running tasks, causing tokens to expire before services can complete their work. By raising the TTL to 1 hour, services have sufficient time to complete tasks and renew tokens, while still maintaining security through short-lived credentials. This approach does not require code changes and leverages Vault's built-in token lifecycle management.

Exam trap

HashiCorp often tests the distinction between token TTL and secret lease TTL, and the trap here is that candidates confuse increasing the KV v2 mount's default lease TTL (Option A) with increasing the token TTL, when only the latter resolves token expiration issues for long-running tasks.

How to eliminate wrong answers

Option A is wrong because increasing the default lease TTL for the KV v2 mount affects the lease duration of secrets read from the mount, not the token TTL itself; the 'lease not found' errors are due to token expiration, not secret lease expiration. Option C is wrong because implementing a renewal loop in each service does not fix the underlying issue that the token TTL is too short for long-running tasks; even with renewal, if a task exceeds the TTL without renewal, the token will expire, and adding renewal logic increases complexity without addressing the root cause. Option D is wrong because periodic tokens are designed for long-lived daemons or services that need indefinite token lifetimes, which would compromise security by removing the short-lived nature of tokens, contrary to the requirement to fix the issue without compromising security.

Full explanation →
258
MCQmedium

An organization uses Vault with a Consul storage backend. They have three Vault servers and three Consul servers. During a routine maintenance, they restart all Consul servers simultaneously. After the restart, Vault becomes sealed and cannot be unsealed. The Vault logs show 'storage: error listing' and 'failed to check status'. The Consul cluster is healthy with a leader. What is the most likely cause and solution?

A.Re-initialize Vault and generate new unseal keys
B.Restore Vault's storage backend from a recent backup
C.Generate a new root token using unseal keys
D.Use the unseal keys to unseal Vault again
AnswerB

Restores the encrypted data and master key.

Why this answer

When all Consul servers are restarted simultaneously, the Vault storage backend (Consul) may lose critical metadata or consistency state that Vault relies on to maintain its seal/unseal status. Even though the Consul cluster appears healthy with a leader, the underlying data corruption or loss of key-value entries (such as the barrier key or storage index) prevents Vault from reading its storage, causing it to seal and fail to unseal. Restoring Vault's storage backend from a recent backup is the correct solution because it recovers the consistent state of the data, including the encrypted master key and configuration, without requiring re-initialization.

Exam trap

HashiCorp often tests the misconception that a healthy Consul cluster with a leader guarantees Vault's storage integrity, but the trap here is that Vault's storage backend can suffer from data corruption or missing keys even when Consul's cluster health appears normal, leading candidates to incorrectly attempt re-unsealing or token generation instead of restoring from backup.

How to eliminate wrong answers

Option A is wrong because re-initializing Vault would generate a new master key and new unseal keys, destroying access to all existing secrets; the issue is data corruption in the storage backend, not a need for new keys. Option C is wrong because generating a new root token requires the Vault to be unsealed first, and the problem is that Vault cannot unseal due to storage errors, not a missing or expired token. Option D is wrong because using the unseal keys to unseal Vault again assumes the storage backend is intact and readable; the logs indicate 'storage: error listing' and 'failed to check status', meaning the storage is corrupted or inaccessible, so unseal operations will fail.

Full explanation →
259
MCQmedium

A financial services company runs a microservices application on Kubernetes. Each service needs to authenticate to Vault using Kubernetes auth and then read secrets from a shared KV v2 engine mounted at 'shared-kv'. The security team requires that Service-A can only read secrets under 'shared-kv/team-alpha/*' and Service-B can only read secrets under 'shared-kv/team-beta/*'. The Vault administrator has already configured the Kubernetes auth method and created roles for each service with bound service account names. However, both services are currently able to read all paths under 'shared-kv/'. The administrator wants to enforce the least privilege access. Which course of action should the administrator take?

A.Configure the Kubernetes auth role to use 'token_policies' with a restrictive policy and ensure the bound service account names are correct.
B.Create a new secrets engine for each team and mount them at 'team-alpha' and 'team-beta', then assign each service to its respective engine.
C.Add a 'path_deny' capability in the policy for the disallowed paths.
D.Review and update the policy attached to the Kubernetes auth roles to restrict capabilities to the specific paths, e.g., 'path "shared-kv/data/team-alpha/*" { capabilities = ["read"] }'.
AnswerD

This directly restricts each service to its allowed paths using Vault's policy language.

Why this answer

The issue is that the policy attached to the Kubernetes auth roles grants read access to the entire 'shared-kv/*' path. By updating the policy to restrict capabilities to specific paths like 'shared-kv/data/team-alpha/*' and 'shared-kv/data/team-beta/*', the administrator enforces least privilege. The 'data' prefix is required for KV v2 engines to access secret data, and the wildcard ensures only the respective team's secrets are readable.

Exam trap

HashiCorp often tests the misconception that 'path_deny' is a valid capability in Vault ACL policies, when in fact Vault uses default-deny and explicit allow, so candidates incorrectly choose Option C instead of updating the allowed paths.

How to eliminate wrong answers

Option A is wrong because 'token_policies' are already used; the problem is the policy content, not the binding or the policy assignment mechanism. Option B is wrong because creating separate engines is unnecessary and violates the requirement to use the shared 'shared-kv' engine; it also adds administrative overhead without addressing the policy misconfiguration. Option C is wrong because 'path_deny' capabilities are not a valid Vault policy construct; Vault uses explicit allow with 'deny' capabilities only via Sentinel or ACL path-based denial, but the correct approach is to restrict the allowed paths, not add deny rules.

Full explanation →
260
MCQeasy

An admin needs to check the remaining lifespan of a lease. Which command should they use?

A.vault read sys/leases/lookup/<lease_id>
B.vault lease list <lease_id>
C.vault lease lookup <lease_id>
D.vault lease renew -increment=0 <lease_id>
AnswerC

This command shows the lease details including remaining TTL.

Why this answer

The `vault lease lookup` command is the correct way to inspect the remaining lifespan and metadata of a specific lease in Vault. It returns details such as the lease ID, issue time, expiration time, and TTL, allowing the admin to determine how much time remains before the lease expires.

Exam trap

The HashiCorp Vault exam often tests the distinction between `vault lease lookup` and `vault read sys/leases/lookup`, where candidates mistakenly think `vault read` can directly access the lease lookup endpoint without the proper command syntax.

How to eliminate wrong answers

Option A is wrong because `vault read sys/leases/lookup/<lease_id>` is not a valid Vault command; the correct API endpoint is `/sys/leases/lookup` but it is accessed via `vault lease lookup`, not `vault read`. Option B is wrong because `vault lease list` lists all lease IDs under a given prefix or mount, but does not show the remaining lifespan of a single lease. Option D is wrong because `vault lease renew -increment=0` attempts to renew the lease with zero increment, which is not a lookup operation and may actually revoke the lease or cause an error depending on the lease type, rather than simply checking its remaining lifespan.

Full explanation →
261
MCQmedium

A financial services company uses HashiCorp Vault's transit engine to encrypt customer credit card numbers. The application sends each credit card number individually to Vault for encryption, and the response time is acceptable. However, during peak hours, the company needs to encrypt large batches of 10,000 credit card numbers. Users report that encrypting the entire batch takes several minutes, causing timeouts. The Vault cluster is healthy and not under high load. The security team wants to reduce the encryption time without changing the encryption algorithm or key strength. What should they do?

A.Enable key derivation on the transit key to allow parallel encryption.
B.Use the `batch_input` parameter to encrypt multiple plaintexts in one API call.
C.Enable convergent encryption to reuse ciphertexts.
D.Switch to an AES-256-GCM key for faster encryption.
AnswerB

Batch encryption reduces overhead.

Why this answer

The `batch_input` parameter allows sending multiple plaintexts in a single API call to Vault's transit engine, significantly reducing the overhead of individual HTTP requests and TLS handshakes. This directly addresses the batch encryption timeout issue without changing the encryption algorithm or key strength, as the Vault cluster is healthy and not under load, indicating the bottleneck is network round-trips, not cryptographic computation.

Exam trap

The trap here is that candidates may confuse 'parallel encryption' (which Vault inherently supports via concurrent API calls) with reducing the number of API calls, or mistakenly think that changing the key type (Option D) or enabling convergent encryption (Option C) would improve performance, when the actual solution is batching input to minimize network overhead.

How to eliminate wrong answers

Option A is wrong because key derivation (enabled via `derived=true`) creates unique encryption keys per context but does not enable parallel encryption; Vault's transit engine already supports concurrent requests, and the bottleneck here is the number of API calls, not parallelism. Option C is wrong because convergent encryption reuses ciphertexts for identical plaintexts, which could reduce storage but does not speed up encryption of unique credit card numbers and may introduce security risks like frequency analysis. Option D is wrong because switching to AES-256-GCM (the default for transit keys) does not change the algorithm or key strength as per the requirement, and the issue is not cryptographic speed but API call overhead.

Full explanation →
262
MCQeasy

A financial technology company uses Vault Enterprise to manage encryption keys for its payment processing system. The system uses the transit secrets engine to encrypt credit card numbers before storing them in a legacy database. The security team mandates that all encryption keys must be automatically rotated every 30 days. The operations team configures the key 'payment-cards' with 'auto_rotate_period' set to 30 days. After the first rotation, the payment processing application starts failing with 'permission denied' errors when trying to decrypt previously encrypted data. The application uses a token with a policy that grants 'create' and 'update' capabilities on 'transit/decrypt/payment-cards'. The application does not use the 'rewrap' endpoint. The Vault audit logs show that the decryption requests are being made to the correct path. What is the most likely cause of the failure?

A.The key rotation changed the encryption algorithm, making old ciphertexts incompatible with the new key.
B.The application's token has expired after the key rotation, requiring a new token with updated policies.
C.The application must use the 'rewrap' endpoint to re-encrypt all ciphertexts with the new key version before decryption.
D.The application is not specifying the key version in the decryption request, and Vault defaults to the latest key version which cannot decrypt data encrypted with the old version.
AnswerD

By default, Vault uses the latest key version for decryption. To decrypt with an older version, the ciphertext must include a version reference, or the application must use the 'rewrap' endpoint.

Why this answer

When Vault rotates a key in the transit secrets engine, it creates a new key version but retains the old version for decryption of existing ciphertexts. By default, decryption requests that do not specify a key version use the latest version, which cannot decrypt data encrypted with an older version. The application must explicitly include the `?version=` parameter or use the ciphertext's embedded version information to target the correct key version for decryption.

Exam trap

The trap here is that candidates assume key rotation automatically makes old ciphertexts decryptable with the new key, when in fact Vault requires explicit version targeting or use of the ciphertext's embedded version metadata to decrypt with the correct key version.

How to eliminate wrong answers

Option A is wrong because key rotation in Vault's transit secrets engine does not change the encryption algorithm; it only creates a new key version under the same algorithm (e.g., AES-GCM). Option B is wrong because token expiration is unrelated to key rotation; the token's policy and TTL remain unchanged unless explicitly revoked or expired by the token's own TTL, which is not indicated in the scenario. Option C is wrong because the `rewrap` endpoint is used to re-encrypt data with the latest key version without exposing plaintext, but it is not a prerequisite for decryption; decryption can succeed by specifying the correct key version.

Full explanation →
263
MCQhard

A security team needs to create a token with a custom TTL of 1 hour and associate it with a policy named 'read-only'. Which Vault CLI command accomplishes this?

A.vault token create -policy=read-only -ttl=1h
B.vault write auth/token/create policies=read-only ttl=1h
C.vault token create -policy=read-only -ttl 1h
D.vault create token -policy=read-only -ttl=1h
AnswerA, C

Correct. Uses the proper `vault token create` command with `-policy` and `-ttl=1h` flags.

Why this answer

Both `vault token create -policy=read-only -ttl=1h` and `vault token create -policy=read-only -ttl 1h` are valid Vault CLI commands that create a token with the specified policy and TTL. The CLI parser accepts both the equals sign and space syntax for string flags. Therefore, both options A and C accomplish the task.

Exam trap

Candidates often confuse `vault token create` with `vault write auth/token/create`, which is a different method requiring different parameter syntax. Also, `vault create` is not a valid command.

How to eliminate wrong answers

Option B is wrong because `vault write auth/token/create policies=read-only ttl=1h` uses the API path `auth/token/create` which is deprecated and requires the `policies` parameter to be a JSON array (e.g., `policies=read-only` is incorrect syntax; it should be `policies=["read-only"]`), and the `ttl` parameter expects a duration string like `1h` but the command structure is for the API, not the CLI. Option C is wrong because `vault token create -policy=read-only -ttl 1h` uses a space instead of an equals sign for the `-ttl` flag, which is incorrect syntax in Vault CLI; flags with values must use `=` (e.g., `-ttl=1h`) or be passed as separate arguments (e.g., `-ttl 1h` is actually valid in some contexts, but the standard and most reliable form is `-ttl=1h`; however, the key issue is that the `-policy` flag also uses `=` and the overall command is ambiguous—strictly, `-ttl 1h` is acceptable but inconsistent with the `-policy=read-only` format, making it less precise; the exam expects consistent `=` syntax). Option D is wrong because `vault create token -policy=read-only -ttl=1h` uses the incorrect subcommand `create` instead of `token create`; the correct Vault CLI command for token creation is `vault token create`, not `vault create token`.

Full explanation →
264
MCQhard

A user with this policy wants to delete secrets under the 'team/' path. Which additional capability must be added?

A.sudo
B.delete
C.list
D.patch
AnswerB

The 'delete' capability allows deletion of secrets.

Why this answer

The user's policy grants 'create' and 'update' capabilities on 'team/*', but not 'delete'. In Vault's ACL policy system, each operation (create, read, update, delete, list, sudo) must be explicitly allowed. Since 'delete' is missing, the user cannot delete secrets under 'team/'.

Adding the 'delete' capability to the policy is required.

Exam trap

HashiCorp often tests the misconception that 'sudo' is a catch-all permission or that 'update' implies delete capability, but in Vault, each operation is explicitly scoped and 'delete' must be granted separately.

How to eliminate wrong answers

Option A is wrong because 'sudo' is a capability that bypasses ACL checks for certain privileged operations (e.g., enabling auth methods), not a generic permission to delete secrets; it would not grant delete access on 'team/*'. Option C is wrong because 'list' only allows listing keys at a path, not deleting them; it is a separate capability. Option D is wrong because 'patch' is not a standard Vault ACL capability; the correct capability for modifying existing secrets is 'update', and 'patch' is not defined in Vault's policy system.

Full explanation →
265
MCQmedium

A large e-commerce company uses Vault to manage secrets for their AWS EC2 instances. They use AWS IAM auth. The Vault role is configured with bound_iam_role_arn to match the IAM role 'ec2-app-role'. Most instances work fine. However, a new instance launched with the same IAM role fails to authenticate. The instance can reach Vault (network is fine) and the AWS credentials are valid. The Vault server logs show: 'error validating login: unable to get instance identity document'. The new instance is in a different AWS region (us-west-2) while most others are in us-east-1. Vault is deployed in us-east-1. What is the most likely cause and solution?

A.The IAM role does not exist in us-west-2.
B.The new instance needs to be associated with an instance profile.
C.Create a new Vault role for the us-west-2 region.
D.Vault's AWS auth method must be configured with the correct region for instance identity validation.
AnswerD

Vault needs to know the region to verify the identity document.

Why this answer

The AWS auth method in Vault validates the instance identity document, which includes the region where the instance is launched. By default, Vault's AWS auth method uses the region configured in its sts_endpoint or the Vault server's own region (us-east-1). When a new instance in us-west-2 presents its identity document signed with a us-west-2 region-specific key, Vault fails to validate it because it is checking against the wrong region's signing key.

Configuring the auth method with the correct region (or a wildcard) allows Vault to validate identity documents from multiple regions.

Exam trap

HashiCorp often tests the misconception that IAM roles are region-specific or that a separate Vault role is needed per region, when the actual issue is the region configuration in the AWS auth method's identity validation logic.

How to eliminate wrong answers

Option A is wrong because the IAM role 'ec2-app-role' is a global AWS resource; IAM roles are not region-specific, so the role exists in all regions. Option B is wrong because the instance already has an IAM role associated; an instance profile is automatically created and attached when an IAM role is assigned to an EC2 instance, and the issue is not about missing instance profiles. Option C is wrong because creating a new Vault role is unnecessary; the existing Vault role can authenticate instances from any region as long as the auth method's region configuration is correct, and the bound_iam_role_arn already matches the role.

Full explanation →
266
Multi-Selectmedium

Which THREE of the following token properties are immutable after token creation? (Select exactly 3 options.)

Select 3 answers
A.Period
B.Policies
C.Renewable
D.Max TTL
E.TTL
AnswersA, B, D

Period is immutable. It defines the renewal period and cannot be changed after token creation.

Why this answer

In Vault, certain token properties are set at creation and cannot be changed later. The immutable properties are: Period (the renewal period), Policies (the list of policies attached to the token), and Max TTL (the maximum time-to-live). These are fixed in the token's metadata.

In contrast, the Renewable flag, though set at creation, is not considered immutable because it can be effectively changed by renewing the token or by updating the token's role policies that affect renewal behavior. TTL is the current time-to-live and decreases over time, so it is mutable.

Exam trap

A common pitfall is assuming that Renewable is immutable because it is set at creation. However, in Vault, the renewable property can be effectively changed through token renewal or role updates, making it mutable. The truly immutable properties are Period, Policies, and Max TTL.

Full explanation →
267
MCQeasy

A small company uses Vault with LDAP authentication for their employees. They configured the LDAP auth method pointing to their on-premises Active Directory. Several users report that they can log in to the Vault UI, but they cannot see any secrets in the paths they expect. The administrator verified that the users are in the correct AD groups. The Vault policies are defined and assigned to groups via the LDAP auth method's group mapping. However, the users still have no permissions. What is the most likely root cause and the correct fix?

A.The group mapping in Vault does not match the AD group names (case or syntax).
B.The LDAP bind credentials are incorrect.
C.The LDAP auth method is not enabled.
D.The Vault token's TTL is too short.
AnswerA

Group names must match exactly.

Why this answer

The most likely root cause is that the group mapping in Vault does not match the AD group names due to case sensitivity or syntax differences. Vault's LDAP auth method performs exact string matching when mapping LDAP groups to Vault policies; if the group names in the Vault configuration (e.g., 'Domain Admins') differ from the actual AD group names (e.g., 'Domain Admins' with a trailing space or different case), the mapping fails, resulting in no policy assignment and thus no permissions.

Exam trap

HashiCorp often tests the nuance that LDAP authentication can succeed while authorization fails due to group mapping mismatches, leading candidates to incorrectly suspect authentication or token issues instead of policy mapping.

How to eliminate wrong answers

Option B is wrong because incorrect LDAP bind credentials would prevent the LDAP auth method from authenticating users at all, but the users can log in successfully, so the bind credentials are valid. Option C is wrong because if the LDAP auth method were not enabled, users would not be able to log in to the Vault UI at all, but they can log in. Option D is wrong because a short Vault token TTL would cause tokens to expire quickly, not prevent users from seeing secrets immediately after login; the issue is about missing permissions, not token lifetime.

Full explanation →
268
MCQeasy

A security team wants to ensure that tokens can be revoked immediately if a compromised token is detected, even if the token ID is unknown. Which token feature should they use?

A.Periodic tokens
B.Batch tokens
C.Token accessors
D.Orphan tokens
AnswerC

Token accessors enable revocation by providing the accessor instead of the token ID.

Why this answer

Token accessors allow revocation of a token without knowing the token ID. They are specifically designed for this purpose.

Full explanation →
269
MCQhard

A company uses AWS IAM auth for EC2 instances. An instance with an IAM role 'app-role' successfully logs in, but another instance with the same IAM role receives a permission denied error when trying to authenticate. The Vault server and AWS account are healthy. What is the most likely cause?

A.The second instance does not have the IAM role attached to its instance profile
B.The Vault server's AWS credentials are expired
C.The Vault role for AWS auth is configured with a wrong bound IAM role ARN
D.The IAM role's trust policy does not allow Vault to assume the role
AnswerA

Without the role in the instance profile, the instance cannot sign the request.

Why this answer

The second instance likely does not have the IAM role 'app-role' attached to its instance profile. For Vault's AWS IAM auth method, the EC2 instance must have the IAM role attached to its instance profile at launch time; the Vault server uses the instance's credentials (via the instance metadata service) to verify the role. If the role is not attached, the instance cannot present valid credentials for authentication, resulting in a permission denied error even though the Vault server and AWS account are healthy.

Exam trap

HashiCorp often tests the distinction between an IAM role being attached to an instance profile versus simply existing in the account, leading candidates to overlook the instance profile attachment requirement and incorrectly blame Vault configuration or trust policies.

How to eliminate wrong answers

Option B is wrong because the question states the Vault server and AWS account are healthy, which implies the Vault server's AWS credentials (used to call AWS STS) are valid and not expired. Option C is wrong because if the Vault role for AWS auth were configured with a wrong bound IAM role ARN, both instances would fail authentication, not just one. Option D is wrong because the IAM role's trust policy controls whether Vault can assume the role (for Vault's own AWS credentials), not whether an EC2 instance can authenticate via the AWS auth method; the trust policy is irrelevant to the instance's authentication flow.

Full explanation →
270
MCQmedium

A company has multiple AWS accounts and wants to allow EC2 instances to authenticate to Vault without storing any secrets on the instances. Which authentication method should they use?

A.OIDC
B.AWS
C.TLS Certificates
D.AppRole
AnswerB

AWS auth uses instance metadata, no secrets stored.

Why this answer

(AWS) is correct because the AWS authentication method in Vault allows EC2 instances to authenticate using their AWS instance identity documents and PKCS#7 signatures, without requiring any long-lived secrets to be stored on the instances. Vault verifies the instance's identity by calling the AWS EC2 API to validate the document and signature, then binds the instance to a Vault role. This eliminates the need to store tokens or credentials on the instance, meeting the requirement of secretless authentication.

Exam trap

HashiCorp often tests the misconception that OIDC or TLS certificates are the 'most secure' or 'standard' methods for secretless authentication, but the trap here is that the question specifically requires no secrets stored on the instance, which only the AWS auth method achieves by using dynamic, ephemeral instance metadata instead of static credentials.

How to eliminate wrong answers

Option A (OIDC) is wrong because OIDC relies on an external identity provider (e.g., Okta, Azure AD) to issue ID tokens, which would still require the EC2 instance to either store a client secret or perform a complex token exchange, and it does not natively leverage AWS instance metadata for secretless authentication. Option C (TLS Certificates) is wrong because while TLS certificates can authenticate instances, they require the certificates and private keys to be stored on the EC2 instances, violating the 'no secrets stored on instances' requirement. Option D (AppRole) is wrong because AppRole requires a RoleID and a SecretID to be provided by the client; the SecretID is a secret that must be stored or delivered to the instance, which contradicts the requirement of not storing any secrets on the instances.

Full explanation →
271
MCQhard

Refer to the exhibit. A user runs 'vault token renew -self' on this token. What is the expected behavior?

A.The token cannot be renewed because the token type is service.
B.The token TTL will reset to 72h from now.
C.The token will be renewed, but TTL cannot exceed 72h from issue time.
D.The token cannot be renewed because it is orphan.
AnswerB

Correct. Renewing a token resets its TTL to the original creation_ttl (72h) from the current time, subject to the token's maximum TTL, which is also 72h in this case.

Why this answer

The token's initial TTL was set to 72h, and the token has a renewable property (service tokens are renewable by default unless explicitly disabled). Running 'vault token renew -self' extends the token's lifetime by resetting the TTL to the original 72h from the current time, as long as the renewal does not exceed the token's maximum TTL (which is also 72h in this case). This behavior is defined by Vault's token lifecycle management, where renewable tokens can have their TTL reset to the initial value upon renewal.

Exam trap

HashiCorp often tests the misconception that service tokens cannot be renewed or that renewal is limited by the original issue time, when in fact renewal resets the TTL to the initial value from the current time, subject to the token's max TTL.

How to eliminate wrong answers

Option A is wrong because service tokens are renewable by default; the token type does not prevent renewal unless explicitly configured with 'renewable=false'. Option C is wrong because the TTL does not have a cap from the issue time; renewal resets the TTL to the initial 72h from the renewal time, not from the original issue time. Option D is wrong because being orphan (no parent token) does not affect renewability; orphan tokens can still be renewed as long as they are renewable and within their max TTL.

Full explanation →
272
MCQeasy

An administrator creates a service token with a TTL of 1 hour and a max TTL of 24 hours. The token is renewed once after 55 minutes. What happens to the token after 24 hours from creation?

A.The token expires and cannot be renewed
B.The token is revoked by the system
C.The token's TTL is automatically extended by 1 hour
D.The token becomes an orphan token
AnswerA

Once max TTL is reached, the token expires and renewal is not possible.

Why this answer

The token's TTL was set to 1 hour with a max TTL of 24 hours. After the first renewal at 55 minutes, the token's TTL resets to 1 hour, but the max TTL remains 24 hours from creation. Once 24 hours have passed from creation, the token reaches its max TTL and expires permanently; it cannot be renewed because the max TTL is a hard upper limit enforced by Vault's token lifecycle logic.

Exam trap

The trap here is that candidates often confuse the current TTL with the max TTL, thinking that renewing the token resets the overall lifetime, but Vault enforces the max TTL as a hard deadline from creation, not from the last renewal.

How to eliminate wrong answers

Option B is wrong because Vault does not actively revoke tokens upon reaching max TTL; instead, the token simply expires and becomes unusable, with no explicit revocation action. Option C is wrong because the token's TTL is not automatically extended; Vault only extends the TTL upon explicit renewal, and only up to the max TTL, which is already reached at 24 hours. Option D is wrong because an orphan token is one whose parent is expired or revoked, but this token is not orphaned—it simply expires due to max TTL, and orphan tokens still have their own TTL and can be renewed if within limits.

Full explanation →
273
Multi-Selectmedium

Which THREE of the following are valid sources of token TTL?

Select 3 answers
A.System default TTL
B.Mount path configuration
C.Policy TTL
D.Explicit TTL set during token creation
E.Role TTL in an auth method
AnswersA, D, E

Vault has a default TTL for tokens.

Why this answer

Vault has a system default TTL that applies to tokens when no other TTL source is specified. This default is typically 32 days (2764800 seconds) and serves as the maximum possible TTL for a token unless overridden by a shorter TTL from another source. The system default TTL is defined in the Vault server configuration and acts as a fallback to ensure tokens do not live indefinitely.

Exam trap

HashiCorp often tests the misconception that policies can set TTL values, but policies only define permissions, not token lifetimes; candidates may confuse policy with role configuration in auth methods.

Full explanation →
274
MCQhard

Refer to the exhibit. A token was created with a creation_ttl of 24h, explicit_max_ttl of 10h, and a current ttl of 12h. What will happen when the token reaches its explicit_max_ttl?

A.The token will be automatically renewed by Vault.
B.The token will remain valid until the creation_ttl expires.
C.The token will be revoked immediately.
D.The token will have its TTL extended to 24h.
AnswerC

explicit_max_ttl is an absolute deadline; the token is revoked exactly at that time.

Why this answer

The explicit_max_ttl overrides any other TTL settings. When the token reaches its explicit_max_ttl (10h from creation), it will be revoked by Vault regardless of renewable or creation_ttl. Options suggesting renewal or extension are incorrect.

Full explanation →
275
MCQhard

A security engineer needs to ensure that if a key is compromised, previous ciphertext can be re-encrypted with a new key version without exposing the plaintext. Which Vault operation should they use?

A.Rewrap
B.Rotate
C.Encode
D.Transform
E.Rekey
AnswerA

Rewrap processes ciphertext without exposing plaintext.

Why this answer

The Rewrap operation in Vault allows a ciphertext to be decrypted with the current key version and re-encrypted with a new key version without exposing the plaintext to the caller. This ensures that if a key is compromised, previous ciphertext can be rotated to a new key version while maintaining data confidentiality.

Exam trap

HashiCorp often tests the distinction between key rotation (creating new key versions) and re-encrypting existing data (Rewrap), where candidates mistakenly choose Rotate thinking it automatically re-encrypts ciphertext.

How to eliminate wrong answers

Option B (Rotate) is wrong because Rotate creates a new key version but does not re-encrypt existing ciphertext; it only affects future encryption operations. Option C (Encode) is wrong because Encode is a generic data transformation (e.g., base64) and does not involve key management or re-encryption. Option D (Transform) is wrong because Transform applies a cryptographic function (e.g., tokenization, masking) but does not re-encrypt ciphertext under a new key version.

Option E (Rekey) is wrong because Rekey changes the master key or encryption key for the entire Vault cluster, not for individual ciphertexts, and does not provide a per-ciphertext re-encryption operation.

Full explanation →
276
MCQhard

A company runs a monolithic application that reads database credentials from Vault KV v2 secrets engine at path 'app/db'. The application authenticates using an AppRole with a periodic token that renews automatically. Recently, the application started failing with permission denied errors when reading the secret. The administrator checks the AppRole's secret-id and token but they are valid. The administrator then runs `vault token capabilities $(cat /tmp/token) app/db/data` and gets an empty list. The administrator knows that the token has the 'app-policy' policy attached. They also run `vault read sys/policy/app-policy` and see the policy rules. The policy allows explicit 'read' on 'app/db/data'. What could be the issue?

A.The secret at 'app/db/data' does not exist
B.The policy path is incorrect because KV v2 requires granting access to 'app/db/data' but the policy might be written for KV v1 syntax
C.The token has expired and needs to be renewed
D.The Capabilities command does not work with AppRole tokens
AnswerA

Correct. If the secret does not exist, Vault returns permission denied errors, and the capabilities command returns an empty list because there is no path to evaluate.

Why this answer

The policy explicitly allows 'read' on 'app/db/data', so the issue is not a policy path mismatch. The empty capabilities list from `vault token capabilities` suggests that the secret at 'app/db/data' does not exist, and Vault returns an empty capabilities list for non-existent paths when no policy grants access to that exact path. Since the application receives permission denied errors, the most likely cause is that the secret has not been created or has been deleted.

Exam trap

Candidates often overlook that a missing secret can also cause permission denied errors, even when the policy is correct. The capabilities command will show an empty list for non-existent paths if no policy grants access to that exact path.

How to eliminate wrong answers

Option A is wrong because if the secret did not exist, the capabilities command would still return the allowed capabilities for the path (e.g., 'read' if the policy allows it), not an empty list. Option C is wrong because the token is described as a periodic token that renews automatically, and the administrator confirmed the token is valid; an expired token would not return an empty capabilities list but would fail authentication entirely. Option D is wrong because the `vault token capabilities` command works with any token, including AppRole tokens, as it queries the token's capabilities against a given path.

Full explanation →
277
MCQeasy

A developer wants to use Vault to encrypt sensitive data before storing it in a database. They need to perform encryption and decryption operations without ever exposing the encryption key. Which secrets engine should they use?

A.PKI
B.KV v2
C.Transit
D.Database
AnswerC

Transit provides encryption as a service without exposing keys.

Why this answer

The Transit secrets engine is designed specifically for encryption-as-a-service workflows, allowing applications to encrypt and decrypt data using keys managed entirely within Vault. The encryption key never leaves Vault, satisfying the requirement to avoid exposing the key. In contrast, other engines like KV v2 store raw secrets but do not perform cryptographic operations without exposing the key material.

Exam trap

HashiCorp often tests the misconception that KV v2 can perform encryption operations because it stores encrypted data, but KV v2 does not provide server-side encryption/decryption APIs—it only stores and retrieves secrets as-is.

How to eliminate wrong answers

Option A is wrong because the PKI secrets engine generates and manages X.509 certificates and private keys, not for encrypting arbitrary data with a hidden key. Option B is wrong because KV v2 stores secrets as plaintext or encrypted at rest, but the client must retrieve the raw secret to use it, exposing the key material. Option D is wrong because the Database secrets engine generates dynamic database credentials (usernames/passwords) and does not provide encryption/decryption operations.

Full explanation →
278
MCQmedium

A company uses Vault to manage database credentials for a production PostgreSQL cluster. The application team reports that dynamic credentials generated from the database secrets engine are being revoked before the application has finished using them. The Vault lease TTL is set to 1 hour, but the application workload sometimes runs for up to 2 hours. What is the MOST efficient way to ensure credentials remain valid for the full workload duration?

A.Set max_ttl to 2 hours on the database role.
B.Set the Vault server's default_lease_ttl to 2 hours in the server configuration.
C.Increase the default_lease_ttl on the database secrets engine mount to 2 hours.
D.Have the application manually renew the lease every 30 minutes.
AnswerC

This raises the default TTL for all credentials created by this engine, matching the workload's maximum duration without code changes.

Why this answer

Increasing the default_lease_ttl on the database secrets engine mount ensures that all credentials generated by that engine have a TTL of 2 hours, matching the maximum workload duration without requiring application changes. Option A is wrong because setting max_ttl on the role alone does not change the default TTL; the application would still need to request a longer TTL when generating credentials. Option B is wrong because changing the server's default_lease_ttl affects all secrets in Vault, not just database credentials, which could reduce security unnecessarily.

Option D is wrong because manually renewing leases adds complexity and overhead; it's more efficient to adjust the lease TTL at the engine level.

Full explanation →
279
MCQmedium

A DevOps team has configured a Vault policy to allow reading secrets from the 'secret/data/engineering' path. The policy contains: path "secret/data/engineering/*" { capabilities = ["read", "list"] } However, when a user attempts to read a secret at 'secret/data/engineering/db/password', they receive a permission denied error. What is the most likely cause?

A.The policy uses a single asterisk, which does not match nested paths; it should use double asterisk or specify the exact path.
B.The policy lacks the 'deny' capability to override the default deny.
C.The secret engine's mount path is different; it is mounted at 'secret/' but the policy expects 'secret/data/'.
D.The user's token does not have the correct identity policies attached.
AnswerA

A single * does not cross directory boundaries in path matching.

Why this answer

In Vault's policy path matching, a single asterisk (`*`) matches only a single level of the path, not nested sub-paths. The path `secret/data/engineering/*` matches `secret/data/engineering/foo` but does NOT match `secret/data/engineering/db/password` because the latter has an additional sub-path level. To match all nested paths, you must use a double asterisk (`**`) or explicitly list the full path.

This is a common pitfall when writing Vault policies for hierarchical secret structures.

Exam trap

The Vault exam often tests the subtle distinction between single and double asterisks in Vault policy path matching, exploiting the common misconception that `*` matches any number of nested sub-paths, when in fact it only matches within a single path segment.

How to eliminate wrong answers

Option B is wrong because Vault's default behavior is to deny any action not explicitly allowed; there is no need to add a 'deny' capability, and the `deny` capability is not a standard Vault capability—it is used in Sentinel policies, not ACL policies. Option C is wrong because the policy path `secret/data/engineering/*` correctly matches the standard KV v2 secret engine mount path, where secrets are accessed under `secret/data/`; the mount path is `secret/`, and the `data/` prefix is part of the API path for KV v2, so the policy is correctly scoped. Option D is wrong because the error is specifically about path-level permissions, not about identity policies; identity policies (attached via tokens or entities) would be evaluated in addition to the ACL policy, but the core issue here is that the ACL policy's glob pattern does not cover the nested path.

Full explanation →
280
Multi-Selecthard

Which TWO statements are true about the AWS secrets engine? (Choose two.)

Select 2 answers
A.It can generate AWS session tokens
B.It can generate dynamic IAM users
C.It can manage EC2 key pairs
D.It supports STS federation
E.It only supports static IAM users
AnswersA, B

The engine can generate temporary STS credentials.

Why this answer

The AWS secrets engine can generate temporary AWS session tokens via the AWS Security Token Service (STS). These tokens provide short-term, limited-privilege credentials for accessing AWS resources, which is a core feature of the engine for dynamic credential management.

Exam trap

HashiCorp often tests the misconception that the AWS secrets engine supports STS federation or EC2 key pair management, when in fact it only handles IAM user credentials and STS session tokens, not broader AWS federation or compute resource management.

Full explanation →
281
MCQmedium

A DevOps engineer is troubleshooting a Vault CLI command that is failing with the error 'Error writing data: Error making API request'. The engineer has verified that the Vault token is valid and unexpired. Which of the following is the most likely cause of this error?

A.The Vault token has been revoked.
B.Network connectivity to Vault is intermittent, causing timeouts.
C.The secret engine at that path has not been enabled.
D.The policy attached to the token does not allow writing to the specified path.
AnswerD

A policy deny will cause a permission denied error, often reported as 'Error making API request'.

Why this answer

The error 'Error writing data: Error making API request' with a valid, unexpired token typically indicates an authorization failure. Vault enforces policy-based access control; if the token's attached policy does not include a 'write' or 'create' capability on the specified path, the API will reject the request with this generic error. Since the token is valid and not revoked, the most likely cause is insufficient permissions.

Exam trap

HashiCorp often tests the distinction between authentication (token validity) and authorization (policy permissions), leading candidates to mistakenly suspect network issues or missing secret engines when the real problem is a missing capability in the token's policy.

How to eliminate wrong answers

Option A is wrong because the engineer verified the token is valid and unexpired, so revocation is not the issue. Option B is wrong because intermittent network connectivity would typically produce timeout or connection refused errors, not a structured 'Error making API request' response from the Vault server. Option C is wrong because if the secret engine were not enabled, Vault would return a 404 'no handler for route' error, not a permission-related write error.

Full explanation →
282
MCQeasy

An organization wants to use Vault's dynamic database credentials to manage MySQL access. They have multiple application servers that need to connect to different databases. What is the best practice for configuring database roles to minimize the number of Vault mounts?

A.Use the same database mount but create a separate role per application server.
B.Create a separate database mount for each database to isolate credential generation.
C.Create a single database mount and define multiple roles within it, each with different credential generation parameters.
D.Use a single role that generates credentials for all databases by using a wildcard in the username.
AnswerC

One mount per engine type, multiple roles for different databases.

Why this answer

Vault allows a single database mount (e.g., `database/`) to manage multiple database connections, and within that mount, you can define multiple roles. Each role can specify different credential generation parameters (e.g., username template, default TTL, max TTL, and allowed roles) for distinct databases or application servers. This minimizes the number of mounts while still providing fine-grained access control and isolation of credentials.

Exam trap

HashiCorp often tests the misconception that more mounts equal better isolation, but the best practice in Vault is to minimize mounts and use roles for logical separation, as mounts are a higher-level administrative boundary that should be reserved for different secret engines or vastly different access policies.

How to eliminate wrong answers

Option A is wrong because creating a separate role per application server does not reduce the number of mounts; it increases the number of roles unnecessarily and does not address the goal of minimizing mounts. Option B is wrong because creating a separate database mount for each database directly contradicts the goal of minimizing mounts; it increases administrative overhead and complexity without any security benefit. Option D is wrong because using a wildcard in the username to generate credentials for all databases is not supported by Vault's database secrets engine; roles are bound to specific database connections and cannot use wildcards to span multiple databases, and this would violate the principle of least privilege.

Full explanation →
283
MCQmedium

A DevOps team is managing secrets for a microservices application using Vault. They have created a policy named 'app-policy' that grants read access to secrets under the path 'secret/data/app/*'. The policy is assigned to an AppRole role. When a service authenticates with the role ID and secret ID, it receives a token but is unable to read secrets from 'secret/data/app/db-creds'. The token's identity metadata shows the policies associated with the token include 'default' and 'app-policy'. The Vault server logs show no errors. The service can successfully read other secrets from the same path, like 'secret/data/app/config'. What is the most likely cause of the issue?

A.The secret 'secret/data/app/db-creds' does not exist in Vault.
B.The token does not have the 'app-policy' policy attached due to a misconfiguration in the role.
C.There is an explicit deny rule in the policy that denies access to 'db-creds'.
D.The token is periodic and does not have the correct capabilities for the path.
AnswerA

Other secrets work, so this specific secret likely does not exist.

Why this answer

The most likely cause is that the secret 'secret/data/app/db-creds' does not exist in Vault. The token has the 'app-policy' policy attached, which grants read access to 'secret/data/app/*', and the service can successfully read other secrets under that path (e.g., 'secret/data/app/config'). The absence of Vault server errors indicates that the policy is correctly evaluated and the path is valid, but a read on a non-existent secret returns a 404 (or a permission-denied-like response) without logging an error.

The token's metadata confirms the policy is present, ruling out policy assignment issues.

Exam trap

HashiCorp often tests the distinction between a missing secret and a policy denial, trapping candidates who assume that a 'permission denied' response always indicates a policy issue, when in fact Vault returns a 404 for non-existent paths without logging an error.

How to eliminate wrong answers

Option B is wrong because the token's identity metadata explicitly shows that 'app-policy' is attached, so there is no misconfiguration in the role's policy assignment. Option C is wrong because the policy 'app-policy' grants read access to 'secret/data/app/*' with no explicit deny rules; Vault uses a default-deny model, and an explicit deny would require a separate 'deny' capability or a negative path match, which is not mentioned. Option D is wrong because periodic tokens are unrelated to the issue; the token's capabilities are determined by the attached policies, and the service can read other secrets under the same path, confirming the token has the correct capabilities.

Full explanation →
284
Drag & Dropmedium

Drag and drop the steps to set up Vault's Kubernetes auth method into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The correct sequence for setting up Vault's Kubernetes auth method is: enable the auth method, configure it with the Kubernetes API server details, create a role that binds to a service account, deploy a pod using that service account, and finally verify login. This order ensures that each prerequisite is fulfilled before the subsequent step can function correctly.

Full explanation →
285
MCQhard

A financial services company runs a microservices architecture on Kubernetes. Each microservice needs to authenticate to Vault to retrieve database credentials. The security team mandates that no secrets (tokens, passwords, certificates) be stored in container images or Kubernetes secrets. They also require that each microservice can only access its own secrets. The platform team is evaluating authentication methods. They consider using AppRole, but are concerned about distributing the SecretID. They also consider Kubernetes auth, but are unsure how to restrict access per microservice. They test with a Kubernetes deployment and find that any pod in the namespace can authenticate to Vault. What should they do to meet all requirements?

A.Use Kubernetes auth with a single role for the namespace, and rely on token TTL to limit exposure.
B.Use AppRole with a unique RoleID and SecretID per microservice, distribute via Kubernetes secrets.
C.Use TLS cert auth, generate a certificate per microservice, and mount as a secret.
D.Use Kubernetes auth, create a role per microservice, bind to specific service account names, and assign appropriate policies.
AnswerD

Kubernetes auth can bind to specific service accounts, and policies enforce access.

Why this answer

Kubernetes auth allows Vault to authenticate pods via their service account tokens, and by creating a separate Vault role per microservice bound to a specific Kubernetes service account name, each pod can only authenticate to its designated role. This ensures that only pods with the correct service account can retrieve their own secrets, meeting the requirement that no secrets are stored in images or Kubernetes Secrets and that access is restricted per microservice.

Exam trap

The trap here is that candidates may think Kubernetes auth cannot restrict access per pod, but Vault tests that by binding Vault roles to specific service account names (not just namespaces), you achieve per-microservice isolation without storing any secrets in the cluster.

How to eliminate wrong answers

Option A is wrong because using a single role for the entire namespace would allow any pod in that namespace to authenticate and access all secrets, violating the requirement that each microservice can only access its own secrets. Option B is wrong because distributing the SecretID via Kubernetes Secrets violates the mandate that no secrets be stored in Kubernetes Secrets, and it also introduces the same distribution problem the team was concerned about. Option C is wrong because TLS cert auth would require distributing certificates to each pod, which again involves storing secrets (the private keys) in the container image or as Kubernetes Secrets, violating the mandate.

Full explanation →
286
MCQhard

A developer runs the commands shown in the exhibit. After renewing the lease, the lease_duration remains 1 hour. What is the most likely reason?

A.The lease is not renewable.
B.The mount's max_lease_ttl is set to 1h.
C.The developer does not have permission to renew the lease.
D.The role's max_ttl is set to 1h.
AnswerD

The role max_ttl caps the lease duration.

Why this answer

The role's max_ttl overrides the lease duration when it is shorter than the requested TTL. Even if the lease is renewed, the effective TTL cannot exceed the role's max_ttl, which is set to 1 hour. This is a common Vault behavior where the role's maximum TTL acts as a hard cap on lease lifetimes.

Exam trap

HashiCorp often tests the distinction between role-level and mount-level TTL limits, trapping candidates who assume the mount's max_lease_ttl is the sole constraint when a lower role max_ttl is configured.

How to eliminate wrong answers

Option A is wrong because Vault leases are inherently renewable unless explicitly configured otherwise; the question states the lease was renewed, so it is renewable. Option B is wrong because the mount's max_lease_ttl is a system-wide limit, but the role's max_ttl is a more specific constraint that takes precedence when it is lower. Option C is wrong because the developer successfully renewed the lease, which requires permission to renew; if permission were lacking, the renewal would fail entirely.

Full explanation →
287
MCQeasy

A policy must allow a user to revoke their own token. Which endpoint and capability are required?

A.path "auth/token/revoke" { capabilities = ["update"] }
B.path "auth/token/revoke-self" { capabilities = ["write"] }
C.path "sys/leases/revoke" { capabilities = ["update"] }
D.path "auth/token/revoke-self" { capabilities = ["update"] }
AnswerD

This is the correct endpoint and capability for self-revocation.

Why this answer

To revoke your own token, you need the endpoint 'auth/token/revoke-self' with the 'update' capability. Option A uses 'auth/token/revoke', which is for revoking other tokens and requires sudo capability. Option B uses the correct endpoint but 'write' is not a valid capability in Vault; the correct capability is 'update'.

Option C uses 'sys/leases/revoke', which is for revoking leases, not tokens.

Full explanation →
288
MCQmedium

A DevOps engineer notices that a long-running application using a Vault token fails after 24 hours. The token was created with a TTL of 48h. The token role has a default TTL of 48h and a max TTL of 72h. What is the most likely cause of the failure?

A.The token was manually revoked by an administrator.
B.The token was revoked due to a policy violation.
C.The token is a batch token and cannot be renewed.
D.The mount's max TTL for the token is 24h, overriding the role's setting.
AnswerD

The mount's max TTL is applied first and can cause early expiration.

Why this answer

The most likely cause is that the mount's max TTL for the token is set to 24h, which overrides the role's max TTL of 72h. In Vault, the effective TTL of a token is the minimum of the role's TTL, the mount's max TTL, and the system's max TTL. Since the token fails exactly after 24 hours, the mount's max TTL of 24h is the limiting factor, causing the token to expire even though the role allows up to 48h.

Exam trap

Candidates often mistakenly assume the role's TTL is the sole determinant, ignoring that mount-level and system-level TTLs can override it.

How to eliminate wrong answers

Option A is wrong because there is no evidence of manual revocation; the failure occurs precisely at the 24-hour mark, which aligns with a TTL expiration rather than an administrative action. Option B is wrong because a policy violation would typically cause immediate revocation or denial of operations, not a delayed failure after 24 hours. Option C is wrong because batch tokens cannot be renewed, but they still have a TTL; if the token were a batch token, it would expire based on its TTL, but the question states the token was created with a TTL of 48h, and the failure at 24h points to a mount-level override, not the batch token's non-renewability.

Full explanation →
289
MCQmedium

An operator needs to create a token role named 'web-app' with a default TTL of 24 hours. Which API request is correct?

A.POST /v1/auth/token/roles/web-app with body {"default_ttl":"24h"}
B.POST /v1/auth/token/create/web-app with body {"default_ttl":"24h"}
C.PUT /v1/auth/token/roles/web-app with body {"default_ttl":"24h"}
D.PUT /v1/auth/token/role/web-app with body {"default_ttl":"24h"}
AnswerC

Correct. PUT /auth/token/roles/<role_name> with body {"default_ttl":"24h"} creates or updates the token role named 'web-app' with a default TTL of 24 hours.

Why this answer

Creating a token role in Vault requires a PUT request to the /v1/auth/token/roles/<role_name> endpoint, and the default_ttl parameter must be specified as a string with a time suffix (e.g., '24h'). The PUT method is used for creating or updating a role, and the path must include 'roles' (plural) followed by the role name.

Exam trap

HashiCorp often tests the distinction between creating a role (PUT /roles) and creating a token using a role (POST /create), and the trap here is that candidates mistakenly use the token creation endpoint or the wrong HTTP method for role creation.

How to eliminate wrong answers

Option A is wrong because it uses the POST method, but Vault's token role creation endpoint requires PUT; POST is used for other operations like token creation. Option B is wrong because it targets the /v1/auth/token/create/<role_name> endpoint, which is used for creating tokens using a role, not for creating the role itself. Option D is wrong because it uses 'role' (singular) in the path instead of 'roles' (plural), which is the correct API path for token role management.

Full explanation →
290
Matchingmedium

Match each Vault term to its definition.

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

Concepts
Matches

Encrypted state requiring unseal

Decrypt master key to access data

Encryption layer protecting storage

Key splitting for unseal

Superuser token with full access

Why these pairings

Correct matches: Secret is sensitive data; Token is an authentication credential. Common confusions: Policy vs. Auth Method — policies control access, auth methods authenticate users.

Full explanation →
291
MCQhard

A company uses Vault to store application configuration secrets for multiple teams. The Vault cluster is running in production and has the KV secrets engine enabled at the path 'secret/' using version 2. A DevOps engineer, using a Vault token with full admin access, creates a new secret at 'secret/data/team-a/app-config' using the CLI command 'vault kv put secret/team-a/app-config key=value'. The secret is intended for the CI/CD pipeline, which uses a token with a policy that grants 'read' capability on 'secret/data/*'. The pipeline is configured to read the secret by calling the Vault API at the path 'v1/secret/team-a/app-config'. The pipeline reports a 404 Not Found error. The pipeline engineer verifies that the token is valid and has the correct policy attached. All other secrets in the same path can be read successfully by the pipeline. What is the most likely cause of the 404 error?

A.The secret engine at 'secret/' is not enabled.
B.The secret was written to a different path than expected.
C.The token's policy does not cover the path 'secret/team-a/app-config'.
D.The pipeline is using the wrong API path: for KV v2, the path must include '/data/' before the secret path.
AnswerD

KV v2 requires '/data/' in the path; the pipeline uses 'v1/secret/team-a/app-config' instead of 'v1/secret/data/team-a/app-config'.

Why this answer

The KV secrets engine version 2 (v2) requires the '/data/' segment in the API path for reading secret data. The pipeline is calling 'v1/secret/team-a/app-config', which omits the mandatory '/data/' prefix, causing a 404 Not Found error. The CLI command 'vault kv put' automatically handles this path translation, but the direct API call does not.

Exam trap

The trap here is that candidates confuse the CLI path (which abstracts away the '/data/' prefix) with the raw API path, leading them to think the secret was written to a different path or that the policy is wrong, when the actual issue is the missing '/data/' segment in the API call.

How to eliminate wrong answers

Option A is wrong because the secret engine at 'secret/' is enabled (the DevOps engineer successfully wrote the secret), and the pipeline can read other secrets in the same path, confirming the engine is active. Option B is wrong because the CLI command 'vault kv put secret/team-a/app-config key=value' writes to the correct path under 'secret/data/team-a/app-config', as KV v2 automatically prepends '/data/'. Option C is wrong because the token's policy grants 'read' on 'secret/data/*', which covers the actual path 'secret/data/team-a/app-config', and the pipeline can read other secrets in that path, so the policy is sufficient.

Full explanation →
292
Multi-Selecthard

Which THREE statements about token accessors are true?

Select 4 answers
A.They can be used to look up token metadata without the token ID
B.They can be used to renew the token
C.They can be used to revoke the token
D.They are human-readable strings
E.They are unique identifiers for each token
AnswersA, B, C, E

Correct. The lookup-accessor endpoint retrieves token metadata using the accessor without needing the token ID.

Why this answer

Token accessors have multiple capabilities. Option A is correct because accessors allow lookup of token metadata without the token ID via the lookup-accessor endpoint. Option B is correct because the renew-accessor endpoint allows token renewal using only the accessor.

Option C is correct because the revoke-accessor endpoint allows token revocation using the accessor. Option E is correct because each token has a unique accessor generated at creation. Option D is incorrect because accessors are UUID strings, not human-readable.

Exam trap

A common misconception is that token accessors cannot perform renewal, but Vault actually provides a dedicated renew-accessor endpoint. However, note that renewal via accessor may require appropriate permissions.

Full explanation →
293
MCQmedium

A DevOps team is using Vault tokens with short TTLs for CI/CD jobs. They notice that some jobs fail intermittently with 'permission denied' errors even though the token policy grants the required capabilities. The token is created with a TTL of 10 minutes and renewed automatically by the client library. What is the most likely cause of the failures?

A.The token's max_ttl has been exceeded, causing renewal to fail.
B.The token's parent token has been revoked.
C.The token's max_ttl is being reset each time the token is renewed.
D.The token's TTL is too short and the client library is not renewing in time.
AnswerA

If the token's lifetime exceeds max_ttl, renewal is denied and the token becomes invalid.

Why this answer

Vault tokens have both a TTL (time-to-live) and a max_ttl (maximum time-to-live). When a token is renewed, its TTL is reset to the original TTL (10 minutes) but only if the cumulative lifetime has not exceeded the max_ttl. If the max_ttl is reached, renewal fails, the token expires, and subsequent operations using that token return 'permission denied' errors, even though the policy itself grants the required capabilities.

Exam trap

HashiCorp often tests the distinction between TTL and max_ttl, trapping candidates who assume that automatic renewal indefinitely extends token validity without considering the hard upper limit imposed by max_ttl.

How to eliminate wrong answers

Option B is wrong because revoking the parent token would immediately invalidate all child tokens, causing consistent failures, not intermittent ones, and the scenario describes intermittent failures. Option C is wrong because the max_ttl is a hard upper bound and is never reset or extended by renewal; only the current TTL is reset. Option D is wrong because the client library is described as renewing automatically, and a 10-minute TTL is generally sufficient for CI/CD jobs; the issue is the cumulative lifetime exceeding max_ttl, not the renewal timing.

Full explanation →
294
Multi-Selecthard

Which THREE of the following are true about using the Vault API with response wrapping? (Choose three.)

Select 3 answers
A.The wrapping token never expires
B.The wrapping token can only be used once to unwrap the response
C.The client can request response wrapping by setting the X-Vault-Wrap-TTL header
D.The original token used to make the wrapped request is required to unwrap the response
E.The wrapped response is stored in a cubbyhole secret engine
AnswersB, C, E

Single use is a key property.

Why this answer

The Vault API's response wrapping feature is designed for one-time use: the wrapping token can be used only once to unwrap the response. After the client successfully calls the sys/wrapping/unwrap endpoint with the wrapping token, the token is immediately revoked, and the wrapped secret is deleted from the cubbyhole. This ensures that the secret is delivered securely and cannot be retrieved again with the same token.

Exam trap

HashiCorp often tests the misconception that the wrapping token is reusable or that the original token is needed to unwrap, when in fact the wrapping token is single-use and self-contained for unwrapping.

Full explanation →
295
MCQhard

A user tries to renew their own token using 'vault token renew -self' and gets 'Error renewing token: Error making API request'. The token is still valid. What could be the cause?

A.The token was created with a period.
B.The token is not renewable.
C.The token's policy denies renewal.
D.The Vault server is unreachable.
AnswerB

Correct. The token is not renewable, so attempting to renew it results in an error, even though the token is still valid.

Why this answer

The error 'Error renewing token: Error making API request' when using 'vault token renew -self' on a still-valid token indicates the token is not renewable. In Vault, tokens have a renewable flag; if set to false, the token cannot have its TTL extended, even if it is still valid. The error message is generic but the core issue is the token's non-renewable property, not a policy denial or server connectivity problem.

Exam trap

HashiCorp often tests the distinction between token validity and renewability, trapping candidates who assume a valid token can always be renewed, when in fact the renewable flag is a separate attribute checked before any policy or TTL logic.

How to eliminate wrong answers

Option A is wrong because a token created with a period (explicit TTL) can still be renewable if the renewable flag is set to true; the period does not inherently prevent renewal. Option C is wrong because policy denial would result in a permission denied error (403), not a generic 'Error making API request' message; the token's own renewable flag is checked before policy. Option D is wrong because if the Vault server were unreachable, the error would typically be a connection timeout or refused, not a specific 'Error making API request' response from the server.

Full explanation →
296
Multi-Selectmedium

An admin needs to revoke all leases associated with a particular policy violation. Which two methods can be used? (Choose two.)

Select 2 answers
A.vault sys/leases/revoke-force <prefix>
B.vault token revoke -mode=orphan <token>
C.vault lease revoke <lease_id>
D.vault write sys/leases/revoke-prefix <prefix>
E.vault lease revoke -prefix <mount_path>
AnswersD, E

API equivalent to revoke by prefix.

Why this answer

`vault write sys/leases/revoke-prefix <prefix>` revokes all leases sharing a given prefix, which is the standard method for bulk revocation based on a policy violation path. Option E is correct because `vault lease revoke -prefix <mount_path>` achieves the same result by revoking all leases under a specified mount path, effectively targeting the same scope. Both commands allow an admin to revoke multiple leases associated with a particular policy violation without needing individual lease IDs.

Exam trap

This question tests your ability to distinguish between the `revoke-prefix` and `revoke-force` commands, as well as understanding that individual lease revocation or token revocation commands are not suited for bulk lease revocation by policy violation. Candidates often confuse the CLI syntax or mistakenly think `vault lease revoke` with a single lease ID can revoke all leases, or that `vault token revoke -mode=orphan` affects leases.

Full explanation →
297
MCQmedium

A security administrator notices that a Vault client using AppRole authentication is generating a very large number of tokens, causing performance issues. The administrator finds that the same AppRole role is used by multiple applications. What should the administrator do to reduce the number of tokens while maintaining security?

A.Decrease the token TTL on the AppRole role
B.Periodically rotate the secret ID
C.Create separate AppRole roles for each application
D.Set secret_id_num_uses to 1 on the AppRole role
AnswerC

This allows distinct secret IDs and token limits per application.

Why this answer

Creating separate AppRole roles for each application allows the administrator to isolate token generation per application, preventing a single role from being overwhelmed by multiple clients. This maintains security by ensuring each application has its own set of credentials and policies, reducing the total number of tokens without compromising access control.

Exam trap

A common pitfall in this question is the misconception that reducing token TTL or limiting secret ID usage directly reduces token volume, when in fact these measures can increase operational overhead or token churn without addressing the underlying issue of shared roles.

How to eliminate wrong answers

Option A is wrong because decreasing the token TTL would cause tokens to expire faster, potentially increasing the frequency of token renewal requests and exacerbating the performance issue. Option B is wrong because periodically rotating the secret ID does not reduce the number of tokens generated; it only changes the credential used to obtain tokens, leaving the root cause of high token volume unaddressed. Option D is wrong because setting secret_id_num_uses to 1 would force each application to obtain a new secret ID for every token request, which would increase the number of token operations and worsen performance.

Full explanation →
298
Multi-Selecteasy

A team is evaluating which secrets engines to use for different use cases. Which TWO statements about secrets engines are true?

Select 2 answers
A.The AWS secrets engine can only generate static access keys
B.The Database secrets engine requires a root database user for all configurations
C.The KV v2 secrets engine supports versioning and can store metadata like TTL
D.The Transit secrets engine can generate dynamic database credentials
E.The PKI secrets engine can issue certificates that are automatically renewed by Vault
AnswersC, E

KV v2 stores versions and metadata such as TTL.

Why this answer

The KV v2 secrets engine stores multiple versions of a secret, supports metadata such as TTL and deletion time, and allows check-and-set operations for conflict detection. This makes it suitable for use cases requiring secret rotation and audit trails.

Exam trap

HashiCorp often tests the misconception that 'Transit' implies dynamic credential generation, when in fact Transit is strictly for cryptographic operations on data, not for database credential rotation.

Full explanation →
299
MCQeasy

A developer wants to store an API key for their application in Vault using the key-value secrets engine. They need to be able to retrieve the key and also roll back to a previous version if needed. Which secrets engine configuration should they use?

A.Enable the Transit secrets engine at a custom path
B.Enable the KV v2 secrets engine at a custom path
C.Enable the KV v1 secrets engine at a custom path
D.Enable the Database secrets engine at a custom path
AnswerB

KV v2 supports versioning and rollback to previous versions.

Why this answer

The KV v2 secrets engine supports versioning, allowing retrieval of previous versions and rollback capabilities. This directly meets the requirement to store an API key and revert to an older version if needed. KV v1 does not support versioning, while Transit and Database engines serve different purposes (encryption and dynamic credentials, respectively).

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2, where candidates mistakenly assume all KV engines support versioning, or confuse the Transit engine's encryption capabilities with secret storage.

How to eliminate wrong answers

Option A is wrong because the Transit secrets engine is designed for encryption/decryption operations, not for storing secrets with versioning. Option C is wrong because KV v1 secrets engine does not support versioning or rollback; it only stores the latest value. Option D is wrong because the Database secrets engine generates dynamic database credentials, not for storing static API keys with version history.

Full explanation →
300
MCQmedium

A company needs to issue short-lived TLS certificates for internal microservices. They want to set up a private CA using Vault. Which steps are required to configure the PKI secrets engine?

A.Enable PKI, create a role, generate root CA, issue certificates
B.Generate root CA, enable PKI, create a role, issue certificates
C.Enable PKI, generate intermediate CA, generate root CA, issue certificates
D.Enable PKI, generate root CA, create a role, issue certificates
AnswerD

This is the correct order: enable, generate root, create role, issue.

Why this answer

The correct order to configure the Vault PKI secrets engine is: first enable the PKI secrets engine at a path, then generate a root CA certificate (which creates the CA's key pair and self-signed certificate), then create a role that defines certificate issuance parameters (such as allowed domains and TTL), and finally issue certificates using that role. This sequence ensures the CA exists before roles reference it, and roles exist before certificates are issued.

Exam trap

HashiCorp often tests the correct sequence of operations in Vault PKI setup, and the trap here is that candidates confuse the order of enabling the engine versus generating the CA, or they incorrectly assume an intermediate CA is always required for a private CA setup.

How to eliminate wrong answers

Option A is wrong because it places 'create a role' before 'generate root CA', but a role cannot be created without an existing CA (the role references the CA's key and certificate). Option B is wrong because it starts with 'generate root CA' before 'enable PKI', but the PKI secrets engine must be enabled first to have a mount point where the CA can be generated. Option C is wrong because it introduces an unnecessary 'generate intermediate CA' step; while intermediate CAs are used in multi-tier PKI, the question asks for a private CA setup, and generating an intermediate CA without first generating a root CA is invalid, and the question does not require an intermediate CA.

Full explanation →
Page 3

Page 4 of 7

Page 5

All pages

1234567

Practice VA-003 by domain

Target a specific domain to shore up weak areas.

Compare authentication methodsAssess Vault tokensCreate Vault policiesManage Vault leasesCompare and configure secrets enginesUtilize Vault CLI and APIExplain Vault architectureExplain encryption as a service
See all domains with question counts →