Courseiva

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

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

Take a mock examExam hub
Page 1

Page 2 of 7

Page 3
76
MCQeasy

A security team wants to store static secrets like API keys in Vault. They need the secrets to be versioned and support rollback. Which secrets engine should they use?

A.Cubbyhole
B.KV v1
C.Transit
D.KV v2
AnswerD

KV v2 supports versioning and rollback of secrets.

Why this answer

KV v2 is the correct choice because it is designed specifically for storing static secrets with built-in versioning and rollback capabilities. Unlike KV v1, which overwrites data without preserving history, KV v2 retains a configurable number of secret versions, allowing administrators to undelete or roll back to a previous version using the `vault kv rollback` command or API calls.

Exam trap

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

How to eliminate wrong answers

Option A is wrong because Cubbyhole is a per-token secrets engine that stores secrets scoped to a single token's lifetime and does not support versioning or rollback. Option B is wrong because KV v1 stores secrets without versioning; each write overwrites the previous value, making rollback impossible. Option C is wrong because Transit is a cryptographic engine for encryption/decryption operations on data in transit or at rest, not for storing static secrets with versioning.

Full explanation →
77
MCQmedium

A Vault cluster with three nodes using Integrated Storage (Raft) is healthy with one active and two standby nodes. A network partition isolates the active node. What will happen?

A.The two standby nodes will seal themselves.
B.The two standby nodes remain in standby state.
C.The two standby nodes elect a new leader and continue writing.
D.The cluster becomes read-only until the active node rejoins.
AnswerC

With a majority, the nodes can elect a new leader and the cluster remains writable.

Why this answer

In a Vault cluster with Integrated Storage (Raft), a majority of nodes (quorum) is required to maintain leadership and process write operations. When the active node is isolated, the two remaining standby nodes still constitute a majority (2 out of 3). They will hold a new leader election using the Raft consensus algorithm, elect a new active node, and continue accepting write requests.

The isolated node, upon reconnection, will be treated as a follower and replicate data from the new leader.

Exam trap

HashiCorp often tests the misconception that losing the active node forces the cluster into read-only or standby mode, but the key is understanding that Raft's majority-based quorum allows the remaining nodes to elect a new leader and continue operations.

How to eliminate wrong answers

Option A is wrong because standby nodes do not seal themselves due to a network partition; sealing is a manual or policy-driven action, not an automatic response to loss of connectivity. Option B is wrong because the two standby nodes, forming a majority, will not remain in standby state; they will initiate a leader election and promote one to active. Option D is wrong because the cluster does not become read-only; as long as a majority of nodes can communicate, writes can continue, and the Raft protocol ensures consistency even during partitions.

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

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

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

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

Token revocation only revokes leases; KV v1 secrets are not leased, so previously read data remains accessible.

Why this answer

Option B is correct because KV v1 secrets do not issue leases, so token revocation does not invalidate previously read data. Option A is wrong because root tokens can still be revoked and would not persist after revocation. Option C is wrong because the token policy does not affect revocation behavior.

Option D is wrong because orphan tokens are still subject to revocation.

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

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

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

HashiCorp often tests the misconception that encryption as a service always produces unique ciphertext by default, but the trap here is that Vault's Transit engine uses deterministic encryption unless key derivation or convergent encryption is explicitly configured, so candidates must remember that uniqueness is not guaranteed without additional settings.

Full explanation →
87
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
AnswerB

KMSE generates keys in an external KMS and uses them without exposing the key to clients.

Why this answer

Option B is correct because the Key Management Secrets Engine (KMSE) is specifically designed to allow Vault to act as a key management service (KMS) for external cloud providers like AWS. When configured, the actual encryption key is generated and stored within the AWS KMS service, and Vault only holds a key reference or a key ID. The application never receives the raw encryption key; instead, it requests encryption/decryption operations from Vault, which forwards them to AWS KMS, ensuring the key never leaves the Vault boundary.

Exam trap

HashiCorp often tests the misconception that the Transit Secrets Engine keeps the key hidden from the application, but in reality, Transit allows key export if the policy grants read access, whereas KMSE delegates key management to an external KMS where the key is never exposed to Vault or the application.

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 →
88
MCQhard

