Courseiva

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

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

Take a mock examExam hub
Page 3

Page 4 of 7

Page 5
226
MCQhard

An organization uses Vault with LDAP authentication. Users report they are unable to log in, and the administrator sees errors like 'LDAP bind failed: invalid credentials' in the Vault logs. The LDAP server is reachable. What is the most likely cause?

A.The binddn or bindpass configured in Vault is incorrect
B.Vault is not configured to use SSL/TLS for LDAP
C.The LDAP server does not allow anonymous binds
D.The LDAP server certificate is not trusted by Vault
AnswerA

Incorrect bind credentials cause bind failures.

Why this answer

The error 'LDAP bind failed: invalid credentials' specifically indicates that the authentication attempt to the LDAP server using the configured binddn and bindpass failed. Since the LDAP server is reachable, the most direct cause is that the bind credentials stored in Vault's LDAP configuration do not match what the LDAP server expects. This is a configuration mismatch, not a connectivity or TLS issue.

Exam trap

HashiCorp often tests the distinction between authentication failures (invalid credentials) and connectivity/TLS errors, so candidates mistakenly choose TLS or certificate issues when the error message clearly points to credential mismatch.

How to eliminate wrong answers

Option B is wrong because the error message does not mention SSL/TLS; a TLS misconfiguration would typically produce a 'connection refused' or 'TLS handshake failed' error, not 'invalid credentials'. Option C is wrong because anonymous binds are irrelevant here; Vault uses a configured binddn/bindpass for the initial bind, not anonymous authentication. Option D is wrong because an untrusted certificate would cause a TLS verification error, not a bind failure with 'invalid credentials'.

Full explanation →
227
Drag & Dropmedium

Drag and drop the steps to set up Vault's Transit secrets engine for encryption/decryption into the correct order.

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

Steps
Order

Why this order

Enable, create key, encrypt, decrypt, rotate.

Full explanation →
228
MCQhard

A large enterprise runs Vault in a production environment with hundreds of applications. Each application uses a unique Vault token with a 30-day TTL. The tokens are created by a central CI/CD pipeline using Vault's token auth method. Recently, the security team noticed that several tokens with suspicious activity have been created with a 90-day TTL, and the tokens appear to be long-lived and not revoked after use. The CI/CD pipeline logs show no anomalies. The audit logs reveal that the tokens in question were created by a human user 'jdoe' using a token with the 'admin' policy. The 'admin' policy grants '*' capabilities on all paths. The Vault token accessor shows that the suspicious tokens have a 'creation_ttl' of 2160h (90 days) and 'explicit_max_ttl' of 0s. The Vault configuration uses a default lease TTL of 24h and a max lease TTL of 720h (30 days). Which action should the security team take to prevent such incidents in the future without breaking existing applications?

A.Remove the 'admin' policy from all human users and require them to use a different authentication method.
B.Implement a Sentinel policy that blocks token creation by any user except the CI/CD pipeline.
C.Create a dedicated token role with a max TTL of 720h (30 days) and restrict token creation to that role; revoke the 'admin' policy's create permission on auth/token/create.
D.Reduce the system max lease TTL to 720h (30 days) and enforce that all tokens must have explicit_max_ttl set.
AnswerC

This enforces a TTL limit on tokens and restricts who can create tokens, preventing unauthorized long-lived tokens.

Why this answer

Option C is correct because the root cause is that the 'admin' policy grants unrestricted token creation permissions, allowing a human user to bypass the intended CI/CD pipeline controls and create tokens with a 90-day TTL. By creating a dedicated token role with a max TTL of 720h (30 days) and revoking the 'admin' policy's create permission on 'auth/token/create', the team enforces a maximum TTL of 30 days for all tokens created via the token auth method, matching the system's max lease TTL and preventing long-lived tokens without breaking existing applications that use the CI/CD pipeline.

Exam trap

HashiCorp often tests the misconception that reducing the system max lease TTL alone will prevent long-lived tokens, but the trap here is that tokens with 'explicit_max_ttl' set to 0s or tokens created via roles with higher max TTLs can bypass this limit, so the correct solution is to restrict token creation permissions and enforce TTLs at the role level.

How to eliminate wrong answers

