HashiCorp Vault Associate VA-003 VA-003 Questions 376–450 | Page 6/7

376

Multi-Selectmedium

A company is deploying Vault in a Kubernetes environment. Which three components are essential for a production-ready Vault on Kubernetes? (Choose three.)

Select 3 answers

A.A ConfigMap to store Vault configuration including unseal keys.

B.A persistent volume claim for each Vault pod for storage.

C.A service account with appropriate RBAC to interact with the Kubernetes API.

D.An Ingress controller to expose Vault externally.

E.A StatefulSet to manage Vault pods with stable network identities.

AnswersB, C, E

Persistent storage is essential for Raft.

Why this answer

Option B is correct because Vault requires durable storage for its encrypted data (the storage backend). In Kubernetes, a PersistentVolumeClaim (PVC) provides this durable block or file storage that survives pod restarts. Without a PVC, Vault would lose its data when the pod is rescheduled, making it unsuitable for production.

Exam trap

HashiCorp often tests the misconception that unseal keys can be stored in a ConfigMap for convenience, but the exam expects you to recognize that this violates Vault's security model and is never production-ready.

Full explanation →

377

Multi-Selectmedium

A company uses Vault transit to encrypt secrets. They want to periodically rotate the encryption key to comply with compliance requirements. Which TWO actions should be taken? (Choose two.)

Select 2 answers

A.Update the min_decryption_version to the newest version immediately.

B.Export the key and re-encrypt all data manually.

C.Rewrap all existing ciphertext with the new key version.

D.Delete old key versions after rotation.

E.Rotate the key using Vault's key rotation endpoint.

AnswersC, E

Rewrapping updates ciphertext to the new version without revealing plaintext.

Why this answer

Option C is correct because Vault's `vault rewrap` command re-encrypts existing ciphertext with the latest key version without decrypting the underlying plaintext, preserving the data's confidentiality. This is essential after a key rotation to ensure all ciphertext uses the new key, meeting compliance requirements for periodic key rotation.

Exam trap

HashiCorp often tests the misconception that you must delete old key versions immediately after rotation, but the correct practice is to keep them until all ciphertext is rewrapped to avoid data loss.

Full explanation →

378

MCQeasy

A security policy requires that all tokens are revoked when a user leaves the organization. What is the most efficient way to revoke all tokens issued to that user?

A.Use the identity/entity endpoint to revoke all tokens associated with the user's entity

B.Revoke each token individually using its accessor

C.Use the auth/token/revoke-prefix endpoint with the user's token path

D.Restart the Vault server

AnswerA

Entity-based revocation revokes all tokens linked to the entity.

Why this answer

Option D is correct. Revoking by entity ID ensures all tokens associated with the user's entity are revoked, regardless of creation path. Option A is inefficient.

Option B is dangerous as root token manages all tokens but not specifically for one user. Option C misses tokens created via other auth methods.

Full explanation →

379

Multi-Selectmedium

Which TWO of the following are true about Vault token accessors?

Select 2 answers

A.An accessor is the same as the token ID.

B.An accessor can be used to revoke a token without having the token ID.

C.Accessors are unique only within a namespace.

D.An accessor is required to look up token properties.

E.An accessor can be used to renew a token without having the token ID.

AnswersB, E

Correct: The /auth/token/revoke-accessor endpoint allows revocation using only the accessor.

Why this answer

Token accessors are unique references to tokens that allow certain operations without exposing the token ID. Options A and B are correct: accessors can be used to revoke or renew tokens without the token ID. Option C is incorrect because token properties can be looked up using either the token ID or its accessor, but the accessor is not required.

Option D is false as accessors are unique globally across the Vault cluster, not just within a namespace. Option E is false because an accessor is a separate identifier from the token ID.

Full explanation →

380

MCQhard

A security team wants to ensure that secrets stored in Vault are encrypted in transit and at rest, and that even Vault administrators cannot read the plaintext secret values. Which configuration is required?

A.Set a strong master key for the Vault cluster

B.Configure storage backend encryption using a KMS

C.Enable the Transit secrets engine and encrypt secrets before writing them to KV

D.Both A and B

AnswerC

Transit encrypts secrets at the application level, so admins cannot see plaintext without the encryption key.

Why this answer

Option C is correct because the Transit secrets engine allows clients to encrypt data (including secrets) using Vault-managed encryption keys before writing the ciphertext to a storage backend like KV. This ensures that even Vault administrators with access to the raw storage backend cannot read plaintext secret values, as the encryption key is never exposed to them. The Transit engine also supports encryption in transit via TLS and at rest via the encrypted ciphertext stored in the KV engine, meeting the full requirement.

Exam trap

HashiCorp often tests the misconception that storage backend encryption or a strong master key alone can protect secrets from administrators, but the correct approach is client-side encryption via the Transit secrets engine, which ensures that plaintext secrets are never visible to Vault operators.

How to eliminate wrong answers

Option A is wrong because a strong master key protects the Vault cluster's root key and seals/unseals the Vault, but it does not prevent Vault administrators from reading plaintext secrets once Vault is unsealed; administrators with appropriate policies can still access secret values. Option B is wrong because configuring storage backend encryption using a KMS encrypts the data at rest in the storage backend, but Vault administrators with access to the unsealed Vault can still read plaintext secrets; KMS encryption protects against physical theft of storage, not against administrative access. Option D is wrong because combining A and B still does not prevent Vault administrators from reading plaintext secrets; neither the master key nor storage backend encryption provides client-side encryption that keeps secrets opaque to Vault operators.

Full explanation →

381

MCQmedium

An organization uses Vault's AWS secret engine to dynamically generate IAM credentials. The application uses the API to request credentials by calling 'POST /v1/aws/creds/my-role'. Recently, the application started receiving '400 Bad Request' with error 'invalid role ARN'. The role 'my-role' is defined in Vault and has been working for months. The administrator checks the role configuration and confirms the ARN is correct and that the associated IAM policy exists in AWS. The Vault server logs show no connectivity issues with AWS. The application code has not changed. What is the most likely cause?

A.The Vault token used for the API call has expired

B.The IAM role's trust policy has been modified to not allow Vault's AWS account to assume the role

C.The role ARN has been changed in AWS but not updated in Vault

D.The application is calling the wrong API endpoint

AnswerB

Vault assumes the role; if trust policy changes, it fails.

Why this answer

The error 'invalid role ARN' from Vault's AWS secret engine indicates that Vault is unable to assume the IAM role during credential generation. Since the role ARN is confirmed correct in Vault and the IAM policy exists, the most likely cause is that the IAM role's trust policy no longer permits Vault's AWS account (or the external ID used by Vault) to assume the role. This would cause AWS to reject the sts:AssumeRole call, returning an error that Vault interprets as an invalid ARN, even though the ARN string itself is correct.

Exam trap

HashiCorp often tests the distinction between a syntactically correct ARN and a role that is actually assumable, leading candidates to focus on the ARN string itself rather than the trust policy that governs cross-account access.

How to eliminate wrong answers

Option A is wrong because an expired Vault token would result in a '403 Forbidden' or 'permission denied' error, not a '400 Bad Request' with 'invalid role ARN', as token expiration is an authentication issue unrelated to the role ARN validation. Option C is wrong because if the role ARN had been changed in AWS but not updated in Vault, the error would likely be 'role not found' or a different AWS error, and the administrator confirmed the ARN is correct in Vault. Option D is wrong because calling the wrong API endpoint would result in a '404 Not Found' or '405 Method Not Allowed', not a '400 Bad Request' with a specific error about the role ARN.

Full explanation →

382

MCQmedium

A company requires that Vault's master key be split into multiple key shares and distributed to different administrators using Shamir's Secret Sharing. They also need to ensure that Vault can automatically unseal if a majority of shares are provided but cannot rely on manual intervention. Which unseal approach should they configure?

A.Store the master key in the transit secrets engine and unseal automatically

B.Use AWS KMS as a seal for auto-unseal

C.Configure Shamir seal with a threshold and use unseal keys via a key provider

D.Use a single unseal key stored in a password manager and manually unseal

AnswerC

Shamir seal with auto-unseal can be achieved by combining shares using a shamir seal wrapper.

Why this answer

Option C is correct because Shamir seal (also known as the 'seal' wrapping mechanism) allows Vault to use Shamir's Secret Sharing to split the master key into shares, and then automatically unseal by providing those shares via a key provider (e.g., a cloud KMS or HSM) without manual intervention. This satisfies the requirement of splitting the key among administrators while enabling auto-unseal when a majority of shares are available.

Exam trap

HashiCorp often tests the distinction between 'Shamir seal' (which uses multiple shares and a key provider for auto-unseal) and 'Shamir's Secret Sharing' (which is the manual unseal process), causing candidates to confuse the two and incorrectly select a single-key auto-unseal option like AWS KMS.

How to eliminate wrong answers

Option A is wrong because storing the master key in the transit secrets engine would defeat the purpose of splitting the key and does not provide auto-unseal; the transit engine is for encrypting data, not for managing unseal keys. Option B is wrong because AWS KMS as a seal (i.e., using AWS KMS as a seal wrapping mechanism) is a single-key auto-unseal approach, not a multi-share split-key method; it does not involve distributing key shares to multiple administrators. Option D is wrong because using a single unseal key stored in a password manager and manually unsealing violates the requirement to split the key into multiple shares and to avoid manual intervention.