A development team is using the Vault transit secrets engine to encrypt sensitive data in their application. They have created a policy that includes: path "transit/keys/*" { capabilities = ["encrypt", "decrypt"] } and attached it to their application tokens. However, when the application calls the '/v1/transit/encrypt/my-key' endpoint, it receives a permission denied error. The key 'my-key' exists in the transit engine. The team has verified that the token is not expired and has the correct policy attached. What is the most likely cause of the error?

A.The policy also needs 'read' capability on 'transit/keys/*'.
B.The encrypt and decrypt capabilities must be applied to the specific encrypt/decrypt paths, not the key metadata path.
C.The application token has expired.
D.The transit engine requires the 'create' capability on the key to perform encryption.
AnswerB

The correct policy should target 'transit/encrypt/my-key' or 'transit/encrypt/*'.

Why this answer

Option B is correct because the encrypt and decrypt operations are performed at the 'transit/encrypt/<key>' and 'transit/decrypt/<key>' endpoints, not at the 'transit/keys/' path which is used for key management (create, read, delete, etc.). The policy must grant the encrypt capability on 'transit/encrypt/my-key' or a wildcard under that path. Option A is not required for encryption.

Option C is not a cause; token expiration was verified. Option D is incorrect; 'create' is not needed for encryption.

Full explanation →
89
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 →
90
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 →
91
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

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

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

Option A is correct because 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 →
96
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 →
97
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 →
98
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 →
99
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. The encryption keys are stored securely within Vault, and applications only interact with the engine via API calls, ensuring that the keys remain protected and never exposed to client memory or logs.

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

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

An administrator notices that after a Vault unseal operation, the root token is no longer usable. The audit logs show no revocations. What is the most likely cause?

A.The root token's TTL expired during unseal
B.The root token was revoked during unseal
C.The root token's policy was removed
D.The root token was stored in memory only and lost on seal
AnswerD

Root tokens are often not persisted; they are lost when Vault seals.

Why this answer

When a Vault node is sealed, all in-memory data, including the root token, is wiped. The root token is not persisted to storage by default; it is only stored in memory after initialization or unseal. If the token was not explicitly persisted (e.g., via a recovery key or a generated token with a storage backend), it is lost upon seal, making it unusable after a subsequent unseal operation.

Exam trap

HashiCorp often tests the misconception that the root token is persisted across seal/unseal cycles, when in fact it is ephemeral and only exists in memory after initialization or unseal.

How to eliminate wrong answers

Option A is wrong because the root token typically has no TTL by default (it is non-expiring unless explicitly set), and the unseal operation does not affect TTL expiration. Option B is wrong because audit logs show no revocations, and the unseal process does not automatically revoke the root token; revocation is an explicit administrative action. Option C is wrong because the root token is associated with the root policy, which cannot be removed or modified; the root policy is built into Vault and is immutable.

Full explanation →
102
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 →
103
MCQmedium

A company is using Vault Transit to encrypt files before uploading them to an S3 bucket. They notice that for a given plaintext file, the ciphertext output is always identical, even when encrypting at different times. They are using the `encrypt` endpoint with the default AES-GCM algorithm. The team is concerned about security because the repeated ciphertext leaks information (e.g., file equality). What is the most likely cause of this behavior?

A.They are using the wrong key
B.They are using a deterministic encryption scheme
C.They are using convergent encryption
D.They are not providing an encryption context
AnswerC

Convergent encryption derives the key from the plaintext, resulting in identical ciphertexts for identical plaintexts.

Why this answer

The correct answer is C because convergent encryption is a deterministic scheme where the encryption key is derived from the hash of the plaintext. When using Vault Transit with the default AES-GCM algorithm, the ciphertext will be identical for the same plaintext if the same key and nonce are used. This behavior matches the scenario described, as convergent encryption is designed to produce identical ciphertexts for identical plaintexts, which leaks file equality information.

Exam trap

HashiCorp often tests the distinction between deterministic encryption (which can be secure with proper nonce management) and convergent encryption (which is inherently deterministic for deduplication), and the trap here is that candidates confuse 'deterministic encryption' (a general property) with 'convergent encryption' (a specific implementation that uses plaintext-derived keys).

How to eliminate wrong answers