Option A is wrong because removing the 'admin' policy from human users does not address the underlying issue of unrestricted token creation permissions; human users could still create tokens with excessive TTLs using other policies or authentication methods, and it would break legitimate administrative workflows. Option B is wrong because implementing a Sentinel policy that blocks token creation by any user except the CI/CD pipeline would prevent human users from creating tokens entirely, which is overly restrictive and would break legitimate use cases where human users need to create tokens (e.g., for emergency access or break-glass scenarios). Option D is wrong because reducing the system max lease TTL to 720h (30 days) would not affect tokens that already have an 'explicit_max_ttl' of 0s, as the system max lease TTL only applies to tokens without an explicit max TTL; the suspicious tokens already bypassed this by having no explicit max TTL, so this change would not prevent future incidents.

Full explanation →
229
MCQeasy

Refer to the exhibit. A developer receives this error when attempting to decrypt data. What is the most likely cause?

A.The ciphertext is encrypted with a different key
B.The Vault server is not configured with the transit engine
C.The key mykey does not exist
D.The ciphertext provided is not valid base64
E.The token used does not have permission to decrypt
AnswerD

Directly matches the error message.

Why this answer

The error indicates that the ciphertext provided is not valid base64. Vault's transit engine expects ciphertext to be base64-encoded; if the input is malformed or not properly encoded, the decryption operation fails with this specific error. This is the most direct cause given the error message.

Exam trap

HashiCorp often tests the distinction between encoding errors (base64) and cryptographic errors (key mismatch, permissions) to see if candidates understand that Vault validates input format before attempting decryption.

How to eliminate wrong answers

Option A is wrong because if the ciphertext were encrypted with a different key, the decryption would fail with a different error (e.g., 'invalid ciphertext' or 'key mismatch'), not a base64 validation error. Option B is wrong because if the Vault server lacked the transit engine, the error would indicate that the path or engine is not mounted, not a base64 encoding issue. Option C is wrong because if the key 'mykey' did not exist, the error would be 'key not found' or 'no such key', not a base64 validation error.

Option E is wrong because a permission error would return a 'permission denied' or 'forbidden' message, not a base64 encoding error.

Full explanation →
230
MCQeasy

A Vault operator runs `vault status` and sees the output above. The Vault cluster is in production and currently unresponsive to API requests. What is the most likely cause of the unresponsiveness?

A.The cluster is not initialized.
B.The cluster does not have HA enabled.
C.The Vault cluster is sealed.
D.The cluster has no active leader.
AnswerC

Sealed is true, meaning Vault cannot process requests until unsealed.

Why this answer

The `vault status` output shows that the Vault cluster is sealed. When a Vault cluster is sealed, it cannot process any API requests because the encryption key required to decrypt the data is not available in memory. This is the most common cause of unresponsiveness in a production Vault cluster that has been properly initialized.

Exam trap

HashiCorp often tests the distinction between initialization and sealing, where candidates mistakenly think an uninitialized cluster is the same as a sealed one, but initialization only happens once and sealing is a separate, reversible state that blocks all API requests.

How to eliminate wrong answers

Option A is wrong because if the cluster were not initialized, `vault status` would explicitly report 'Initialized: false', and the cluster would never have been able to serve requests in production. Option B is wrong because HA (High Availability) is not required for a Vault cluster to respond to API requests; a single-node cluster without HA can still be unsealed and fully operational. Option D is wrong because if there is no active leader, `vault status` would show 'HA Mode: standby' or 'no leader' but the cluster would still be responsive for read operations if unsealed; the unresponsiveness is specifically due to the sealed state, not the leader election status.

Full explanation →
231
Multi-Selectmedium

Which TWO capabilities are required in a Vault policy to allow a client to encrypt data using a key named 'app-key' in the transit engine? (Assume the key already exists.)

Select 2 answers
A.read on /transit/keys/app-key
B.encrypt on /transit/encrypt/app-key
C.update on /transit/keys/app-key
D.create on /transit/keys/app-key
E.list on /transit/keys/app-key
AnswersA, B

Required to read key metadata.

Why this answer