Full explanation →

383

Multi-Selecthard

Which THREE factors contribute to the security of the AppRole authentication method? (Choose three.)

Select 3 answers

A.Keeping the RoleID secret

B.Configuring token policies

C.Setting a secret_id_num_uses limit

D.Binding the SecretID to a specific CIDR block

E.Setting a secret_id_ttl

AnswersC, D, E

Prevents replay attacks.

Why this answer

Option C is correct because setting a `secret_id_num_uses` limit restricts the number of times a SecretID can be used to obtain a token from Vault. This prevents replay attacks and limits the blast radius if a SecretID is leaked, as it becomes invalid after the specified number of uses.

Exam trap

HashiCorp often tests the misconception that the RoleID must be kept secret, but in reality it is the SecretID that must be protected, and the RoleID is analogous to a username.

Full explanation →

384

Matchingmedium

Match each Vault auth method to its authentication mechanism.

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

Concepts

Matches

RoleID and SecretID

Username/password against LDAP server

Static or periodic tokens

Service account token

JSON Web Token / OpenID Connect

Why these pairings

These are standard Vault authentication methods.

Full explanation →

385

MCQhard

An organization wants to ensure that even Vault administrators cannot see the plaintext of data encrypted with the transit engine, but they want to use Vault for key management. What feature should be enabled?

A.Seal wrapping

B.Convergent encryption

C.Client-side encryption with datakey

D.Key deletion prevention

E.Key derivation

AnswerC

Datakey allows local encryption; Vault only stores and unwraps the key.

Why this answer

Option C is correct because client-side encryption with a datakey allows the application to encrypt data locally using a key obtained from Vault, ensuring that Vault administrators never see the plaintext. The datakey is generated by Vault and returned in both plaintext and ciphertext forms; the application encrypts data with the plaintext key and then discards it, storing only the ciphertext key alongside the encrypted data. This decouples key management from data encryption, meeting the requirement that even Vault administrators cannot access the plaintext.

Exam trap

HashiCorp often tests the distinction between server-side encryption (where Vault handles encryption/decryption) and client-side encryption (where the application handles encryption using a Vault-provided key), and candidates mistakenly choose seal wrapping or key derivation because they sound like they add security layers, but they do not prevent administrators from accessing plaintext.

How to eliminate wrong answers

Option A is wrong because seal wrapping encrypts Vault's own data (e.g., storage backend entries) using a seal mechanism, but it does not prevent administrators from seeing plaintext data encrypted via the transit engine; it protects Vault's internal state, not user data. Option B is wrong because convergent encryption uses the data's hash as part of the encryption key, enabling deduplication, but it does not prevent administrators from seeing plaintext; the transit engine still holds the key and can decrypt data on demand. Option D is wrong because key deletion prevention (e.g., deletion protection in Vault) prevents accidental or malicious deletion of encryption keys, but it does not address plaintext visibility; administrators can still use the key to decrypt data.

Option E is wrong because key derivation (e.g., using derived keys per context) creates unique keys for different contexts, but the transit engine still manages the encryption and decryption operations, meaning administrators could potentially decrypt data if they have access to the key.

Full explanation →

386

MCQmedium

A token with a policy granting 'write' on 'secret/team-alpha/*' is unable to write to 'secret/team-alpha/db-creds' in a KV v2 engine. What is the most likely cause?

A.The token is not a root token

B.The token's TTL has expired

C.The token has a conflicting policy from a parent token

D.The policy path should be 'secret/data/team-alpha/*' for KV v2

AnswerD

KV v2 secrets are accessed under the 'data' sub-path.

Why this answer

Option B is correct because KV v2 requires the 'data' prefix in the policy path for accessing secrets. Option A is wrong because token expiration would give a 403 with a different error. Option C is wrong because the token is not root but still should work with the correct path.

Option D is wrong because the token may have other policies that grant or deny, but the primary issue is the missing 'data' prefix.

Full explanation →

387

Multi-Selectmedium

An administrator is reviewing Vault token policies and wants to ensure that tokens created by a specific application cannot be renewed and have a fixed lifetime. Which two token configurations should be applied?

Select 2 answers

A.Set max_ttl on the role to a very large value.

B.Set renewable to false.

C.Set ttl on the token to 0.

D.Set explicit_max_ttl on the token to match the desired TTL.

E.Set no_default_policy to true.

AnswersB, D

Setting renewable to false prevents the token from being renewed.

Why this answer

To prevent renewal and fix the lifetime, set 'explicit_max_ttl' to the desired maximum TTL (which cannot be extended) and set 'renewable' to false so that renewal is not allowed. Option B (max_ttl) is a limit but doesn't prevent renewal, Option D (ttl=0) is not valid, and Option E (no_default_policy) is unrelated.

Full explanation →

388

MCQhard

A company deploys Vault in a production environment with three nodes using Integrated Storage (Raft). They have configured Performance Replication to a secondary datacenter. The primary datacenter experiences a complete outage. After restoring the primary, they promote the secondary to primary. However, they notice that some secrets written to the primary just before the outage are missing in the secondary. The replication status shows no errors. What is the most likely cause and correct action?

A.Accept the data loss and continue with the secondary as primary

B.Restore the primary from backup to recover missing secrets

C.Failback to the original primary after restoring it

D.Re-promote the original primary and use it as the new primary

AnswerA

Asynchronous replication may lose recent writes; accept and move on.

Why this answer

Performance Replication in Vault is asynchronous, meaning there is no guarantee that all writes to the primary are replicated to the secondary before a failure. When the primary experiences a complete outage, any secrets written just before the outage that had not yet been acknowledged by the secondary are permanently lost. Since the replication status shows no errors, the system is consistent up to the last replicated point, and the only correct action is to accept the data loss and continue with the promoted secondary as the new primary.

Exam trap

The trap here is that candidates assume replication guarantees zero data loss because the status shows no errors, but they fail to recognize that asynchronous replication inherently allows a small window of unreplicated writes.

How to eliminate wrong answers

Option B is wrong because restoring the primary from backup would reintroduce stale data and potentially cause conflicts with the promoted secondary, and it does not recover the missing secrets that were never replicated. Option C is wrong because failing back to the original primary after restoring it would require the original primary to catch up with the secondary, but the missing secrets were never on the secondary, so they cannot be recovered through failback. Option D is wrong because re-promoting the original primary as the new primary would ignore the fact that the secondary has already been promoted and is now the authoritative source; this would cause a split-brain scenario and data inconsistency.

Full explanation →

389

MCQmedium

A team is adopting Vault and wants to organize secrets by application and environment (e.g., production, staging). What is the best practice for secrets engine path naming?

A.Use hierarchical paths like 'app/env/secret'

B.Use a single path like 'secrets/' for simplicity

C.Use the same path for all applications but separate with prefixes like 'app1-'

D.Use random UUIDs to avoid guessing

AnswerA

Hierarchical paths enable fine-grained ACLs and easy organization by app and environment.

Why this answer

Hierarchical paths like 'app/env/secret' are the best practice because they allow Vault's ACL policies to apply fine-grained access control at each level of the path. This structure maps directly to the organization's application and environment boundaries, enabling least-privilege access without complex policy rules. It also simplifies secret rotation and auditing by keeping related secrets logically grouped.

Exam trap

HashiCorp often tests the misconception that flat or prefix-based naming is simpler and therefore better, but the trap is that Vault's ACL engine is path-based and hierarchical paths are required for proper policy isolation and least-privilege access control.

How to eliminate wrong answers

Option B is wrong because using a single flat path like 'secrets/' prevents any granular access control; all policies would apply to the entire path, violating the principle of least privilege. Option C is wrong because using prefixes like 'app1-' on a shared path still forces all secrets under one policy scope, making it impossible to restrict access to specific applications or environments without cumbersome regex-based policies. Option D is wrong because random UUIDs make secrets unmanageable and impossible to organize by application or environment; they also break the human-readable path structure that Vault policies rely on for clear, maintainable access rules.

Full explanation →

390

MCQmedium

A Vault administrator wants to configure a role for dynamic secrets with a default TTL of 1 hour and a max TTL of 4 hours. They also want to allow renewal but only up to the max TTL. Which configuration achieves this?

A.default_ttl=1h, max_ttl=4h, renewable=false

B.default_ttl=4h, max_ttl=1h, renewable=true

C.default_ttl=1h, max_ttl=4h, renewable=true

D.default_ttl=1h, max_ttl=4h, renewable=true, ttl=1h

AnswerC

This allows renewal up to the max_ttl of 4 hours.

Why this answer

Setting default_ttl=1h, max_ttl=4h, and renewable=true allows the lease to be renewed up to a total lifespan of 4 hours, with initial TTL of 1 hour. Option B is correct. Option A has renewable=false, preventing renewal.

Option C has max_ttl less than default, which is invalid. Option D adds an unnecessary ttl parameter.

Full explanation →

391

MCQmedium