Option A is wrong because using the wrong key would result in decryption failure or different ciphertext, not identical ciphertext for the same plaintext. Option B is wrong because deterministic encryption (e.g., AES-SIV) can produce identical ciphertext for the same plaintext and key, but Vault Transit's default AES-GCM is non-deterministic (uses a random nonce), so this is not the cause unless a fixed nonce is explicitly set. Option D is wrong because encryption context is an optional authenticated additional data (AAD) in AWS KMS, not in Vault Transit; omitting it does not cause deterministic ciphertext output.

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

Option C is correct because the first policy statement grants read and list on all secrets under secret/data/engineering/. The other capabilities are restricted to the projects subpath.

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

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

Setting both default_lease_ttl and max_lease_ttl to 1h ensures that secrets are issued with a 1h TTL and cannot be renewed beyond that.

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

Option A is correct because the periodic token's max TTL is determined by the system's 'max_lease_ttl' (24h), and when the token reaches that limit, renewal is impossible even if the token is periodic. Option B is wrong because the token's renewable flag is true; renewal attempts are made but fail due to max TTL. Option C is wrong because the services are correctly configured to renew; the issue is max TTL exhaustion.

Option D is wrong because the token lease duration is not expiring; the tokens are being renewed until they hit max TTL.

Full explanation →
108
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 →
109
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 →
110
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

Option A is correct because 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 →
111
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 →
112
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 →
113
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' means that the entity (user or role) has reached the maximum number of tokens allowed. This is controlled by the 'token_count_limit' parameter in the token role. Option B is wrong because it's not about TTL.

Option C is wrong because the error is about count, not permissions. Option D is wrong because it specifically mentions 'per user'.

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

Option D is correct. The path matches entity IDs. 'list' allows listing all entity IDs, and 'read' allows reading the details of each entity. Option A is too broad (might include aliases).

Option B is partially correct but D is more precise. Option C includes update which is not allowed.

Full explanation →
115
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 →
116
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 default_lease_ttl on the database role is set to 1 hour, which causes credentials to expire before the max_lease_ttl. Adjusting the default_lease_ttl to match the desired lease duration allows credentials to last longer, up to the max_lease_ttl. Option A is correct because it directly addresses the discrepancy between the default and maximum TTLs.

Option B is wrong because the max_lease_ttl is already 24 hours and not the cause. Option C is wrong because renewing does not change the underlying TTL configuration. Option D is wrong because the token TTL does not affect the credential lease TTL.

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

Option A is correct because 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 →
118
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 policy grants read and list on engineering/*, so reading secret/data/engineering/db-pass is allowed. It does not grant delete or list on finance, nor update on engineering.

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

B is correct: renews a token's TTL.

Why this answer

Option B is correct because 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 →
120
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 →
121
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 →
122
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

Option B is correct because 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 →
123
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 →
124
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 →
125
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 →
126
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

Option C is correct because using the POST method on the KV v2 secret path returns the data and version metadata, allowing the script to preserve history. Option A is wrong because PUT would overwrite without preserving previous version if not used with CAS. Option B is wrong because DELETE would remove the secret.

Option D is wrong because the secret engine is KV v2, not v1.

Full explanation →
127
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 →
128
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 →
129
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 →
130
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

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

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

Option A is correct because `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 →
135
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 Cisco 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 →
136
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

These are seal mechanisms for unsealing Vault.

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

Option A is correct because 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 →
138
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 →
139
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 'lease not found' error typically indicates that the lease has expired and been removed from Vault's storage. The lease ID may be incorrect, but if the user copied it correctly, expiration is more common.

Full explanation →
140
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 →
141
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

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

Using the token accessor allows revocation without the token ID, and using `vault token revoke -mode path` on the auth mount revokes all tokens created by that mount path.

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

Option D is correct because `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 →
144
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 →
145
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

Option A is correct. The 'cascade' parameter in the revoke API call causes recursive revocation of all child tokens. Option B is wrong because that would orphan children.

Option C is wrong because setting 'orphan=true' prevents children from being orphaned, but does not revoke them. Option D is wrong because it only applies to the token itself.

Full explanation →
146
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 are non-renewable and lightweight, ideal for short-lived credentials where renewal is unnecessary.

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

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

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

For periodic tokens, the "period" defines the TTL that is refreshed on each renewal. Periodic tokens have no max TTL and can be renewed indefinitely as long as renewal occurs within the period.

Full explanation →
150
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 →
Page 1

Page 2 of 7

Page 3

All pages

1234567

Practice VA-003 by domain

Target a specific domain to shore up weak areas.

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