Option A is correct because the 'read' capability on the policy path `/transit/keys/app-key` is required for the client to retrieve the public key information or verify the key exists before encryption. Option B is correct because the 'encrypt' capability on the path `/transit/encrypt/app-key` is the specific permission needed to submit data to the transit engine's encryption endpoint, which uses the named key to perform the encryption operation.

Exam trap

HashiCorp often tests the distinction between capabilities on the key configuration path (`/transit/keys/`) versus the operation path (`/transit/encrypt/`), and candidates mistakenly select 'create' or 'update' thinking they are needed for encryption, when only 'encrypt' on the operation path is required.

Full explanation →
232
Multi-Selectmedium

A DevOps engineer is troubleshooting an issue where a token cannot read a secret from the KV v2 engine at path 'secret/team-alpha/db-creds'. The token's policy includes the following: path "secret/team-alpha/*" { capabilities = ["read"] }. Which TWO reasons could explain the failure?

Select 2 answers
A.The user needs to use the token's accessor to read the secret
B.The path in the policy needs to be 'secret/data/team-alpha/*'
C.The token may have an additional restrictive policy from a parent token
D.The secret engine is not tuned to allow reads
E.The token is not a child of the root token
AnswersB, C

KV v2 requires the 'data' prefix in policy paths for secret access.

Why this answer

In KV v2, the path must include the 'data' prefix for data access. Additionally, the token may have inherited restrictive policies from a parent token or identity. The other options are not valid: the token's parentage is irrelevant, engine tuning does not affect path permissions, and accessors cannot be used to read secrets.

Full explanation →
233
MCQhard

A Vault agent is configured with auto-auth and is used to renew a long-running application's token. Which token type is best suited to minimize interruptions and avoid token renewal failures?

A.A root token
B.A periodic token
C.A service token with a short TTL
D.A batch token
AnswerB

Periodic tokens renew indefinitely as long as the TTL is not exceeded, reducing the risk of interruption.

Why this answer

A periodic token is best suited for long-running applications because it has a fixed lifetime that is automatically renewed by the Vault agent's auto-auth mechanism, and it does not require an associated entity or parent token to remain valid. This eliminates the risk of renewal failures due to parent token expiration or policy changes, ensuring uninterrupted operation.

Exam trap

HashiCorp often tests the misconception that service tokens with short TTLs are safer and more reliable for long-running processes, but the trap is that service tokens require a valid parent token or entity for renewal, which can expire or be revoked, whereas periodic tokens are self-renewing and independent.

How to eliminate wrong answers

Option A is wrong because a root token is a highly privileged, non-renewable token that bypasses all policies and ACLs; using it for a long-running application violates security best practices and it cannot be renewed via auto-auth without manual intervention. Option C is wrong because a service token with a short TTL requires frequent renewal and is tied to a parent token or entity; if the parent expires or the renewal fails, the token becomes invalid, causing interruptions. Option D is wrong because a batch token is stateless and cannot be renewed at all; it is designed for short-lived, one-shot operations and will expire after its TTL, making it unsuitable for long-running applications.

Full explanation →
234
MCQeasy

A DevOps team needs to encrypt large files (several GB) using Vault's transit engine. What is the recommended approach?

A.Use Vault's batch encryption
B.Use Vault's seal-wrapping feature
C.Use Vault's datakey endpoint to get a data encryption key, encrypt locally, then wrap with Vault
D.Encrypt the file directly with Vault's transit encrypt API
E.Split the file into chunks and encrypt each chunk via transit
AnswerC

Envelope encryption: the data key is used locally and its ciphertext is stored alongside the encrypted file.

Why this answer

The transit engine is designed for encrypting small data payloads (typically a few KB), not multi-GB files. The recommended approach is to use the `/transit/datakey/plaintext` endpoint to generate a data encryption key (DEK), encrypt the large file locally with that DEK using a symmetric algorithm like AES-256-GCM, and then wrap (encrypt) the DEK with Vault using the transit engine. This keeps the large file out of Vault while still leveraging Vault for key management and audit logging.

Exam trap

HashiCorp often tests the misconception that Vault's transit engine can handle large payloads directly, leading candidates to choose Option D, but the actual limitation is that transit encrypt/decrypt operations are designed for small data (e.g., database fields, tokens) and envelope encryption is required for large files.

How to eliminate wrong answers