An administrator wants to create a policy that grants the ability to list all authentication methods enabled on the Vault server. Which path and capability are required?

A.path "sys/auth" { capabilities = ["list"] }

B.path "sys/auth" { capabilities = ["read", "list"] }

C.path "sys/auth" { capabilities = ["read"] }

D.path "auth/*" { capabilities = ["list"] }

AnswerA

List on sys/auth returns the names of all enabled auth methods.

Why this answer

Option B is correct. The path 'sys/auth' with 'list' capability lists all auth methods. Option A with 'read' would give details but not list.

Option C includes both, which is overkill. Option D uses a wildcard that may also list unrelated items.

Full explanation →

392

MCQeasy

An administrator wants to allow users to authenticate to Vault using their existing corporate GitHub accounts. Which authentication method should be enabled?

A.LDAP

B.Okta

C.Username & password (userpass)

D.GitHub

AnswerD

GitHub auth uses GitHub personal access tokens.

Why this answer

The GitHub authentication method in Vault allows users to authenticate using their existing corporate GitHub accounts by mapping GitHub teams to Vault policies. This is the only option that directly integrates with GitHub's OAuth-based authentication flow, enabling single sign-on without requiring additional directory services or identity providers.

Exam trap

HashiCorp often tests the distinction between 'direct integration' (GitHub auth method) and 'federation via an identity provider' (Okta, LDAP), leading candidates to confuse Okta or LDAP as valid options for GitHub authentication.

How to eliminate wrong answers

Option A is wrong because LDAP is used for authenticating against an LDAP directory (e.g., Active Directory or OpenLDAP), not against GitHub accounts. Option B is wrong because Okta is a third-party identity provider that integrates via OIDC/SAML, not a direct GitHub authentication method. Option C is wrong because username & password (userpass) is a built-in Vault auth method for local users, not for federating with external GitHub accounts.

Full explanation →

393

Multi-Selecthard

Which TWO statements about Vault replication are correct?

Select 2 answers

A.A DR secondary can be promoted to primary only if the primary is offline.

B.DR replication replicates all data including tokens and leases.

C.Performance replication allows read requests to be served locally on the secondary cluster.

D.Performance replication replicates all secrets and auth methods.

E.Both performance and DR replication require a shared storage backend.

AnswersB, C

DR replication is a full data copy.

Why this answer

Option B is correct because Vault DR replication is designed to replicate all data, including tokens, leases, and secrets, to a secondary cluster for disaster recovery purposes. This ensures that the secondary cluster can take over with a complete state if the primary fails, as it mirrors the entire Vault data store.

Exam trap

HashiCorp often tests the misconception that performance replication replicates all data (including auth methods and mount configurations), when in fact it only replicates the data within the mount paths and does not replicate auth method configurations or system data like tokens.

Full explanation →

394

MCQhard

An organization uses Vault's token auth method to issue tokens for long-running services. They want to ensure that tokens are automatically revoked after 30 days, even if the service repeatedly renews them. Which token role configuration achieves this?

A.Set ttl to 720h without setting max_ttl

B.Set explicit_max_ttl to 720h on the token role

C.Set period to 720h without setting max_ttl

D.Set max_ttl to 720h on the token role

AnswerD

max_ttl imposes a hard limit on the token's total lifetime, regardless of renewals.

Why this answer

Option C is correct because setting max_ttl on the token role enforces an absolute lifetime; even if the token is renewed, it cannot exceed max_ttl. Option A is wrong because periodic tokens without max_ttl can be renewed indefinitely. Option B is wrong because setting ttl without max_ttl allows renewal beyond the initial ttl.

Option D is wrong because explicit_max_ttl is not a parameter on the role; it is a role attribute, but the correct property is max_ttl.

Full explanation →

395

MCQeasy

What command is used to view the remaining time on a lease?

A.vault lease lookup <lease_id>

B.vault lease info <lease_id>

C.vault status <lease_id>

D.vault read <lease_id>

AnswerA

This command shows lease information including TTL.

Why this answer

The correct command to view the remaining time on a lease is `vault lease lookup <lease_id>`. This command retrieves the lease metadata, including the issue time, duration (TTL), and remaining time, directly from the Vault server. It is the standard method for inspecting lease details without extending or modifying the lease.

Exam trap

HashiCorp often tests the distinction between `vault lease lookup` and `vault read`, where candidates mistakenly think `vault read` can inspect lease details because it is used to read secrets, but lease metadata requires a dedicated lease API command.

How to eliminate wrong answers

Option B is wrong because `vault lease info` is not a valid Vault CLI command; the correct subcommand is `lookup`. Option C is wrong because `vault status` displays the seal status and HA state of the Vault server, not lease information. Option D is wrong because `vault read` is used to read secrets or data from a path, not to inspect lease metadata; it would attempt to read the path as a secret, which would fail or return unrelated data.

Full explanation →

396

MCQmedium

A company wants to securely store database credentials for a dynamic application that spins up new instances frequently. They need to ensure each instance gets a unique, time-limited username/password pair with minimal operational overhead. Which approach should they use?

A.Enable the database secrets engine and configure role-based dynamic credential generation

B.Use the transit secrets engine to encrypt the static credentials and distribute them

C.Use the PKI secrets engine to issue certificates for database authentication

D.Store the credentials in KV v2 and have each instance read them

AnswerA

The database secrets engine creates unique, time-limited credentials on the fly, matching the requirement.

Why this answer

The database secrets engine in HashiCorp Vault is designed specifically for dynamic credential generation, creating unique, time-limited username/password pairs on-demand for each instance. This approach minimizes operational overhead by automating credential lifecycle management, including automatic revocation after the TTL expires, which aligns perfectly with the requirement for frequently spinning up instances.

Exam trap

HashiCorp often tests the distinction between secrets engines that generate dynamic credentials (database secrets engine) versus those that manage static secrets (KV v2) or provide encryption (transit) or certificates (PKI), leading candidates to confuse the purpose of each engine.

How to eliminate wrong answers

Option B is wrong because the transit secrets engine is used for encryption/decryption of data in transit, not for generating dynamic credentials; encrypting static credentials still requires manual rotation and does not provide unique, time-limited pairs per instance. Option C is wrong because the PKI secrets engine issues X.509 certificates for TLS/mTLS authentication, not username/password pairs, and database authentication typically does not use certificates unless the database supports certificate-based auth (e.g., MySQL with SSL), which is not the stated requirement. Option D is wrong because storing credentials in KV v2 (Key-Value version 2) provides static secrets that must be manually rotated and shared across instances, failing to deliver unique, time-limited credentials and increasing operational overhead for credential management.

Full explanation →

397

MCQmedium

A Vault cluster uses Integrated Storage with 5 nodes. After a network split, the cluster loses quorum and becomes sealed. The network is restored, but the cluster does not automatically recover. What should the administrator do to recover the cluster?

A.Use `vault operator raft snapshot restore` on each node to restore from a backup.

B.Restart all nodes simultaneously to force a new leader election.

C.Manually unseal each node using the unseal keys.

D.Identify the node with the most recent data and use `vault operator raft recover` to create a new cluster from that node.

AnswerD

Raft recover creates a new cluster from a single node.

Why this answer

When a Vault cluster with Integrated Storage loses quorum due to a network split, the cluster seals itself to prevent split-brain. After the network is restored, the cluster does not automatically recover because the Raft consensus algorithm requires a majority of nodes to form a quorum. Option D is correct because `vault operator raft recover` allows an administrator to force a single node (typically the one with the most recent data) to form a new cluster, discarding the other nodes' data and re-establishing quorum.

Exam trap

HashiCorp often tests the misconception that unsealing or restarting nodes alone can recover a Raft-based cluster after quorum loss, when in fact the Raft layer must be explicitly recovered using a command like `vault operator raft recover`.

How to eliminate wrong answers

Option A is wrong because `vault operator raft snapshot restore` is used to restore data from a previously taken snapshot, not to recover from a quorum loss; it requires a functioning cluster or a single-node recovery first. Option B is wrong because restarting all nodes simultaneously does not resolve the underlying Raft quorum issue; the nodes will still attempt to form a cluster with the same stale peer set and will remain sealed if quorum cannot be achieved. Option C is wrong because manual unsealing only decrypts the Vault's seal, but the Raft layer still requires quorum to operate; unsealing does not repair the broken consensus.

Full explanation →

398

MCQmedium

An organization uses the Transit secrets engine to encrypt sensitive files. They want to rotate the encryption key regularly without re-encrypting all existing files. Which feature allows this?

A.Key versioning

B.Key derivation

C.Key ttl

D.Convergent encryption

AnswerA

Versioning allows new data encrypted with new key, old data decryptable with old key.

Why this answer

The Transit secrets engine in Vault supports key versioning, which allows you to rotate the encryption key by creating a new version while keeping older versions available for decryption of existing ciphertext. This means you can regularly rotate the key without needing to re-encrypt all previously encrypted files, as each ciphertext is tagged with the key version used to encrypt it.

Exam trap

HashiCorp often tests the distinction between key rotation (which preserves access to old ciphertext via versioning) and key expiration (which invalidates the key entirely), leading candidates to confuse 'key ttl' with a rotation mechanism.

