HashiCorp Vault Associate VA-003 VA-003 Questions 76–150 | Page 2/7

MCQhard

A company uses Vault for secrets management. They want to authenticate using GitHub tokens, but only for users who are members of a specific GitHub team. What must be configured?

A.Vault validates the token's scope.

B.Users must generate a personal access token with repo scope.

C.The GitHub token must include the team scope.

D.Map the GitHub team to a Vault policy in the auth method configuration.

AnswerD

Mapping teams to policies is required to enforce membership.

Why this answer

Vault's GitHub auth method requires mapping GitHub teams to Vault policies. When a user authenticates with a GitHub personal access token, Vault checks the token's associated teams against the configured team-to-policy mappings. Only users belonging to a mapped team receive the corresponding Vault policy, enabling access control based on team membership.

Exam trap

HashiCorp often tests the misconception that Vault validates token scopes or that GitHub tokens have a 'team' scope, when in reality Vault relies on GitHub API team membership lookups and the token must have the appropriate OAuth scope (read:org) to retrieve that information.

How to eliminate wrong answers

Option A is wrong because Vault does not validate the token's scope; it validates the token's associated teams via the GitHub API, not the scope claim. Option B is wrong because while a personal access token is required, the 'repo' scope is not mandatory for authentication; any token with access to the user's team membership information (typically requiring 'read:org' scope) suffices. Option C is wrong because GitHub tokens do not include a 'team' scope; team membership is determined by the token's ability to read organization data, not by a dedicated scope.

Full explanation →

MCQeasy

The CLI command returns a 403 error. What is the most likely cause?

A.The role 'readonly' does not exist

B.The database secrets engine is not mounted at 'database/'

C.The token does not have a policy allowing read on 'database/creds/readonly'

D.The field 'value' does not exist in the secret

AnswerC

403 is a permission denied error; the token's policy must grant read capability on that path.

Why this answer

A 403 Forbidden error from Vault indicates that the request was authenticated (the token is valid) but the token's policies do not grant permission for the requested action. Since the command attempts to read from 'database/creds/readonly', the most likely cause is that the token lacks a policy allowing read access on that path. This is a standard authorization failure, not an authentication or configuration issue.

Exam trap

HashiCorp often tests the distinction between authentication (401) and authorization (403) errors, where candidates mistakenly attribute a 403 to a missing mount or nonexistent role instead of recognizing it as a policy/permission issue.

How to eliminate wrong answers

Option A is wrong because a 403 error means the token was authenticated and the path exists; if the role 'readonly' did not exist, Vault would return a 404 (path not found) or a 400 (invalid role), not a 403. Option B is wrong because if the database secrets engine were not mounted at 'database/', Vault would return a 404 (path not found) or a 400 (invalid mount), not a 403. Option D is wrong because the field 'value' is irrelevant to a 403 error; a missing field would cause a 400 or 500 error during secret creation, not a permission-denied response on a read operation.

Full explanation →

MCQhard

A fintech company uses Vault Transit to encrypt credit card numbers (PANs) for PCI-DSS compliance. The security team enforces key rotation every 30 days, and Vault keeps previous key versions to allow decryption of old data. One day, a developer accidentally runs a command that deletes the latest key version before the rotation is complete. The company has Vault configured with key version soft-delete enabled. The incident response team needs to recover the ability to decrypt ciphertexts that were encrypted with the deleted key version. Which action should they take first?

A.Use the `vault write transit/keys/credit-cards/undelete` API to recover the soft-deleted key version

B.Restore the entire Vault cluster from the latest backup snapshot

C.Use the `rewrap` endpoint to re-encrypt all ciphertexts with the current key version

D.Restore the deleted key version from a secondary Vault cluster using replication

AnswerA

Soft-delete allows undeletion of key versions quickly and without data loss.

Why this answer

Vault's Transit secrets engine supports soft-delete for key versions, which allows recovery of a deleted key version using the `undelete` API before the deletion grace period expires. Since the company has soft-delete enabled, the key version is not permanently purged and can be restored without data loss, enabling decryption of ciphertexts encrypted with that version.

Exam trap

HashiCorp often tests the distinction between soft-delete and permanent deletion, and the trap here is that candidates may assume a deleted key version is irrecoverable and jump to a disruptive recovery method like restoring from backup, ignoring the soft-delete feature specifically designed for this scenario.

How to eliminate wrong answers

Option B is wrong because restoring the entire Vault cluster from a backup snapshot is an extreme measure that risks data loss from other changes and is unnecessary when soft-delete can recover the specific key version. Option C is wrong because the `rewrap` endpoint re-encrypts ciphertexts using the current key version, but it requires the original key to be available for decryption first, which is not possible if the key version is deleted and not yet recovered. Option D is wrong because restoring from a secondary cluster using replication would require the key version to exist in the secondary cluster's data, which is not guaranteed if the deletion propagated via replication, and it is not the first action to take when soft-delete is available.

Full explanation →

MCQmedium

A company is using the PKI secrets engine to issue certificates for internal services. They want to ensure that certificates are automatically revoked if a service is decommissioned. What should they implement?

A.Implement certificate pinning in all services.

B.Use Vault's built-in lifecycle management and revocation capabilities.

C.Set a very short TTL on certificates so they expire quickly.

D.Configure a Certificate Revocation List (CRL) that clients check.

AnswerB

Vault can revoke certificates via API or when lease expires.

Why this answer

Vault's PKI secrets engine includes built-in lifecycle management that can automatically revoke certificates when a lease expires or when a secret is deleted via the API. This allows you to tie certificate validity to the service's lifecycle in Vault, ensuring decommissioned services have their certificates revoked without manual intervention.

Exam trap

The trap here is that candidates confuse passive revocation mechanisms (like CRLs or short TTLs) with active, automated revocation, assuming that expiration or client-side checks are sufficient for decommissioning scenarios.

How to eliminate wrong answers

Option A is wrong because certificate pinning is a security mechanism to prevent man-in-the-middle attacks by hardcoding certificates, not a method for automatic revocation upon decommissioning. Option C is wrong because setting a very short TTL only forces certificates to expire quickly, but does not actively revoke them; expired certificates may still be accepted by clients that do not validate expiration, and this approach does not handle immediate revocation needs. Option D is wrong because a Certificate Revocation List (CRL) is a passive distribution mechanism that clients must fetch and check; it does not automate the revocation trigger when a service is decommissioned, and relies on clients to enforce revocation.

Full explanation →

MCQmedium

A startup uses Vault to manage secrets for their web application. They currently have a single admin user who authenticates with a root token. They want to allow two developers to authenticate with their own credentials and restrict them to read-only access to a specific path 'secret/data/webapp'. They decide to use the Userpass auth method. The admin creates a user 'dev1' with password 'password123' and assigns a policy 'webapp-readonly' that grants read capability on 'secret/data/webapp'. However, when dev1 tries to log in, Vault returns a permission denied error. The admin checks the token and sees no policies attached. What is the most likely issue?

A.The policy 'webapp-readonly' does not exist.

B.The admin did not assign any policies to the user.

C.The user 'dev1' does not exist.

D.The password is incorrect.

AnswerB

Userpass requires explicit policy assignment; without it, no policies are attached.

Why this answer

The most likely issue is that the admin created the user 'dev1' but did not assign any policies to that user. In Vault's Userpass auth method, simply creating a user does not attach any policies; the admin must explicitly specify the policies when creating or updating the user. Without a policy attached, the token issued upon login has no capabilities, resulting in a permission denied error even if the policy 'webapp-readonly' exists.

Exam trap

HashiCorp often tests the nuance that creating a user in Vault does not automatically assign any policies; candidates mistakenly assume that simply creating a user and a policy with the same name is sufficient, but the policy must be explicitly linked to the user.

How to eliminate wrong answers

Option A is wrong because if the policy 'webapp-readonly' did not exist, Vault would still allow the user to log in (the token would be issued) but would deny access to the path; however, the error occurs at login time and the token has no policies attached, indicating the policy exists but was not assigned. Option C is wrong because the admin successfully created the user 'dev1', and if the user did not exist, Vault would return a 'user not found' error, not a permission denied error. Option D is wrong because an incorrect password would cause an authentication failure (invalid credentials), not a permission denied error after login; the token would not be issued at all.

Full explanation →

MCQmedium

A user's token was revoked by an administrator, but the user can still read secrets from a KV v1 secrets engine. What is the most likely reason?

A.The token had sudo capabilities on the path

B.The token was a root token and cannot be revoked

C.The token was an orphan token and therefore immune to revocation

D.The secrets were from a KV v1 engine that does not use leases

AnswerD

Correct. KV v1 does not use leases, so after reading a secret, the client may cache it or the engine does not require a valid token for subsequent reads of the same data. Token revocation only stops new lease-based operations, but KV v1 reads are not lease-based.

Why this answer

KV v1 secrets engines do not issue leases for read operations, so token revocation does not affect access to previously read secrets. The token itself was revoked, but the user's ability to read secrets from KV v1 persists because the engine does not enforce lease-based expiration or revocation checks on stored data.

Exam trap

The trap here is that candidates assume token revocation immediately blocks all access to any previously read secrets, but KV v1's lack of leases means the client can continue using cached data without needing a valid token for the read operation itself.

How to eliminate wrong answers

Option A is wrong because sudo capabilities on a path allow a token to bypass ACL path restrictions, but they do not make a token immune to revocation; a revoked token cannot perform any operations regardless of sudo privileges. Option B is wrong because root tokens can be revoked; they are not immune to revocation, though they have unrestricted access until explicitly revoked. Option C is wrong because orphan tokens are not immune to revocation; they lack a parent token in the lineage, but they can still be revoked by an administrator or through token revocation operations.

Full explanation →

Multi-Selecthard

Which TWO statements correctly describe differences between AppRole and Kubernetes authentication methods?

Select 2 answers

A.AppRole requires a role_id and secret_id, while Kubernetes requires a service account token.

B.Kubernetes auth requires the secret_id to be specified in a configuration file.

C.Kubernetes authentication uses JWT tokens that are signed by the Kubernetes API server.

D.Both AppRole and Kubernetes support response wrapping for initial credentials.

E.AppRole tokens are always batch tokens, while Kubernetes tokens are service tokens.

AnswersA, C

AppRole uses two components; Kubernetes uses a single token.

Why this answer

AppRole authentication indeed requires a RoleID and SecretID to be presented by the client to obtain a Vault token, whereas Kubernetes authentication requires a service account token (a JWT) that is signed by the Kubernetes API server. This is a fundamental difference in the credential material each method uses to prove identity.

Exam trap

HashiCorp often tests the misconception that both methods use a similar two-factor credential model, but the trap is that Kubernetes authentication relies solely on a signed JWT from the Kubernetes API server, not a separate secret_id, and that AppRole tokens are not inherently batch tokens.

Full explanation →

MCQhard

A security team notices that some Vault users are authenticating with the Userpass auth method, but they want to enforce password complexity and expiration. What is the best approach?

A.Migrate users to an external identity provider and use LDAP or OIDC auth.

B.Switch to token-based authentication and issue tokens with TTL.

C.Use Vault's password policy plugin with Userpass.

D.Configure password policies in Vault's Userpass auth method.

AnswerA

External IDPs can enforce password policies; Vault can leverage them.

Why this answer

The Userpass auth method in Vault does not natively support password complexity or expiration policies. Migrating to an external identity provider (IdP) via LDAP or OIDC allows the organization to enforce these policies externally, where they are natively supported, and then federate authentication into Vault. This approach leverages the IdP's mature password management capabilities while maintaining Vault's authorization and audit controls.

Exam trap

HashiCorp often tests the misconception that Vault's built-in auth methods (like Userpass) can be extended with plugins or policies to enforce password rules, when in reality Vault delegates such policy enforcement to external identity providers.

How to eliminate wrong answers

Option B is wrong because switching to token-based authentication does not enforce password complexity or expiration; tokens are ephemeral credentials issued after authentication, not a replacement for password policies. Option C is wrong because Vault does not have a 'password policy plugin' for Userpass; password policies are a separate feature but are not directly enforceable within the Userpass auth method itself. Option D is wrong because Vault's Userpass auth method does not support configuring password complexity or expiration policies; it only stores hashed passwords and lacks built-in policy enforcement.

Full explanation →

Multi-Selectmedium

Which TWO statements correctly describe Vault's encryption as a service using the Transit secrets engine?

Select 2 answers

A.Ciphertext is stored within Vault for later retrieval.

B.Data is encrypted and decrypted on the server side without the client having direct access to the encryption key.

C.Encryption always produces a unique ciphertext even with the same plaintext and key.

D.Key rotation is not supported; the key version is fixed.

E.The encryption key can be derived per context using key derivation, ensuring unique ciphertext per context.

AnswersB, E

Transit encrypts data server-side using a managed key, never exposing the key to clients.

Why this answer