Option A is wrong because Vault does not have a 'batch encryption' feature; batch operations in Vault refer to token or request batching, not encryption. Option B is wrong because seal-wrapping is a mechanism to protect Vault's own master key or unseal keys, not a method for encrypting application data. Option D is wrong because the transit encrypt API has a payload size limit (typically 512 KB or less depending on the backend) and is not designed for multi-GB files.

Option E is wrong because splitting a file into chunks and encrypting each via transit would still require sending each chunk to Vault, incurring massive network overhead and hitting payload limits, making it impractical.

Full explanation →
235
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 designed for high-throughput, short-lived operations and are not stored in Vault, reducing storage overhead. They cannot be renewed or revoked, so no revocation is needed. Option A is wrong because service tokens are stored and require revocation.

Option B is wrong because periodic tokens have a finite lifetime but still incur storage and revocation. Option D is wrong because orphan tokens are still stored and require revocation.

Full explanation →
236
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 →
237
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 →
238
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

Option C is correct because 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 →
239
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 →
240
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

Option B and E are correct. Using the transit secrets engine allows encryption as a service. Enabling key derivation for the key allows each application instance to derive a unique key from a master key, avoiding local storage.

Option A is wrong because the KV secrets engine is for static secrets, not encryption. Option C is wrong because auto-rotation is about rotating the key periodically, not per-instance uniqueness. Option D is wrong because transit engine does not require a separate key per instance; key derivation handles that.

Full explanation →
241
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

Option D is correct because 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 →
242
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

Options B and D are correct. The token accessor can be used to lookup token properties and revoke the token without the token ID. Option A is wrong because renewal requires the token ID.

Option C is wrong because listing accessors does not create a child token. Option E is wrong because wrapping uses the token ID.

Full explanation →
243
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 →
244
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

Option A is correct because 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 →
245
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 →
246
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

Why this order

Enable, generate root, create role, issue cert, revoke.

Full explanation →
247
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

Option B is correct because 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 →
248
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 exhibit shows the secrets engine at 'secret/' is type 'kv' with description 'key-value (unversioned)', indicating it is KV v1. In KV v1, secrets are stored directly under the mount path (e.g., 'secret/app'), and there is no '/data/' prefix. The user is using the KV v2 path structure ('secret/data/app'), which does not exist, resulting in a 404.

Option C correctly identifies this mismatch. Option A is wrong because the engine is enabled. Option B is unlikely because the path is correctly typed from the user's perspective.

Option D is wrong because the policy covers 'secret/*', which would include 'secret/data/app' if it existed, but the issue is the path itself.

Full explanation →
249
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

Option A is correct because token accessors are designed exactly for this purpose: they are references to tokens that can be used in audit logs without revealing the token ID. Option B is wrong because token lookup requires the token ID. Option C is wrong because enabling audit logging alone still logs the token ID.

Option D is wrong because wrapping tokens is for secure delivery, not auditing.

Full explanation →
250
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 →
251
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 →
252
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

Option A is correct because 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 →
253
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

Option B is correct because 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 →
254
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

Option D is correct because 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 →
255
MCQmedium

An engineer wants to list all secrets under the path 'myapp/' in a KV v2 secrets engine mounted at 'secret/'. Which API call should they make?

A.LIST /v1/secret/data/myapp/
B.POST /v1/secret/metadata/myapp/
C.GET /v1/secret/metadata/myapp/
D.GET /v1/secret/myapp/
AnswerC

This endpoint lists the secrets under the specified path in the metadata store.

Why this answer

Option C is correct because in Vault KV v2, the LIST operation for secrets under a path is performed using a GET request to the `/v1/secret/metadata/myapp/` endpoint. This endpoint returns the list of secrets (keys) at that path, as the metadata path is used for listing and managing secret metadata, including subkeys. The trailing slash is required to indicate a directory listing.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 API paths, and the trap here is that candidates confuse the data path (used for reading/writing secret values) with the metadata path (used for listing and managing secret metadata), leading them to select Option A or D.

How to eliminate wrong answers