How to eliminate wrong answers

Option B (Key derivation) is wrong because key derivation is a process that generates a unique encryption key per input plaintext using a key derivation function (KDF), but it does not provide a mechanism to rotate the master key without re-encrypting existing data. Option C (Key ttl) is wrong because key TTL (time-to-live) sets an expiration time for a key, but it does not enable rotation without re-encryption; once the TTL expires, the key becomes unusable, forcing re-encryption if the data must remain accessible. Option D (Convergent encryption) is wrong because convergent encryption derives the encryption key from the hash of the plaintext, making it deterministic and unsuitable for key rotation—changing the key would break the ability to decrypt existing ciphertext.

Full explanation →

399

MCQhard

Refer to the exhibit. An application token has the above policy. Which operation will fail?

A.Rotating the key mykey

B.Decrypting data using the key mykey

C.Encrypting data using the key mykey

D.Deleting the key mykey

E.Listing keys in the transit engine

AnswerE

Listing requires list capability on `transit/keys/`, which is not granted.

Why this answer

The policy shown in the exhibit grants 'create', 'update', 'delete', and 'deny' capabilities on the transit engine, but it does not include a 'list' capability. In Vault's transit secrets engine, listing keys requires the 'list' capability on the engine path. Without it, the operation will fail due to insufficient permissions, even though other key management operations are allowed.

Exam trap

HashiCorp often tests the distinction between key-level operations (encrypt, decrypt, rotate, delete) and path-level operations (list), where candidates mistakenly assume that having 'create' or 'update' on keys implies the ability to list them.

How to eliminate wrong answers

Option A is wrong because rotating a key requires the 'update' capability on the specific key path, which is granted by the policy. Option B is wrong because decrypting data requires the 'update' capability on the key for decryption, which is allowed. Option C is wrong because encrypting data requires the 'create' or 'update' capability on the key, both of which are present.

Option D is wrong because deleting a key requires the 'delete' capability, which is explicitly granted in the policy.

Full explanation →

400

MCQmedium

An operator configures a PKI role with allow_any_name=true and max_ttl=72h. A user requests a certificate with common_name='admin.example.com' and ttl=48h. What is the resulting TTL?

A.24h

B.72h

C.48h

D.48h if allowed_domains matches, else error

AnswerC

User's request is within max_ttl and allowed.

Why this answer

Option C is correct because the `max_ttl` setting on the PKI role defines the upper bound for certificate validity, but the user-requested TTL (48h) is within that bound (72h). The `allow_any_name=true` parameter permits any common name without restriction, so the certificate is issued with the requested TTL of 48h. The resulting TTL is the lesser of the requested TTL and the role's `max_ttl`, which in this case is 48h.

Exam trap

HashiCorp often tests the misconception that `max_ttl` overrides a shorter requested TTL, leading candidates to pick the max_ttl value (72h) instead of understanding that the requested TTL is honored if it is within the limit.

How to eliminate wrong answers

Option A is wrong because 24h would only result if the requested TTL were subtracted from max_ttl or if a default TTL were applied, but no such subtraction or default is specified; the role's max_ttl is an upper limit, not a deduction. Option B is wrong because 72h is the max_ttl, but the user explicitly requested a shorter TTL (48h), and the PKI role honors the requested TTL as long as it does not exceed max_ttl. Option D is wrong because `allow_any_name=true` bypasses the `allowed_domains` check entirely, so no matching is required; the certificate is issued regardless of domain, and the TTL remains 48h.

Full explanation →

401

MCQeasy

What is the purpose of the `storage` stanza in a Vault server configuration file?

A.Defines where Vault stores encrypted data.

B.Defines the encryption algorithm for secrets.

C.Defines the seal mechanism.

D.Defines the listener address.

AnswerA

The storage stanza configures the backend used to persist Vault's encrypted data.

Why this answer

The `storage` stanza in a Vault server configuration file defines the backend where Vault stores all encrypted data, including secrets, tokens, and metadata. This backend can be a file system, Consul, Raft, or other supported storage backends, and it is the persistent layer that holds the encrypted data after it has been processed by the seal mechanism. Without a properly configured `storage` stanza, Vault cannot persist any data and will fail to start.

Exam trap

HashiCorp often tests the distinction between the `storage` stanza (where data is stored) and the `seal` stanza (how data is encrypted), leading candidates to confuse the purpose of these two separate configuration blocks.

How to eliminate wrong answers

Option B is wrong because the encryption algorithm for secrets is not defined in the `storage` stanza; it is determined by the seal mechanism (e.g., using AES-256-GCM by default) and is not configurable in the storage stanza. Option C is wrong because the seal mechanism is defined in the `seal` stanza (e.g., `seal "awskms"` or `seal "shamir"`), not in the `storage` stanza. Option D is wrong because the listener address is defined in the `listener` stanza (e.g., `listener "tcp" { address = "127.0.0.1:8200" }`), which configures the network interface and port for API requests, not the storage backend.

Full explanation →

402

MCQeasy

A user forgets to renew their token before it expires. What happens to the token and its associated leases?

A.The token becomes invalid but can be renewed within a grace period

B.The token is revoked and all its leases are revoked

C.The token is automatically renewed for another period

D.The token remains active but read-only

AnswerB

Expiration leads to revocation of the token and its leases.

Why this answer

Option C is correct because when a token expires, Vault automatically revokes it and all leases created by it. Option A is wrong because the token is not automatically renewed. Option B is wrong because the token is revoked, not just deactivated.

Option D is wrong because the token cannot be used after expiration.

Full explanation →

403

MCQmedium

A Vault administrator runs `vault auth list` and sees the output above. The administrator wants to disable the default token authentication method to improve security. Which command should they run?

A.vault auth disable userpass/

B.vault auth disable token/

C.vault auth disable ldap/

D.vault auth disable approle/

AnswerB

This disables the token auth method at path token/.

Why this answer

The `vault auth list` output shows that the default token authentication method is enabled at the `token/` path. To disable it, the administrator must run `vault auth disable token/`, which removes the token auth method entirely. This improves security by preventing unauthenticated users from using the default token login endpoint, forcing the use of other configured auth methods like LDAP or AppRole.

Exam trap

The trap here is that candidates assume the default token method cannot be disabled or confuse it with other auth methods like userpass or LDAP, leading them to select an option that disables a different auth method instead of the correct `token/` path.

How to eliminate wrong answers

Option A is wrong because `userpass/` is not the default token authentication method; it is a separate username/password auth method that may or may not be enabled, and disabling it does not affect the default token method. Option C is wrong because `ldap/` is an LDAP-based auth method, not the default token method, and disabling it would not remove the token auth endpoint. Option D is wrong because `approle/` is an AppRole auth method used for machine-to-machine authentication, not the default token method, and disabling it leaves the default token method intact.

Full explanation →

404

MCQmedium

A company is running Vault in production with a single active node and two standby nodes using Integrated Storage. The operations team notices that after a network partition, one of the standby nodes becomes unavailable for a few minutes. Upon recovery, the node rejoins the cluster. However, the active node's performance degrades temporarily. What is the most likely cause?

A.The standby node caused a leadership election upon reconnection.

B.The standby node was not using a seal wrapping key, causing re-encryption of all data.

C.The standby node's recovery caused Raft snapshot installation, leading to temporary I/O load on the active node.

D.The standby node forced a full data sync from the active node, consuming resources.

AnswerC

When a node rejoins after a partition, it may need to install a snapshot, causing I/O on the leader.

Why this answer

When a standby node reconnects after a network partition, the Raft consensus protocol may require the node to catch up on missed log entries. If the log gap is large, the active node initiates a snapshot installation, which involves reading and sending a compressed snapshot of the Raft state. This process causes significant I/O and CPU load on the active node, temporarily degrading its performance.

Exam trap

HashiCorp often tests the misconception that a reconnecting standby node triggers a leadership election or a full data sync, when in reality Raft uses snapshot installation to efficiently catch up followers, which can cause temporary performance degradation on the active node.

How to eliminate wrong answers

Option A is wrong because a standby node rejoining does not trigger a leadership election; elections only occur when the active node fails or becomes unreachable. Option B is wrong because seal wrapping keys are used for encrypting the unseal key or root token, not for re-encrypting all data; re-encryption of all data is not a standard behavior upon node reconnection. Option D is wrong because Raft does not force a full data sync from the active node; it uses log replication and snapshot installation to bring the node up to date, which is more efficient than a full sync.

Full explanation →

405

Multi-Selecthard

Which THREE steps are required to configure the database secrets engine for generating dynamic credentials?

Select 3 answers

A.Create a role that maps to the database user and permissions

B.Configure a policy to allow users to read credentials from the role

C.Configure the database connection with connection details and credentials

D.Tune the engine's default TTL

E.Enable the database secrets engine

AnswersA, C, E

A role defines the generated credential attributes (e.g., username template, default TTL).

Why this answer

Option A is correct because creating a role is the step that maps a named role in Vault to a database user template and its associated permissions (e.g., SQL statements for creation and revocation). This role definition is what Vault uses to dynamically generate a unique username and password when credentials are requested, ensuring each lease gets a dedicated database account with the specified privileges.