The Transit secrets engine in Vault performs encryption and decryption on the server side, meaning the client sends plaintext to Vault and receives ciphertext back without ever having direct access to the underlying encryption key. This is the core of encryption as a service: the key remains securely stored within Vault's barrier, and the client only interacts with the key via API calls, never seeing the key material itself.

Exam trap

Candidates often mistakenly believe that Vault's Transit encryption always produces unique ciphertext. However, while the default is non-deterministic (random nonce), encryption is not guaranteed to be unique because key derivation or convergent encryption can produce deterministic outputs. Option C is incorrect because it states 'always', which is too absolute.

Full explanation →

MCQmedium

A company wants to use Vault's Key Management Secrets Engine (KMSE) to encrypt data stored in AWS S3. The security team requires that the encryption key used by Vault is never exposed to the application. Which Vault architecture component ensures that the encryption key remains within the Vault boundary and is not accessible to the application?

A.Vault's Cubbyhole Response Wrapping

B.Vault's Key Management Secrets Engine (KMSE)

C.Vault's Transit Secrets Engine

D.Vault's PKI Secrets Engine

AnswerC

Correct. Transit Secrets Engine maintains the encryption key inside Vault and performs crypto operations without exposing the key to the application.

Why this answer

Transit Secrets Engine performs encryption/decryption using keys stored entirely within Vault. The application sends data to Vault, which processes it with the key and returns the result, ensuring the key is never exposed. KMSE (B) delegates key storage to an external KMS, placing the key outside Vault's boundary, which contradicts the requirement that the key remains within Vault.

Exam trap

Candidates often assume KMSE is the correct answer because it proxies encryption, but the key resides externally. Transit keeps the key inside Vault, fulfilling the 'within Vault boundary' requirement.

How to eliminate wrong answers

Option A is wrong because Cubbyhole Response Wrapping is a mechanism for securely delivering secrets to a client by wrapping them in a one-time-use token; it does not prevent the application from accessing the underlying encryption key after unwrapping. Option C is wrong because the Transit Secrets Engine performs encryption and decryption operations within Vault using a key that is stored in Vault's backend, but the application could potentially retrieve the key if it has sufficient permissions (e.g., via the 'read' capability on the key path), which violates the requirement that the key never be exposed. Option D is wrong because the PKI Secrets Engine is used for generating and managing X.509 certificates, not for encrypting data with a key that remains hidden from the application.

Full explanation →

Multi-Selecteasy

A DevOps team is troubleshooting token access in Vault. They need to determine which of the following token operations require sudo capability. Which TWO operations require sudo capability?

Select 2 answers

A.Create a token

B.Renew a token

C.Read token accessor information

D.Revoke a token

E.Access a token's capabilities against a path

AnswersD, E

Revoking a token requires sudo capability because it destroys a token.

Why this answer

Revoking a token (Option D) requires sudo capability because it is a privileged operation that can disrupt access for users or services. By default, Vault's token revocation endpoints are protected by sudo policies to prevent accidental or unauthorized revocation of tokens, which could lead to denial of service.

Exam trap

HashiCorp often tests the misconception that all token management operations require sudo, but only destructive or highly privileged actions like revocation and capability access (which can reveal policy details) need it, while creation, renewal, and read operations do not.

Full explanation →

MCQeasy

A company is migrating from a file storage backend to Consul. Which Vault command should be used to move the data?

A.vault operator rekey

B.vault operator unseal

C.vault operator migrate

D.vault operator init

AnswerC

Migrates data from one storage backend to another.

Why this answer

The `vault operator migrate` command is specifically designed to move Vault data from one storage backend to another, such as from a file storage backend to Consul. It handles the safe transfer of all encrypted data, including secrets, policies, and tokens, while ensuring consistency and minimal downtime during the migration process.

Exam trap

HashiCorp often tests the distinction between storage backend migration and other operator tasks, so candidates mistakenly choose `vault operator rekey` or `vault operator init` because they associate 'moving data' with key management or initialization rather than the dedicated migration command.

How to eliminate wrong answers

Option A is wrong because `vault operator rekey` is used to generate new unseal keys and change the key shares/threshold, not to migrate data between storage backends. Option B is wrong because `vault operator unseal` is used to unseal a Vault instance by providing a key share, not for moving data. Option D is wrong because `vault operator init` initializes a new Vault instance, generating the initial root token and unseal keys, but does not perform any data migration.

Full explanation →

Multi-Selectmedium

Which THREE are requirements for a Vault High Availability (HA) cluster?

Select 3 answers

A.Standby nodes must be able to serve read requests.

B.A load balancer in front of all nodes.

C.A shared storage backend accessible by all nodes.

D.The active node must be able to handle all requests.

E.Standby nodes must forward requests to the active node.

AnswersC, D, E

All nodes must read/write to the same storage.

Why this answer

Vault HA clusters require a shared storage backend (e.g., Consul, Integrated Storage, or Raft) that all nodes can access to maintain consistent state. Without shared storage, standby nodes cannot synchronize data or take over seamlessly if the active node fails.

Exam trap

HashiCorp often tests the misconception that standby nodes can serve read requests or that a load balancer is mandatory for HA, but Vault's architecture explicitly requires standby nodes to be passive and a load balancer to be optional.

Full explanation →

Multi-Selecthard

Which TWO best practices should be followed when tuning secrets engine mounts?

Select 2 answers

A.Enable audit logging on the mount to track secret access

B.Configure 'max_lease_ttl' to limit the maximum duration secrets can be valid

C.Set 'default_lease_ttl' to a low value appropriate for the secrets engine

D.Set a high default lease TTL to reduce renewals

E.Disable the 'default' policy for the mount to restrict access

AnswersB, C

This ensures even if a role requests a long TTL, it cannot exceed the mount limit.

Why this answer

Setting a low default lease TTL and enforcing maximum TTL per mount helps control secret lifetimes and reduce risk. Disabling using default policy is not a mount tuning best practice, and audit logging is a system-wide setting.

Full explanation →

Multi-Selecthard

Which THREE of the following are true about batch tokens?

Select 3 answers

A.They can be created as orphan tokens

B.They have a TTL that must be set at creation

C.They are non-renewable

D.They are always root tokens

E.They are lightweight and have no storage cost

AnswersB, C, E

Batch tokens require a TTL.

Why this answer

Batch tokens in Vault are designed to be lightweight, non-renewable tokens that must have a Time-To-Live (TTL) set at creation. They are not renewable, meaning once they expire, they cannot be renewed or extended. This makes them ideal for short-lived, high-volume workloads where token lifecycle management is automated.

Exam trap

HashiCorp often tests the misconception that batch tokens can be orphaned or renewed, when in fact they are non-renewable and cannot be created as orphans, which are properties exclusive to service tokens.

Full explanation →

MCQmedium

A company runs its containerized workloads on multiple Kubernetes clusters and also maintains a number of legacy virtual machines running critical applications. The Vault cluster is deployed outside Kubernetes and is used to manage secrets for both environments. The DevOps team has configured the Kubernetes auth method for pods in the Kubernetes clusters, but they are experiencing authentication failures for pods in one specific namespace. Meanwhile, legacy VMs cannot authenticate at all because they are not part of any Kubernetes cluster. The Vault administrator needs to enable authentication for all workloads while minimizing changes to existing applications. The administrator has received the following requirements: containerized pods should authenticate without manual token distribution, legacy VMs should use a method that supports machine-oriented authentication with short-lived tokens, and all authentication should be auditable. Which course of action should the administrator take?

A.Configure the LDAP auth method for both pods and legacy VMs, creating service accounts in Active Directory for each application.

B.Configure the Kubernetes auth method on all clusters and also install a Vault sidecar on the legacy VMs to make them appear as pods.

C.Use AppRole as the sole authentication method for all workloads, generating secret IDs for each pod and VM.

D.Keep the Kubernetes auth method for pods (fixing the namespace-specific issue) and enable AppRole authentication for the legacy VMs, using response wrapping or trusted entities for SecretID delivery.

AnswerD

This approach uses the most suitable auth method for each environment: Kubernetes auth for pods (short-lived, no manual tokens) and AppRole for VMs (machine-oriented, auditable). The failing namespace issue can be resolved by verifying service account and token reviewer configurations.

Why this answer

It preserves the existing Kubernetes auth method for pods (after fixing the namespace-specific issue) and introduces AppRole for legacy VMs, which provides machine-oriented authentication with short-lived tokens via SecretIDs. This approach minimizes changes to existing applications, meets the requirement for auditable authentication (both methods log to Vault audit devices), and avoids manual token distribution by using response wrapping or trusted entities for secure SecretID delivery.

Exam trap

HashiCorp often tests the distinction between authentication methods designed for human users (LDAP) versus machine workloads (AppRole, Kubernetes), and the trap here is assuming that a single method can be universally applied without considering the operational overhead of SecretID distribution or the namespace-specific configuration nuances of Kubernetes auth.

How to eliminate wrong answers

Option A is wrong because LDAP auth method is designed for user authentication against an LDAP directory, not for machine-oriented authentication; it would require creating and managing service accounts in Active Directory for each application, which is not minimal change and does not natively support short-lived tokens for machines. Option B is wrong because installing a Vault sidecar on legacy VMs to make them appear as pods is impractical and violates the requirement to minimize changes; the sidecar would require significant reconfiguration and does not solve the authentication issue for non-Kubernetes workloads. Option C is wrong because using AppRole as the sole authentication method for all workloads would require generating and distributing SecretIDs for every pod, which contradicts the requirement for containerized pods to authenticate without manual token distribution; Kubernetes auth method is more appropriate for pods as it leverages service account tokens automatically.

Full explanation →

Multi-Selectmedium

A Vault administrator needs to manage leases for dynamic secrets. Which TWO of the following are valid operations related to lease management?

Select 2 answers

A.Call the sys/leases/renew endpoint to renew a lease.

B.Call the sys/leases/list endpoint to disable a lease.

C.Call the sys/leases/revoke endpoint to revoke a lease.

D.Call the sys/leases/extend endpoint to increase the lease duration.

E.Call the sys/leases/rotate endpoint to rotate the secret associated with a lease.

AnswersA, C

Correct operation to renew a lease.

Why this answer

The `sys/leases/renew` endpoint is the standard Vault API endpoint used to renew the lease of a dynamic secret, extending its time-to-live (TTL) within the maximum allowed limit. Option C is correct because the `sys/leases/revoke` endpoint is the designated API endpoint to immediately invalidate a lease and its associated secret, preventing further use and cleaning up the secret engine's state.

Exam trap

HashiCorp often tests the misconception that lease management endpoints have intuitive names like 'extend' or 'rotate', when in fact Vault uses only three core lease operations: renew, revoke, and list (with no dedicated extend or rotate endpoints).

Full explanation →

MCQeasy

A user wants to log in using the userpass auth method with username 'jdoe' and password 'p@ssw0rd'. What is the correct API endpoint and request?

A.GET /v1/auth/userpass/login/jdoe with header "password: p@ssw0rd"

B.PUT /v1/auth/userpass/login/jdoe with JSON body {"password":"p@ssw0rd"}

C.POST /v1/auth/userpass/login/jdoe?password=p@ssw0rd

D.POST /v1/auth/userpass/login/jdoe with JSON body {"password":"p@ssw0rd"}

AnswerD

Correct; standard userpass login API call.

Why this answer

The userpass auth method in Vault requires a POST request to the login endpoint with the password provided in the JSON body. Option D correctly uses POST /v1/auth/userpass/login/jdoe with {"password":"p@ssw0rd"}, which matches the Vault API specification for authenticating against a userpass backend.

Exam trap

HashiCorp often tests the misconception that authentication requests can use GET or PUT methods or pass credentials in headers or query parameters, when Vault strictly requires POST with a JSON body for login endpoints.

How to eliminate wrong answers

Option A is wrong because it uses GET with a header, but Vault's userpass login endpoint requires a POST request, and the password must be sent in the JSON body, not as a header. Option B is wrong because it uses PUT, but Vault's login endpoints only accept POST requests for authentication. Option C is wrong because it passes the password as a query parameter, which is insecure and not supported by Vault's API; the password must be in the JSON body.

Full explanation →

MCQeasy

Refer to the exhibit. A Vault policy allows 'list' on 'secret/data/*'. A user tries to list keys under 'secret/data/' and gets a permission denied error. What is the most likely reason?

A.The user's token has no default policy

B.The policy lacks 'read' capability

C.The path must be 'secret/metadata/*' for list

D.The secrets engine is not enabled

AnswerC

List operations in KV v2 are on the metadata path.

Why this answer

C is correct because in Vault, listing keys under a KV v2 secrets engine requires the 'list' capability on the 'secret/metadata/*' path, not 'secret/data/*'. The 'data' path is used for reading and writing actual secret values, while 'metadata' is the correct path for listing and deleting metadata (including key names). The policy only grants 'list' on 'secret/data/*', which does not cover the list operation on the metadata endpoint, resulting in a permission denied error.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 path structures, specifically that 'list' operations in KV v2 require the 'metadata' path, not the 'data' path, which candidates frequently confuse because they assume the same path works for both reading and listing.