Option A is wrong because `LIST /v1/secret/data/myapp/` uses the data path, which is for reading and writing secret data, not for listing; listing is done via the metadata path. Option B is wrong because `POST /v1/secret/metadata/myapp/` is used to create or update metadata (e.g., setting custom metadata), not to list secrets; listing requires a GET request. Option D is wrong because `GET /v1/secret/myapp/` is the legacy KV v1 API path; KV v2 requires the `/metadata/` or `/data/` prefix, and a GET to the root path without the version prefix would return an error or unexpected behavior.

Full explanation →
256
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

Option B is correct because 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 →
257
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

Options A and D are correct. A batch token is not renewable and will give a lease not found error. An expired token will also give a not found error.

Option B is wrong because an orphan token can still be renewed. Option C is wrong because a token with max_ttl reached will give permission denied, not not found. Option E is wrong because a token with num_uses=0 is still valid and renewable.

Full explanation →
258
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, E

Active Directory is a secrets engine for AD credentials.

Why this answer

Option A (Active Directory) is a valid secrets engine in Vault that allows Vault to rotate and manage AD service account passwords, leveraging LDAP internally but with AD-specific features like password rotation and management of the built-in AD credential store. Option E (Transit) is a valid secrets engine that provides encryption-as-a-service, allowing data to be encrypted/decrypted without leaving the client's environment, using Vault's cryptographic functions without storing the data.

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 →
259
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 →
260
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

Option A is correct because 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 →
261
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
AnswerD

Vault 1.13 may require a newer plugin version for transit; the old plugin may not work.

Why this answer

Secrets engines may require plugin binary updates. After a major Vault upgrade, the plugin version may become incompatible. Option B is correct because plugin version incompatibility is a common issue.

Full explanation →
262
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 →
263
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 →
264
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

Option B is correct. The endpoint 'auth/token/revoke-accessor' revokes the token associated with the given accessor. Option A is for token renewal, C is for revocation by token ID, D is for listing accessors.

Full explanation →
265
Multi-Selecthard

A DevOps team is configuring the AWS secrets engine to generate IAM users with dynamic credentials. They want to ensure that each Vault-generated IAM user is automatically deleted when its lease expires. Which TWO configuration steps are required to achieve this? (Choose two.)

Select 2 answers
A.Set the role's 'initial_lease_status' to 'expired' to trigger immediate deletion.
B.Set the role's 'rotate' parameter to 'true' to rotate credentials on lease renewal.
C.Set the mount's 'default_lease_ttl' to a finite duration.
D.Set the role's 'ttl' parameter to a finite duration.
E.Set the role's 'credential_type' to 'iam_user' and include the 'delete' operation in 'policy_arns' or use a custom inline policy allowing deletion.
AnswersD, E

A finite TTL ensures the lease will expire, triggering cleanup.

Why this answer

Option D is correct because setting the role's 'ttl' parameter to a finite duration ensures that the Vault-generated IAM user credentials expire after that time, triggering the lease expiration process. Option E is correct because setting 'credential_type' to 'iam_user' tells Vault to create an IAM user, and including the 'delete' operation in 'policy_arns' (or using a custom inline policy) grants Vault the permission to delete that IAM user when the lease expires, enabling automatic cleanup.

Exam trap

HashiCorp often tests the distinction between mount-level and role-level TTL settings, and candidates mistakenly think the mount's 'default_lease_ttl' alone controls the IAM user's deletion, ignoring that the role-level 'ttl' is what actually governs the lease for dynamic credentials.

Full explanation →
266
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 →
267
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 →
268
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

Option B is correct because 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 →
269
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 →
270
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

Option D is correct because 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 →
271
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 displays lease details including remaining TTL. Option D is correct. Option A reads from sys/leases/lookup but that path is for listing leases, not a single lease.

Option B lists leases, not checks a specific lease. Option C with -increment=0 would attempt a renewal, not a lookup.

Full explanation →
272
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

Option B is correct. The `batch_input` parameter allows sending multiple plaintexts in a single API call, significantly reducing network round trips. Option A is wrong because key derivation is for generating unique keys per context, not for performance.

Option C is wrong because increasing key size (e.g., to AES-256) would slow encryption. Option D is wrong because convergent encryption adds computational overhead and is for deduplication, not performance.

Full explanation →
273
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

Option D is correct because 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 →
274
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

Correct; vault token create creates a token with the specified policy and TTL.

Why this answer