Exam trap

HashiCorp often tests the distinction between required configuration steps and optional or subsequent steps, so the trap here is that candidates mistakenly include tuning TTL or writing policies as mandatory steps when they are not part of the core three-step configuration sequence (enable, configure connection, create role).

Full explanation →

406

Multi-Selecteasy

Which two of the following are valid lease operations? (Choose two.)

Select 2 answers

A.vault lease renew

B.vault lease create

C.vault lease delete

D.vault lease generate

E.vault lease revoke

AnswersA, E

This is a valid command to renew leases.

Why this answer

Option A is correct because `vault lease renew` is a valid Vault CLI command used to extend the lifetime of a lease before it expires. In HashiCorp Vault, leases are associated with dynamic secrets (e.g., database credentials, AWS IAM keys) and must be periodically renewed to maintain access. The `renew` operation is a core lease lifecycle operation supported by the Vault API and CLI.

Exam trap

HashiCorp often tests the distinction between lifecycle operations that are explicitly supported (renew, revoke) versus operations that are not part of the Vault CLI (create, delete, generate), leading candidates to assume all CRUD-like verbs are valid.

Full explanation →

407

MCQmedium

An operator wants to enable the AWS auth method at the default path. Which curl command is correct?

A.curl -X POST -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws/

B.curl -X PUT -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws

C.curl -X POST -H "X-Vault-Token: s.abc" -d '{"method":"aws"}' https://vault:8200/v1/sys/auth/aws

D.curl -X POST -H "X-Vault-Token: s.abc" -d '{"type":"aws"}' https://vault:8200/v1/sys/auth/aws

AnswerD

Correct; POST to /v1/sys/auth/aws with type 'aws' enables the AWS auth method.

Why this answer

Option D is correct because enabling an auth method at the default path requires a POST request to the `/v1/sys/auth/aws` endpoint with a JSON payload containing the `type` field set to `"aws"`. The POST method is used to create a new mount, and the trailing slash is optional but accepted. The `X-Vault-Token` header provides the necessary authentication token.

Exam trap

HashiCorp often tests the distinction between the correct HTTP method (POST vs PUT) and the exact payload field name (`type` vs `method`), as candidates may confuse the API for enabling auth methods with other Vault operations that use PUT or different field names.

How to eliminate wrong answers

Option A is wrong because it includes a trailing slash in the URL (`/v1/sys/auth/aws/`), which is not the standard path for enabling auth methods; Vault API expects the path without a trailing slash for this operation. Option B is wrong because it uses the PUT method instead of POST; while Vault's API sometimes accepts PUT for updates, enabling a new auth method requires POST as per the official documentation. Option C is wrong because the payload uses `{"method":"aws"}` instead of `{"type":"aws"}`; the correct field name is `type`, not `method`, and using `method` would cause Vault to ignore the field or return an error.

Full explanation →

408

MCQhard

An administrator wants to ensure that a token created by a user cannot be used after 24 hours, even if the user tries to renew it. What should the administrator do?

A.Use a periodic token with a period of 24h

B.Create an orphan token with a TTL of 24h

C.Use a batch token

D.Set explicit max TTL on the token to 24h

AnswerD

Explicit max TTL cannot be exceeded by renewal.

Why this answer

Option D is correct because setting an explicit max TTL on the token to 24h ensures that the token's lifetime cannot be extended beyond 24 hours, even if the user attempts to renew it. In Vault, the `explicit_max_ttl` parameter overrides any renewal requests, enforcing a hard upper limit on the token's validity. This directly addresses the requirement that the token cannot be used after 24 hours, regardless of renewal attempts.

Exam trap

The trap here is that candidates confuse TTL (time-to-live, which can be extended via renewal) with explicit max TTL (which sets a hard, non-renewable expiration), leading them to choose periodic or orphan tokens that allow indefinite renewal.

How to eliminate wrong answers

Option A is wrong because a periodic token with a period of 24h can be renewed indefinitely as long as the renewal occurs within the period, allowing the token to exist beyond 24 hours. Option B is wrong because an orphan token with a TTL of 24h can still be renewed before expiration, extending its lifetime beyond the initial 24-hour window. Option C is wrong because a batch token is designed for high-throughput, short-lived operations and does not inherently enforce a hard maximum lifetime; it can be renewed or have its TTL extended unless explicitly constrained.

Full explanation →

409

MCQmedium

Refer to the exhibit. A Vault administrator configures a three-node cluster with the above configuration on all nodes (with appropriate node_id). After starting all nodes, the administrator unseals node2 and node3. Node1 remains sealed. What will be the cluster state?

A.Nodes 2 and 3 will each try to become leader, causing a split-brain.

B.Node1 will automatically join the cluster once unsealed.

C.Nodes 2 and 3 will form a quorum and elect a leader; Node1 will be a standby when unsealed.

D.The cluster will be unavailable because Node1 is sealed.

AnswerC

Two nodes constitute a majority and can operate normally.

Why this answer

In a Vault cluster, a quorum requires a majority of nodes to be unsealed and available. With three nodes, the quorum size is 2. Nodes 2 and 3, both unsealed, form a quorum and elect a leader among themselves.

Node1, though sealed, is still a cluster member; once unsealed, it will join as a standby node, not as a leader, because the leader election has already occurred.

Exam trap

HashiCorp often tests the misconception that a sealed node makes the entire cluster unavailable, but the key is that Vault only requires a quorum of unsealed nodes for cluster operation, not all nodes.

How to eliminate wrong answers

Option A is wrong because Vault uses Raft consensus, which prevents split-brain by requiring a majority (quorum) for leader election; two nodes cannot both become leader as they will coordinate via Raft. Option B is wrong because Node1 will not automatically join the cluster once unsealed; it will join as a standby node only after being unsealed, but it does not automatically unseal itself. Option D is wrong because the cluster remains available as long as a quorum of nodes (2 out of 3) is unsealed; Node1 being sealed does not make the cluster unavailable.

Full explanation →

410

MCQhard

An organization needs to store secrets with versioning support, allowing rollback to previous secret values. Which KV secrets engine version should be enabled?

A.KV v3

B.KV v1

C.KV v2

D.Transit secrets engine

AnswerC

KV v2 stores metadata and multiple versions, allowing rollback and undelete.

Why this answer

KV v2 is the correct choice because it provides versioning support for secrets, allowing users to retrieve and rollback to previous secret values. KV v1 stores secrets without versioning, and the Transit secrets engine is designed for encryption/decryption operations, not secret storage with versioning.

Exam trap

HashiCorp often tests the misconception that KV v3 exists or that the Transit secrets engine can handle versioned secret storage, leading candidates to choose those incorrect options.

How to eliminate wrong answers

Option A is wrong because KV v3 does not exist in Vault; the KV secrets engine has only two versions (v1 and v2). Option B is wrong because KV v1 stores secrets without versioning, so it cannot support rollback to previous values. Option D is wrong because the Transit secrets engine is used for encryption as a service, not for storing secrets with versioning capabilities.

Full explanation →

411

Multi-Selecteasy

Which TWO are core components of Vault's architecture?

Select 2 answers

A.Seal

B.Storage backend

C.Audit device

D.Auth method

E.Replication

AnswersA, B

Core component that protects the encryption key.

Why this answer

The Seal is a core component of Vault's architecture because it provides the mechanism to encrypt and decrypt the master key, which is used to protect all other keys and data within Vault. When Vault is sealed, the master key is encrypted and cannot be accessed, rendering the Vault unable to decrypt its data. Unsealing requires a threshold of unseal keys to reconstruct the master key, ensuring that no single individual can access the Vault's secrets.

Exam trap

HashiCorp often tests the distinction between core architectural components (Seal and Storage Backend) and optional or pluggable features (audit devices, auth methods, replication), leading candidates to mistakenly select features that are critical for operation but not part of the minimal core architecture.

Full explanation →

412

MCQhard

A Vault administrator is designing a policy for a CI/CD pipeline that must be able to read dynamic database credentials from "database/creds/my-role" and also write to "secret/data/ci-cd" for storing build artifacts. The policy should follow the principle of least privilege. Which policy statements should be used?

A.path "database/creds/my-role" { capabilities = ["read"] }; path "secret/data/ci-cd" { capabilities = ["create", "update", "delete"] }

B.path "database/creds/my-role" { capabilities = ["read"] }; path "secret/data/ci-cd" { capabilities = ["create", "update"] }

C.path "database/creds/my-role" { capabilities = ["read"] }; path "secret/data/ci-cd/*" { capabilities = ["create", "update"] }

D.path "database/creds/my-role" { capabilities = ["read"] }; path "secret/data/ci-cd" { capabilities = ["write"] }

AnswerB

This grants read to credentials and create/update to the specific secret path, following least privilege.

Why this answer

Option A is correct. For database creds, read is sufficient. For KV v2, to write data, you need both create and update capabilities.

Option B uses 'write' which is not a standard capability. Option C uses a glob that may be too broad. Option D adds delete which is not needed.

Full explanation →

413

Multi-Selectmedium

Which TWO of the following are differences between using Vault's token auth method and other auth methods? (Choose two.)

