HashiCorp Vault Associate VA-003 VA-003 Questions 151–225 | Page 3/7

151

MCQhard

An organization uses the AWS secrets engine to generate IAM users dynamically. They notice that the generated IAM user is not immediately available for use in AWS. What is the most likely reason?

A.The Vault write operation failed due to network latency.

B.The TTL on the role is too short.

C.Vault must wait for the AWS secret key to be rotated before returning the user.

D.AWS IAM is eventually consistent and the user may take a few seconds to propagate.

AnswerD

AWS IAM has eventual consistency, causing a short delay.

Why this answer

AWS IAM is an eventually consistent system. When Vault uses the AWS secrets engine to create an IAM user via the CreateUser API call, the user is not immediately available across all AWS services due to propagation delays. This eventual consistency means the generated IAM user may take a few seconds to be fully usable, which is a known behavior of AWS IAM.

Exam trap

The trap here is that candidates may confuse eventual consistency with a Vault-side failure or misconfiguration, such as a short TTL or a write failure, rather than recognizing it as an inherent property of AWS IAM.

How to eliminate wrong answers

Option A is wrong because a Vault write operation failure due to network latency would result in an error response from Vault, not a delayed availability of the IAM user; the user would simply not be created. Option B is wrong because the TTL on the role controls how long the generated credentials are valid, not the time it takes for the IAM user to become available after creation. Option C is wrong because Vault does not wait for AWS secret key rotation before returning the user; the AWS secrets engine creates the IAM user and returns credentials immediately, with propagation delay being an AWS-side behavior.

Full explanation →

152

Drag & Dropmedium

Drag and drop the steps to configure Vault's AWS secrets engine to generate IAM credentials into the correct order.

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence for configuring Vault's AWS secrets engine to generate IAM credentials is: first enable the AWS secrets engine at a path, then configure the root IAM credentials that Vault will use to interact with AWS, then create a role that defines the permissions for generated credentials, then generate the actual IAM credentials using that role, and finally rotate the root credentials to enhance security. This order ensures that each step's prerequisites are met.

Full explanation →

153

MCQhard

A large e-commerce company uses Vault to manage database credentials for microservices. They have a Vault cluster of 5 nodes using Integrated Storage (Raft). To increase capacity, they add a sixth node to the cluster. Shortly after, they notice intermittent 'no leader' errors in the Vault logs, and some clients experience failures when reading secrets. The cluster was functioning correctly before the addition. What is the most likely cause and the recommended action?

A.The cluster now has an even number of nodes, which can cause split-brain scenarios and leader election issues. Recommended action: remove the new node to revert to 5 nodes, or add a seventh node to make it odd.

B.The cluster's Raft protocol requires all nodes to be voters, but the new node is a non-voter. Recommended action: promote the new node to voter.

C.The new node has a different storage performance, causing it to lag behind and not participate in consensus. Recommended action: replace the new node with a faster instance.

D.The new node was not properly joined to the cluster and is running as a standalone server. Recommended action: re-run the join command and ensure the node is part of the cluster.

AnswerA

Raft performs best with an odd number of nodes to avoid split-brain. With 6 nodes, quorum is 4, and a partition could lead to no leader.

Why this answer

The Vault cluster uses Integrated Storage (Raft), which relies on a consensus protocol that requires an odd number of nodes to maintain a quorum. Adding a sixth node creates an even number, increasing the risk of a split-brain scenario where no single group can achieve a majority, leading to 'no leader' errors and client failures. The recommended action is to either remove the new node to revert to 5 nodes or add a seventh node to restore an odd count.

Exam trap

A common misconception is that adding more nodes always improves reliability, but in a Vault Raft cluster an even number of nodes can cause quorum failures, leading to 'no leader' errors, not just performance degradation.

How to eliminate wrong answers

Option B is wrong because the Raft protocol does not require all nodes to be voters; non-voters can participate as read replicas without affecting consensus, and the issue is about the total number of nodes, not voter status. Option C is wrong because storage performance differences would cause replication lag or slow writes, not intermittent 'no leader' errors, and the cluster was functioning before the addition, indicating a configuration issue rather than hardware mismatch. Option D is wrong because if the node were standalone, it would not cause 'no leader' errors across the entire cluster; the logs and client failures point to a quorum problem, not a join failure.

Full explanation →

154

MCQhard

A company wants to grant developers the ability to read and write secrets under the path 'secret/dev/*', but only they should be able to delete their own secrets. Which policy design best meets this requirement?

A.path "secret/dev/*" { capabilities = ["create", "read", "update", "delete", "list"] }

B.path "secret/dev/*" { capabilities = ["read", "list"] }

C.path "secret/dev/+/{{identity.entity.name}}" { capabilities = ["create", "read", "update", "delete"] }