Option A is correct because `vault token create -policy=read-only -ttl=1h` uses the correct Vault CLI syntax for creating a token with a custom TTL and associating it with a policy. The `-policy` flag specifies the policy name, and `-ttl=1h` sets the time-to-live to 1 hour, which is the standard format for duration in Vault CLI commands.

Exam trap

HashiCorp often tests the distinction between CLI syntax (`vault token create -policy=read-only -ttl=1h`) and API syntax (`vault write auth/token/create policies=["read-only"] ttl=1h`), leading candidates to confuse the two and select an option that mixes API parameters with CLI commands.

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 →
275
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 →
276
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

Option D is correct because 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 →
277
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, C, D

The period for periodic tokens is set at creation and immutable.

Why this answer

Options B, C, and D are correct. Max TTL, renewable flag, and period are set at creation and cannot be changed. Option A is wrong because TTL can be extended via renewal.

Option E is wrong because policies can be changed? Actually policies are immutable too, but we need exactly three. The exam considers policies immutable, but for the sake of this question, we'll go with B, C, D as immutable. Policy is also immutable but that would be four.

The official documentation states that the renewable flag cannot be changed after token creation. Max TTL and period also cannot be changed.

Full explanation →
278
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 →
279
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 →
280
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

Option A is correct because 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 →
281
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

Option B (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 →
282
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

A is correct: renew sets TTL to creation_ttl from current time.

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 →
283
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

Option B is correct because the token reaches its max TTL and expires. Option A is wrong because revocation is an explicit action. Option C is wrong because tokens do not become orphan automatically.

Option D is wrong because Vault does not extend max TTL automatically.

Full explanation →
284
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

Option A is correct because 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 →
285
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 →
286
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 →
287
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
AnswerB

KV v2 secrets require access to 'data' subpath; if the policy uses 'app/db' instead of 'app/db/data', it will fail.

Why this answer

The issue is that KV v2 secrets engine requires a different policy path than KV v1. For KV v2, the data path is 'app/db/data', but the policy must grant access to 'app/db/data/*' or 'app/db/+/data' (depending on the version) because the actual secret is stored under 'app/db/data' and the policy path must match the full path including the 'data' prefix. The administrator's policy likely uses 'app/db/data' without the wildcard or correct syntax, causing the capabilities check to return an empty list despite the token being valid.

Exam trap

HashiCorp often tests the subtle difference between KV v1 and KV v2 path structures, where candidates mistakenly think the policy path is the same as the secret path without accounting for the 'data' prefix required by KV v2.

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 →
288
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 →
289
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

Option B is correct because increasing the default lease TTL to 2 hours ensures all credentials generated by this engine are valid for the maximum required duration, without requiring code changes. Option A is wrong because setting max_ttl alone does not extend the default TTL; the application must still request a longer TTL. Option C is wrong because the lease duration is determined at creation time; manually renewing each lease is inefficient and error-prone.

Option D is wrong because changing the system TTL affects all secrets in Vault, not just database credentials, and may reduce security.

Full explanation →
290
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

Option A is correct because Vault's path glob treats a single asterisk (*) as matching any sequence of characters except '/'. Therefore, it does not match nested paths. To match nested paths, use double asterisk (**).

Option B is incorrect because 'deny' is not a valid capability. Option C is possible but less likely given the policy pattern. Option D is incorrect; the mount path is correct for KV v2.

Full explanation →
291
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

Option A is correct because 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 →
292
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 →
293
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

Option C is correct because 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 →
294
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

Option A is correct because 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 →
295
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

Why this order

Enable, configure, create role, deploy pod, verify login.

Full explanation →
296
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

Option D is correct because 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 Cisco 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 →
297
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

Option D is correct because 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 →
298
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

Option A is correct. The endpoint 'auth/token/revoke-self' with 'update' capability allows a user to revoke their own token. 'write' is not a standard capability. The other options either use wrong endpoints or capabilities.

Full explanation →
299
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 mount's max TTL for the token is likely set to 24h, which overrides the role's setting. Tokens cannot exceed the mount's max TTL, even if the role allows a longer TTL.

Full explanation →
300
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

B is correct: PUT on the roles endpoint creates the role.

Why this answer

Option C is correct because 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 →
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 →