Select 2 answers

A.Token auth is always enabled and cannot be disabled

B.Token auth does not support policies

C.Token auth is the only method that can create periodic tokens

D.Token auth cannot be used to create a root token

E.Token auth is typically used for Vault's own internal token management, not for end-user authentication

AnswersA, E

Token auth is the default and can't be disabled.

Why this answer

Token auth is always enabled and cannot be disabled because it is the core authentication mechanism that Vault uses internally to represent all authenticated sessions. Every other auth method ultimately produces a Vault token, making the token auth method the foundational layer that cannot be removed or turned off without breaking Vault's entire authentication model.

Exam trap

HashiCorp often tests the misconception that token auth is just another optional auth method like LDAP or AppRole, when in reality it is the mandatory, always-enabled foundation that all other auth methods depend on.

Full explanation →

414

Multi-Selecteasy

Which TWO of the following are valid methods to authenticate to Vault using the CLI without using a token? (Choose two.)

Select 2 answers

A.vault login -method=userpass username=joe password=pass

B.vault login -method=ldap username=joe password=pass

C.vault auth -method=ldap username=joe password=pass

D.vault write auth/userpass/login/joe password=pass

E.vault token create -policy=default

AnswersA, B

This authenticates and sets the token for the CLI session.

Why this answer

Option A is correct because the `vault login -method=userpass` command authenticates to Vault using the userpass auth method via the CLI, which does not require a pre-existing token. Instead, it directly exchanges the provided username and password for a client token from the Vault server. This is a standard tokenless authentication flow for the userpass method.

Exam trap

HashiCorp often tests the distinction between the `vault login` command (which performs tokenless authentication) and the `vault write` command (which requires an existing token), leading candidates to mistakenly choose D as a valid tokenless method because it appears to send credentials directly.

Full explanation →

415

MCQhard

Refer to the exhibit. An application needs to encrypt data using the transit engine with key "app-key". It currently has this policy. Which statement is true?

A.The policy allows both encryption and decryption, but the capabilities should be "read" and "write" instead.

B.The policy allows both encryption and decryption, which is correct for the transit engine.

C.The policy allows encryption but not decryption, which is sufficient.

D.The policy incorrectly uses "create" and "update" for transit operations; it should use "read" and "write".

AnswerB

The policy correctly provides the necessary capabilities for both operations.

Why this answer

Option C is correct. In Vault Transit, encryption and decryption operations require 'create' or 'update' capabilities on the respective endpoints. The policy provides both, allowing the application to encrypt and decrypt as needed.

Full explanation →

416

MCQmedium

Refer to the exhibit. A developer ran the command and received the JSON output. Which command would retrieve only the value of 'api_key' in plain text?

A.vault read -field=api_key secret/team

B.vault read -field=api_key secret/data/team

C.vault read -field=data.api_key secret/data/team

D.vault read secret/data/team

AnswerC

Correct; -field=data.api_key extracts the nested value.

Why this answer

Option C is correct because the `vault read` command with `-field=data.api_key` uses dot notation to navigate the nested JSON structure returned by the KV v2 secrets engine at `secret/data/team`. The KV v2 engine wraps the actual data under a `data` key, so to extract the `api_key` value directly, you must specify the full path `data.api_key`. Without this, the command would either fail or return the entire JSON object.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 engines, and the trap here is that candidates forget the `data.` prefix required for KV v2, leading them to choose Option B which looks correct but fails due to the nested structure.

How to eliminate wrong answers

Option A is wrong because `secret/team` is the KV v1 path, but the exhibit shows a KV v2 engine (indicated by the `data` key in the JSON output), and using the v1 path would return a different structure or an error. Option B is wrong because `-field=api_key` without the `data.` prefix attempts to access `api_key` at the top level of the JSON, but in KV v2 the actual key is nested under `data`, so this would return nothing or an error. Option D is wrong because it omits the `-field` flag entirely, so it would print the full JSON output including metadata, not just the plain-text value of `api_key`.

Full explanation →

417

Matchingmedium

Match each Vault policy capability to its permission.

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

Concepts

Matches

Allow creating data at a path

Allow reading data at a path

Allow modifying existing data

Allow deleting data

Allow listing keys

Why these pairings

These are the standard policy capabilities in Vault.

Full explanation →

418

Multi-Selecthard

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

Select 3 answers

A.The Secret ID contains the token policies

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

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

D.The Role ID is analogous to a username

E.The Secret ID can only be used once

AnswersB, C, D

Response wrapping secures the Secret ID.

Why this answer

Option B is correct because Vault supports wrapping the Secret ID in a single-use, time-limited JWT-based response-wrapping token. This allows the Secret ID to be securely delivered to the target application without exposing it in transit, as the wrapping token can be unwrapped only by the intended recipient using a separate unwrap operation.

Exam trap

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

Full explanation →

419

Multi-Selectmedium

Which three of the following are valid capabilities in a Vault policy path statement? (Select three.)

Select 3 answers

A.list

B.encrypt

C.deny

D.patch

E.sudo

AnswersA, C, E

list is a valid capability for listing keys or items at a path.

Why this answer

The valid capabilities are sudo, list, and deny. Patch and encrypt are not standard Vault policy capabilities.

Full explanation →

420

Multi-Selectmedium

Which THREE of the following are capabilities of the PKI secrets engine? (Choose three.)

Select 3 answers

A.Automatically rotate certificates

B.Generate one-time pads

C.Revoke certificates

D.Generate self-signed root certificates

E.Create intermediate CA certificates

AnswersC, D, E

Revocation is a standard PKI operation.

Why this answer

Option C is correct because the PKI secrets engine in Vault supports certificate revocation via Certificate Revocation Lists (CRLs) or by directly marking a certificate as revoked in its storage backend. This is a core PKI lifecycle management capability, allowing operators to invalidate compromised or expired certificates immediately.

Exam trap

HashiCorp often tests the distinction between 'automatic rotation' and 'manual revocation' in PKI secrets engines, leading candidates to incorrectly assume that rotation is a built-in capability when it actually requires external orchestration.

Full explanation →

421

Multi-Selectmedium

Which THREE are benefits of using Vault response wrapping?

Select 3 answers

A.Reduces the risk of secret exposure in transit

B.Supports unlimited unwraps

C.Ensures the secret is used only once

D.Increases the TTL of the secret

E.Enables delegation of access without sharing the actual token

AnswersA, C, E

The wrapped token contains the secret and is unwrapped only by the intended recipient.

Why this answer

Vault response wrapping is a feature that encapsulates a secret or token in a single-use, time-limited wrapping token. Option A is correct because the secret is never transmitted in plaintext over the wire; instead, the wrapping token is sent, and the actual secret is retrieved only by unwrapping it, which reduces the risk of secret exposure during transit. Option C is correct because the wrapping token is designed for a single unwrap operation—once unwrapped, the token is destroyed, ensuring the secret is used only once.

Option E is correct because response wrapping allows a user to delegate access to a secret by sharing the wrapping token instead of the actual token, enabling secure delegation without exposing the underlying credential.

Exam trap

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

Full explanation →

422

MCQmedium

A DevOps team uses Vault to generate temporary database credentials. They notice that some applications are failing because their database credentials expire unexpectedly before the expected TTL. The Vault admin configured the database role with a default TTL of 1h and max TTL of 24h. What is the most likely cause?

A.The database role's max TTL is being enforced, but the default TTL is shorter.

B.The Vault server's clock is skewed, causing early expiry.

C.The application is renewing the lease too frequently, causing Vault to reset the TTL.

D.The application is not renewing the lease, and the lease TTL is counted from the issue time.

AnswerD

Leases expire based on their original TTL if not renewed before expiry.

Why this answer

Leases expire based on their original TTL from issue time unless renewed. The default TTL is 1h, so credentials expire after 1h if not renewed, causing failures if applications assume longer validity. Option B correctly identifies that the applications are likely not renewing the lease.

Option A is wrong because frequent renewal extends the lease. Option C is unlikely without evidence. Option D is incorrect because max TTL is higher than default, so it does not cause early expiry.

Full explanation →

423

MCQmedium

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

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

B.Use the KV engine to store encryption keys

C.Create a separate transit key per application

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

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

AnswerC

Isolates encryption domains; follows least privilege principle.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Full explanation →

424

MCQhard

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

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

B.Use 'vault unwrap' on the remote service

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

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

AnswerC

This command generates a wrapped token with a 5-minute TTL, which is then unwrapped by the recipient.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

425

MCQeasy

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

A.KV secrets engine

B.PKI secrets engine

C.Database secrets engine

D.Transit secrets engine

AnswerD

Transit provides encryption as a service and handles key management without storing data.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

426

MCQmedium

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

A.Enable token renewal to keep it alive

B.Use a periodic token and revoke it manually

C.Set a TTL on the token

D.Use a batch token to limit its lifetime

AnswerC

TTL ensures the token expires automatically.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

427

MCQmedium

A DevOps engineer needs to write a new secret to the KV v2 engine at path 'secret/data/team' with key 'api_key' and value 'abc123'. Which Vault CLI command achieves this?

A.vault kv put secret/data/team api_key=abc123