D.path "secret/dev/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "secret/dev/{{identity.entity.name}}/*" { capabilities = ["delete"] }

AnswerD

Correctly grants full access to the dev path, but delete is only allowed on the user's own sub-path using entity name.

Why this answer

It grants full CRUDL access to 'secret/dev/*' for reading and writing, but then restricts delete to only the path 'secret/dev/{{identity.entity.name}}/*', which uses the entity's name to ensure developers can only delete secrets under their own sub-path. This leverages Vault's identity entity name templating to enforce per-developer delete scoping.

Exam trap

HashiCorp often tests the distinction between wildcard '*' (matches any number of segments) and '+' (matches exactly one segment), and the use of identity template variables to scope permissions per entity, which candidates may overlook by choosing a broad delete permission.

How to eliminate wrong answers

Option A is wrong because it grants delete on the entire 'secret/dev/*' path, allowing any developer to delete any secret, violating the requirement that only they should delete their own. Option B is wrong because it only allows read and list, not create, update, or delete, so developers cannot write secrets at all. Option C is wrong because the path pattern 'secret/dev/+/{{identity.entity.name}}' uses a wildcard '+' for a single segment, but the requirement is for secrets under 'secret/dev/*'; also, it grants delete on that specific path but does not allow creating or updating secrets under other sub-paths, and the '+' does not match multi-segment paths.

Full explanation →

155

MCQmedium

When running Vault in development mode, which storage backend is used by default?

A.Raft integrated storage

B.File system backend at /var/lib/vault

C.In-memory backend

D.Consul backend

AnswerC

Dev mode uses an in-memory backend by default.

Why this answer

When Vault is started in development mode using `vault server -dev`, it defaults to an in-memory storage backend. This is explicitly designed for local testing and development, as all data is stored in memory and lost when the process terminates. The in-memory backend requires no configuration and is automatically selected when no `-dev` flag overrides are provided.

Exam trap

HashiCorp often tests the distinction between development mode defaults and production mode defaults, trapping candidates who assume that Raft integrated storage (the production default) is also the development default, or who confuse the file system backend path with a default setting.

How to eliminate wrong answers

Option A is wrong because Raft integrated storage is the default for Vault in production mode (when no storage backend is explicitly configured), but not for development mode; development mode always uses the in-memory backend. Option B is wrong because the file system backend at /var/lib/vault is a common production storage backend but is never the default in development mode; it must be explicitly configured in the Vault configuration file. Option D is wrong because Consul backend is an external storage backend that requires a separate Consul cluster and is never the default in any Vault mode; it must be explicitly specified.

Full explanation →

156

Multi-Selecteasy

A Vault administrator needs to create a policy for a developer who must read and list secrets from the path 'secret/data/engineering/' and create new secrets under 'secret/data/engineering/projects/'. Which two policy statements should the administrator include? (Choose two.)

Select 2 answers

A.path "secret/data/engineering/projects/*" { capabilities = ["create","update"] }

B.path "secret/data/engineering" { capabilities = ["read","list"] }

C.path "secret/data/engineering/projects/*" { capabilities = ["create"] }

D.path "secret/engineering/*" { capabilities = ["read","list"] }

E.path "secret/data/engineering/*" { capabilities = ["read","list"] }

AnswersC, E

Correct: Grants create capability on the projects subpath, fulfilling the create requirement with minimal permissions.

Why this answer

The developer needs to create new secrets under 'secret/data/engineering/projects/', which requires the 'create' capability on that path. Option E is correct because the developer needs to read and list secrets from 'secret/data/engineering/', and the wildcard 'secret/data/engineering/*' covers all paths under that prefix, including the base path itself when using KV v2 (the 'data/' prefix is part of the path).

Exam trap

The VA-003 exam often tests the distinction between KV v1 and KV v2 path structures — the trap here is that candidates forget the mandatory 'data/' prefix in KV v2 paths, leading them to select option D, or they overlook that 'create' alone (without 'update') is sufficient for creating new secrets, causing them to choose the overly permissive option A.

Full explanation →

157

MCQhard

A cloud-native application uses Vault's Kubernetes auth method to inject tokens into pods. Each pod receives a Vault token with a TTL of 1 hour, renewable. The application is designed to renew tokens before they expire. However, after a recent update, some pods are failing to authenticate with Vault, reporting 'token not found' errors. The operations team checks the Vault audit logs and sees that tokens associated with these pods are being revoked immediately after creation. The pods have not performed any revocation. What is the most likely cause?

A.The Kubernetes auth method's 'kubernetes_ca_cert' has expired, causing Vault to invalidate all tokens.

B.The Kubernetes service account that the pod uses has been deleted or its token has been invalidated, causing Vault to revoke derived tokens.

C.The Vault tokens are being created as batch tokens and are immediately revoked due to a misconfiguration.

D.The pods are attempting to renew tokens too frequently, exceeding a rate limit.

AnswerB

Correct: Vault automatically revokes tokens when the underlying identity (service account) is removed or the JWT becomes invalid.

Why this answer

Vault's Kubernetes auth method creates a derived token that is tied to the Kubernetes service account token used during login. If the Kubernetes service account is deleted or its token is invalidated (e.g., due to rotation or expiration), Vault immediately revokes all derived tokens. The audit logs confirm revocation without pod action, and the TTL/renewal design points to an external dependency failure, not a Vault-side issue.

Exam trap

Hashicorp often tests the dependency between Kubernetes service account tokens and Vault-derived tokens, trapping candidates who assume the issue is with Vault's token configuration (TTL, batch, or renewal) rather than the upstream identity source.

How to eliminate wrong answers

Option A is wrong because the 'kubernetes_ca_cert' is used to validate the Kubernetes API server's TLS certificate during auth method configuration; its expiration would prevent new logins entirely, not cause immediate revocation of already-issued tokens. Option C is wrong because batch tokens are non-renewable and have a fixed lifetime, but they are not automatically revoked upon creation; the 'token not found' error and immediate revocation suggest a parent token invalidation, not a batch token misconfiguration. Option D is wrong because Vault does not enforce a rate limit on token renewal that would cause revocation; exceeding a rate limit would result in a 429 HTTP response or throttling, not token revocation.

Full explanation →

158

Matchingmedium

Match each Vault storage backend to its description.

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

Concepts

Matches

Highly available, key-value store

Integrated storage with consensus

Local filesystem storage

AWS object storage

AWS NoSQL database

Why these pairings

Vault supports multiple storage backends. Consul and Integrated Raft are both highly available, while File is for single-node setups. Common confusions include mixing Consul's distributed KV nature with file-based storage or incorrectly attributing external dependencies to Raft.

Full explanation →

159

MCQeasy

A DevOps engineer needs to create a token that can only read secrets under the path 'secret/engineering'. What is the recommended approach?

A.Create a token with a short TTL so it expires quickly

B.Create a token with the default policy only

C.Use the root token and restrict usage with a low TTL

D.Create a policy that allows read on secret/engineering/* and attach it to the token

AnswerD

A custom policy with minimal privileges follows the principle of least privilege.

Why this answer

Vault's recommended approach for granting least-privilege access is to create a policy that explicitly defines the allowed actions and paths, then attach that policy to the token. A policy with `path "secret/engineering/*" { capabilities = ["read"] }` ensures the token can only read secrets under that specific path, adhering to the principle of least privilege.

Exam trap

In Vault exams, a common trap is confusing time-based restrictions with proper policy-based access control. TTL limits duration but does not restrict which paths a token can access; a policy is required for that.

How to eliminate wrong answers

Option A is wrong because a short TTL only limits the token's lifespan, not its permissions; the token could still have excessive privileges (e.g., root or default policy) and read other paths while active. Option B is wrong because the default policy grants broad read access to many paths (like `secret/*`), which would allow reading secrets outside `secret/engineering`. Option C is wrong because using a root token, even with a low TTL, violates security best practices—root tokens have unrestricted superuser access and should never be used for routine operations; a low TTL does not restrict the token's capabilities.

Full explanation →

160

MCQeasy

A user runs 'vault write secret/mydata value=hello' and gets a warning about missing metadata. They intended to store a simple key-value pair. What is the most likely issue?

A.The value must be JSON-encoded.

B.The token lacks write capability on that path.

C.The path is under KV v2 engine, which requires the data/ prefix.

D.The secret engine is not enabled.

AnswerC

Correct. In KV v2, writing directly to the path without the data/ subpath triggers a warning because it expects metadata. Using `vault write secret/data/mydata value=hello` would work correctly.

Why this answer

The warning about missing metadata indicates the path is under a KV v2 secret engine, which requires the `data/` prefix before the path (e.g., `vault write secret/data/mydata value=hello`). KV v2 stores metadata and versioned data separately, so writing directly to `secret/mydata` triggers a warning because it expects the `data/` subpath. This is the most likely issue given the user's intent to store a simple key-value pair.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 path requirements, trapping candidates who assume all key-value engines use the same flat path structure without the `data/` prefix.

How to eliminate wrong answers

Option A is wrong because KV v2 accepts plain string values like `value=hello`; JSON encoding is optional and not required for simple key-value pairs. Option B is wrong because the warning specifically mentions missing metadata, not a permission error; if the token lacked write capability, the command would return a 403 Forbidden error, not a warning. Option D is wrong because if the secret engine were not enabled, the command would fail with an error like 'no secret engine mounted at secret/', not a warning about metadata.

Full explanation →

161

MCQmedium

A company is using Vault's PKI secrets engine to issue certificates for internal services. They have set up a root CA and an intermediate CA. The intermediate CA's certificate expires soon, and they need to renew it. They generate a new intermediate CSR and have it signed by the root CA. After importing the new intermediate certificate, the team notices that certificates issued by the old intermediate are still valid but new certificate requests fail with 'no valid intermediate CA found'. What step did the team likely miss?

A.They forgot to set the new intermediate certificate as the issuing CA by writing it to the correct path (e.g., pki/intermediate/set-signed).

B.They forgot to update the CRL distribution points on the new intermediate.

C.They changed the root CA's key algorithm, causing incompatibility.

D.They did not revoke the old intermediate CA before importing the new one.

AnswerA

After signing the CSR, the signed certificate must be written back to the intermediate mount via set-signed endpoint.

Why this answer

In Vault's PKI secrets engine, after the root CA signs a new intermediate certificate, the signed certificate must be explicitly set as the issuing CA by writing it to the `pki/intermediate/set-signed` endpoint. Without this step, Vault still references the old (expiring) intermediate certificate and cannot sign new ones, resulting in the 'no valid intermediate CA found' error. Simply importing the signed certificate is not sufficient; it must be configured as the active issuing CA.

Option B is incorrect because failing to update CRL distribution points would affect CRL distribution, not cause a 'no valid intermediate CA found' error during certificate issuance.

Exam trap

HashiCorp often tests the specific API workflow of Vault's PKI secrets engine, where candidates confuse the CSR generation and signing process with the final step of importing the signed certificate via `set-signed`, assuming that simply having the signed certificate in the mount path is sufficient.

How to eliminate wrong answers

Option B is wrong because updating CRL distribution points is a configuration detail for certificate revocation, not a prerequisite for the intermediate to be recognized as a valid issuing CA; the immediate failure is due to the missing set-signed step, not CRL endpoints. Option C is wrong because changing the root CA's key algorithm would require re-signing the entire chain and is unrelated to the described renewal process; the question states they generated a new CSR and had it signed by the root CA, implying no algorithm change. Option D is wrong because revoking the old intermediate CA is not required before importing the new one; Vault can have multiple intermediate certificates in the same mount, and the old one remains valid until its expiration — the issue is that the new certificate was not set as the active issuing CA.

Full explanation →

162

MCQeasy

A developer wants to authenticate to Vault using a username and password without any external identity provider. Which authentication method should be enabled?

A.Userpass authentication

B.Token authentication

C.LDAP authentication

D.AppRole authentication

AnswerA

Userpass allows local username/password authentication.

Why this answer

The userpass authentication method is designed for Vault to authenticate users directly with a username and password, without relying on any external identity provider. It stores the credentials within Vault's own backend, making it the correct choice for a standalone authentication scenario where no external system like LDAP or an OIDC provider is involved.

Exam trap

HashiCorp often tests the distinction between authentication methods that require external dependencies versus those that are self-contained; the trap here is that candidates may confuse token authentication (which is a result, not a method) with a credential-based login, or assume LDAP is the only option for username/password authentication.

How to eliminate wrong answers

Option B (Token authentication) is wrong because tokens are the result of a successful authentication, not a method for authenticating with a username and password; tokens are issued after authentication and are used for subsequent requests. Option C (LDAP authentication) is wrong because it requires an external LDAP directory service (e.g., OpenLDAP or Active Directory) to validate credentials, which contradicts the requirement of no external identity provider. Option D (AppRole authentication) is wrong because it is designed for machine-to-machine authentication using a RoleID and SecretID, not for human users providing a username and password.

Full explanation →

163

MCQeasy

A company needs to automatically generate short-lived database credentials for developers. Which secrets engine should they use?

A.KV v2

B.AWS

C.Cubbyhole

D.Database

AnswerD

Database engine creates dynamic credentials.

Why this answer

The Database secrets engine is specifically designed to generate short-lived, dynamic database credentials on demand. It connects to a database and creates unique user accounts with configurable time-to-live (TTL) values, which are automatically revoked when the lease expires. This directly meets the requirement for automatically generating temporary database credentials for developers.

Exam trap

HashiCorp often tests the distinction between secrets engines that generate dynamic credentials (like Database, AWS) versus those that only store static secrets (like KV v2), leading candidates to mistakenly choose KV v2 because it is the most commonly used engine for general secret storage.

How to eliminate wrong answers

Option A is wrong because KV v2 is a static key-value store that does not generate dynamic credentials; it stores secrets as-is and does not support automatic credential rotation or TTL-based expiration. Option B is wrong because the AWS secrets engine generates dynamic credentials for AWS services (e.g., IAM users, STS tokens), not for databases. Option C is wrong because Cubbyhole is a per-token private storage space that is tied to the lifetime of the token itself and cannot be used to generate or manage database credentials for other users.

Full explanation →

164

MCQeasy

A DevOps team uses Vault to manage secrets for a microservices application. The application authenticates to Vault using AppRole, and each service obtains a periodic token with a TTL of 24 hours and a period of 1 hour. The tokens are used to read secrets from a path. Recently, the team noticed that some services are unable to read secrets after a few hours, with error messages indicating that the token is not authorized or has expired. Upon investigation, the team finds that the tokens are being renewed properly but still fail after some time. What is the most likely cause of this issue?

A.The Vault server's maximum number of tokens per client has been exceeded.

B.The tokens are not being renewed correctly due to a bug in the renewal logic.

C.The tokens have a shorter max TTL than the period, causing them to expire before they can be renewed.

D.The AppRole secret ID is being revoked, causing tokens to become invalid.

AnswerC

Correct: Periodic tokens have a max TTL that caps total lifetime; if max TTL is less than the period, the token will expire and cannot be renewed.

Why this answer

The tokens have a period of 1 hour and a TTL of 24 hours, but the max TTL (maximum allowed lifetime) for the token or the role is likely set to a value shorter than the period. In Vault, the period controls how often the token must be renewed, while the max TTL is the absolute upper limit on the token's lifetime. If the max TTL is less than the period (e.g., 30 minutes), the token will expire before the next renewal attempt, even if renewal logic is correct.

Exam trap

The trap here is that candidates assume 'renewed properly' means the token is indefinitely valid, overlooking that Vault's max TTL can override periodic renewal and cause silent expiration.

How to eliminate wrong answers

Option A is wrong because Vault does not enforce a hard limit on the number of tokens per client by default; token exhaustion would cause creation failures, not post-renewal authorization errors. Option B is wrong because the scenario explicitly states tokens are being renewed properly, so a renewal logic bug is not the cause. Option D is wrong because revoking the AppRole secret ID would prevent new token creation but would not affect already-issued tokens that are being renewed successfully.

Full explanation →

165

MCQmedium

A company has a Vault cluster and wants to allow applications running in Kubernetes pods to authenticate without storing static secrets. Which Vault authentication method is specifically designed for Kubernetes?

A.AWS IAM

B.Kubernetes

C.JWT/OIDC

D.AppRole

AnswerB

Kubernetes auth uses the pod's service account token.

Why this answer

The Kubernetes auth method is specifically designed for Kubernetes workloads. It allows pods to authenticate to Vault using their Kubernetes service account token, which Vault validates against the Kubernetes API server. This eliminates the need to store static secrets in the cluster.

Exam trap

HashiCorp often tests the distinction between 'designed for Kubernetes' (Kubernetes auth) and 'can be used with Kubernetes' (JWT/OIDC or AppRole), leading candidates to pick a generic method that works but is not purpose-built.

How to eliminate wrong answers

Option A is wrong because AWS IAM is an authentication method for AWS EC2 instances or Lambda functions, not for Kubernetes pods. Option C is wrong because JWT/OIDC is a generic method for any OIDC-compliant identity provider, not specifically designed for Kubernetes; it requires manual JWT management and does not leverage Kubernetes service account tokens natively. Option D is wrong because AppRole uses a secret ID and role ID, which are static credentials that must be stored somewhere, defeating the purpose of avoiding static secrets in Kubernetes.

Full explanation →

166

MCQeasy

A team wants to store static secrets like database passwords and rotate them periodically. Which secrets engine should they enable?

A.AWS secrets engine

B.PKI secrets engine

C.Transit secrets engine

D.KV v2 secrets engine

AnswerD

KV v2 supports versioning and can store static secrets with rotation capabilities.

Why this answer

The KV v2 secrets engine is designed for static secrets like database passwords, offering versioning, configurable deletion, and periodic rotation via lease management or external automation. It stores secrets as key-value pairs with metadata, making it ideal for static credentials that need controlled lifecycle management.

Exam trap

HashiCorp often tests the distinction between secrets engines that generate dynamic secrets (like AWS or PKI) versus those that store static secrets (like KV v2), leading candidates to confuse 'rotation' with 'dynamic generation' and pick a dynamic engine instead.

How to eliminate wrong answers

Option A is wrong because the AWS secrets engine is specifically for dynamically generating AWS IAM credentials or accessing AWS Secrets Manager, not for storing static secrets locally in Vault. Option B is wrong because the PKI secrets engine generates and manages X.509 certificates, not static passwords or secrets. Option C is wrong because the Transit secrets engine performs encryption/decryption operations on data in transit without storing secrets; it is a cryptographic function, not a storage backend.

Full explanation →

167

MCQhard

A token with this policy attempts to read the secret at path 'secret/data/engineering/special'. Will the read succeed?

A.Yes, because the first path grants read on all secrets under 'secret/data/engineering/'

B.No, because the token needs an additional policy to read from that specific path

C.Yes, because the second path implicitly allows read

D.No, because the second path is more specific and only allows create/update

AnswerA

The wildcard includes 'special'.

Why this answer

The first path grants read on secret/data/engineering/*, which includes 'special'. The second path grants create/update on a different path (without 'data' prefix) and does not deny read. Vault merges capabilities, so read is allowed.

Option B is wrong because ACL merging does not cause one statement to override another unless there is an explicit deny. Option C is wrong because the token already has a policy covering that path. Option D is wrong because the second path does not grant read but also does not deny it.

Exam trap

A common trap is thinking that a more specific path overrides a less specific one. In Vault, ACL policies are additive; permissions are merged unless there is an explicit denial.

Full explanation →

168

MCQhard

A token is created with policies 'default' and 'web-app'. Later, a parent token's policy is updated to add 'logging'. The child token's policies are not updated. What will happen when the child token is used?

A.The child token will still have only 'default' and 'web-app' policies

B.The child token will be automatically renewed to pick up the new policy

C.The child token will automatically gain the 'logging' policy

D.The child token will be invalidated due to policy mismatch

AnswerA

Token policies are set at creation and do not change.

Why this answer

In Vault, child tokens inherit the policies of their parent at the time of creation, but subsequent changes to the parent's policies do not propagate to existing child tokens. The child token retains its original policy set ('default' and 'web-app') because policies are evaluated based on the token's own metadata, not the parent's current state. This behavior is by design to ensure token immutability and prevent unintended privilege escalation.

Exam trap

A common misconception is that policy changes to a parent token propagate to existing child tokens, similar to group membership updates in some systems. However, Vault decouples parent and child policies after token creation; child tokens retain their original policy set indefinitely.

How to eliminate wrong answers

Option B is wrong because Vault does not automatically renew or update child tokens when parent policies change; token renewal only extends the TTL and does not alter policy associations. Option C is wrong because policy inheritance is a one-time snapshot at token creation; the child token cannot gain new policies without explicit re-issuance or a policy update applied directly to the child. Option D is wrong because there is no policy mismatch check that invalidates a child token; the child remains valid with its original policies as long as it has not expired or been revoked.

Full explanation →

169

MCQhard

An organization uses the transit engine with key rotation. They want to ensure that data encrypted with an older key version can be decrypted by Vault, but only if the key has not been deleted. Which of the following must be true?

A.The key's `min_decryption_version` must be set to 1

B.The key must have the `allow_plaintext_backup` setting enabled

C.The key must have a `deletion_allowed` set to false

D.The key's `latest_version` must be greater than 0

E.The key must not have been archived

AnswerE

Archived key versions are removed from the decryption set and cannot be used.

Why this answer

In Vault's transit engine, key rotation creates new key versions while preserving older ones. The ability to decrypt data encrypted with an older key version depends on whether that version is still available in the key's version history. Archiving a key removes all versions from the active key ring, making decryption of data encrypted with any version of that key impossible.

Therefore, the key must not have been archived to allow decryption of data encrypted with an older key version, provided the key itself has not been deleted.

Exam trap

HashiCorp often tests the distinction between key deletion and key archiving, where candidates mistakenly assume that as long as a key is not deleted, older versions remain decryptable, overlooking that archiving also removes access to all versions.

How to eliminate wrong answers

Option A is wrong because `min_decryption_version` controls the minimum version allowed for decryption, not the ability to decrypt older versions; setting it to 1 would allow decryption of all versions, but it does not address the condition that the key must not be deleted. Option B is wrong because `allow_plaintext_backup` permits exporting the key in plaintext for backup purposes, but it has no effect on the ability to decrypt data with older key versions. Option C is wrong because `deletion_allowed` controls whether the key can be deleted entirely, but even if deletion is not allowed, the key could still be archived, which would prevent decryption of older versions.

Option D is wrong because `latest_version` being greater than 0 simply indicates that at least one version exists; it does not guarantee that older versions are available for decryption if the key has been archived.

Full explanation →

170

MCQeasy

An organization is implementing Vault policies for the first time. They want to ensure that policies are easy to manage and follow the principle of least privilege. Which approach should they take when creating policies?

A.Create policies with broad paths and then restrict via ACL tokens.

B.Create a single policy with a wildcard path '*' and full capabilities for all administrators.

C.Create a single policy with all paths and capabilities for all users.

D.Create separate policies for each application and use group aliases to attach them.

AnswerD

This enables granular, least-privilege access based on application needs.

Why this answer

It aligns with the principle of least privilege by creating separate policies for each application, ensuring that each application only has access to the specific paths and capabilities it requires. Using group aliases to attach these policies allows for centralized management and simplifies policy updates, as changes can be made at the group level rather than per user or token. This approach also leverages Vault's identity-based policies, which are evaluated based on the entity's group memberships, providing a scalable and maintainable policy structure.

Exam trap

A common misconception in Vault is that using broad policies with wildcards simplifies management, but the correct approach is to create granular, application-specific policies to enforce least privilege and maintain auditability.

How to eliminate wrong answers

Option A is wrong because creating policies with broad paths and then restricting via ACL tokens violates the principle of least privilege by initially granting excessive access, and ACL tokens are not a mechanism for restricting policies—policies themselves define capabilities, and tokens inherit them. Option B is wrong because a single policy with a wildcard path '*' and full capabilities for all administrators grants unrestricted access to all secrets and operations, which is a security risk and directly contradicts the principle of least privilege. Option C is wrong because a single policy with all paths and capabilities for all users provides no granularity, allowing every user to access every secret and perform all operations, which is insecure and unmanageable.

Full explanation →

171

MCQmedium

A Vault administrator needs to allow users to authenticate using their existing corporate Active Directory credentials. The administrator has configured the LDAP authentication method but users cannot log in. The Vault logs show 'LDAP bind successful' but then 'user not found in group' error. What is the most likely issue?

A.The LDAP server hostname is incorrect

B.The userattr configuration is incorrect

C.The groupfilter or groupattr configuration is incorrect

D.The LDAP server does not allow anonymous queries

AnswerC

Group membership check fails after bind.

Why this answer

The error 'LDAP bind successful' confirms that the Vault server can connect and authenticate to the LDAP server using the bind credentials. The subsequent 'user not found in group' error indicates that while the user exists and can bind, the group membership lookup fails. This is most commonly caused by an incorrect `groupfilter` or `groupattr` configuration, which defines how Vault queries the LDAP directory to map users to groups for authorization.

Exam trap

HashiCorp often tests the distinction between authentication (bind) and authorization (group lookup) — candidates mistakenly focus on the bind success and assume the issue is with user attributes or server connectivity, when the real problem lies in the group membership configuration.

How to eliminate wrong answers

Option A is wrong because an incorrect LDAP server hostname would cause a connection failure, not a successful bind. Option B is wrong because the `userattr` configuration controls how the user's DN is derived during login; a successful bind implies this is correct. Option D is wrong because anonymous queries are not required for group lookup; Vault uses the bind credentials (or a configured service account) to perform the group search, so anonymous access is irrelevant.

Full explanation →

172

MCQmedium

A DevOps engineer runs `vault token lookup s.abc123` and receives a permission denied error. The engineer has a valid token with the default policy attached. What is the most likely cause?

A.The token does not have an attached policy that allows 'token/lookup'

B.The token is expired or revoked

C.The engineer used the token accessor instead of the token ID

D.The default policy does not grant permission to look up other tokens

AnswerD

The default policy only allows self token lookup, not other tokens.

Why this answer

The default policy in Vault is intentionally restrictive and does not include the `token/lookup` capability for tokens other than the caller's own token. Since the engineer is attempting to look up a specific token ID (`s.abc123`) rather than their own token, the default policy denies this action. The permission denied error is expected because the default policy only allows basic operations like reading system capabilities and managing the caller's own token, not inspecting other tokens.

Exam trap

HashiCorp often tests the misconception that the default policy grants broad token management capabilities, when in reality it only allows self-service operations and denies any cross-token inspection unless explicitly permitted via a custom policy with sudo capabilities.

How to eliminate wrong answers

Option A is wrong because the default policy does include the `token/lookup` capability for the caller's own token (via the `self` path), but the engineer is trying to look up a different token, which requires a policy that explicitly grants `token/lookup` on the specific token ID or a broader path. Option B is wrong because if the token were expired or revoked, the `vault token lookup` command would return an error like 'token not found' or 'bad token', not a permission denied error; permission denied indicates the token is valid but lacks authorization. Option C is wrong because the engineer used a token ID (starting with `s.`), not a token accessor (which starts with `a.`); using an accessor would also require specific policy permissions and would not cause a permission denied error in this context.

Full explanation →

173

Multi-Selecthard

Which TWO statements are true about Vault's encryption as a service using the transit engine?

Select 2 answers

A.Encryption keys cannot be rotated once created. [wrong]

B.Data encrypted with a key can be decrypted with a later version of the same key if the key is rotated. [CORRECT]

C.The transit engine supports convergent encryption. [CORRECT]

D.Vault stores the plaintext data for audit purposes. [wrong]

E.Clients can provide their own key material when creating a key. [CORRECT]

AnswersB, C

When a key is rotated, Vault creates a new version but retains old versions for decryption, so data encrypted with an earlier version can still be decrypted.

Why this answer

Options B and C are correct. Option B is correct because the transit engine retains old key versions after rotation, allowing decryption of data encrypted with previous versions. Option C is correct because the transit engine supports convergent encryption, which allows encrypting the same plaintext with the same key to produce the same ciphertext, enabling deduplication.

Option A is incorrect because keys can be rotated. Option D is incorrect because Vault does not store plaintext data; it only performs encryption/decryption without storing data. Option E is incorrect because Vault does not allow clients to provide their own key material; keys are generated internally by Vault.

Exam trap

HashiCorp often tests the misconception that key rotation invalidates previous ciphertext, but Vault's transit engine retains old key versions specifically to allow decryption of data encrypted before rotation.

Full explanation →

174

MCQmedium

A team needs to issue unique tokens to each of 100 microservices, each with its own policy, and ensure that revoking one token does not affect others. Which token feature should they use?

A.Periodic tokens

B.Orphan tokens

C.Token accessors

D.Token roles with distinct policies

AnswerD

Token roles enable creation of tokens with specific policies, providing isolation.

Why this answer

Vault token roles allow you to define distinct policies per token, ensuring each microservice gets a unique token with its own policy. When a token is revoked, only that specific token is invalidated, leaving all others unaffected. This satisfies the requirement for independent revocation without impacting other services.

Exam trap

Vault often tests the misconception that token accessors (Option C) provide policy isolation, but accessors are merely handles for token management and do not control policy assignment or revocation independence.

How to eliminate wrong answers

Option A is wrong because periodic tokens are designed for long-lived access with automatic renewal, not for ensuring independent revocation; revoking one periodic token does not inherently isolate others, but the feature does not address policy uniqueness per microservice. Option B is wrong because orphan tokens are tokens whose parent has been revoked, leaving them without a valid lineage; this is a security risk and does not provide a mechanism for distinct policies or isolated revocation. Option C is wrong because token accessors are identifiers used to perform token operations without exposing the token ID itself; they do not assign policies or guarantee that revoking one token does not affect others.

Full explanation →

175

MCQmedium

A company has deployed Vault with an LDAP auth method and has created entity aliases for all users. The company uses KV v2 secrets engine mounted at 'secret/'. Each team's secrets are stored under a path like 'secret/data/team_<team_name>/'. They have multiple teams (engineering, marketing, sales). Currently, an administrator manually creates a separate policy for each team, e.g., path "secret/data/team_engineering/*" { capabilities = ["read", "list"] }. This is becoming cumbersome as new teams are added. The administrator wants to create a single policy that dynamically grants read access to the secrets path corresponding to the user's team, which is stored in the entity's metadata as 'team'. The LDAP auth method is configured to sync group memberships and map to entity aliases, and the entity metadata is correctly populated. Which approach should the administrator take?

A.Create a policy using a wildcard alias for each team in the entity alias.

B.Create a policy that uses the 'default' policy to allow all reads and then restrict with ACL tokens.

C.Create a policy using a templated path: path "secret/data/{{identity.entity.metadata.team}}/*" { capabilities = ["read", "list"] }.

D.Create a policy with path "secret/data/*" { capabilities = ["read", "list"] } and assign it to all users.

AnswerC

This uses entity metadata to dynamically match the correct team path.

Why this answer

Vault's ACL policy templating allows dynamic path construction using entity metadata. By using `{{identity.entity.metadata.team}}` in the policy path, the policy automatically resolves to the team name stored in the user's entity metadata, granting read/list access only to that team's secrets path. This eliminates the need for per-team policies while maintaining least-privilege access.

Exam trap

Vault often tests the distinction between static wildcard paths and dynamic templated paths, where candidates mistakenly think a simple wildcard like `secret/data/*` is sufficient, ignoring the need for metadata-driven access control.

How to eliminate wrong answers

Option A is wrong because wildcard aliases are not a Vault feature; entity aliases map external identities to Vault entities but do not support wildcards for policy path construction. Option B is wrong because the 'default' policy is a built-in policy that cannot be modified to restrict reads; ACL tokens are used for authentication, not for restricting permissions after a policy grants access. Option D is wrong because granting read/list on `secret/data/*` would give every user access to all team secrets, violating the principle of least privilege and the requirement for team-specific access.

Full explanation →

176

MCQhard

A company uses Kubernetes auth. A pod in namespace 'prod' with service account 'my-sa' can authenticate and read secrets. After upgrading the Kubernetes cluster, the same pod fails to authenticate with error 'JWT token issuer is not valid'. What is the most likely cause?

A.The service account was deleted

B.The Vault role's bound_service_account_names is incorrect

C.The Vault server's Kubernetes API address changed

D.The issuer in the Vault configuration does not match the new cluster issuer

AnswerD

Vault's configuration must match the cluster's issuer, which may change on upgrade.

Why this answer

The error 'JWT token issuer is not valid' indicates that the Kubernetes cluster's issuer URL (typically found in the service account token's `iss` claim) has changed after the upgrade. Vault's Kubernetes auth method must be configured with the correct `kubernetes_ca_cert`, `kubernetes_host`, and crucially the `issuer` parameter. If the cluster's new issuer (e.g., `https://kubernetes.default.svc.cluster.local` or a custom OIDC issuer) does not match the one stored in Vault's configuration, Vault will reject the JWT during validation, causing authentication to fail.

Exam trap

HashiCorp often tests the distinction between authentication failures (issuer mismatch, token validation) and authorization failures (role bindings, service account names), so candidates mistakenly choose Option B when the error message explicitly points to the JWT issuer.

How to eliminate wrong answers

Option A is wrong because deleting the service account would cause a different error (e.g., 'service account not found' or 'token not found'), not a JWT issuer validation error. Option B is wrong because `bound_service_account_names` controls authorization (which service accounts are allowed to use a role), not the JWT issuer validation; an incorrect role binding would result in a permission denied error, not an issuer error. Option C is wrong because if the Vault server's Kubernetes API address changed, the error would be a connection or TLS error (e.g., 'dial tcp: lookup' or 'x509: certificate is valid for'), not a JWT issuer validation error.

Full explanation →

177

MCQhard

A security team must automate periodic credential rotation for a database. The rotation script should run on a server that cannot have the Vault binary installed but can make HTTP requests. Which approach should they use?

A.Use the Vault CLI with curl to wrap commands.

B.Install Vault binary on the server and use CLI.

C.Use the Vault API with proper authentication.

D.Use Vault Agent to handle rotation.

AnswerC

Using the Vault API directly with proper authentication (e.g., using curl with an X-Vault-Token header) allows the server to interact with Vault via HTTP requests without installing any binary. This satisfies the constraint and enables automated credential rotation by calling the appropriate endpoint.

Why this answer

The server can make HTTP requests, allowing it to interact with Vault's RESTful API directly without installing the Vault binary. The Vault API supports token-based authentication (e.g., using X-Vault-Token header) and can be used to programmatically rotate database credentials by calling the appropriate endpoint (e.g., POST /v1/database/rotate-root/:name). This approach satisfies the constraint of no binary installation while enabling secure, automated credential rotation.

Exam trap

HashiCorp often tests the distinction between using the Vault API directly versus relying on the Vault CLI or Agent, trapping candidates who assume that automation always requires the Vault binary or that Vault Agent is a lightweight alternative that doesn't need installation.

How to eliminate wrong answers

Option A is wrong because the Vault CLI is a binary that must be installed on the server, which violates the constraint that the server cannot have the Vault binary installed; wrapping CLI commands with curl does not eliminate the need for the binary. Option B is wrong because it explicitly requires installing the Vault binary on the server, which is prohibited by the scenario. Option D is wrong because Vault Agent is a separate binary that must be installed and configured on the server; it is not a solution for a server that cannot have the Vault binary installed.

Full explanation →

178

MCQhard

A company uses both userpass and AppRole authentication methods. They notice that tokens issued via AppRole are not properly revoked when the corresponding secret_id is deleted. Which concept explains this behavior?

A.The secret_id TTL was not set, causing the token to outlive the secret_id.

B.AppRole does not support entity aliases, so revoking the secret_id does not affect the token.

C.The token was created with a periodic token and cannot be revoked.

D.Tokens are independent of secret_id after login; deleting secret_id does not revoke the token.

AnswerD

The secret_id is used only during login; once the token is issued, it is separate.

Why this answer

When a token is issued via AppRole, the token is created after a successful login using a secret_id. The token itself is independent of the secret_id; deleting the secret_id does not affect the token's lifecycle. Token revocation must be performed explicitly on the token, not by removing the secret_id.

Exam trap

The trap here is that candidates mistakenly believe that deleting the authentication credential (secret_id) will cascade to revoke the token, when in fact tokens and their authentication credentials are independent after login.

How to eliminate wrong answers

Option A is wrong because the secret_id TTL controls the validity of the secret_id itself, not the token's lifetime; even if the secret_id expires, the token remains valid until its own TTL or explicit revocation. Option B is wrong because AppRole does support entity aliases when used with identity entities, but the core issue is that tokens are decoupled from the secret_id after login, not the presence or absence of entity aliases. Option C is wrong because periodic tokens can be revoked just like any other token; the periodic nature only affects renewal behavior, not revocability.

Full explanation →

179

MCQhard

A Vault cluster configured with auto-unseal using AWS KMS is deployed across two availability zones. After a network partition, the standby node remains sealed while the active node is unsealed and serving requests. What is the most likely reason the standby cannot unseal?

A.The standby node is using the wrong AWS region configuration.

B.The active node consumed all available KMS API quota for the region.

C.The cluster address on the standby is misconfigured.

D.The standby node cannot communicate with AWS KMS due to the network partition.

AnswerD

Auto-unseal requires network access to the seal provider.

Why this answer

In a Vault cluster with auto-unseal via AWS KMS, each node must independently communicate with AWS KMS to unseal itself. A network partition that isolates the standby node from AWS KMS prevents it from reaching the KMS endpoint, so it cannot decrypt its unseal key and remains sealed. The active node is unaffected because it is already unsealed and serving requests from the other side of the partition.

Exam trap

The trap here is that candidates may confuse the cluster replication traffic (which uses the cluster address) with the auto-unseal traffic (which uses outbound HTTPS to AWS KMS), leading them to incorrectly select Option C.

How to eliminate wrong answers

Option A is wrong because the standby node would use the same AWS region configuration as the active node (typically set in Vault's configuration file or environment variables), and a network partition does not change the region setting; a misconfigured region would cause persistent unseal failures regardless of partition. Option B is wrong because KMS API quotas are per-account per-region and are not consumed by a single node; even if quota were exhausted, it would affect both nodes equally, not selectively leave the standby sealed. Option C is wrong because the cluster address is used for Raft or integrated storage replication between nodes, not for the auto-unseal process; a misconfigured cluster address would affect replication health but not the standby's ability to contact AWS KMS.

Full explanation →

180

MCQhard

A multinational corporation uses Vault Enterprise with the transit engine to encrypt sensitive financial data across multiple cloud regions. Each region has its own Vault cluster, and they use performance replication to synchronize transit keys. Recently, the team in the Asia-Pacific region reports that encryption operations are slower than in other regions. They also notice that some decryption requests for data encrypted with a key that was rotated in the primary region are failing with 'key version not found' errors. The transit key is named 'fin-key' and has been rotated three times. The Asia-Pacific cluster is up-to-date with replication according to the replication status dashboard. Which action should the operations team take to resolve the decryption failures?

A.Verify that the policy in the Asia-Pacific cluster grants 'decrypt' capability on the key path for older key versions.

B.Increase the performance standby count in the Asia-Pacific cluster.

C.Manually copy the key material from the primary to the secondary cluster.

D.Re-encrypt all data encrypted with version 1 of 'fin-key' using the current version.

AnswerA

Policy might be missing decrypt on older versions.

Why this answer

The decryption failures are caused by missing key versions in the Asia-Pacific cluster's transit engine. Even though performance replication synchronizes transit keys, older key versions may not be replicated if the transit engine's key version caching or policy does not explicitly grant access to them. Verifying that the policy includes 'decrypt' capability on the key path for older key versions ensures that the cluster can serve decryption requests for data encrypted with rotated keys.

Exam trap

HashiCorp often tests the misconception that replication automatically grants all capabilities, but the trap here is that policy must explicitly allow access to older key versions, and candidates may incorrectly focus on replication health or manual key copying instead.

How to eliminate wrong answers

Option B is wrong because increasing the performance standby count improves read scalability and failover speed, but does not resolve missing key versions or policy restrictions. Option C is wrong because manually copying key material violates Vault's security model and replication design; performance replication automatically synchronizes transit keys, and manual intervention is neither supported nor necessary. Option D is wrong because re-encrypting all data with the current version is a costly workaround that does not address the root cause—the policy or replication issue preventing access to older key versions.

Full explanation →

181

Multi-Selecthard

Which THREE API endpoints are valid for managing policies in Vault?

Select 3 answers

A.GET /v1/sys/policy/{name}

B.PUT /v1/sys/policy/{name}

C.PATCH /v1/sys/policy/{name}

D.DELETE /v1/sys/policy/{name}

E.POST /v1/sys/policy/{name}

AnswersA, D, E

GET retrieves the named policy.

Why this answer

The GET, DELETE, and POST endpoints are valid for managing policies in Vault. GET retrieves a policy, DELETE removes it, and POST creates or updates a policy. These correspond to the standard CRUD operations supported by Vault's sys/policy API.

Exam trap

HashiCorp often tests the misconception that PUT is the standard HTTP method for creating/updating resources in Vault, but Vault specifically uses POST for policy management, making PUT an invalid choice.

Full explanation →

182

MCQmedium

A DevOps team is using Vault's database secrets engine to generate dynamic credentials for a PostgreSQL database. They notice that the lease duration is set to 24 hours, but security policy requires that credentials expire after 1 hour. What should the team do to enforce the 1-hour expiration without changing the default lease TTL for all secrets?

A.Set the mount's max_lease_ttl to 1h.

B.Ask each developer to set the TTL when requesting credentials.

C.Configure the role with a ttl of 1h.

D.Use a periodic token with a period of 1h.

AnswerC

The role-level ttl overrides the default lease TTL.

Why this answer

The database secrets engine allows role-level TTL configuration that overrides the default lease duration for credentials generated from that role. By setting the role's `ttl` to 1h, the team enforces a 1-hour expiration for credentials created under that specific role without affecting the default lease TTL for all secrets or other roles. This directly meets the security policy requirement while maintaining flexibility for other secrets.

Exam trap

The trap here is that candidates often confuse mount-level TTL settings with role-level TTL settings, assuming that changing the mount's `max_lease_ttl` is the only way to enforce expiration, when in fact role-level configuration provides granular control without affecting other secrets.

How to eliminate wrong answers

Option A is wrong because setting the mount's `max_lease_ttl` to 1h would enforce a hard upper limit on all secrets generated from that mount, including other roles or engines, which violates the requirement to not change the default lease TTL for all secrets. Option B is wrong because relying on each developer to set the TTL when requesting credentials is error-prone and does not enforce the policy centrally; developers might forget or intentionally set a longer TTL, leading to non-compliance. Option D is wrong because periodic tokens are used for long-lived tokens that automatically renew, not for database credentials; they do not control the TTL of dynamic credentials generated by the database secrets engine.

Full explanation →

183

MCQhard

An admin creates a token with TTL=48h and explicit_max_ttl=120h. The token is renewed every 24h. After 10 days, will the token still be valid?

A.Yes, because TTL refreshes to 48h on each renewal.

B.Yes, if renewed before TTL expires, it can persist indefinitely.

C.No, because the total lifetime cannot exceed the explicit_max_ttl of 120h.

D.No, because tokens cannot be renewed more than 5 times.

AnswerC

Explicit_max_ttl caps the total lifetime regardless of renewals.

Why this answer

The token's total lifetime is capped by the `explicit_max_ttl` of 120 hours (5 days). Even though the token is renewed every 24 hours, the cumulative time since creation cannot exceed the explicit maximum TTL. After 10 days (240 hours), the token will have long surpassed the 120-hour limit and will be invalid.

Exam trap

In HashiCorp Vault, the explicit_max_ttl sets an absolute upper bound on token lifetime regardless of renewals. Candidates often mistakenly think that renewals reset the clock, but the total time since token creation cannot exceed explicit_max_ttl.

How to eliminate wrong answers

Option A is wrong because the TTL refreshes to 48h on each renewal, but the explicit_max_ttl overrides this behavior and limits the total lifetime from creation, not per-renewal. Option B is wrong because indefinite renewal is not possible when an explicit_max_ttl is set; the token will be revoked once the total lifetime exceeds that limit. Option D is wrong because Vault does not impose a hard limit on the number of renewals; the constraint is based on time, not count.

Full explanation →

184

MCQhard

Refer to the exhibit. Based on the output from 'vault status', which statement is true?

A.The storage backend is a file backend.

B.The unseal configuration uses 5 key shares with a threshold of 3.

C.Auto-unseal is enabled using Consul as the seal provider.

D.Vault is not configured for high availability.

AnswerB

Total Shares is 5, Threshold is 3.

Why this answer

The 'vault status' output shows 'Sealed: false', 'Key Shares: 5', and 'Key Threshold: 3'. This indicates that Vault is unsealed and uses a Shamir seal configuration with 5 key shares, requiring any 3 of them to unseal. Option B correctly states this unseal configuration.

Exam trap

HashiCorp often tests the distinction between 'storage backend' and 'seal type' — candidates confuse the Consul storage backend with auto-unseal, but auto-unseal requires a separate seal provider like AWS KMS, not Consul.

How to eliminate wrong answers

Option A is wrong because the output shows 'Storage Type: consul', not 'file', so the storage backend is Consul, not a file backend. Option C is wrong because the output shows 'Seal Type: shamir', not 'auto-unseal' or 'Consul as seal provider'; auto-unseal would show a seal type like 'awskms' or 'gcpckms'. Option D is wrong because the output shows 'HA Enabled: true', indicating Vault is configured for high availability.

Full explanation →

185

Multi-Selecthard

Which THREE of the following are valid parameters when creating a token via the API?

Select 3 answers

A.num_uses

B.ttl

C.policies

D.accessor

E.max_ttl

AnswersA, B, C

num_uses is a valid parameter for token creation; it limits the number of times the token can be used.

Why this answer

When creating a token via the Vault API, valid parameters include `num_uses` to set the number of times the token can be used, `ttl` to set the time-to-live, and `policies` to attach policies. `max_ttl` is not a direct input parameter; it is a property that may be inherited from the role or mount configuration. `accessor` is a read-only field returned in the response, not an input parameter.

Exam trap

Candidates often mistake the `max_ttl` field as an input parameter for token creation, but it is not settable at creation time. They may also incorrectly consider `accessor` as an input parameter, but it is only returned in the response.

Full explanation →

186

MCQeasy

A development team wants to authenticate to Vault using a method that does not require storing secrets in source code and supports automatic rotation of credentials. Which authentication method best meets these requirements?

A.Token authentication

B.LDAP authentication

C.AWS IAM authentication

D.Userpass authentication

AnswerC

AWS IAM auth uses instance metadata service to obtain a signed identity, no secrets stored in code.

Why this answer

AWS IAM authentication allows Vault to authenticate using AWS IAM credentials (access key/secret key or instance metadata) without storing any secrets in source code. It supports automatic credential rotation by leveraging AWS IAM roles and STS to generate temporary credentials, which Vault can validate via the AWS API. This eliminates the need for long-lived secrets in code and enables seamless rotation.

Exam trap

HashiCorp often tests the misconception that token authentication is stateless and secret-free, but the trap here is that tokens themselves are secrets that must be stored and rotated manually, whereas AWS IAM authentication leverages cloud-native identity federation to eliminate stored secrets entirely.

How to eliminate wrong answers

Option A is wrong because token authentication requires a Vault token to be stored somewhere (e.g., in a file or environment variable), which means a secret is still present in source code or configuration, and tokens do not automatically rotate unless explicitly managed. Option B is wrong because LDAP authentication requires storing LDAP credentials (username/password) in source code or configuration, and those credentials are long-lived with no built-in automatic rotation mechanism. Option D is wrong because userpass authentication requires storing a username and password in source code or configuration, and those credentials are static unless manually rotated, which defeats the requirement of no stored secrets and automatic rotation.

Full explanation →

187

MCQhard

An application uses a Vault token with a policy that grants read access to secrets. The security team wants to ensure that if the application is compromised, the token cannot be used after a certain time even if the attacker has the token. What is the best approach?

A.Use a revocation script that runs periodically

B.Set explicit max TTL on the token

C.Use a periodic token with a long period

D.Set a short TTL on the token and do not allow renewal

AnswerD

A short TTL ensures the token expires quickly.

Why this answer

Setting a short TTL on the token and disallowing renewal ensures that the token automatically expires after a fixed, short duration. Even if an attacker compromises the token, they cannot extend its lifetime, limiting the window of exposure. This directly meets the security requirement of preventing token use beyond a certain time without relying on external revocation mechanisms.

Exam trap

HashiCorp often tests the distinction between TTL and renewal behavior; the trap here is that candidates confuse 'max TTL' (which still allows renewal) with 'short TTL + no renewal' (which enforces absolute expiry), leading them to incorrectly select Option B.

How to eliminate wrong answers

Option A is wrong because a revocation script that runs periodically introduces a window of vulnerability between revocation checks; the token remains valid until the script executes, and the script itself adds operational complexity and potential failure points. Option B is wrong because setting an explicit max TTL on the token does not prevent the token from being renewed up to that max TTL; if renewal is allowed, an attacker could keep the token alive for the entire max TTL duration, which may be longer than desired. Option C is wrong because a periodic token with a long period is designed for long-lived, renewable access; it can be renewed indefinitely as long as the parent policy allows, which contradicts the requirement to limit token lifetime after compromise.

Full explanation →

188

MCQhard

A finance company runs a microservices architecture on Kubernetes. Each microservice has its own service account and uses Kubernetes auth to authenticate to Vault and read secrets. Recently, a new microservice 'payment' was deployed in the 'prod' namespace with service account 'payment-sa'. The team created a Vault role with bound_service_account_names=['payment-sa'] and bound_service_account_namespaces=['prod']. The microservice can authenticate and obtains a token, but when it tries to read the secret at path 'secret/data/payments/db', it gets a permissions error. Other microservices in the same namespace with similar roles work fine. The Vault policy for the role includes read access to 'secret/data/payments/*'. What is the most likely issue and correct action?

A.Update the Vault role to include the policy 'payments-read' in the token_policies parameter.

B.Increase the TTL of the Vault token to give more time for the secret read.

C.Add the microservice's service account to the bound_service_account_names of an existing role that works.

D.Change the authentication method to AppRole for the payment microservice.

AnswerA

The role must specify which policies to attach.

Why this answer

The Vault role is configured with `token_policies` that grant read access to `secret/data/payments/*`, but the role itself does not include that policy in its `token_policies` parameter. When the microservice authenticates via Kubernetes auth, the token issued by Vault only carries policies explicitly attached to the role. Without the policy being listed in `token_policies`, the token lacks the necessary permissions to read the secret, even though the policy exists.

Updating the role to include the policy in `token_policies` resolves the permissions error.

Exam trap

HashiCorp often tests the distinction between creating a policy and attaching it to a role; the trap here is assuming that simply having a policy with the correct path is sufficient, when in fact the policy must be explicitly referenced in the role's `token_policies` parameter.

How to eliminate wrong answers

Option B is wrong because increasing the TTL does not affect permissions; it only extends the token's validity period, which is irrelevant to a permissions error. Option C is wrong because adding the service account to an existing role that works would grant the same policies as that role, but those policies may not include read access to `secret/data/payments/*`, and it would bypass the intended role isolation. Option D is wrong because changing to AppRole is unnecessary; the Kubernetes auth method is already functioning for authentication, and the issue is purely a policy attachment problem, not an authentication method flaw.

Full explanation →

189

Multi-Selecthard

A security architect is designing a secrets management solution with Vault. Which THREE secrets engines are most appropriate for dynamically generating credentials for external systems?

Select 3 answers

A.PKI secrets engine

B.KV v2 secrets engine

C.AWS secrets engine

D.Transit secrets engine

E.Database secrets engine

AnswersA, C, E

PKI dynamically issues X.509 certificates.

Why this answer

The PKI secrets engine is correct because it dynamically generates X.509 certificates for TLS/mTLS authentication, enabling short-lived credentials that reduce the risk of key compromise. This aligns with the requirement for dynamically generating credentials for external systems, as certificates can be issued on-demand with configurable TTLs and revocation support.

Exam trap

HashiCorp often tests the distinction between secrets engines that generate dynamic credentials (PKI, AWS, Database) versus those that store or process static data (KV v2, Transit), leading candidates to incorrectly select KV v2 for its familiarity or Transit for its security focus.

Full explanation →

190

Multi-Selectmedium

Which TWO authentication methods support multi-factor authentication (MFA) natively within Vault Enterprise?

Select 2 answers

A.AWS IAM authentication

B.Token authentication

C.Userpass authentication

D.LDAP authentication

E.Kubernetes authentication

AnswersC, D

Userpass can be configured with MFA by adding an MFA method.

Why this answer

Userpass authentication in Vault Enterprise supports MFA natively because it can be configured with a second factor such as TOTP, Duo, or Okta directly within the auth method's configuration. This allows the userpass method to enforce both a password and an additional authentication factor without requiring an external identity provider or custom wrapper.

Exam trap

HashiCorp often tests the distinction between 'native MFA support' (where the auth method itself can be configured with MFA without external plugins) versus 'MFA can be added externally' (which is possible for all auth methods via login MFA enforcement, but not native to the method).

Full explanation →

191

MCQhard

A multi-national company uses Vault's AWS secrets engine to manage access to multiple AWS accounts. They have a central Vault cluster and need to generate IAM users in account A that assume a role in account B for cross-account access. The team has configured the AWS secrets engine with the root credentials of account A. They created a role on the engine that should generate STS credentials for the cross-account role. However, when they try to generate credentials, Vault returns an error: 'AccessDenied: User: arn:aws:iam::<accountA>:user/vault-user is not authorized to perform: STS:AssumeRole on resource: arn:aws:iam::<accountB>:role/CrossAccountRole'. What additional configuration is required?

A.Create a new role in the AWS secrets engine that uses the cross-account role ARN directly.

B.Change the AWS secrets engine mount path to avoid conflicts.

C.Set up AWS federation with SAML to allow cross-account access.

D.Attach an IAM policy to the Vault user in account A that allows sts:AssumeRole on the cross-account role ARN.

AnswerD

The Vault user needs explicit permission to assume the target role.

Why this answer

The error indicates that the Vault user in account A lacks the IAM permission to call sts:AssumeRole on the cross-account role in account B. Even though the AWS secrets engine is configured with root credentials of account A, the engine uses those credentials to make API calls on behalf of the Vault user. Therefore, you must attach an IAM policy to the Vault user in account A that explicitly allows sts:AssumeRole on the target role ARN in account B.

This is a prerequisite for cross-account access via STS.

Exam trap

HashiCorp often tests the misconception that configuring the AWS secrets engine role with the cross-account role ARN is sufficient, when in fact the underlying IAM permissions for the Vault user must also be explicitly granted.

How to eliminate wrong answers

Option A is wrong because creating a new role in the AWS secrets engine that uses the cross-account role ARN directly does not grant the Vault user the required sts:AssumeRole permission; the engine role definition alone cannot bypass IAM authorization. Option B is wrong because changing the mount path only affects the API endpoint path in Vault and has no impact on AWS IAM permissions or cross-account trust. Option C is wrong because SAML federation is an alternative identity federation method, but it is not required here; the existing AWS secrets engine with root credentials can perform cross-account access once the proper IAM policy is attached to the Vault user.

Full explanation →

192

Drag & Dropmedium

Drag and drop the steps to create and use a periodic service token in Vault into the correct order.

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First create the role, then generate a token with a TTL, use it, and renew periodically.

Full explanation →

193

MCQmedium

Refer to the exhibit. A developer issues a Vault CLI command to write a secret to path 'secret/data/team/billing'. What will be the outcome?

A.The write is denied because the policy does not include a 'write' capability.

B.The write is denied because the second rule only allows read capability on the exact path, overriding the wildcard rule.

C.The write is denied unless the developer is authenticated with a token that has sudo privileges.

D.The write is allowed if the developer uses the 'vault kv put' command with the -force flag.

E.The write is allowed because the first rule grants create and update to all paths under team/.

AnswerB

Vault evaluates the most specific path first; the second rule matches exactly and only allows read, so the write is denied.

Why this answer

Vault policies are evaluated using a most-specific-path-wins model. The second rule explicitly allows 'read' on 'secret/data/team/billing', which is more specific than the wildcard rule 'secret/data/team/*'. Since the write operation requires 'create' or 'update' capabilities, and the specific rule only grants 'read', the write is denied even though the wildcard rule would have allowed it.

Exam trap

This question tests the most-specific-path-wins rule in Vault policy evaluation, where candidates mistakenly assume that a broader wildcard rule will always apply, ignoring that an exact or more specific path rule can override it.

How to eliminate wrong answers

Option A is wrong because the policy does include a 'write' capability via the first rule (create, update) on the wildcard path 'secret/data/team/*', so the denial is not due to a missing 'write' capability. Option C is wrong because sudo privileges are not required for writes; Vault's sudo capability is only needed for certain administrative operations (e.g., enabling auth methods) and does not apply to standard secret writes. Option D is wrong because the '-force' flag on 'vault kv put' is used to force a write even when the secret version already exists, but it does not override policy restrictions.

Option E is wrong because the first rule does grant create and update to all paths under 'team/', but the more specific second rule overrides it for the exact path 'secret/data/team/billing', denying the write.

Full explanation →

194

MCQmedium

An organization wants to use Vault to generate AWS IAM users with specific managed policies attached. They have configured the AWS secrets engine with the appropriate IAM credentials. What step is required to ensure each generated user gets the correct policies?

A.Enable the AWS secrets engine at a custom path

B.Set a high TTL on the AWS secrets engine mount

C.Use the transit secrets engine to encrypt the AWS credentials

D.Configure a role in the AWS secrets engine that specifies the managed policies

AnswerD

The role defines the policies to attach to generated IAM users.

Why this answer

The AWS secrets engine in Vault uses roles to define the exact permissions and policies for generated IAM users. By configuring a role that specifies the managed policies, Vault ensures that each dynamically generated IAM user is created with those policies attached, meeting the organization's requirement.

Exam trap

The trap here is that candidates may confuse the purpose of the AWS secrets engine role with other Vault features like mount paths or encryption engines, assuming policy attachment is handled automatically or through unrelated configurations.

How to eliminate wrong answers

Option A is wrong because enabling the AWS secrets engine at a custom path does not affect policy assignment; it only changes the mount point for API access. Option B is wrong because setting a high TTL on the AWS secrets engine mount controls credential lease duration, not the policies attached to generated users. Option C is wrong because the transit secrets engine is used for encryption of data in transit or at rest, not for defining IAM policies; it is unrelated to AWS IAM user generation.

Full explanation →

195

MCQeasy

Refer to the exhibit. A Vault administrator starts a Vault server and receives this error. What is the most likely cause?

A.The Vault binary is corrupt.

B.The listener address is incorrect.

C.The seal stanza is misconfigured.

D.The storage stanza is missing from the configuration file.

AnswerD

Vault requires a storage stanza to define the backend for persisting data.

Why this answer

The error indicates that Vault cannot find a configured storage backend. The storage stanza is mandatory in Vault's configuration file because it defines where Vault persists its data (e.g., Consul, Raft, file). Without it, the server fails to start because it has no backend to store secrets and state.

Exam trap

HashiCorp often tests the mandatory nature of the storage stanza, tricking candidates into thinking a listener or seal misconfiguration is the cause when the real issue is the absence of a storage backend definition.

How to eliminate wrong answers

Option A is wrong because a corrupt binary would typically produce a different error (e.g., checksum mismatch or segmentation fault), not a missing storage backend message. Option B is wrong because an incorrect listener address would cause a bind or connection error, not a missing storage stanza error. Option C is wrong because a misconfigured seal stanza (e.g., wrong transit path or key) would produce a seal initialization error, not a missing storage backend error.

Full explanation →

196

MCQeasy

An administrator needs to revoke a token but wants to keep all child tokens that were created using this token as the parent. Which revocation operation should be used?

A.Orphan token revocation

B.Immediate token revocation

C.Sudo token revocation

D.Self token revocation

AnswerA

Orphan revocation removes the token from the hierarchy but preserves children.

Why this answer

Orphan token revocation is the correct operation because it revokes the parent token while preserving all child tokens that were created using it. This is achieved by removing the parent token's accessor and its associated policies, but leaving the child tokens' hierarchy intact so they continue to function independently. In Vault, this is done via the `vault token revoke -orphan` command or the corresponding API endpoint.

Exam trap

A common trap in Vault exams is confusing 'orphan' revocation with 'immediate' revocation. Candidates may incorrectly assume that all token revocations are recursive, forgetting that the -orphan flag specifically preserves child tokens. Some may also mistakenly think 'sudo' revocation is required for this operation.

How to eliminate wrong answers

Option B (Immediate token revocation) is wrong because it revokes the token and all its child tokens recursively, which would delete the child tokens the administrator wants to keep. Option C (Sudo token revocation) is wrong because 'sudo' is not a valid revocation operation in Vault; it refers to a policy capability, not a token revocation mode. Option D (Self token revocation) is wrong because it only revokes the token used to authenticate the request (the caller's own token), not a specific parent token while preserving children.

Full explanation →

197

MCQmedium

Refer to the exhibit. An admin wants to ensure this token can be used for 60 hours total. Which action should be taken?

A.Increase the creation_ttl to 60h.

B.The token will expire after 48h, so increase explicit_max_ttl to 60h on the current token.

C.Create a new token with explicit_max_ttl=60h.

D.The token already can be used for 60h because it is renewable.

AnswerC

A new token with appropriate max TTL is required.

Why this answer

The token's current `explicit_max_ttl` is set to 48h, and the `creation_ttl` (24h) cannot be increased beyond that bound. To achieve a total lifetime of 60 hours, a new token must be created with `explicit_max_ttl=60h`, which overrides the default or role-based TTL limits and sets the absolute maximum lifetime for the token.

Exam trap

HashiCorp Vault exams often test the misconception that `explicit_max_ttl` can be modified on an existing token or that renewal alone can extend a token's lifetime beyond its `explicit_max_ttl`.

How to eliminate wrong answers

Option A is wrong because increasing `creation_ttl` to 60h would be capped by the existing `explicit_max_ttl` of 48h, so the token would still expire at 48h. Option B is wrong because `explicit_max_ttl` cannot be changed on an existing token; it is a creation-time parameter and is immutable after issuance. Option D is wrong because the token is renewable, but renewal only extends the token's lifetime up to the `explicit_max_ttl` (48h), not beyond it, so it cannot reach 60 hours total.

Full explanation →

198

MCQmedium

Refer to the exhibit. A user with this policy attempts to read the secret at path "secret/data/team-a/admin". What will happen?

A.The read fails because the path does not exist.

B.The read succeeds because the first path grants read.

C.The read succeeds because deny only applies to write operations.

D.The read is denied because the deny policy takes precedence.

AnswerD

Deny always takes precedence over other capabilities.

Why this answer

The deny policy takes precedence over any allow policy in Vault, regardless of the path specificity. Even though the first path grants read access to 'secret/data/team-a/*', the second path explicitly denies all capabilities (including read) on 'secret/data/team-a/admin', which is a more specific path. Vault's policy evaluation uses a deny-overrides model, so the deny action blocks the read operation.

Exam trap

Candidates often mistakenly think Vault uses a first-match or most-specific-path-wins model, similar to firewall rules, when in fact deny always overrides allow regardless of path specificity.

How to eliminate wrong answers

Option A is wrong because the path 'secret/data/team-a/admin' exists in the policy (it is explicitly listed in the deny statement), so the failure is not due to a missing path. Option B is wrong because Vault does not use a first-match-wins model; deny policies take precedence over allow policies, even if the allow path is broader. Option C is wrong because the deny policy applies to all capabilities (read, write, list, delete, etc.) unless specific capabilities are listed; the deny statement here has no capabilities list, so it denies all operations, including read.

Full explanation →

199

MCQeasy

A DevOps team wants to authenticate a CI/CD pipeline running on a Jenkins server outside Kubernetes. The pipeline needs to obtain short-lived tokens to read secrets. Which authentication method should be used?

A.AppRole auth

B.LDAP auth

C.Kubernetes auth

D.GitHub auth

AnswerA

AppRole is ideal for non-human clients like CI/CD pipelines.

Why this answer

AppRole auth is designed for machine-to-machine authentication, allowing Jenkins (outside Kubernetes) to obtain short-lived tokens by providing a RoleID and SecretID. This method supports automated workflows without human intervention, making it ideal for CI/CD pipelines that need to read secrets from Vault.

Exam trap

HashiCorp often tests the distinction between authentication methods designed for humans (LDAP, GitHub) versus those for machines (AppRole), and the trap here is assuming Kubernetes auth can be used from outside the cluster because it is commonly associated with CI/CD pipelines.

How to eliminate wrong answers

Option B (LDAP auth) is wrong because it requires a human username/password and is intended for user authentication, not for automated pipelines. Option C (Kubernetes auth) is wrong because it relies on a Kubernetes service account token and is only valid for pods running inside a Kubernetes cluster, not for an external Jenkins server. Option D (GitHub auth) is wrong because it is designed for authenticating users via GitHub OAuth, not for machine-to-machine token generation in a CI/CD pipeline.

Full explanation →

200

MCQhard

You are a Vault administrator for a large organization. Your team uses a centralized Vault cluster with multiple auth methods enabled, including userpass, LDAP, and approle. Recently, a developer reported that they are unable to authenticate using their userpass credentials, receiving the error 'permission denied'. The developer confirms the username and password are correct. Other developers using userpass can authenticate successfully. The Vault audit logs show that the authentication request for this developer is reaching Vault but failing with 'invalid password'. You have verified that the password is correct by resetting it via the Vault CLI. The developer's userpass entry exists and is not disabled. Which of the following is the most likely cause and correct course of action?

A.The developer's user entry is disabled. The admin should enable it using 'vault write auth/userpass/users/<username>/enable'.

B.The developer's password has expired. The admin should update the password with a new one.

C.The developer's password hash is corrupted. The admin should delete and recreate the user entry.

D.The developer's account is locked due to too many failed login attempts. The admin should unlock the account using 'vault write auth/userpass/users/<username>/unlock'.

AnswerD

Correct; account lockout is a common cause of authentication failures after repeated failed attempts.

Why this answer

Vault's userpass auth method supports account locking after a configurable number of failed login attempts (default is 0, meaning no lockout, but if set to a positive integer via `max_attempts`, the account becomes locked). The audit log shows 'invalid password' despite the password being verified as correct, and other users can authenticate, which points to a lockout rather than a password or user entry issue. The admin can unlock the account using `vault write auth/userpass/users/<username>/unlock` to restore access.

Exam trap

HashiCorp often tests the misconception that 'invalid password' always means the password is wrong, when in fact it can also indicate an account lockout, especially when the user confirms the password is correct and other users authenticate successfully.

How to eliminate wrong answers

Option A is wrong because the developer's user entry is confirmed to exist and not disabled; Vault userpass does not have an 'enable' endpoint—the correct command to enable a user would be `vault write auth/userpass/users/<username>/enable` does not exist; disabling is done via `vault write auth/userpass/users/<username>/disable` and re-enabling is not a standard operation. Option B is wrong because userpass passwords do not have an expiration mechanism by default; password expiry is not a feature of the userpass auth method unless custom TTL policies are applied, but the error 'invalid password' would not occur from expiry alone. Option C is wrong because password hash corruption is extremely unlikely in Vault's backend storage (which uses encrypted storage and integrity checks); deleting and recreating the user entry would be an unnecessary destructive action when the issue is lockout.

Full explanation →

201

MCQeasy

A developer requests a credential from this role. Which statement about the resulting lease is true?

A.The lease will have a TTL of 24 hours and can be renewed.

B.The lease will have a TTL of 1 hour and can be renewed.

C.The lease will have a TTL of 1 hour and cannot be renewed.

D.The lease will have a TTL of 24 hours and cannot be renewed.

AnswerC

The default_ttl sets the initial TTL, and renewable=false prevents renewal.

Why this answer

In Vault, when a developer requests a credential from a role that is configured with the default lease TTL of 1 hour and the role has `explicit_max_ttl` set to 0 (or not set), the resulting lease will have a TTL of 1 hour. Additionally, if the role is configured with `renewable=false`, the lease cannot be renewed. Option C correctly reflects both the 1-hour TTL and non-renewable behavior.

Exam trap

In the Vault exam, candidates often confuse the default lease TTL (1 hour) with the maximum TTL (24 hours or higher), and they may incorrectly assume all leases are renewable. The 'renewable' flag is a separate configuration that can be set to false, making the lease non-renewable regardless of TTL.

How to eliminate wrong answers

Option A is wrong because the lease TTL is 1 hour, not 24 hours, and the lease cannot be renewed when `renewable=false`. Option B is wrong because while the TTL is 1 hour, the lease cannot be renewed when the role has `renewable=false`. Option D is wrong because the lease TTL is 1 hour, not 24 hours, and although the non-renewable part is correct, the TTL value is incorrect.

Full explanation →

202

MCQeasy

Which Vault component is responsible for encrypting data before storing it in the storage backend?

A.Storage Backend

B.Audit Device

C.Barrier

D.Secrets Engine

AnswerC

Encrypts all data before storage.

Why this answer

The Barrier (also known as the Security Barrier) is the Vault component responsible for encrypting all data before it is written to the storage backend. It wraps every entry with encryption using the master key, ensuring that data at rest is never stored in plaintext. This is a core architectural layer that provides a cryptographic boundary between Vault's internal operations and the underlying storage.

Exam trap

HashiCorp often tests the misconception that the Storage Backend handles encryption, but the trap here is that candidates confuse the storage layer's persistence role with the Barrier's cryptographic role, leading them to pick Option A.

How to eliminate wrong answers

Option A is wrong because the Storage Backend is a passive, durable storage layer (e.g., Consul, file system, S3) that only persists encrypted data; it has no encryption capabilities and never sees plaintext. Option B is wrong because an Audit Device logs requests and responses for auditing purposes but does not perform encryption of stored data; it operates at the logging layer, not the storage layer. Option D is wrong because a Secrets Engine generates, manages, and returns secrets (e.g., KV, AWS, database credentials) but does not encrypt data before storage; it relies on the Barrier to encrypt its output before writing to the storage backend.

Full explanation →

203

Multi-Selecteasy

Which TWO are benefits of using Vault's encryption as a service?

Select 2 answers

A.Enables encryption of data at rest in cloud storage

B.Allows applications to delegate encryption/decryption to Vault without handling keys

C.Provides automatic key rotation and versioning

D.Eliminates the need for any network connectivity to Vault

E.Supports only symmetric key algorithms

AnswersB, C

Core benefit of encryption as a service.

Why this answer

Vault's encryption as a service allows applications to offload encryption and decryption operations to Vault via its API, without the application ever handling or storing encryption keys. This reduces the risk of key exposure and simplifies compliance with security policies.

Exam trap

HashiCorp often tests the misconception that encryption as a service is for encrypting cloud storage at rest, when in fact it is for application-level data encryption without key management exposure.

Full explanation →

204

MCQhard

Given the output from 'vault operator raft list-peers', which node(s) will become unavailable if node1 (leader) experiences a network partition away from all other nodes?

A.Only node1 becomes unavailable; the cluster remains operational with a new leader from node2 or node3

B.All nodes become unavailable because node1 is the leader

C.No nodes become unavailable; node1 remains leader but cannot serve writes

D.Node1, node4, and node5 become unavailable

AnswerA

Node1 is partitioned, but node2 and node3 (voters) can form quorum (2 out of 3) and elect a new leader.

Why this answer

In a Raft-based Vault cluster, only the leader node becomes unavailable during a network partition that isolates it from the other nodes. The remaining nodes (node2 and node3) form a quorum (2 out of 3) and will elect a new leader, allowing the cluster to continue serving requests. Node1, being isolated, cannot participate in Raft consensus and will step down as leader, becoming unavailable for client operations.

Exam trap

The trap here is that candidates assume the leader is essential for cluster operation, but Raft's fault tolerance allows the cluster to survive the loss of the leader as long as a quorum remains.

How to eliminate wrong answers

Option B is wrong because it assumes the entire cluster depends on the leader; in Raft, a new leader is elected from the remaining quorum, so the cluster remains operational. Option C is wrong because node1 cannot remain leader without connectivity to the majority; Raft requires the leader to maintain contact with a quorum, and without it, node1 will step down and become unavailable. Option D is wrong because node4 and node5 are not mentioned in the output; the cluster only has three nodes (node1, node2, node3), so no additional nodes exist to become unavailable.

Full explanation →

205

MCQeasy

A data analytics company needs to encrypt streaming data (e.g., clickstream events) before sending to a cloud data lake. Each event is about 1KB. They use Vault Transit to encrypt each event individually. The encryption rate is too slow for the volume (100,000 events/second). The team considers options to improve performance. Which approach is most effective for reducing the number of API calls to Vault while maintaining security?

A.Use a different secrets engine like Database or PKI.

B.Generate a local data encryption key (DEK) and encrypt it with Vault's Transit engine (KEK). Encrypt each event locally with the DEK, storing the encrypted DEK alongside the data.

C.Increase the number of Vault nodes and load balance requests.

D.Use Vault's batch encryption to send multiple events in one request.

AnswerB

Envelope encryption reduces Vault calls to one per DEK rotation, enabling high throughput with minimal API overhead.

Why this answer

It implements an envelope encryption pattern: a local Data Encryption Key (DEK) encrypts each event locally, avoiding an API call per event, while the DEK itself is encrypted by Vault's Transit engine (Key Encryption Key, KEK). This reduces the number of Vault API calls from 100,000 per second to a single call per DEK rotation, drastically improving throughput without exposing the DEK in plaintext.

Exam trap

HashiCorp often tests the misconception that Vault's Transit engine can batch multiple data items in a single API call, but Transit only supports single-item encrypt/decrypt operations per request, making envelope encryption the only viable solution for high-throughput streaming data.

How to eliminate wrong answers

Option A is wrong because switching to Database or PKI secrets engines does not provide encryption-as-a-service; they generate credentials or certificates, not encrypt data, and would not reduce API calls for encryption. Option C is wrong because scaling Vault nodes and load balancing only distributes the same per-event API call load, not reducing the number of calls; the bottleneck is the per-event encryption request, not node capacity. Option D is wrong because Vault's Transit engine does not support batch encryption in a single API call; each event still requires a separate encrypt operation, so batching is not a feature of Transit and would not reduce API calls.

Full explanation →

206

MCQeasy

Which Vault API path is used to encrypt data with the transit engine?

A./v1/transit/enc/

B./v1/transit/encrypt/

C./v1/transit/encrypt/{keyname}

D./v1/transit/encryption/

E./v1/transit/encryption/{keyname}

AnswerC

This is the standard endpoint for transit encryption.

Why this answer

The Vault transit engine uses the exact path `/v1/transit/encrypt/{keyname}` to encrypt plaintext data. The `{keyname}` parameter specifies the named encryption key stored in the transit engine, and the API endpoint expects a POST request with the plaintext base64-encoded in the request body. This path aligns with Vault's RESTful design where the action (`encrypt`) is a sub-path under the transit mount, and the key name is a required path parameter.

Exam trap

HashiCorp often tests the exact API path syntax, and the trap here is that candidates confuse the action verb 'encrypt' with the noun 'encryption' or use abbreviations, leading them to pick options like D or E that sound correct but use the wrong word.

How to eliminate wrong answers

Option A is wrong because `/v1/transit/enc/` uses an incomplete and non-standard abbreviation ('enc' instead of 'encrypt'), which does not match Vault's documented API. Option B is wrong because `/v1/transit/encrypt/` omits the required key name parameter; Vault's transit encrypt endpoint requires the key name as part of the path, not as a query parameter or request body field. Option D is wrong because `/v1/transit/encryption/` uses the full word 'encryption' instead of the correct action verb 'encrypt', and also lacks the key name.

Option E is wrong because while it includes the key name, it uses 'encryption' instead of 'encrypt'; Vault's API is case-sensitive and uses the exact verb 'encrypt' for this operation.

Full explanation →

207

MCQmedium

A DevOps team is using Vault tokens for authentication in CI/CD pipelines. They notice that tokens are often expired before the pipeline completes, causing failures. Which Vault feature should they use to address this without manual intervention?

A.Use batch tokens for better performance

B.Use periodic tokens with a short period and allow renewal

C.Create orphan tokens so they don't expire with the parent

D.Increase the default TTL on the token auth method

AnswerB

Periodic tokens can be renewed before expiration as long as they are within max TTL.

Why this answer

Periodic tokens are designed for long-running processes like CI/CD pipelines. They have no maximum TTL and can be renewed indefinitely as long as the renewal occurs before the current token's TTL expires. By using a periodic token with a short period and enabling automatic renewal in the pipeline, the token stays valid without manual intervention, solving the expiration issue.

Exam trap

HashiCorp often tests the misconception that increasing TTL or using orphan tokens solves indefinite expiration, but the key is that periodic tokens are the only token type designed for renewable, long-lived use without a hard upper limit.

How to eliminate wrong answers

Option A is wrong because batch tokens are stateless and cannot be renewed; they have a fixed TTL and are unsuitable for long-running pipelines. Option C is wrong because orphan tokens are detached from their parent but still have a finite TTL and must be renewed; they do not inherently prevent expiration. Option D is wrong because increasing the default TTL on the token auth method only extends the initial validity but does not allow indefinite renewal; the token will still eventually expire, and manual intervention would be needed to re-authenticate.

Full explanation →

208

MCQeasy

Based on the exhibit, what is the maximum total lifespan of this lease?

A.2 hours

B.90 minutes

C.1 hour

D.30 minutes

AnswerC

The max_ttl indicates the maximum total lifespan.

Why this answer

The lease duration for a Vault lease is specified in seconds, and the exhibit shows a lease duration of 3600 seconds. Converting 3600 seconds to hours gives exactly 1 hour (3600 / 3600 = 1). This represents the maximum total lifespan of the lease before it expires or must be renewed.

Exam trap

A common trap is misreading the lease duration unit: Vault displays lease durations in seconds, but candidates may mistakenly interpret them as minutes. In this question, 3600 seconds equals 1 hour, not 90 minutes or 2 hours.

How to eliminate wrong answers

Option A is wrong because 2 hours would correspond to 7200 seconds, which is not the value shown in the exhibit. Option B is wrong because 90 minutes equals 5400 seconds, not the 3600 seconds displayed. Option D is wrong because 30 minutes equals 1800 seconds, which is half the actual lease duration of 3600 seconds.

Full explanation →

209

MCQeasy

A company deploys Vault in a single data center with 3 nodes using Integrated Storage. The application team reports that secret reads are slow, with median latency of 200ms. The Vault cluster is under moderate load of 100 requests per second. The administrator checks the server metrics and sees that the Raft commit latency is low, but the HTTP request handling time is high. The Vault nodes are running on virtual machines with 4 vCPUs and 8GB RAM each. The administrator suspects that the bottleneck is due to resource contention. What should the administrator do to reduce read latency without compromising availability?

A.Add performance standby nodes to the cluster to handle read requests.

B.Increase the CPU and memory of the existing Vault nodes.

C.Switch to a Consul storage backend with more Consul servers.

D.Add more Vault nodes to the cluster to distribute read load.

AnswerA

Performance standbys reduce read latency by bypassing Raft.

Why this answer

Adding performance standby nodes is the correct solution because they are specifically designed to handle read requests without participating in the Raft consensus protocol. Since the bottleneck is high HTTP request handling time (not Raft commit latency), performance standbys offload read traffic from the active cluster nodes, reducing latency without affecting write availability or requiring changes to the existing cluster topology.

Exam trap

HashiCorp often tests the distinction between scaling reads with performance standbys versus scaling the cluster with additional Raft nodes, where candidates mistakenly assume adding more cluster nodes will improve read performance without considering the consensus overhead.

How to eliminate wrong answers

Option B is wrong because increasing CPU and memory addresses resource contention, but the metrics show low Raft commit latency and high HTTP request handling time, indicating the bottleneck is at the application layer (request handling), not compute resources; scaling vertically may not resolve the issue and could be less cost-effective. Option C is wrong because switching to a Consul storage backend introduces additional complexity and dependency on Consul servers, and the current issue is not related to storage backend performance (Raft commit latency is low); this would not directly reduce HTTP request handling time. Option D is wrong because adding more Vault nodes to the cluster increases the number of Raft participants, which can actually increase write latency and complexity, and does not specifically address read latency since all nodes in a Raft cluster can handle reads but still share the same consensus overhead; performance standbys are a more targeted solution for read scaling.

Full explanation →

210

MCQhard

An administrator runs the commands shown in the exhibit. Later, they run 'vault kv delete kv-v2/secret' and then 'vault kv undelete -versions=1 kv-v2/secret' to recover the secret. Which command must the administrator run to verify that the secret is now readable?

A.vault kv list kv-v2/secret

B.vault read kv-v2/data/secret

C.vault kv get kv-v2/secret

D.vault kv metadata get kv-v2/secret

AnswerC

After undelete, the secret is readable; this command retrieves the data.

Why this answer

'vault kv get' is the standard command to read and display the latest version of a secret from a KV v2 secrets engine. After running 'vault kv undelete -versions=1', version 1 is restored from a deleted state, and 'vault kv get kv-v2/secret' will retrieve and show that version's data, confirming it is readable.

Exam trap

HashiCorp often tests the distinction between 'vault kv get' (reads secret data) and 'vault kv metadata get' (reads metadata only), leading candidates to choose the metadata command when they need to verify data readability.

How to eliminate wrong answers

Option A is wrong because 'vault kv list' lists the secret paths under a given path, not the data of a specific secret; it would show 'secret' as a key but not its values. Option B is wrong because 'vault read kv-v2/data/secret' is the correct raw API path for reading a KV v2 secret, but the question asks for the command to verify readability, and the standard CLI command is 'vault kv get', not 'vault read' (though 'vault read' would also work technically, it is not the intended answer in the context of the 'kv' subcommand). Option D is wrong because 'vault kv metadata get' retrieves metadata (like version info, deletion time, created time) but does not return the secret's actual data, so it cannot verify that the secret is readable.

Full explanation →

211

Multi-Selecteasy

Which TWO of the following are valid token states?

Select 2 answers

A.Expired

B.Orphan

C.Suspended

D.Revoked

E.Active

AnswersD, E

A revoked token is invalid.

Why this answer

'Revoked' is a valid token state in Vault. Tokens can be explicitly revoked, rendering them unusable. Option E is correct because 'Active' is the initial state of a token when it is created and remains valid until it expires or is revoked.

Options A, B, and C are not valid token states in Vault: 'Expired' is a result of TTL expiry but not a distinct state; 'Orphan' describes a token whose parent is gone, but it is still considered active if not revoked; 'Suspended' is not a Vault token state.

Exam trap

HashiCorp often tests the distinction between token lifecycle states and token properties (like orphan status) to confuse candidates who may think 'orphan' or 'suspended' are official states, when in fact only 'Active' and 'Revoked' are the primary valid token states in Vault.

Full explanation →

212

Multi-Selectmedium

Which TWO of the following are valid methods to authenticate to Vault using the CLI?

Select 2 answers

A.vault auth -method=token token=s.abc

B.vault login -method=userpass username=jdoe

C.vault authenticate -method=userpass username=jdoe

D.Setting environment variable VAULT_AUTH=s.abc

E.vault login -method=ldap username=jdoe

AnswersB, E

Valid; userpass authentication via CLI.

Why this answer

`vault login -method=userpass username=jdoe` is the valid CLI command to authenticate using the userpass auth method, which prompts for the password interactively. Option E is correct because `vault login -method=ldap username=jdoe` is the valid CLI command to authenticate using the LDAP auth method, also prompting for the password. Both commands follow the standard `vault login -method=<type>` syntax required by the Vault CLI.

Exam trap

HashiCorp often tests the distinction between the deprecated `vault auth` and the current `vault login` command, as well as the correct environment variable (`VAULT_TOKEN` vs. `VAULT_AUTH`), to catch candidates who rely on outdated documentation or assume generic naming conventions.

Full explanation →

213

MCQeasy

A company runs multiple microservices in a Kubernetes cluster. Each microservice authenticates to Vault using a service token created via the token auth method. The tokens are created with a default TTL of 72h, a max TTL of 168h, and renewable set to true. The services are configured to renew their tokens when the remaining TTL drops below 24h. Recently, some tokens have been expiring prematurely, causing service outages. Upon investigation, you find that the expired tokens were created with a role that includes explicit_max_ttl = 72h. The services see the TTL decreasing normally, but then it jumps to zero even though the services attempted renewal. What is the most likely cause and correct action?

A.Configure the services to renew the token when TTL drops below 48h.

B.Remove the explicit_max_ttl setting from the role or set it to 0.

C.Increase the default TTL on the token auth mount to 168h.

D.Set max_ttl on the role to 72h.

AnswerB

Removing explicit_max_ttl allows tokens to be renewed up to the max TTL of 168h.

Why this answer

The `explicit_max_ttl` setting on the role overrides the token's renewable property. When a token has an `explicit_max_ttl` of 72h, it cannot be renewed beyond that absolute lifetime, regardless of the `renewable = true` setting. The services attempt renewal, but Vault enforces the hard limit, causing the TTL to jump to zero at the 72-hour mark.

Removing `explicit_max_ttl` or setting it to 0 allows the token to be renewed up to the system's `max_ttl` (168h), preventing premature expiration.

Exam trap

In HashiCorp Vault, the distinction between `max_ttl` (which can be extended by renewal up to the mount's limit) and `explicit_max_ttl` (which is an absolute, non-renewable cap) is crucial. Candidates often overlook that `explicit_max_ttl` overrides the renewable property, causing premature token expiration.

How to eliminate wrong answers

Option A is wrong because increasing the renewal threshold to 48h does not address the root cause; the token will still hit the `explicit_max_ttl` hard limit and expire at 72h regardless of when renewal is attempted. Option C is wrong because increasing the default TTL on the token auth mount to 168h does not override the role's `explicit_max_ttl` of 72h; the explicit maximum takes precedence and still caps the token's lifetime. Option D is wrong because setting `max_ttl` on the role to 72h would actually enforce the same hard limit as `explicit_max_ttl`, making the problem worse or identical, not fixing it.

Full explanation →

214

MCQmedium

Refer to the exhibit. A DevOps engineer runs `vault read -format=json transit/keys/mykey` and receives the output shown. A microservice attempts to decrypt data that was encrypted with version 1 of the key. Will the decryption succeed?

A.Yes, because min_decryption_version does not affect decryption.

B.Yes, because min_decryption_version is 1, which allows decryption with version 1 and higher.

C.No, because min_decryption_version is 1, so only version 2 and higher can decrypt.

D.No, because the data was encrypted with version 1 and min_decryption_version is 1, so decryption is blocked.

AnswerB

Correct interpretation of min_decryption_version.

Why this answer

The `min_decryption_version` parameter in Vault's transit secrets engine specifies the lowest key version that can be used for decryption. In the exhibit, `min_decryption_version` is set to 1, meaning any version from 1 upward is allowed. Since the data was encrypted with version 1, decryption will succeed.

This parameter does not block decryption with version 1; it only prevents decryption with versions lower than the specified value.

Exam trap

The trap here is that candidates often misinterpret `min_decryption_version` as a minimum version that is required (i.e., only versions above that number are allowed), when in fact it means the minimum version that is still permitted — so version 1 is allowed if the value is 1.

How to eliminate wrong answers

Option A is wrong because `min_decryption_version` does affect decryption — it explicitly controls which key versions are permitted for decryption operations. Option C is wrong because a `min_decryption_version` of 1 allows decryption with version 1 and higher, not only version 2 and higher. Option D is wrong because setting `min_decryption_version` to 1 does not block decryption with version 1; it actually permits it.

Full explanation →

215

MCQeasy

A developer wants to authenticate to Vault using LDAP credentials. Which CLI command should they use?

A.vault login -method=ldap username=john

B.vault token create -policy=ldap

C.vault write auth/ldap/login username=john

D.vault auth enable ldap

AnswerA

Correct. vault login -method=ldap is the standard CLI command to authenticate using LDAP credentials. It prompts for the password or accepts the -password flag, and returns a Vault token upon successful authentication.

Why this answer

`vault login -method=ldap username=john` is the standard Vault CLI command to authenticate using LDAP credentials. This command triggers the LDAP auth method, prompting the user for their password (or accepting it via `-password` flag) and returning a Vault token upon successful authentication against the configured LDAP server.

Exam trap

The trap here is that candidates confuse the raw API endpoint (`vault write auth/ldap/login`) with the correct CLI login command (`vault login -method=ldap`), or mistake enabling the auth method for performing authentication.

How to eliminate wrong answers

Option B is wrong because `vault token create -policy=ldap` creates a new token with a specified policy, but it does not perform LDAP authentication; it requires an existing valid token and is used for token management, not for logging in with LDAP credentials. Option C is wrong because `vault write auth/ldap/login username=john` is an API-style command that would require the password to be passed in the request body (e.g., via `-password` flag or stdin), but the question specifies using the CLI, and the standard CLI command for login is `vault login -method=ldap`, not a raw write operation. Option D is wrong because `vault auth enable ldap` enables the LDAP auth method at a path (default `auth/ldap`), but it does not perform authentication; it is an administrative operation to configure the backend, not a login command.

Full explanation →

216

MCQhard

A large enterprise runs Vault in a production environment with multiple secrets engines, including databases, AWS, and PKI. Recently, the operations team noticed that the number of active leases has grown significantly, causing performance degradation in Vault. The team suspects that many leases are orphaned or expired but not cleaned up. They run the vault lease tidy command regularly, but the issue persists. The vault audit logs show no errors during revocation. However, the team observes that the database credentials are being revoked correctly, but the PKI certificates are not being revoked when their leases expire. Additionally, some AWS IAM user leases seem to persist beyond their max TTL. What is the most likely cause of this issue?

A.The max_ttl setting for the PKI and AWS roles is set incorrectly.

B.The vault lease tidy command is not effective for PKI and AWS secrets engines.

C.The PKI and AWS secrets engines require explicit revocation of the underlying secret, which is not triggered by lease expiration alone.

D.The Vault server's clock is out of sync, causing lease expiration calculations to be inaccurate.

AnswerC

Lease expiration does not automatically revoke certificates or IAM users; explicit revocation is needed.

Why this answer

In Vault, lease expiration triggers revocation only for secrets engines that support automatic revocation at the Vault level. The PKI secrets engine does not automatically revoke issued certificates when a lease expires; it only removes the lease metadata. Similarly, AWS IAM user credentials are not automatically revoked upon lease expiration because the underlying secret (the IAM user or access key) must be explicitly revoked via the AWS API.

The `vault lease tidy` command cleans up stale lease entries in Vault's storage but does not trigger revocation of the underlying secrets for these engines.

Exam trap

HashiCorp Vault often tests the misconception that lease expiration always triggers revocation of the underlying secret, but in reality, some secrets engines (like PKI and AWS) require explicit revocation actions separate from lease lifecycle management.

How to eliminate wrong answers

Option A is wrong because the max_ttl setting controls the maximum lifetime of a lease, but the issue is not about the lease duration; it is about the failure to revoke the underlying secret when the lease expires. Option B is wrong because the `vault lease tidy` command is effective for cleaning up orphaned lease entries in Vault's storage, but it does not perform revocation of secrets for engines like PKI and AWS that require explicit revocation. Option D is wrong because clock skew would affect lease expiration calculations globally, but the audit logs show no errors during revocation, and the database credentials are being revoked correctly, indicating that clock sync is not the issue.

Full explanation →

217

MCQeasy

Refer to the exhibit. What does min_decryption_version = 1 indicate?

A.Data encrypted with version 1 can only be decrypted with version 1.

B.Only data encrypted with version 1 or higher can be decrypted.

C.Version 1 is the minimum version that can be used for decryption.

D.All ciphertext must be rewrapped to version 1.

E.Version 1 keys are not allowed for decryption.

AnswerC

Decryption requests must use a key version >= min_decryption_version.

Why this answer

In Vault Enterprise, the `min_decryption_version` parameter on a transit key specifies the lowest key version that is allowed to decrypt existing ciphertext. Setting `min_decryption_version = 1` means that any key version from 1 up to the current version can be used for decryption; version 1 is the minimum allowed. This ensures backward compatibility while allowing newer versions to be used for encryption.

Exam trap

HashiCorp often tests the distinction between `min_encryption_version` and `min_decryption_version`; the trap here is confusing which parameter controls encryption versus decryption, leading candidates to incorrectly assume `min_decryption_version` restricts encryption or forces rewrapping.

How to eliminate wrong answers

Option A is wrong because `min_decryption_version = 1` does not restrict decryption to only version 1; it allows version 1 and any higher version to decrypt. Option B is wrong because it implies a minimum encryption version, but `min_decryption_version` controls decryption, not encryption; data encrypted with version 1 can be decrypted by version 1 or higher, but the statement is reversed and imprecise. Option D is wrong because `min_decryption_version` does not force rewrapping of ciphertext; rewrapping is a separate operation (e.g., `rewrap` API) and is not automatically triggered by this setting.

Option E is wrong because version 1 keys are explicitly allowed for decryption when `min_decryption_version = 1`; setting it to 1 means version 1 is the lowest permitted, not forbidden.

Full explanation →

218

MCQhard

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

A.The binddn or bindpass configured in Vault is incorrect

B.Vault is not configured to use SSL/TLS for LDAP

C.The LDAP server does not allow anonymous binds

D.The LDAP server certificate is not trusted by Vault

AnswerA

Incorrect bind credentials cause bind failures.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

219

Drag & Dropmedium

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

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct order is to first enable the Transit secrets engine, then create a key, use the key to encrypt and decrypt data, and finally rotate the key for security. Enabling creates the path, key creation provides the encryption material, and rotation updates the key without interrupting operations.

Full explanation →

220

MCQhard

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

A.Remove the 'admin' policy from all human users and require them to use a different authentication method.

B.Implement a Sentinel policy that blocks token creation by any user except the CI/CD pipeline.

C.Create a dedicated token role with a max TTL of 720h (30 days) and restrict token creation to that role; revoke the 'admin' policy's create permission on auth/token/create.

D.Reduce the system max lease TTL to 720h (30 days) and enforce that all tokens must have explicit_max_ttl set.

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

221

MCQeasy

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

A.The ciphertext is encrypted with a different key

B.The Vault server is not configured with the transit engine

C.The key mykey does not exist

D.The ciphertext provided is not valid base64

E.The token used does not have permission to decrypt

AnswerD

Directly matches the error message.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Full explanation →

222

MCQeasy

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

A.The cluster is not initialized.

B.The cluster does not have HA enabled.

C.The Vault cluster is sealed.

D.The cluster has no active leader.

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

223

Multi-Selectmedium

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

Select 2 answers

A.The user needs to use the token's accessor to read the secret

B.The path in the policy needs to be 'secret/data/team-alpha/*'

C.The token may have an additional restrictive policy from a parent token

D.The secret engine is not tuned to allow reads

E.The token is not a child of the root token

AnswersB, C

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

Why this answer

KV v2 engine requires the path prefix 'data/' after the mount path to access the actual secret data. The policy path 'secret/team-alpha/*' only covers the metadata and sub-paths, not the data endpoint. To read a secret, the policy must specify 'secret/data/team-alpha/*' with 'read' capability, as the actual secret retrieval occurs via the 'data/' sub-path.

Exam trap

Hashicorp Vault often tests the distinction between KV v1 and KV v2 path structures, specifically that KV v2 requires the 'data/' prefix in policies, which candidates frequently overlook.

Full explanation →

224

MCQhard

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

A.A root token

B.A periodic token

C.A service token with a short TTL

D.A batch token

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

225

MCQeasy

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

A.Use Vault's batch encryption

B.Use Vault's seal-wrapping feature

C.Use Vault's datakey endpoint to get a data encryption key, encrypt locally, then wrap with Vault

D.Encrypt the file directly with Vault's transit encrypt API

E.Split the file into chunks and encrypt each chunk via transit

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Full explanation →

HashiCorp Vault Associate VA-003 (VA-003) — Questions 151–225