How to eliminate wrong answers

Option A is wrong because the default policy is not required for listing; the user's token only needs a policy that grants 'list' on the correct path. Option B is wrong because 'read' capability is not needed for listing keys; 'list' is a distinct capability that must be explicitly granted on the appropriate path. Option D is wrong because if the secrets engine were not enabled, the error would be 'path not found' or 'no handler', not a permission denied error.

Full explanation →

MCQmedium

A user attempts to read a secret at path 'secret/data/app' and receives a 403 Forbidden error. What is the most likely cause?

A.The secret engine is not mounted at 'secret/'

B.The secret key does not exist

C.The token has expired

D.The token's policy does not grant read capability on that path

AnswerD

403 errors are caused by lack of permissions; the token's policy must allow 'read' on the path.

Why this answer

A 403 Forbidden error in Vault indicates that the token used for the request is valid and the path exists, but the token's attached policy does not grant the required 'read' capability on that specific path. This is a policy enforcement action by Vault's ACL system, which explicitly denies access when the policy lacks a matching 'read' rule for the path.

Exam trap

HashiCorp often tests the distinction between HTTP status codes in Vault: candidates confuse a 403 (policy denial) with a 404 (path not found) or assume an expired token always returns a 403, but the trap is that a 403 can also occur with a valid token lacking the correct policy, which is the most common scenario in practice.

How to eliminate wrong answers

Option A is wrong because if the secret engine were not mounted at 'secret/', the API would return a 404 Not Found error (path not found), not a 403. Option B is wrong because a missing secret key would also result in a 404 error (no value at path), not a 403, as the path itself is valid. Option C is wrong because an expired token would return a 403 Forbidden error, but the question asks for the 'most likely' cause; while an expired token can cause a 403, the scenario describes a user 'attempting to read' a secret, implying the token is still valid but lacks the necessary policy, which is the more common and direct cause in Vault's design.

Full explanation →

Multi-Selecthard

Which TWO of the following are benefits of using Vault's transit engine for encryption as a service?

Select 2 answers

A.The encryption key is stored in the application's memory

B.Applications can encrypt/decrypt data without accessing the key material

C.Keys can be exported and used in external applications

D.Only the root token can manage keys

E.Key rotation is handled centrally without downtime

AnswersB, E

Vault holds the keys and performs operations on behalf of applications.

Why this answer

Vault's transit engine enables applications to encrypt and decrypt data without ever having access to the underlying key material (Option B). Additionally, key rotation is handled centrally by Vault without any application downtime, as applications continue to use the same API calls and Vault manages the rotation transparently (Option E).

Exam trap

HashiCorp often tests the misconception that 'encryption as a service' requires exporting keys to applications, but the transit engine's core benefit is that applications never touch the key material, ensuring centralized control and security.

Full explanation →

MCQhard

A company with strict security requirements uses Vault's Transit secrets engine to encrypt data in a microservices architecture. They have multiple applications that each require a unique encryption key. The security team wants to enforce key rotation every 30 days for all keys, and also require that keys be destroyed after they are no longer used. The application team is concerned that key rotation might cause downtime because applications need to re-encrypt data. The Vault architect needs to design a key management solution. What is the best approach?

A.Use the Transit engine's key rotation capability with versioning and configure applications to use the latest key version for encryption, while keeping old versions for decryption.

B.Manually rotate keys every 30 days and update applications with new key IDs.

C.Set the key TTL to 30 days and configure Vault to automatically re-encrypt data when keys are rotated.

D.Use a single key for all applications and rotate it by creating a new key and deleting the old one.

AnswerA

Versioning allows seamless rotation.

Why this answer

Vault's Transit secrets engine supports key rotation with versioning, where each rotation creates a new key version while retaining older versions for decryption. This allows applications to always encrypt using the latest version (via the `encrypt` endpoint) and decrypt using any previous version (via the `decrypt` endpoint), ensuring zero downtime during rotation. The security team's requirement for key destruction after disuse can be met by trimming or deleting old key versions once all data encrypted with them is re-encrypted.

Exam trap

HashiCorp often tests the misconception that key rotation in Vault automatically re-encrypts existing ciphertext, when in fact the Transit engine only creates new key versions and relies on applications to re-encrypt data separately.

How to eliminate wrong answers

Option B is wrong because manually rotating keys and updating application configurations with new key IDs introduces operational overhead and potential downtime, as applications would need to be redeployed or restarted to use the new key, violating the zero-downtime requirement. Option C is wrong because Vault's Transit engine does not support automatic re-encryption of existing ciphertext when a key is rotated; the `key TTL` parameter controls key expiration, not automatic data re-encryption, and old ciphertext remains decryptable only if the old key version is retained. Option D is wrong because using a single key for all applications violates the requirement for unique encryption keys per application, and deleting the old key immediately after rotation would break decryption of any data still encrypted with that key, causing data loss.

Full explanation →

Multi-Selectmedium

Which TWO components are required for Vault to process client requests after startup?

Select 2 answers

A.Audit Device

B.A policy

C.Unseal key shares

D.A secrets engine

E.An enabled auth method

AnswersC, E

Required to unseal Vault.

Why this answer

C is correct because Vault starts in a sealed state and requires a threshold of unseal key shares to reconstruct the master key and decrypt the storage backend. Without unsealing, Vault cannot access any data or process client requests. E is correct because an enabled auth method is necessary to authenticate clients; Vault rejects all unauthenticated requests by default.

Exam trap

HashiCorp often tests the misconception that a secrets engine or policy is required for Vault to function, but the core requirement is unsealing and an auth method to accept any client request.

Full explanation →

MCQmedium

Refer to the exhibit. Based on the policy shown, which statement is true?

A.A user can create secrets under secret/data/engineering/.

B.A user can read all secrets under secret/data/engineering/.

C.A user can delete secrets under secret/data/engineering/.

D.A user can update secrets under secret/data/engineering/.

AnswerB