B.vault kv put secret/team api_key=abc123

C.vault write secret/data/team api_key=abc123

D.vault write secret/team api_key=abc123

AnswerB

Correct command; 'vault kv put' writes to KV v2 engine at the specified path (mount path is 'secret/', the secret is 'team').

Why this answer

Option B is correct because the KV v2 engine automatically prefixes the path with 'data/' when using the 'vault kv put' command. The correct path for writing a secret to the KV v2 engine is 'secret/data/team', but the CLI command 'vault kv put secret/team api_key=abc123' handles this internally by appending '/data/' to the path. This is a key difference from the 'vault write' command, which requires the full path including 'data/'.

Exam trap

HashiCorp often tests the distinction between 'vault kv put' and 'vault write' for KV v2, where candidates mistakenly use the full API path with 'vault kv put' or the wrong command for the engine version.

How to eliminate wrong answers

Option A is wrong because it uses 'vault kv put' with the full path 'secret/data/team', which would result in a double 'data/' prefix (i.e., 'secret/data/data/team'), causing a 404 error. Option C is wrong because 'vault write' with path 'secret/data/team' is the correct raw API path for KV v2, but the question asks for the CLI command that 'achieves' this, and 'vault kv put' is the preferred and simpler CLI method; however, this option is technically correct for writing but not the best practice CLI command, and the exam expects the 'vault kv put' syntax. Option D is wrong because 'vault write secret/team' would target the KV v1 engine (or the metadata path in v2), not the data path, and would fail to write the secret correctly under KV v2.

Full explanation →

428

MCQhard

A company uses Vault Enterprise with Performance Replication across two data centers. The primary data center is in us-east-1 and the secondary is in eu-west-1. They have an application that writes secrets to the primary cluster, and those secrets are replicated to the secondary cluster for read access. Recently, they noticed that some secrets written to the primary are not appearing on the secondary even after several minutes. The latency between data centers is typically 50ms. The administrator checks the replication status and sees a 'merkle sync' in progress. What is the most likely reason for the delay?

A.The replication token has expired.

B.The primary cluster is using a different seal type than the secondary.

C.The secondary cluster is experiencing write load that is causing replication to fall behind.

D.Performance Replication only replicates data once per hour by default.

AnswerC

Heavy load can cause replication lag.

Why this answer

Performance Replication in Vault Enterprise uses asynchronous streaming of write-ahead log (WAL) entries to replicate data to secondary clusters. When a 'merkle sync' is in progress, it indicates that the secondary cluster has fallen behind and is performing a full tree comparison to reconcile differences. The most likely cause is that the secondary cluster is under write load, which can cause it to process replication WAL streams more slowly, leading to a backlog and triggering a merkle sync to catch up.

Exam trap

The trap here is that candidates may assume replication is always instant or that a merkle sync indicates a permanent failure, when in fact it is a normal recovery mechanism triggered by transient load or latency issues.

How to eliminate wrong answers

Option A is wrong because a replication token expiration would cause replication to stop entirely with an authentication error, not a merkle sync in progress. Option B is wrong because seal types (e.g., Shamir, Auto Unseal) do not affect replication mechanics; replication operates independently of the seal configuration. Option D is wrong because Performance Replication is near real-time, streaming WAL entries continuously; there is no default one-hour interval.

Full explanation →

429

MCQhard

An organization uses a PostgreSQL database. They configure a database secrets engine with a role that grants read-only access. However, after revoking the lease, the database user still exists. What is the most likely cause?

A.The database secrets engine does not support revocation

B.The role's default_ttl is set too high

C.The lease duration is too long

D.The revocation statement is not configured in the database connection

AnswerD

If no revocation statement is set, Vault cannot delete the user on lease revocation.

Why this answer

Option D is correct because when a database secrets engine role is configured in Vault, the revocation statement (e.g., `ALTER USER "{{name}}" NOLOGIN;` or `DROP USER IF EXISTS "{{name}}";`) must be explicitly defined in the database connection's `rotation_statements` or `revocation_statements`. If no revocation statement is set, Vault will successfully create and manage the database user but will not execute any SQL to disable or drop that user when the lease is revoked, leaving the user active in PostgreSQL.

Exam trap

The trap here is that candidates often assume Vault automatically removes database users on lease revocation, but in reality, the revocation behavior must be explicitly defined in the connection configuration; otherwise, no cleanup occurs.

How to eliminate wrong answers

Option A is wrong because the database secrets engine does support revocation; it can execute custom SQL statements to disable or drop users when leases expire or are revoked. Option B is wrong because the `default_ttl` controls how long a lease is valid before it must be renewed, not whether the user is removed after revocation; a high TTL would delay expiration but not prevent revocation. Option C is wrong because the lease duration (TTL) determines the lifetime of the credential, not the revocation behavior; a long lease would simply keep the user active longer, but revocation would still occur if properly configured.

Full explanation →

430

MCQeasy

A company uses Vault's KV v2 secrets engine. A policy is needed to allow a service to only update existing secrets at path "secret/data/service/config", but not create new ones. Which capabilities should be included?

A.["read", "update"]

B.["write"]

C.["update"]

D.["create", "update"]

AnswerC

Update allows modifying existing secrets without creating new ones.

Why this answer

Option C is correct. The 'update' capability alone allows modifying existing secrets without creating new ones. 'create' would allow new secrets, and 'read' would add unnecessary read access. 'write' is not a valid capability.

Full explanation →

431

MCQmedium

An organization requires that all Vault secrets be encrypted with a key derived from a hardware security module (HSM) and that the cluster can be unsealed automatically. Which seal type should they use?

A.PKCS11 seal

B.Transit seal

C.Shamir seal

D.Cloud KMS seal

AnswerA

PKCS11 seal supports HSM integration for automatic unsealing and key management.

Why this answer

The PKCS11 seal type is correct because it enables Vault to derive the unseal key from a key stored in a hardware security module (HSM) via the PKCS#11 interface. This allows automatic unsealing of the cluster by leveraging the HSM's key, meeting both the encryption and auto-unseal requirements.

Exam trap

HashiCorp often tests the distinction between 'auto-unseal' and 'HSM-backed key derivation'; the trap here is that candidates may confuse Cloud KMS seal (which also provides auto-unseal) with HSM-based sealing, but Cloud KMS does not use a dedicated hardware security module for key derivation.

How to eliminate wrong answers

Option B (Transit seal) is wrong because the Transit seal uses Vault's Transit secrets engine to encrypt the unseal key, but it does not derive the key from an HSM; it relies on another Vault cluster or a separate encryption service, not a hardware security module. Option C (Shamir seal) is wrong because it uses Shamir's secret sharing to split the unseal key into shards, requiring manual intervention from multiple operators to unseal, and does not involve an HSM or automatic unsealing. Option D (Cloud KMS seal) is wrong because while it provides auto-unseal using a cloud provider's key management service (e.g., AWS KMS, Azure Key Vault, GCP Cloud KMS), it does not derive the key from a hardware security module; the key is managed by the cloud provider's software-based KMS, not a dedicated HSM.

Full explanation →

432

MCQmedium

A security team needs to audit all interactions with Vault, including requests that are denied due to policy violations. They want to ensure that even if the audit device is full, Vault does not halt operations. Which audit device configuration should they recommend?

A.Socket audit device with a remote log aggregator

B.File audit device with blocking=true and a separate backup file

C.File audit device with blocking=false and fallback path configured

D.Syslog audit device with local syslog server

AnswerC

Non-blocking with fallback ensures audits continue even if primary fails, without halting Vault.

Why this answer

The file audit device with `blocking=false` ensures that Vault does not block requests when the audit log cannot be written, preventing denial of service. The fallback path provides a secondary location to continue logging if the primary path fails, maintaining audit coverage without halting operations.

Exam trap

The trap here is that candidates assume any remote or syslog-based audit device inherently avoids blocking, but Vault's default audit device behavior is blocking unless explicitly configured otherwise, and only the file audit device supports a fallback path to prevent data loss without halting operations.

How to eliminate wrong answers

Option A is wrong because a socket audit device sends logs over TCP/UDP, and if the remote log aggregator is unreachable or the socket buffer is full, Vault will block requests by default unless `blocking=false` is explicitly set, which is not mentioned. Option B is wrong because `blocking=true` causes Vault to halt operations when the audit device is full, directly contradicting the requirement to not halt operations. Option D is wrong because a syslog audit device with a local syslog server can still block Vault if the syslog server is overwhelmed or the local socket is full, as the default behavior is blocking; additionally, syslog does not natively support a fallback mechanism like the file audit device's fallback path.

Full explanation →

433

MCQmedium

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

A.The token is a service token and has expired

B.The token is a batch token

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

D.The token is an orphan token

AnswerB

Batch tokens are not renewable and return a 'no matching lease' error.

Why this answer

Option C is correct. Batch tokens are not renewable, and attempting to renew them results in a 'no matching lease' error because they do not have an associated lease. Option A is wrong because service tokens are renewable.

Option B is wrong because periodic tokens are renewable. Option D is wrong because the token type is not orphan.

Full explanation →

434

MCQeasy

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

A.SSH secrets engine

B.Cert secrets engine

C.Transit secrets engine

D.PKI secrets engine

AnswerD

PKI engine issues and manages X.509 certificates.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

435

MCQeasy

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

A.LDAP

B.Username & password (userpass)

C.AppRole

D.Okta

AnswerC

Uses Role ID and Secret ID.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

436

MCQhard

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

A.Reinitialize Vault with new unseal keys.

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

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

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

AnswerB

Rotates the barrier encryption key used for data at rest.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

437

MCQmedium

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

A.Token value

B.Creation TTL

C.Token accessor

D.Policy list

AnswerC

Accessor is a non-sensitive reference for token operations.

Why this answer

The token accessor is a non-sensitive identifier that can be used for token lifecycle operations without revealing the token. Option B is wrong because the token value is sensitive and should not be logged. Option C is wrong because the creation TTL is not a unique identifier.

Option D is wrong because the policies are set at creation and do not uniquely identify a token.

Full explanation →

438

MCQhard

A company is migrating from on-premises to cloud and needs to authenticate applications using short-lived credentials. They have a mix of workloads: some on AWS EC2, some on Kubernetes, and some in their own datacenter. Which Vault authentication method provides a unified solution that works across all these environments without requiring a shared secret?

A.AWS IAM authentication

B.JWT/OIDC authentication

C.Kubernetes authentication

D.AppRole authentication

AnswerB

Supports any workload that can present a valid JWT from a trusted OIDC provider, works across cloud and on-prem.

Why this answer

JWT/OIDC authentication is the correct choice because it provides a unified, standards-based method for verifying identity across AWS EC2, Kubernetes, and on-premises environments without requiring a shared secret. By leveraging OpenID Connect (OIDC) identity tokens issued by trusted providers (e.g., AWS IAM Identity Center, Kubernetes service account token, or an on-premises IdP), Vault can validate the token's signature and claims to authenticate workloads. This eliminates the need for pre-shared secrets or per-environment-specific integrations, making it ideal for heterogeneous deployments.

Exam trap

HashiCorp often tests the misconception that Kubernetes authentication is the only way to authenticate Kubernetes workloads, but the question asks for a unified solution across multiple environments, which JWT/OIDC provides by being environment-agnostic.

How to eliminate wrong answers

Option A is wrong because AWS IAM authentication is specific to AWS environments and cannot authenticate workloads running on Kubernetes or on-premises without additional bridging, and it relies on AWS IAM roles and signed requests, not a unified token standard. Option C is wrong because Kubernetes authentication is limited to Kubernetes clusters and requires a Kubernetes service account token or a kubeconfig, making it unsuitable for EC2 or on-premises workloads. Option D is wrong because AppRole authentication requires a pre-shared secret (RoleID and SecretID) to be distributed to each workload, which contradicts the requirement for short-lived credentials without a shared secret and adds operational overhead for secret distribution.

Full explanation →

439

Multi-Selecthard

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

Select 3 answers

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

B.The HTTP method used is GET

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

D.The HTTP method used is POST

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

AnswersA, B, E

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

Why this answer

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

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

Exam trap

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

Full explanation →

440

MCQhard

A Vault cluster has a performance secondary cluster replicating from a primary. An administrator needs to generate a one-time password (OTP) for an SSH target. They are on the secondary cluster. They run `vault write ssh/otp/otp_role ip=10.0.0.1 username=admin`. What is the expected behavior?

A.The request fails because the CLI command syntax is wrong

B.The request fails because secondary clusters cannot write any data

C.The request succeeds because the SSH secret engine is a local mount that exists on the secondary

D.The request fails because the SSH secret engine must be replicated to the secondary

AnswerC

SSH secret engine is typically local, so it works on the secondary.

Why this answer

Option C is correct because the SSH secret engine is a local mount, meaning it is not replicated from the primary to the performance secondary cluster. Local mounts exist independently on each cluster, so the secondary can write data to its own local SSH engine. The `vault write ssh/otp/otp_role` command is syntactically correct and will succeed on the secondary as long as the role and engine are configured locally.

Exam trap

HashiCorp often tests the misconception that performance secondary clusters are entirely read-only, but the trap here is that local mounts (like the SSH secret engine) are writable on the secondary, while only replicated mounts are read-only.

How to eliminate wrong answers

Option A is wrong because the CLI command syntax is correct; `vault write ssh/otp/otp_role ip=10.0.0.1 username=admin` is the proper format for generating an OTP for an SSH target. Option B is wrong because performance secondary clusters can write data to local mounts (like the SSH secret engine) and to certain replicated paths that allow writes (e.g., token creation), though they cannot write to replicated mounts from the primary. Option D is wrong because the SSH secret engine is a local mount by default and does not need to be replicated; in fact, replicating it would defeat the purpose of local SSH OTP generation.

Full explanation →

441

MCQmedium

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

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

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

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

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

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

AnswerC

Correct API call; plaintext must be base64-encoded.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Full explanation →

442

MCQmedium

A Vault server is configured with the above snippet. After starting, the server remains in a sealed state. Which command should the operator run to complete the initial unseal?

A.vault operator unseal -auto

B.vault operator unseal <key>

C.vault operator generate-root

D.vault operator init

AnswerD

Initialization generates the root token and sets up the seal; unseal happens automatically via GCP KMS.

Why this answer

Option D is correct because the snippet shows a Vault configuration but no `seal` or `unseal` keys have been generated yet. The `vault operator init` command generates the initial root token and unseal keys, which are required before any unseal operation can be performed. Without initialization, the server has no keys to unseal with, so it remains in a sealed state.

Exam trap

The trap here is that candidates confuse the initialization step with the unseal step, assuming a Vault server can be unsealed without first generating the unseal keys via `vault operator init`.

How to eliminate wrong answers

Option A is wrong because `vault operator unseal -auto` is not a valid command; Vault does not support an `-auto` flag for unsealing, and unsealing requires explicit key shares. Option B is wrong because `vault operator unseal <key>` assumes unseal keys already exist, but the server has not been initialized yet, so no keys are available to provide. Option C is wrong because `vault operator generate-root` is used to generate a new root token after initialization, not to unseal the server; it requires an already unsealed Vault to function.

Full explanation →

443

MCQeasy

A development team needs tokens that can be renewed automatically as long as they are still in use, up to a maximum lifetime of 72 hours. Which token type and configuration should be used?

A.Periodic token with a TTL of 72h

B.Orphan token with a TTL of 1h

C.Batch token with a TTL of 72h

D.Service token with a TTL of 1h and max TTL of 72h

AnswerD

Service tokens can be renewed until max TTL is reached.

Why this answer

Service tokens with a max TTL of 72h allow renewal up to that limit. Option B is wrong because batch tokens cannot be renewed. Option C is wrong because periodic tokens have no max TTL by default (infinite), not a 72h limit.

Option D is wrong because orphan is not a token type, it's a property.

Full explanation →

444

Drag & Dropmedium

Drag and drop the steps to enable AppRole authentication in Vault 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

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

Full explanation →

445

MCQeasy

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

A.All nodes

B.The active node only

C.Standby nodes

D.The node that receives the request

AnswerB

The active node is the only node that can accept and process write requests.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

446

MCQeasy

A DevOps team needs to create a Vault policy that allows reading secrets from path "secret/data/app" but only for the key "db_password". They want to enforce this using Vault's policy syntax. Which policy statement achieves this?

A.path "secret/data/app" { capabilities = ["read"]; allowed_parameters = {"db_password"=[]} }

B.path "secret/data/app" { capabilities = ["read"] }

C.path "secret/data/app/db_password" { capabilities = ["read"] }

D.path "secret/data/app" { capabilities = ["read"]; required_parameters = ["db_password"] }

AnswerA

This allows reading only the key db_password, with any value.

Why this answer

Option C is correct because it uses allowed_parameters to restrict to the key "db_password". Option A allows reading all keys. Option B uses an incorrect path for key-level restriction.

Option D requires the parameter but does not restrict to only that key.

Full explanation →

447

MCQeasy

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

A.Store secrets encrypted by the Transit engine

B.Store secrets that are isolated per token

C.Store secrets that are replicated across clusters

D.Store secrets with high availability

AnswerB

Correct; each token has its own cubbyhole.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

448

MCQhard

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

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

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

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

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

AnswerA

This creates a token with the specified policy.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

449

Drag & Dropmedium

Drag and drop the steps to configure Vault's audit logging to a file 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 audit, verify, generate logs, check the file, then optionally tune.

Full explanation →

450

Multi-Selecteasy

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

Select 2 answers

A.Reducing the default lease TTL

B.Revoking a lease

C.Creating a new lease

D.Increasing the max lease TTL

E.Renewing a lease

AnswersA, B

Shorter TTLs cause leases to expire faster, reducing count.

Why this answer

Reducing the default lease TTL (time-to-live) shortens the maximum duration for which a lease can be issued without renewal. When existing leases expire sooner, the system automatically removes them from the active lease count, thereby reducing the number of active leases. This directly affects the lease lifecycle by forcing earlier expiration.

Exam trap

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

Full explanation →

HashiCorp Vault Associate VA-003 (VA-003) — Questions 376–450