Correct: The policy grants read and list on secret/data/engineering/*, so all secrets under that path can be read.

Why this answer

The policy shown grants 'read' capability on the path 'secret/data/engineering/*'. In Vault, the 'read' capability allows listing and reading secrets at that path, but not creating, updating, or deleting them. Therefore, a user can read all secrets under secret/data/engineering/.

Exam trap

Vault often tests the distinction between 'read' and 'create'/'update' capabilities, where candidates mistakenly assume 'read' includes the ability to modify secrets.

How to eliminate wrong answers

Option A is wrong because creating secrets requires the 'create' or 'sudo' capability, which is not granted by the policy. Option C is wrong because deleting secrets requires the 'delete' capability, which is not included in the policy. Option D is wrong because updating secrets requires the 'update' capability, which is not granted by the policy.

Full explanation →

100

MCQeasy

A developer wants to encrypt data using Vault's transit engine with a key named 'payment-key'. The key already exists and is set to allow encryption. Which API path should the developer use to encrypt the data?

A.POST /v1/transit/decrypt/payment-key

B.POST /v1/transit/rewrap/payment-key

C.POST /v1/transit/keys/payment-key

D.POST /v1/transit/encrypt/payment-key

AnswerD

Correct path for encryption.

Why this answer

The Vault transit engine exposes the `/v1/transit/encrypt/<key_name>` endpoint for encrypting plaintext data using a named encryption key. Since the key 'payment-key' already exists and is allowed to encrypt, a POST request to this path will perform the encryption operation and return the ciphertext.

Exam trap

HashiCorp often tests the distinction between key management endpoints (like `/keys/`) and cryptographic operation endpoints (like `/encrypt/`), trapping candidates who confuse managing the key with using the key to encrypt data.

How to eliminate wrong answers

Option A is wrong because `/v1/transit/decrypt/payment-key` is used for decryption, not encryption; it would attempt to reverse the encryption process. Option B is wrong because `/v1/transit/rewrap/payment-key` is used to re-encrypt existing ciphertext under a new version of the key, not to encrypt new plaintext. Option C is wrong because `/v1/transit/keys/payment-key` is used to manage the key itself (e.g., read configuration, rotate, or delete), not to perform cryptographic operations on data.

Full explanation →

101

MCQmedium

A security policy requires that all leases must be revoked within 1 hour of creation. Which setting should be configured on the secret engine mount?

A.default_lease_ttl = 1h

B.token_ttl = 1h

C.max_lease_ttl = 1h

D.default_lease_ttl = 1h and max_lease_ttl = 1h

AnswerD

This combination caps the lease at 1h and ensures initial TTL is 1h.

Why this answer

The security policy requires that all leases must be revoked within 1 hour of creation, meaning no lease can exceed 1 hour. The `default_lease_ttl` sets the initial TTL for leases when no specific TTL is provided, and the `max_lease_ttl` enforces an absolute upper limit that no lease can exceed. Configuring both to 1h ensures that every lease starts with a 1-hour TTL and cannot be renewed or extended beyond that hard cap, guaranteeing revocation within 1 hour.

Exam trap

A common trap is that candidates assume setting only `max_lease_ttl` is sufficient, overlooking that `default_lease_ttl` must also be set to ensure all leases start with the required TTL and cannot be extended beyond it.

How to eliminate wrong answers

Option A is wrong because setting only `default_lease_ttl = 1h` does not prevent a client from requesting a longer TTL or renewing the lease beyond 1 hour; the `max_lease_ttl` is needed to enforce the absolute cap. Option B is wrong because `token_ttl` controls the lifetime of the authentication token itself, not the TTL of leases issued by a secret engine mount; leases are governed by `default_lease_ttl` and `max_lease_ttl` on the mount. Option C is wrong because setting only `max_lease_ttl = 1h` without `default_lease_ttl` means leases could be created with a shorter TTL (e.g., 30 minutes) and then renewed up to the max, but the policy requires all leases to be revoked within 1 hour of creation—without a default, some leases might be issued with a very short TTL and still be renewed, but the policy's intent is that no lease lasts longer than 1 hour from creation, which both settings together guarantee.

Full explanation →

102

MCQeasy

A company runs a microservices architecture where each service authenticates to Vault using AppRole and is assigned a role with a periodic token. The operations team notices that some services experience authentication failures after exactly 24 hours of uptime, even though their tokens were initially issued with a TTL of 24 hours and 'renewable' set to true. The services are configured to renew their tokens automatically before expiry. Upon investigation, the Vault logs show the error: 'failed to renew token: token has exceeded its max TTL'. The Vault server is configured with a default 'max_lease_ttl' of 24 hours and a 'default_lease_ttl' of 1 hour at the system level. The AppRole role has no explicit TTL or max TTL set. What is the most likely cause of the failure?

A.The token's lease duration is actually 1 hour (the default) and the services fail to renew before expiry.

B.The AppRole role has an implicit max TTL of 0, which prevents any renewal after the initial TTL.

C.The services are not renewing their tokens because the 'renewable' flag is ignored by periodic tokens.

D.The periodic token's max TTL is set by the system's 'max_lease_ttl' of 24 hours, and once that time is reached, renewal is no longer allowed.

AnswerD

Periodic tokens have a max TTL equal to the system's 'max_lease_ttl' unless overridden on the role. Here, 24 hours elapsed, hitting the limit.

Why this answer

The periodic token's max TTL is derived from the system's 'max_lease_ttl' of 24 hours when no explicit max TTL is set on the AppRole role. Even though the token is renewable and the services attempt to renew before expiry, the token cannot be renewed once its cumulative lifetime reaches the max TTL of 24 hours, causing the 'token has exceeded its max TTL' error. The periodic token's TTL is reset on each renewal, but the max TTL is a hard limit on the total lifespan of the token.

Exam trap

A common pitfall when working with Vault periodic tokens is confusing the token TTL, which resets on each renewal, with the max TTL, which is a cumulative lifetime limit. Candidates may mistakenly think that automatic renewal prevents any expiry, but the max TTL is a hard limit that cannot be exceeded, even with renewal.

How to eliminate wrong answers

Option A is wrong because the token's lease duration is not 1 hour; the token was issued with a TTL of 24 hours (the default_lease_ttl of 1 hour applies to non-periodic leases, not to the token's TTL when renewable is true and no explicit TTL is set on the role). Option B is wrong because an AppRole role with no explicit max TTL does not have an implicit max TTL of 0; instead, it inherits the system's max_lease_ttl, and a max TTL of 0 would mean no renewal is allowed at all, which is not the case here. Option C is wrong because the 'renewable' flag is not ignored by periodic tokens; periodic tokens are explicitly designed to be renewable, and the failure is due to the max TTL limit, not the renewable flag being ignored.

Full explanation →

103

Multi-Selecteasy

Which THREE authentication methods are built into Vault (no plugin required)?

Select 3 answers

A.OIDC

B.LDAP

C.SAML

D.RADIUS

E.AppRole

AnswersA, B, E

OIDC is built-in.

Why this answer

OIDC (OpenID Connect) is built into Vault as an identity provider and authentication method without requiring any external plugin. It allows clients to authenticate via OIDC providers like Okta or Azure AD, leveraging JWT tokens for identity verification. Vault's built-in OIDC support is configured through the `vault auth enable oidc` command and does not depend on any separate plugin binary.

Exam trap

HashiCorp often tests the distinction between 'built-in' and 'plugin-based' authentication methods, and the trap here is that candidates mistakenly assume SAML is built-in because it is a common enterprise protocol, but Vault requires a separate plugin for SAML support.

Full explanation →

104

MCQeasy

A developer wants to encrypt a string "hello" using Vault's transit engine. What must they send in the API request?

A.The ciphertext of "hello"

B.Both the key name and the ciphertext

C.A reference to the key

D.The plaintext "hello" in raw bytes

E.The plaintext "hello" as a base64 encoded string

AnswerE

Correct, the API expects base64-encoded plaintext.

Why this answer

E is correct because Vault's transit engine requires plaintext to be base64-encoded before encryption. The API endpoint expects the plaintext as a base64-encoded string in the `plaintext` field of the request body. This ensures binary-safe transmission and consistent encoding across different systems.

Exam trap

HashiCorp often tests the requirement for base64 encoding of plaintext in transit engine operations, trapping candidates who assume raw bytes or ciphertext are acceptable inputs.

How to eliminate wrong answers

Option A is wrong because sending ciphertext would be for decryption, not encryption; the transit engine encrypts plaintext, not ciphertext. Option B is wrong because the key name is required, but ciphertext is not sent for encryption—only plaintext is provided. Option C is wrong because a reference to the key is insufficient; the actual plaintext data must be included in the request.

Option D is wrong because raw bytes are not accepted; Vault requires base64 encoding to avoid issues with binary data in JSON.

Full explanation →

105

MCQeasy

An operator needs to enable the KV v2 secrets engine at the path 'team-alpha'. Which command should they run?

A.vault secrets enable -path=team-alpha kv-v2

B.vault secrets enable kv-v2 team-alpha

C.vault secrets enable -path=team-alpha kv

D.vault secrets mount -path=team-alpha kv

AnswerA

Correct syntax: enable kv-v2 at custom path.

Why this answer

The `vault secrets enable` command with the `-path` flag specifies the mount path as 'team-alpha', and `kv-v2` is the correct engine type for the KV v2 secrets engine. This command mounts the KV v2 engine at the desired path, enabling versioned key-value storage.

Exam trap

HashiCorp often tests the distinction between `kv` (v1) and `kv-v2` (v2) engines, and the requirement to use the `-path` flag for custom mount points, causing candidates to confuse the engine type or omit the flag.

How to eliminate wrong answers

Option B is wrong because it omits the `-path` flag, causing the engine to be mounted at the default path 'kv-v2' instead of 'team-alpha'. Option C is wrong because `kv` refers to the KV v1 secrets engine (non-versioned), not the KV v2 engine required. Option D is wrong because `vault secrets mount` is a legacy command; the correct modern command is `vault secrets enable`, and `kv` again specifies the wrong engine type.

Full explanation →

106

MCQhard

A Vault cluster uses DR replication. The primary cluster fails, and the DR secondary is promoted to primary. After promotion, some secret data written to the primary shortly before the failure is missing on the new primary. What is the most likely reason?

A.The data had not yet been replicated to the DR secondary before the primary failed.

B.The seal wrapping key was rotated on the primary after the last replication.

C.The secret engine was not enabled on the DR secondary.

D.The DR secondary was promoted with the 'force' option, which skips replication of the last writes.

AnswerA

Asynchronous replication means some writes may be lost.

Why this answer

In Vault DR replication, data is asynchronously replicated from the primary to the secondary cluster. If the primary fails before the replication stream has transmitted the most recent writes, those writes are lost. When the DR secondary is promoted to primary, it only contains data that was successfully replicated up to the point of failure.

This is the most likely reason the secret data is missing.

Exam trap

HashiCorp often tests the misconception that DR replication is synchronous or that the 'force' promotion option can recover missing writes, when in fact asynchronous replication inherently risks data loss of the most recent writes that have not yet been replicated.

How to eliminate wrong answers

Option B is wrong because the seal wrapping key is a cluster-level key used for encrypting the storage backend; its rotation does not affect the replication of secret data. Option C is wrong because DR replication operates at the storage layer, replicating all mounted secret engines and their data; if a secret engine was not enabled on the DR secondary, it would not have been replicated, but the question states the data was written to the primary, implying the engine was enabled there and would be replicated. Option D is wrong because the 'force' option during promotion is used to override a replication checkpoint mismatch (e.g., when the secondary is behind), but it does not skip replication of the last writes; it simply allows promotion despite the gap, meaning the missing data was never replicated, not that it was skipped.

Full explanation →

107

MCQhard

During a performance test, Vault becomes unresponsive for several seconds when the storage backend experiences high latency. Which architectural change would best improve Vault's resilience to storage latency?

A.Configure Performance Standby nodes

B.Add more storage backend nodes

C.Disable storage replication

D.Increase the number of Vault nodes without replication

AnswerA

Offloads read operations and reduces load on the active node.

Why this answer

Performance Standby nodes are designed to handle read requests and can serve as hot standbys that take over active duty if the primary node becomes unresponsive due to storage backend latency. They maintain a local copy of the data via replication, allowing them to continue serving requests without waiting for the slow storage backend, thus improving resilience to high-latency storage conditions.

Exam trap

HashiCorp often tests the misconception that adding more nodes or storage capacity alone solves latency issues, but the key is replication and local data access, which Performance Standby nodes provide.

How to eliminate wrong answers

Option B is wrong because adding more storage backend nodes does not address the root cause of high latency; it may even increase complexity and replication overhead without providing a local, low-latency copy of the data. Option C is wrong because disabling storage replication would eliminate the mechanism that allows Performance Standby nodes to have a local copy, making the system more vulnerable to storage latency, not less. Option D is wrong because increasing the number of Vault nodes without replication means each node still depends on the same slow storage backend, so they would all become unresponsive simultaneously during high-latency events.

Full explanation →

108

MCQhard

An administrator creates a token role with 'allowed_policies' and tries to create a child token. What does this error indicate?

A.The token has been revoked too many times

B.The token's TTL is too short

C.The token's policy is not allowed by the role

D.The token role's token_count_limit has been reached

AnswerD

The token_count_limit restricts the number of tokens a role can create.

Why this answer

The error 'token count per user (3) exceeded' indicates that the number of tokens issued for that entity (user or role) has exceeded the maximum allowed, which is controlled by the 'token_count_limit' parameter in the token role. Option D correctly identifies this limit as the cause. Option A is irrelevant because revocation count is not involved.

Option B is incorrect because the error is about token count, not TTL. Option C is incorrect because the error is about quantity, not policy permissions.

Full explanation →

109

MCQmedium

A Vault policy has the following: path "identity/entity/id/*" { capabilities = ["read", "list"] }. What does this policy allow?

A.Reading and updating all identity entities.

B.Reading and listing all identity entities.

C.Listing all identity entities and reading their details.

D.Reading and listing all identity entity IDs.

AnswerC

List returns entity IDs, read returns full details of each entity.

Why this answer

The policy grants 'read' and 'list' capabilities on the path `identity/entity/id/*`. In Vault, the 'list' capability returns entity IDs (a summary), while the 'read' capability retrieves the full details of a specific entity. Option C correctly captures both actions: listing all entities and reading their details.

Exam trap

Vault candidates often conflate 'list' (returns entity IDs) with 'read' (returns full details) on the identity/entity/id/* path. The 'list' action provides a summary of IDs, while 'read' gives the complete entity details for a specific ID.

How to eliminate wrong answers

Option A is wrong because 'update' is not listed in the capabilities; the policy only allows 'read' and 'list', not 'update'. Option B is wrong because it says 'reading and listing all identity entities', but 'read' retrieves details of a specific entity, not a bulk read of all entities; listing returns IDs, not full entities. Option D is wrong because it says 'reading and listing all identity entity IDs', but 'read' retrieves entity details, not just IDs; listing returns IDs, but reading returns the full entity object.

Full explanation →

110

MCQeasy

A company needs to generate short-lived, dynamic database credentials for its MySQL instances. Which secrets engine should be configured?

A.KV secrets engine

B.AWS secrets engine

C.Database secrets engine

D.PKI secrets engine

AnswerC

Database secrets engine is specifically designed to generate dynamic credentials for databases like MySQL, PostgreSQL, etc.

Why this answer

The Database secrets engine is specifically designed to generate short-lived, dynamic credentials for databases like MySQL. It creates unique, time-bound usernames and passwords on demand, which aligns with the requirement for temporary database access without manual credential management.

Exam trap

HashiCorp often tests the distinction between static and dynamic secrets engines, and the trap here is confusing the Database secrets engine with the KV secrets engine because both can store database passwords, but only the Database engine generates them on-the-fly with automatic expiration.

How to eliminate wrong answers

Option A is wrong because the KV secrets engine stores static secrets (e.g., passwords, API keys) and does not support dynamic credential generation or automatic rotation. Option B is wrong because the AWS secrets engine generates dynamic credentials for AWS services (e.g., IAM users, STS tokens), not for MySQL databases. Option D is wrong because the PKI secrets engine issues X.509 certificates for TLS/SSL authentication, not database credentials.

Full explanation →

111

MCQeasy

A development team is using Vault to dynamically generate PostgreSQL credentials for their application. They configured a database role with a max_lease_ttl of 24 hours. However, credentials are becoming invalid after only 1 hour, causing application errors. The team has verified that the credentials are not being explicitly revoked. Which action should the Vault administrator take to resolve this issue?

A.Extend the TTL of the token used to generate credentials.

B.Update the database role's default_lease_ttl to 24 hours.

C.Increase the database engine's max_lease_ttl to 48 hours.

D.Instruct the team to renew the lease every 30 minutes.

AnswerB

The default_lease_ttl controls the initial lease duration; increasing it to match the max prevents early expiration.

Why this answer

The issue is that the credentials are expiring after 1 hour, which is the default value for `default_lease_ttl` in Vault database roles. Even though the `max_lease_ttl` is set to 24 hours, the actual lease duration for each credential is determined by the `default_lease_ttl` unless it is explicitly configured. By setting `default_lease_ttl` to 24 hours, the administrator ensures that each generated credential has a lease duration matching the maximum allowed, preventing premature expiration.

Exam trap

The trap here is that candidates assume setting `max_lease_ttl` alone controls the credential lifetime, but the actual lease duration is governed by `default_lease_ttl` unless explicitly configured.

How to eliminate wrong answers

Option A is wrong because extending the TTL of the token used to generate credentials does not affect the lease TTL of the dynamically generated database credentials; token TTL and credential lease TTL are independent. Option C is wrong because increasing the database engine's `max_lease_ttl` to 48 hours does not change the fact that the `default_lease_ttl` is still 1 hour; the credentials would still expire after 1 hour unless the role's `default_lease_ttl` is updated. Option D is wrong because instructing the team to renew the lease every 30 minutes is a workaround, not a resolution; the proper fix is to adjust the role's `default_lease_ttl` to match the desired lease duration.

Full explanation →

112

MCQmedium

A Vault administrator has enabled the PKI secrets engine and configured a root CA. They now need to issue certificates for multiple internal services, each with its own common name (CN). Which is the most efficient way to issue certificates while maintaining security?

A.Create a separate role for each service with specific allowed domains

B.Create one role with the allow_any_name parameter set to true

C.Create one role with a wildcard allowed domain and use the common_name parameter when issuing

D.Create one role without any allowed domains and specify the common name in the request

AnswerA

This enforces least privilege for each service.

Why this answer

Creating a separate role for each service allows you to enforce least-privilege by restricting each role to specific allowed domains (e.g., via `allowed_domains` and `allow_subdomains`). This ensures that each service can only request certificates for its own CN, preventing cross-service impersonation while maintaining efficient, role-based issuance. The PKI secrets engine uses roles to define TTL, key type, and domain constraints, making per-service roles the most secure and manageable approach.

Exam trap

The trap here is that candidates assume a single wildcard role is more efficient, but they overlook that Vault's role-based access control (RBAC) and domain restrictions are designed for granularity, and that `allow_any_name` or missing allowed domains create security holes or request failures.

How to eliminate wrong answers

Option B is wrong because setting `allow_any_name` to true removes all domain restrictions, allowing any CN to be issued from a single role, which violates security best practices and could lead to unauthorized certificate generation. Option C is wrong because a wildcard allowed domain (e.g., `*.example.com`) would allow any subdomain under that domain, but it does not restrict the CN to a specific service; additionally, the `common_name` parameter in the issue request must still match the allowed domain, so it does not provide per-service isolation. Option D is wrong because creating a role without any allowed domains (i.e., `allowed_domains` empty) will cause the issue request to fail unless `allow_any_name` is true, as Vault requires at least one allowed domain or the wildcard flag to validate the CN.

Full explanation →

113

MCQeasy

Refer to the exhibit. A token has this policy. Which action can the token perform?

A.Update a secret at "secret/data/engineering/config"

B.Read a secret at "secret/data/engineering/db-pass"

C.List secrets at "secret/data/finance/"

D.Delete a secret at "secret/data/finance/budget"

AnswerB

The policy allows read on engineering/*.

Why this answer

The token's policy grants 'read' capability on 'secret/data/engineering/*' via the 'data' path. Since 'secret/data/engineering/db-pass' falls under that wildcard, the token can read it. The policy does not allow 'update', 'list', or 'delete' actions on the specified paths.

Exam trap

A common misconception is that a wildcard path like 'secret/data/engineering/*' implies all capabilities (create, read, update, delete, list) on that path, when in fact only the explicitly listed capabilities are allowed.

How to eliminate wrong answers

Option A is wrong because the policy only grants 'read' capability on 'secret/data/engineering/*', not 'update' or 'create' (which require 'create' or 'update' capabilities). Option C is wrong because listing secrets at 'secret/data/finance/' requires 'list' capability on that path, which the policy does not grant. Option D is wrong because deleting a secret at 'secret/data/finance/budget' requires 'delete' capability on that path, which the policy does not grant.

Full explanation →

114

Multi-Selecthard

An operator needs to perform token lifecycle operations. Which THREE API endpoints are valid for token-related actions?

Select 3 answers

A.PUT /v1/auth/token/roles

B.POST /v1/auth/token/renew

C.DELETE /v1/auth/token/revoke

D.POST /v1/auth/token/create

E.GET /v1/auth/token/lookup

AnswersB, D, E

Correct. POST /v1/auth/token/renew is the standard call to extend a token's TTL, a core lifecycle operation.

Why this answer

The `POST /v1/auth/token/renew` endpoint is the standard Vault API call to extend the Time-To-Live (TTL) of an existing token, which is a core token lifecycle operation. This endpoint accepts the token to renew in the request body and returns a new lease duration, adhering to Vault's token management design.

Exam trap

HashiCorp often tests the misconception that token revocation uses a DELETE HTTP method, but Vault's API consistently uses POST for all token lifecycle mutations, including revoke, renew, and create, to align with its idempotency and security design.

Full explanation →

115

MCQhard

A financial services company runs a mixed environment of on-premises and cloud workloads. They use Vault Enterprise with performance replication across two data centers: primary in us-east and secondary in eu-west. The secrets engine configuration includes KV v2 for static secrets, database engine for PostgreSQL credentials, and transit for encryption. Recently, the operations team noticed that after a network partition between the data centers, the secondary cluster stopped serving read requests for database credentials, although other secrets like KV v2 were still accessible. The team confirmed that the replication status shows 'secondary' and the cluster is healthy. The Vault configuration uses a single replication path filter that includes all mounts. What is the most likely reason for the database credentials not being available on the secondary?

A.The replication path filter excludes the database engine mount.

B.The secondary cluster has a network issue preventing it from connecting to the database.

C.The secondary cluster is configured to only serve static secrets.

D.Dynamic secrets are not replicated; the secondary cannot generate credentials if the primary is unreachable.

AnswerD

Performance replication replicates configuration, not leases or dynamic secrets.

Why this answer

In Vault Enterprise, performance replication replicates static data (like KV v2 secrets) but does not replicate dynamic secrets such as database credentials. Dynamic secrets are generated on-demand by the primary cluster; the secondary cluster cannot generate them if the primary is unreachable because it lacks the ability to create new leases or credentials. This is why database credentials were unavailable on the secondary after the network partition, while static KV v2 secrets remained accessible.

Exam trap

HashiCorp often tests the misconception that all secrets engines behave identically under replication, but the trap here is that dynamic secrets require primary availability for generation, unlike static secrets which are fully replicated and available on secondaries.

How to eliminate wrong answers

Option A is wrong because the replication path filter includes all mounts, so the database engine mount is not excluded. Option B is wrong because the secondary cluster is healthy and serving other secrets, indicating no network issue to the database itself; the problem is with credential generation, not connectivity. Option C is wrong because the secondary cluster is not configured to serve only static secrets; it can serve all replicated data, but dynamic secrets require primary reachability for generation.

Full explanation →

116

Multi-Selectmedium

Which TWO of the following are valid authentication methods in HashiCorp Vault? (Choose two.)

Select 2 answers

A.GitHub

B.SAML

C.RADIUS

D.Cloud Foundry

E.SSH

AnswersA, D

GitHub is a valid auth method.

Why this answer

GitHub is a valid authentication method in HashiCorp Vault. It allows users to authenticate using their GitHub personal access tokens, which are mapped to Vault policies based on the user's team membership in a specified GitHub organization. This method is commonly used for integrating Vault with existing GitHub workflows.

Exam trap

HashiCorp often tests the distinction between authentication methods (how you prove identity to Vault) and secrets engines (how Vault generates or stores secrets), leading candidates to mistakenly select SSH or other secrets-engine-related options as authentication methods.

Full explanation →

117

MCQhard

During a security assessment, a penetration tester discovers that Vault's seal configuration uses a single master key stored in a file on the server. The attacker gains root access to the server and retrieves the unseal key. What is the best mitigation to prevent this scenario?

A.Restrict network access to the Vault server with a firewall

B.Use a cloud auto-unseal mechanism such as AWS KMS

C.Use Shamir's secret sharing to split the key across multiple files

D.Encrypt the unseal key file with a strong password

AnswerB

Auto-unseal with KMS stores the master key in KMS, not on the server, requiring additional cloud credentials to retrieve.

Why this answer

Cloud auto-unseal mechanisms like AWS KMS decouple the unseal key from the Vault server itself. Instead of storing the master key on the local filesystem, Vault uses a cloud-based key management service (KMS) to wrap and unwrap the master key. Even if an attacker gains root access to the server, they cannot retrieve the unseal key because it is never stored locally; Vault must call the KMS API (with appropriate IAM credentials) to unseal, and those credentials can be further protected with instance profiles or roles.

Exam trap

HashiCorp often tests the misconception that Shamir's secret sharing is a sufficient standalone protection, but the trap here is that storing all shares on the same server negates its security benefit, as a root attacker can simply collect all shares from the filesystem.

How to eliminate wrong answers

Option A is wrong because restricting network access with a firewall does not prevent an attacker who already has root access to the server from reading the unseal key file; the key is still stored locally and accessible. Option C is wrong because Shamir's secret sharing splits the key into multiple shares, but if all shares are stored on the same server (e.g., in separate files), an attacker with root access can retrieve all of them and reconstruct the key. Option D is wrong because encrypting the unseal key file with a password only shifts the problem; the password must also be stored somewhere (e.g., in a script or environment variable) and can be extracted by an attacker with root access, making it a weak mitigation.

Full explanation →

118

MCQeasy

After migrating from an older version of Vault, the operator wants to replace the deprecated 'generic' secrets engine with a modern alternative. Which secrets engine should be used to store static key-value pairs?

A.KV v2 secrets engine

B.AWS secrets engine

C.Database secrets engine

D.Transit secrets engine

AnswerA

KV v2 is the current standard for static secrets storage, with versioning and delete protection.

Why this answer

The KV v2 secrets engine is the modern replacement for the deprecated 'generic' secrets engine in Vault. It stores static key-value pairs with added features such as versioning, configurable delete and destroy behaviors, and check-and-set operations, making it the correct choice for this use case.

Exam trap

HashiCorp often tests the misconception that the 'generic' secrets engine is still valid or that any secrets engine can store static key-value pairs, leading candidates to overlook the specific deprecation and the KV v2 replacement.

How to eliminate wrong answers

Option B is wrong because the AWS secrets engine dynamically generates AWS IAM credentials or STS tokens, not static key-value pairs. Option C is wrong because the Database secrets engine dynamically generates short-lived database credentials, not static key-value pairs. Option D is wrong because the Transit secrets engine performs encryption/decryption operations on data in transit and does not store key-value pairs.

Full explanation →

119

MCQhard

A company uses Vault Enterprise with Performance Replication. The primary cluster is in us-east-1, and a secondary cluster is in eu-west-1. Clients in eu-west-1 report that they receive stale data when reading from the local secondary cluster's active node. What is the most likely cause?

A.The secondary cluster has not enabled performance standby.

B.The replication filter is excluding certain paths.

C.The cluster is in 'primary_failover' mode.

D.The secondary cluster is in primary state instead of secondary.

AnswerB

If paths are excluded from replication, the secondary will not see updates, leading to stale data.

Why this answer

In Vault Enterprise Performance Replication, replication filters can be configured to exclude specific paths (e.g., secret engines or policies) from being replicated to secondary clusters. If a filter excludes certain paths, the secondary cluster will not receive updates for those paths, causing clients reading from the local secondary to see stale or missing data. This matches the symptom of stale reads on the secondary's active node.

Exam trap

HashiCorp often tests the misconception that stale data on a secondary is always due to network latency or cluster failover issues, when in fact replication filters are a deliberate configuration that can cause selective staleness.

How to eliminate wrong answers

Option A is wrong because performance standby nodes are used for read scalability within a cluster, not for replication between clusters; disabling them would affect read load distribution, not cause stale data from replication. Option C is wrong because 'primary_failover' mode is not a valid Vault cluster state; the correct term is 'performance standby' or 'disaster recovery' mode, and this mode would not cause stale reads on a properly configured secondary. Option D is wrong because if the secondary cluster were in primary state, it would not be receiving replicated data at all, leading to completely missing data rather than stale data, and clients would likely get errors or no data.

Full explanation →

120

Multi-Selecthard

Which THREE of the following are true regarding Vault's high availability (HA) and replication? (Choose three.)

Select 3 answers

A.With Integrated Storage, all nodes can handle write requests

B.In an HA cluster with Integrated Storage, only the active node can serve write requests

C.Performance standby nodes can serve read requests without forwarding

D.Performance Replication replicates mounts and auth methods but not policies

E.Disaster Recovery Replication replicates everything including policies and audit logs

AnswersB, C, D

Standby nodes forward writes to the active node; only the active node handles writes.

Why this answer

In an HA cluster with Integrated Storage (Raft), only the active node can serve write requests because Raft ensures strong consistency by requiring all writes to go through the elected leader. The leader replicates the write to a quorum of follower nodes before acknowledging the client, preventing split-brain scenarios. This is a fundamental property of the Raft consensus protocol used by Vault Integrated Storage.

Exam trap

HashiCorp often tests the distinction between Performance Replication and DR Replication, specifically that DR Replication does replicate policies but NOT audit logs, while Performance Replication replicates mounts and auth methods but NOT policies.

Full explanation →

121

MCQhard

A security team needs to automate the rotation of a database password stored in Vault. The password is currently written as a static secret at 'database/creds/prod'. They want to use the Vault API to read and rewrite the secret, ensuring that the previous version is preserved for audit. The script must handle the case where the secret path may not exist. Which approach should they use?

A.Use POST to write a new version at the secret path, which automatically preserves previous versions

B.Use GET on the secret path, then PUT with the new data including the old version's data

C.Use DELETE to remove the old secret, then POST to create a new one

D.Use PUT to write the new password directly, then use GET to verify

AnswerA

POST is the correct method to create a new version in KV v2, preserving history.

Why this answer

Vault's KV Secrets Engine (version 2) uses POST to create a new version of a secret at a given path, automatically preserving previous versions for audit. This approach ensures the password is rotated without data loss, and the API handles non-existent paths by creating the secret if it does not exist, satisfying the requirement to handle missing paths gracefully.

Exam trap

A common misconception is that PUT is the standard write operation in Vault, but in KV v2, POST is used to create new versions while preserving history, whereas PUT overwrites the entire secret and destroys previous versions unless using advanced features like `cas` (check-and-set).

How to eliminate wrong answers

Option B is wrong because using GET then PUT with old version data is unnecessary and error-prone; PUT in KV v2 overwrites the secret entirely (destroying previous versions) unless you explicitly use the `check-and-set` parameter, and it does not automatically preserve history. Option C is wrong because DELETE in KV v2 deletes the latest version (or all versions if using `delete` with metadata), which would lose the audit trail, and then POST creates a new secret without preserving the old one. Option D is wrong because PUT writes the new password directly, which overwrites the secret and destroys previous versions (unless using KV v1, which has no versioning), and the subsequent GET only verifies the current value, not preserving history.

Full explanation →

122

MCQhard

A DevOps engineer configures the AWS secrets engine to assume a specific IAM role for generating dynamic credentials. The engine is enabled and the root configuration is set. Which parameter is essential in the role configuration to allow assuming the IAM role?

A.role_type

B.credential_type

C.inline_policy

D.arn

AnswerD

The 'arn' parameter specifies the full Amazon Resource Name of the IAM role to assume.

Why this answer

The `arn` parameter is essential in the role configuration for the AWS secrets engine because it specifies the Amazon Resource Name (ARN) of the IAM role that Vault will assume to generate dynamic credentials. Without this parameter, Vault cannot identify which IAM role to assume via AWS STS AssumeRole API, making dynamic credential generation impossible.

Exam trap

HashiCorp often tests the misconception that `credential_type` (Option B) is the essential parameter for assuming a role, but it only defines the credential generation method, not the target role ARN, which is the actual requirement for the AssumeRole operation.

How to eliminate wrong answers

Option A is wrong because `role_type` is not a valid parameter in the AWS secrets engine role configuration; the engine uses the `credential_type` parameter to define whether credentials are IAM users or STS-based, but `role_type` does not exist. Option B is wrong because `credential_type` defines the type of credential (e.g., `iam_user` or `assumed_role`) but does not specify which IAM role to assume; it is a separate configuration parameter. Option C is wrong because `inline_policy` is used to attach an inline policy to the generated IAM user credentials, not to specify the IAM role to assume; it is optional and unrelated to the AssumeRole action.

Full explanation →

123

MCQeasy

A DevOps team needs to encrypt sensitive configuration data before storing it in a version control system. They want to use Vault's encryption as a service to encrypt the data using a named encryption key. Which Vault path should they use to perform the encryption?

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

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

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

D.POST /v1/transit/random

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

AnswerA

The encryption endpoint is /encrypt under the transit engine path, providing encryption as a service.

Why this answer

The correct path for encrypting data using Vault's encryption-as-a-service is POST /v1/transit/encrypt/my-key. The Transit secrets engine provides encryption as a service, and the /encrypt endpoint is specifically designed to encrypt plaintext data using a named encryption key. The key name 'my-key' in the path identifies which key in the Transit engine should be used for the encryption operation.

Exam trap

HashiCorp often tests the distinction between encryption (/encrypt), signing (/sign), and HMAC (/hmac) endpoints, and candidates frequently confuse the purpose of /encrypt with /sign or /hmac because all three involve cryptographic operations on data.

How to eliminate wrong answers

Option B is wrong because POST /v1/transit/sign/my-key is used for cryptographic signing (creating digital signatures), not encryption. Option C is wrong because POST /v1/transit/hmac/my-key is used to generate an HMAC hash for data integrity verification, not encryption. Option D is wrong because POST /v1/transit/random generates random bytes from the Vault's entropy source, not encryption of user-provided data.

Option E is wrong because POST /v1/transit/decrypt/my-key is the decryption endpoint, which reverses the encryption operation but does not perform encryption itself.

Full explanation →

124

MCQmedium

Refer to the exhibit. A user deletes the current version of 'secret/myapp' using 'vault kv delete secret/myapp'. What happens to the version?

A.It is destroyed because cas_required is true

B.It is deleted and can be undeleted if not destroyed

C.It is permanently deleted immediately

D.It is marked as deleted but can be undeleted because cas_required is true

AnswerB

Soft delete allows undelete unless destroyed.

Why this answer

With default delete_version_after=0s and max_versions=0, deleting a version marks it as deleted but does not destroy it. The version can be undeleted. The cas_required setting affects write operations, not delete.

Permanent destruction requires a separate 'destroy' command or automatic cleanup if delete_version_after is set.

Full explanation →

125

MCQeasy

Refer to the exhibit. A developer reports that they cannot read secrets under 'secret/data/kv-v2/engineering/db-pass' using a token that has the above policy attached. What is the most likely cause?

A.The policy requires the 'sudo' capability for reading secrets.

B.The secret does not exist because the path is incorrect.

C.The token does not have the policy attached.

D.The path uses a glob that does not match the exact secret path.

AnswerC

The policy itself looks correct; the most likely cause is that the token was not assigned this policy.

Why this answer

The policy shown in the exhibit defines a path with a glob pattern (`secret/data/kv-v2/engineering/*`), which matches the secret path `secret/data/kv-v2/engineering/db-pass`. However, the developer reports they cannot read the secret, indicating the token likely does not have this policy attached. In Vault, a token must have a policy explicitly attached to it; merely having the policy defined in Vault does not grant permissions unless the token is associated with that policy.

Exam trap

HashiCorp often tests the misconception that a policy defined in Vault automatically applies to all tokens, when in fact a token must have the policy explicitly attached via a token role, identity group, or direct token creation.

How to eliminate wrong answers

Option A is wrong because the `sudo` capability is not required for reading secrets; `sudo` is used for privileged operations like modifying policies or enabling auth methods, not for standard read operations on KV v2 secrets. Option B is wrong because the path `secret/data/kv-v2/engineering/db-pass` is correctly formed for KV v2 (the `data/` prefix is mandatory), and the glob `secret/data/kv-v2/engineering/*` matches this exact path, so the secret path is valid. Option D is wrong because the glob `*` matches any single path segment, including `db-pass`, so it does match the exact secret path; the issue is not with the glob pattern.

Full explanation →

126

MCQmedium

An organization previously used userpass auth and is migrating to LDAP auth. After enabling LDAP and configuring the bind user, users can authenticate but their policies do not apply. What is the most likely cause?

A.The bind credentials are incorrect

B.The userpass auth method is still enabled

C.LDAP groups are not mapped to Vault policies

D.The LDAP server is unreachable

AnswerC

Users authenticate but need group-policy mapping to have permissions.

Why this answer

When users can authenticate but policies do not apply, it indicates that authentication itself is working (LDAP bind succeeded), but Vault has no way to associate the authenticated user with the correct policies. In Vault, LDAP authentication relies on group membership mapping: the LDAP server returns the user's groups, and Vault must have those groups mapped to Vault policies via `vault write auth/ldap/groups/<group_name> policies=<policy_name>`. Without this mapping, the user authenticates but receives no policies, resulting in an empty token with no permissions.

Exam trap

The trap here is that candidates assume successful authentication automatically grants permissions, but in Vault, authentication and authorization are decoupled — LDAP only verifies identity, and group-to-policy mapping is a separate configuration step that is easy to overlook.

How to eliminate wrong answers

Option A is wrong because incorrect bind credentials would prevent authentication entirely, not allow successful authentication without policies. Option B is wrong because having the userpass auth method still enabled does not interfere with LDAP authentication or policy application; multiple auth methods can coexist, and the user is authenticating via LDAP. Option D is wrong because if the LDAP server were unreachable, authentication would fail with a connection error, not succeed without policies.

Full explanation →

127

Multi-Selectmedium

An administrator is configuring the Transit secrets engine for encryption as a service. Which TWO configuration options are valid?

Select 2 answers

A.Using the engine to generate one-time passwords

B.Configuring the engine to export the key in plaintext

C.Enabling automatic key derivation per context

D.Setting the encryption key rotation period

E.Setting a TTL on the key itself

AnswersC, D

You can enable derived keys so that each context gets a unique encryption key.

Why this answer

The Transit secrets engine supports key derivation, which allows a base key to be combined with a user-supplied context value to generate a unique encryption key per context. This enables multiple parties to use the same base key while deriving distinct keys for different data sets, enhancing security without managing separate keys. Option D is correct because the Transit engine allows administrators to set a rotation period for encryption keys, automatically rotating the key after a specified interval to comply with cryptographic best practices.

Exam trap

HashiCorp often tests the distinction between key rotation (which is supported) and key TTL (which is not), leading candidates to incorrectly assume that keys have an expiration time like tokens or leases.

Full explanation →

128

Multi-Selectmedium

Which TWO of the following are components of Vault's architecture? (Choose two.)

Select 2 answers

A.Senlin

B.Consul Template

C.Vault Agent

D.Barrier

E.Seal

AnswersD, E

The barrier encrypts all data written to storage.

Why this answer

The Barrier and Seal are fundamental components of Vault's architecture. The Barrier is an encryption layer that protects all data written to storage by encrypting it with a master key before it is persisted. The Seal is the mechanism that wraps the master key, requiring an unseal process (using Shamir's Secret Sharing or an external key service like AWS KMS) to decrypt the master key and make Vault operational.

Exam trap

HashiCorp often tests the distinction between core architectural components (Barrier, Seal) and auxiliary tools (Vault Agent, Consul Template) or unrelated technologies (Senlin), expecting candidates to recognize that only the Barrier and Seal are integral to Vault's internal data protection and unsealing workflow.

Full explanation →

129

MCQeasy

Which Vault CLI command is used to authenticate a user with a username and password to the userpass auth method?

A.vault login -method=userpass username=alice password=secret

B.vault auth userpass username=alice password=secret

C.vault token create -policy=userpass

D.vault authenticate userpass username=alice password=secret

AnswerA

This authenticates using the userpass method with provided credentials.

Why this answer

`vault login -method=userpass` is the standard Vault CLI command to authenticate against the userpass auth method, passing the username and password as parameters. This command triggers the login endpoint (`/v1/auth/userpass/login/:username`) and returns a client token upon successful authentication.

Exam trap

HashiCorp often tests the exact CLI syntax, and the trap here is that candidates confuse `vault login` with non-existent commands like `vault auth` or `vault authenticate`, or misuse `vault token create` which is for generating tokens from an existing token, not for initial authentication.

How to eliminate wrong answers

Option B is wrong because `vault auth` is not a valid Vault CLI command; the correct subcommand for authentication is `vault login`. Option C is wrong because `vault token create -policy=userpass` creates a new token associated with a policy named 'userpass', not authenticating with a username and password. Option D is wrong because `vault authenticate` is not a valid Vault CLI command; the correct verb is `login`.

Full explanation →

130

MCQhard

After a failover event in a Vault HA cluster with Integrated Storage, the new active node reports a 'sealed' status incorrectly in monitoring metrics, but the cluster is still functioning correctly. What is the most likely cause?

A.Inconsistent seal configuration across nodes.

B.The new active node is actually a standby.

C.The Vault token used for monitoring has expired.

D.The storage backend is corrupted.

AnswerA

If seal blocks differ, nodes may report different seal statuses even when the cluster is healthy.

Why this answer

When a Vault HA cluster with Integrated Storage experiences a failover, the new active node must have a seal configuration that matches the cluster's unseal mechanism. If the seal configuration (e.g., Shamir threshold, auto-unseal KMS key, or transit engine path) is inconsistent across nodes, the new active node may report as 'sealed' in monitoring metrics even though the cluster is functional. This happens because the monitoring endpoint reads the node's local seal status, which can differ from the actual cluster state if the node cannot properly verify its own unseal state due to misconfiguration.

Exam trap

The trap here is that candidates assume a 'sealed' status always means the cluster is down or unavailable, but HashiCorp Vault tests the nuance that monitoring metrics can reflect a node-level seal state that is inconsistent with the cluster's actual operational status due to configuration drift.

How to eliminate wrong answers

Option B is wrong because if the new active node were actually a standby, the cluster would not be functioning correctly—standby nodes do not serve requests, and the monitoring metrics would show a standby status, not a 'sealed' status. Option C is wrong because an expired Vault token used for monitoring would cause authentication failures or empty responses, not a false 'sealed' status in the metrics; the seal status is derived from the node's internal state, not token validity. Option D is wrong because a corrupted storage backend would prevent the cluster from functioning correctly—reads and writes would fail, and the node would likely crash or enter a recovery state, not simply report a false 'sealed' status while the cluster remains operational.

Full explanation →

131

Matchingmedium

Match each Vault seal type to its description.

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

Concepts

Matches

Split key into shares

Use AWS Key Management Service

Use Azure Key Vault

Use Google Cloud KMS

Use hardware security module

Why these pairings

The correct matches are: Shamir seal uses secret sharing; AWS KMS seal uses AWS KMS; HSM seal uses a hardware module. Common confusions involve swapping cloud-based seals with Shamir or HSM.

Full explanation →

132

MCQmedium

A company is deploying Vault in a high-availability configuration across three data centers. They need to ensure that if the active Vault node fails, another node can take over without manual intervention. Which Vault feature should they configure?

A.Configure Vault with a highly available storage backend such as Raft and enable automatic leader election.

B.Enable performance standby nodes.

C.Use a load balancer with health checks to redirect traffic.

D.Set up Disaster Recovery (DR) replication between data centers.

AnswerA

Vault HA with Raft automatically elects a new leader if the active node fails.

Why this answer

Vault's integrated Raft storage backend supports automatic leader election via the Raft consensus protocol. When the active node fails, the remaining nodes automatically hold an election to select a new leader, ensuring high availability without manual intervention. This is the native HA mechanism for Vault when using Raft as the storage backend.

Exam trap

HashiCorp often tests the distinction between automatic leader election (Raft HA) and manual failover mechanisms (DR replication), leading candidates to mistakenly choose DR replication for intra-cluster high availability.

How to eliminate wrong answers

Option B is wrong because performance standby nodes are designed to handle read requests and offload work from the active node, but they do not automatically take over as the new leader if the active node fails; leader election is required for write operations. Option C is wrong because a load balancer with health checks can redirect traffic away from a failed node, but it cannot elect a new leader or handle Vault's internal state replication; it only manages network traffic distribution. Option D is wrong because Disaster Recovery (DR) replication is intended for cross-datacenter failover and requires manual promotion of the DR secondary to become the primary; it does not provide automatic leader election within a single cluster.

Full explanation →

133

MCQhard

An administrator enables the database secrets engine for PostgreSQL. After configuring the connection, running `vault write database/config/someconfig` yields error: 'x509: certificate signed by unknown authority'. What is the most likely cause?

A.The connection string is incorrect

B.The PostgreSQL server's TLS certificate is not trusted by Vault's CA bundle

C.The database engine is not enabled

D.The Vault server's TLS certificate is self-signed

AnswerB

Vault must trust the database server's certificate; otherwise x509 error occurs.

Why this answer

The error 'x509: certificate signed by unknown authority' indicates that Vault, when connecting to the PostgreSQL database, received a TLS certificate from the server that was not signed by any Certificate Authority (CA) present in Vault's trusted CA bundle. Vault uses its system's CA pool or a custom CA bundle configured in the connection string to verify the database server's certificate. If the PostgreSQL server uses a self-signed certificate or one issued by an internal CA not trusted by Vault, this error occurs.

Option B correctly identifies that the PostgreSQL server's TLS certificate is not trusted by Vault's CA bundle.

Exam trap

HashiCorp often tests the distinction between TLS errors related to the target server's certificate (outbound connection) versus the Vault server's own certificate (inbound connection), causing candidates to confuse the direction of the TLS handshake.

How to eliminate wrong answers

Option A is wrong because an incorrect connection string typically results in a connection timeout, refused connection, or authentication failure, not an x509 certificate validation error. Option C is wrong because if the database engine were not enabled, the `vault write` command would fail with a 'path not found' or 'no handler' error, not a TLS certificate error. Option D is wrong because the error refers to the PostgreSQL server's certificate not being trusted, not Vault's own TLS certificate; Vault's server certificate is used for client-facing HTTPS, not for outbound connections to databases.

Full explanation →

134

MCQeasy

Refer to the exhibit. What is the most likely cause of this error?

A.The token lacks permission.

B.The secret engine was disabled.

C.The lease ID is incorrect.

D.The lease has expired.

AnswerC

An incorrect lease ID will result in 'lease not found'.

Why this answer

The error message indicates that the lease ID provided for the renewal or revocation operation is invalid. In Vault, lease IDs are unique identifiers tied to a specific secret or token lease. If the lease ID is incorrect—due to a typo, truncation, or mismatch—Vault cannot locate the lease, resulting in this error.

Option C correctly identifies this as the most likely cause.

Exam trap

In the HashiCorp Vault exam, a common pitfall is confusing an invalid lease ID with an expired lease. The error message explicitly states the lease ID is incorrect, so candidates should avoid selecting 'lease has expired' when the lease ID itself is malformed or mistyped.

How to eliminate wrong answers

Option A is wrong because a token lacking permission would produce a 'permission denied' or '403 Forbidden' error, not an invalid lease ID error. Option B is wrong because if the secret engine were disabled, Vault would return an error indicating the mount path is not enabled or the engine is unavailable, not a lease ID issue. Option D is wrong because an expired lease would generate a 'lease not found or expired' error, but the error message specifically states the lease ID is invalid, not that it has expired.

Full explanation →

135

MCQeasy

A team wants to store configuration data such as feature flags in Vault. They need to be able to list all keys under a path. Which secrets engine supports listing?

A.Transit

B.KV v1

C.Cubbyhole

D.PKI

AnswerB

KV v1 supports LIST operation on paths.

Why this answer

The KV v1 secrets engine stores key-value pairs and supports listing all keys under a path via the LIST operation (e.g., `vault list secret/`). This is because KV v1 maintains a flat, non-versioned directory structure that allows enumeration of keys. The team's requirement to list all keys under a path is directly satisfied by KV v1's inherent listing capability.

Exam trap

HashiCorp often tests the misconception that Cubbyhole supports listing because it is a key-value store, but Cubbyhole is strictly per-token and does not expose a LIST endpoint, making it unsuitable for team-wide configuration enumeration.

How to eliminate wrong answers

Option A is wrong because Transit is an encryption-as-a-service engine that performs cryptographic operations on data in transit or at rest; it does not store or list configuration data or feature flags. Option C is wrong because Cubbyhole is a per-token private storage engine that only allows the owning token to read/write its own data and does not support listing keys under a path for other tokens or users. Option D is wrong because PKI is a secrets engine for generating and managing X.509 certificates and does not provide a key-value store for configuration data or support listing arbitrary keys.

Full explanation →

136

MCQeasy

A new administrator is tasked with setting up a Vault development environment. They installed Vault and started the server in dev mode. They want to use the CLI to write and read a secret without authentication. They run `vault kv put secret/hello value=world` but get an error: 'Error writing data to secret/data/hello: Error making API request. URL: PUT https://127.0.0.1:8200/v1/secret/data/hello Code: 403. Errors: * permission denied'. What should they do first to resolve this?

A.Use the API directly with curl instead of the CLI

B.Enable the KV secret engine at a different path

C.Change the path to 'secret/hello' without 'data'

D.Login with the root token that was output when the server started

AnswerD

Dev mode starts with a root token that is not automatically set.

Why this answer

Vault dev mode starts with an initial root token displayed in the output. The CLI and API require authentication for all operations, including writing secrets. The error 403 indicates the request lacks a valid token.

Logging in with the root token via `vault login <root-token>` authenticates the CLI session, allowing subsequent `vault kv put` commands to succeed.

Exam trap

HashiCorp often tests the misconception that the CLI can operate without authentication in dev mode, or that the error is due to path syntax rather than missing credentials.

How to eliminate wrong answers

Option A is wrong because using curl directly would still require authentication (a valid token) and would result in the same 403 error without it. Option B is wrong because the KV secret engine is already enabled at the default path `secret/` in dev mode; enabling it at a different path does not resolve the authentication issue. Option C is wrong because the path `secret/hello` is automatically translated to `secret/data/hello` by the CLI for KV v2; changing the path does not bypass authentication.

Full explanation →

137

Multi-Selectmedium

Which TWO methods can be used to revoke a token without knowing the token ID?

Select 2 answers

A.Using the token's role name if it has one.

B.Using `vault token revoke -mode path` on the auth mount.

C.Using the token's policy name.

D.Using the token's creation time.

E.Using the token accessor.

AnswersB, E

This revokes all tokens created by that mount path without needing individual IDs.

Why this answer

`vault token revoke -mode path` allows revocation of all tokens issued by a specific auth mount (e.g., `userpass/` or `ldap/`) without needing individual token IDs. This method uses the mount's accessor path to revoke all tokens associated with that mount, effectively cleaning up tokens in bulk when their IDs are unknown.

Exam trap

The trap here is that candidates confuse the token accessor (a separate, revocable identifier) with the token ID itself, or assume that policy names or roles can be used to target tokens for revocation, when in fact Vault only supports revocation by token ID, accessor, or mount path.

Full explanation →

138

Multi-Selectmedium

Which TWO of the following Vault CLI commands can be used to write data to Vault?

Select 2 answers

A.vault set

B.vault put

C.vault push

D.vault write

E.vault kv put

AnswersD, E

'vault write' is a valid CLI command for writing data to any path, including KV secrets.

Why this answer

`vault write` is the primary Vault CLI command for writing data directly to a specified path, including secrets, policies, or configuration. Option E is correct because `vault kv put` is the dedicated command for writing key-value pairs to the KV secrets engine, which is a common use case for storing secret data.

Exam trap

HashiCorp often tests the distinction between `vault write` and `vault kv put` by including plausible but nonexistent commands like `vault set` or `vault push`, leading candidates to confuse them with common Unix or Git commands.

Full explanation →

139

MCQeasy

An administrator wants to retrieve the value of a secret stored at the path 'kv/secret/mykey' using the Vault CLI. Which command should they use?

A.vault get kv/secret/mykey

B.vault retrieve kv/secret/mykey

C.vault show kv/secret/mykey

D.vault read kv/secret/mykey

AnswerD

'vault read' is the correct command to read a secret.

Why this answer

The correct command to retrieve a secret from Vault's KV secrets engine is `vault read`. This command is used to read data and metadata from a specified path. Option D is correct because `vault read kv/secret/mykey` will retrieve the value stored at that path, assuming the KV engine is mounted at `kv/`.

Exam trap

HashiCorp often tests the exact CLI verb (`read`) versus common but incorrect verbs like `get`, `retrieve`, or `show`, exploiting the fact that candidates may guess based on other tools (e.g., `curl`, `aws s3 cp`) rather than memorizing Vault's specific command set.

How to eliminate wrong answers

Option A is wrong because `vault get` is not a valid Vault CLI command; the correct verb is `read`. Option B is wrong because `vault retrieve` is not a valid Vault CLI command; Vault uses `read` for this operation. Option C is wrong because `vault show` is not a valid Vault CLI command; the command to read a secret is `vault read`.

Full explanation →

140

MCQhard

A Vault administrator wants to ensure that when a parent token is revoked, all child tokens are also automatically revoked. Which option should they use?

A.Use the 'force' parameter when revoking the parent token

B.Revoke the parent token using the 'revoke-orphan' endpoint

C.Set the parent token's orphan property to 'false'

D.Use the 'cascade=true' parameter when revoking the parent token

AnswerD

Cascade revokes all child tokens recursively.

Why this answer

Vault's token revocation system supports a 'cascade' parameter that, when set to 'true', ensures that revoking a parent token also revokes all its child tokens. This is the intended mechanism for hierarchical token cleanup, as child tokens are tracked via the parent token's accessor and are recursively invalidated.

Exam trap

The trap here is that candidates confuse the 'cascade' parameter with the 'force' parameter or mistakenly think that setting an 'orphan' property on a token can retroactively change its parent-child relationship, when in fact orphan status is determined at creation and is immutable.

How to eliminate wrong answers

Option A is wrong because the 'force' parameter in Vault's token revocation API is used to bypass certain checks (e.g., revoking a token that is already expired) and does not affect child token revocation. Option B is wrong because the 'revoke-orphan' endpoint is specifically designed to revoke a token while leaving its child tokens orphaned (i.e., not revoked), which is the opposite of the desired behavior. Option C is wrong because tokens in Vault do not have an 'orphan' property that can be set to 'false'; the orphan status is determined at token creation time via the 'no_parent' flag, and it is immutable after creation.

Full explanation →

141

MCQmedium

Which token type should be used for short-lived credentials that do not need to be renewed?

A.Service tokens

B.Periodic tokens

C.Batch tokens

D.Orphan tokens

AnswerC

Batch tokens are non-renewable and have a limited TTL, suitable for short-lived use.

Why this answer

Batch tokens in HashiCorp Vault are designed for short-lived, non-renewable credentials. They have a fixed Time-to-Live (TTL) and cannot be renewed or revoked individually; once the TTL expires, the token is automatically invalidated. This makes them ideal for batch jobs or one-time tasks where credential renewal is unnecessary.

Exam trap

A common pitfall is confusing periodic tokens (which are renewable) with batch tokens (which are non-renewable), as both can have a short TTL but differ fundamentally in renewal behavior.

How to eliminate wrong answers

Option A is wrong because service tokens are long-lived and can be renewed, making them unsuitable for short-lived credentials that do not need renewal. Option B is wrong because periodic tokens have a renewable TTL and are intended for long-running processes that require periodic re-authentication, not for non-renewable short-lived use. Option D is wrong because orphan tokens are tokens that have lost their parent due to revocation but still function; they are not a token type designed for short-lived or non-renewable credentials.

Full explanation →

142

MCQmedium

An operator runs `vault lease renew -increment=3600 database/creds/readonly/abc123` and gets an error: 'Error renewing lease: Error making API request. URL: PUT https://vault.example.com/v1/sys/leases/renew. Code: 400. Errors: * invalid lease ID'. What is the most likely cause?

A.The lease has already expired and cannot be renewed

B.The increment value is too large and exceeds the maximum TTL

C.The lease ID is incomplete; it should include the full path like 'database/creds/readonly/abc123'

D.The operator does not have permission to renew leases

AnswerC

The lease ID must be the full ID, not just the suffix.

Why this answer

The error 'invalid lease ID' indicates that the lease ID provided to the `vault lease renew` command is malformed or incomplete. In Vault, a lease ID for dynamic secrets like database credentials is a full path that includes the mount point, role name, and a unique UUID (e.g., `database/creds/readonly/abc123/xyz789`). The command only passed `database/creds/readonly/abc123`, which is the role path, not the full lease ID.

The correct lease ID can be retrieved from the initial secret response or via `vault list sys/leases/lookup/database/creds/readonly`.

Exam trap

HashiCorp often tests the distinction between a role path and a lease ID, trapping candidates who assume the role path is the lease ID because it looks similar to the path used in `vault read` commands.

How to eliminate wrong answers

Option A is wrong because if the lease had already expired, the error would typically be 'lease not found' or 'lease expired', not 'invalid lease ID'. Option B is wrong because the increment value of 3600 seconds (1 hour) is within normal bounds and would only cause an error if it exceeded the backend's maximum TTL, which would produce a different error like 'TTL exceeds max TTL'. Option D is wrong because a permission error would return a 403 Forbidden status with an error like 'permission denied', not a 400 Bad Request with 'invalid lease ID'.

Full explanation →

143

MCQmedium

A Vault administrator is configuring Consul as the storage backend. The Consul cluster will span three data centers with low latency links. Which Consul deployment is recommended for Vault to ensure data safety?

A.3 Consul servers across 3 datacenters (1 per DC)

B.3 Consul servers in each datacenter (total 9)

C.3 Consul servers in one datacenter with agents in others

D.5 Consul servers in a single datacenter

AnswerD

A single datacenter setup provides strong consistency and low latency for Vault writes.

Why this answer

Vault requires a strong consistency guarantee for its storage backend, and Consul achieves this via the Raft consensus protocol, which requires a majority of servers to be available. A single datacenter with 5 Consul servers provides the necessary fault tolerance and quorum (3 out of 5) to survive failures while maintaining data safety. Spreading servers across datacenters with low latency links still introduces network partitions and higher latency, which can break Raft's stability and lead to split-brain scenarios or degraded performance.

Exam trap

HashiCorp often tests the misconception that distributing Consul servers across datacenters improves resilience, but in reality, Raft requires low-latency, reliable connectivity between all servers, and spreading them across DCs increases the risk of network partitions that break quorum.

How to eliminate wrong answers

Option A is wrong because 3 Consul servers across 3 datacenters (1 per DC) creates a scenario where a single datacenter failure or network partition can cause loss of quorum (only 2 servers remain, which is not a majority of 3), leading to Vault becoming unavailable or data inconsistency. Option B is wrong because 9 Consul servers (3 per DC) introduces unnecessary complexity and latency; Raft consensus performance degrades with more nodes, and cross-datacenter links, even with low latency, increase the risk of network partitions that can disrupt quorum. Option C is wrong because placing 3 Consul servers in one datacenter with agents in others does not provide data safety; agents do not participate in Raft consensus, so the cluster still relies on a single datacenter for quorum, and a failure of that datacenter causes total data loss.

Full explanation →

144

MCQeasy

What is the purpose of a token's "period" attribute?

A.It is the starting TTL for a periodic token and is refreshed on each renewal.

B.It defines the maximum lifetime of a token.

C.It defines the number of uses before token expires.

D.It is the time after which the token is revoked if not used.

AnswerA

Correct description of period for periodic tokens.

Why this answer

The 'period' attribute in Vault tokens defines the starting TTL (time-to-live) for a periodic token. When a periodic token is renewed, its TTL is reset to this period value, allowing the token to exist indefinitely as long as it is renewed before the period expires. This is distinct from a non-periodic token, which has a fixed maximum TTL that cannot be extended beyond its original lifetime.

Exam trap

The Vault exam often tests the distinction between 'period' and 'explicit_max_ttl' — candidates mistakenly think 'period' sets a maximum lifetime, when in fact it sets a renewable interval that allows indefinite token life if renewed on time.

How to eliminate wrong answers

Option B is wrong because the 'period' attribute does not define the maximum lifetime of a token; that is the role of the 'explicit_max_ttl' attribute or the system's default max TTL. Option C is wrong because Vault tokens do not have a 'number of uses' attribute; token usage is controlled by TTL and renewal policies, not a use count. Option D is wrong because the 'period' attribute does not cause revocation after a period of inactivity; that behavior is associated with the 'explicit_max_ttl' or 'ttl' attributes, and Vault does not automatically revoke tokens based on idle time unless configured with a specific TTL.

Full explanation →

145

MCQmedium

A development team is building a microservices application that needs to encrypt sensitive customer data before storing it in a shared database. They want to minimize changes to their existing code and avoid managing encryption keys themselves. Which Vault feature should they use?

A.Vault's Database secrets engine

B.Vault's PKI secrets engine

C.Vault's Transit secrets engine

D.Vault's Key Management Secrets Engine

AnswerC

Transit engine allows encryption as a service, offloading key management to Vault.

Why this answer

The Transit secrets engine is designed for encryption-as-a-service, allowing applications to encrypt data without exposing encryption keys to the application code. It performs encryption and decryption operations on the Vault server, so the development team can minimize code changes and avoid managing keys themselves.

Exam trap

The trap here is that candidates confuse the Key Management Secrets Engine (KMSE) with encryption-as-a-service, but KMSE only distributes keys to external KMS providers and does not perform server-side encryption operations, which is the core requirement for minimizing code changes.

How to eliminate wrong answers

Option A is wrong because the Database secrets engine is used to dynamically generate database credentials, not to encrypt data. Option B is wrong because the PKI secrets engine generates X.509 certificates for TLS/SSL, not for encrypting arbitrary data. Option D is wrong because the Key Management Secrets Engine (KMSE) distributes encryption keys to external services like AWS KMS or Azure Key Vault, but still requires the application to manage the encryption operations, whereas the Transit secrets engine handles the cryptographic operations server-side.

Full explanation →

146

MCQeasy

Where can you view a list of all active tokens in Vault?

A.There is no way to list all tokens.

B.`vault token list`

C.`vault list auth/token/accessors`

D.Both A and B

AnswerC

This is correct. `vault list auth/token/accessors` lists token accessors, which represent active tokens.

Why this answer

`vault list auth/token/accessors` retrieves token accessors, which are unique identifiers for active tokens. While you cannot directly list tokens for security reasons, listing accessors is the standard way to view active tokens. Option A is false because there is a way to list tokens via their accessors.

Option B is false because `vault token list` is not a valid command. Option D is false because both A and B are not true.

Exam trap

Candidates often believe there is no way to list tokens or that `vault token list` is valid. The actual command is `vault list auth/token/accessors`, which returns accessors, not the tokens themselves.

How to eliminate wrong answers

Option A is wrong because it is actually correct in stating there is no way to list all active tokens (the token values themselves), but the question asks for the correct answer among the options, and since A is part of the correct pair, it is not wrong in isolation. Option B is wrong because `vault token list` is not a valid Vault CLI command; the correct command to list token accessors is `vault list auth/token/accessors`. Option C is wrong because `vault list auth/token/accessors` lists token accessors, not the active tokens themselves, and the question asks for viewing a list of all active tokens, which is not possible.

Full explanation →

147

MCQeasy

A company stores static secrets in Vault and requires that all data is encrypted at rest in the storage backend. Which Vault feature provides this encryption?

A.The storage backend must be configured to encrypt data.

B.The transit secrets engine for encrypting secrets.

C.Vault's storage encryption via the barrier.

D.The storage backend's built-in encryption (e.g., Consul's encryption).

AnswerC

The barrier encrypts all data at rest.

Why this answer

C is correct because Vault's storage encryption is handled by the security barrier, which automatically encrypts all data written to the storage backend using a 256-bit AES-GCM encryption key. This ensures that data is encrypted at rest regardless of the storage backend's own capabilities, meeting the requirement without relying on backend-specific features.

Exam trap

HashiCorp often tests the misconception that storage backend encryption (e.g., Consul's built-in encryption) is required or sufficient, when in fact Vault's barrier provides mandatory encryption at rest that is independent of the backend.

How to eliminate wrong answers

Option A is wrong because the storage backend itself does not need to be configured to encrypt data; Vault's barrier handles encryption transparently, and the backend only stores the encrypted ciphertext. Option B is wrong because the transit secrets engine is used for encrypting application data in transit or at rest outside Vault, not for encrypting Vault's own stored secrets. Option D is wrong because relying on the storage backend's built-in encryption (e.g., Consul's encryption) is optional and not required by Vault; Vault's barrier provides its own encryption layer independent of the backend.

Full explanation →

148

MCQhard

An application is failing to decrypt data using the transit secrets engine. The ciphertext was generated with key 'my-key' version 3, but the engine currently shows key version 5. What is the most likely cause of the failure?

A.The min_decryption_version is set to 4, preventing decryption with version 3

B.The ciphertext was generated by a different transit key

C.The key was rotated, and automatic data re-encryption is required

D.The application is using the wrong encryption algorithm

AnswerA

If min_decryption_version is higher than the ciphertext's key version, decryption is denied.

Why this answer

The transit secrets engine allows configuring a minimum decryption version (`min_decryption_version`) for each key. If this value is set to 4, the engine will refuse to decrypt any ciphertext generated with key version 3, even if version 3 still exists in the key ring. This is the most direct and likely cause of the failure, as the ciphertext was created with version 3 but the engine now enforces a higher minimum version.

Exam trap

HashiCorp often tests the misconception that key rotation automatically invalidates older ciphertext, but the actual mechanism is the `min_decryption_version` setting, which explicitly controls which versions are allowed for decryption.

How to eliminate wrong answers

Option B is wrong because the ciphertext was explicitly generated with key 'my-key', and the failure is tied to version mismatch, not a different key name. Option C is wrong because key rotation does not automatically re-encrypt existing ciphertext; the transit engine never re-encrypts data automatically, and decryption with older versions is allowed unless `min_decryption_version` blocks it. Option D is wrong because the encryption algorithm is set at key creation time and does not change with version bumps; the algorithm remains consistent across versions of the same key.

Full explanation →

149

MCQmedium

An administrator wants to use Vault's authentication method that allows users to log in with their corporate credentials via a federated identity system. The credentials are stored in an external identity provider (IdP) and Vault should not store any passwords. Which authentication method should be configured?

A.LDAP authentication

B.OIDC authentication

C.Userpass authentication

D.Token authentication

AnswerB

Uses external IdP for authentication, no password stored in Vault.

Why this answer

OIDC (OpenID Connect) authentication is the correct choice because it enables federated identity, allowing users to log in with corporate credentials managed by an external IdP (e.g., Azure AD, Okta) without Vault storing any passwords. Vault acts as a relying party, delegating authentication to the IdP and receiving identity tokens, which aligns with the requirement for a passwordless, federated approach.

Exam trap

In HashiCorp Vault, the key distinction is between LDAP (direct authentication against an LDAP directory, where Vault validates credentials) and OIDC (federated authentication where an external IdP handles credential validation). Candidates often confuse LDAP with true federation, but LDAP still requires Vault to verify passwords, whereas OIDC delegates authentication entirely to the IdP.

How to eliminate wrong answers

Option A is wrong because LDAP authentication requires Vault to directly bind to an LDAP directory server and, while it does not store passwords, it does not support federated identity via an external IdP; it relies on direct directory lookups. Option C is wrong because Userpass authentication stores password hashes locally in Vault's backend, contradicting the requirement that Vault should not store any passwords. Option D is wrong because Token authentication is a core Vault mechanism for session management, not an authentication method that integrates with an external IdP or federated identity system.

Full explanation →

150

MCQmedium

A periodic token is created with a TTL of 30 days. After 60 days, the token is still in use but suddenly stops working. What is the most likely reason?

A.The token exceeded its max TTL of 60 days

B.The token reached its default max TTL of 32 days

C.The token's explicit_max_ttl was set to a value less than 60 days

D.The token was revoked manually or by an administrator

AnswerD

Periodic tokens can be revoked at any time; the most likely cause after 60 days is revocation.

Why this answer

The token's TTL (time-to-live) of 30 days determines how long it is valid from its creation or last renewal, but it does not set an absolute maximum lifetime. After 60 days, the token would have been renewed or used periodically, so it should still be valid unless an external action invalidated it. Manual revocation by an administrator or via a revocation endpoint is the most likely cause for a token that was working but suddenly stops, as it overrides any TTL-based expiration.

Exam trap

The exam often tests the distinction between TTL (renewal period) and max TTL (absolute lifetime) for periodic tokens. Candidates may mistakenly assume that a periodic token's TTL alone determines its total lifespan, ignoring that such tokens can be renewed indefinitely unless a max TTL or manual revocation intervenes.

How to eliminate wrong answers

Option A is wrong because a token's TTL does not have a hard max of 60 days; the TTL is 30 days, and periodic renewal can extend its life indefinitely unless a max TTL is explicitly set. Option B is wrong because there is no default max TTL of 32 days in Vault; the default max TTL is typically 32 days only for certain token types like periodic tokens if not explicitly configured, but the question states the token is periodic with a 30-day TTL, and after 60 days it would have been renewed, so a 32-day max would have blocked it earlier. Option C is wrong because if explicit_max_ttl were set to less than 60 days, the token would have expired at that limit, not suddenly stop working after 60 days; the token was still in use until day 60, indicating no max TTL was hit.

Full explanation →

HashiCorp Vault Associate VA-003 (VA-003) — Questions 76–150