HashiCorp Vault Associate VA-003 VA-003 Questions 451–498 | Page 7/7

451

MCQmedium

The token was created 12 hours ago and has not been used yet. What will happen if the token is not used or renewed?

A.It can be renewed indefinitely if used

B.It will expire when the number of uses reaches 0

C.It will expire immediately because it was not used within 12 hours

D.It will expire in 12 hours

AnswerD

The current TTL is 12h, so without renewal, it expires in 12 hours.

Why this answer

Vault tokens have a configurable Time-To-Live (TTL) and a maximum TTL. If a token is not used within its TTL, it will expire. Since the token was created 12 hours ago and has not been used, and the default TTL for many token types in Vault is 24 hours, the token will expire in 12 hours (the remaining TTL).

This is because the token's TTL begins counting down from creation, not from first use.

Exam trap

A common misconception is that tokens expire after a fixed period of non-use, but in Vault the TTL counts down from creation, and non-use simply means the token will not be renewed or its TTL extended.

How to eliminate wrong answers

Option A is wrong because a token cannot be renewed indefinitely; it has a maximum TTL (often 24 hours by default) beyond which it cannot be renewed, even if used. Option B is wrong because tokens do not have a 'number of uses' counter that determines expiration; they have a TTL and an explicit max uses parameter (if set), but expiration is primarily time-based. Option C is wrong because the token does not expire immediately after 12 hours of non-use; it expires when its TTL (e.g., 24 hours) elapses, which would be 12 hours from now.

Full explanation →

452

MCQhard

An application uses a periodic token with period=24h. The application renews every 12h. After 48h, the token is still valid. After 72h, the token is still valid. What is the maximum lifetime of this periodic token?

A.Unlimited (as long as it keeps renewing)

B.72h

C.48h

D.24h

AnswerA

Periodic tokens have no max TTL and can be renewed indefinitely.

Why this answer

A periodic token with a defined period (e.g., 24h) has no maximum lifetime; it remains valid indefinitely as long as it is renewed before the period expires. In this scenario, the token is renewed every 12h (well within the 24h period), so after 48h and 72h it is still valid because each renewal resets the token's lifetime, effectively giving it an unlimited lifespan. This behavior is inherent to periodic tokens in Vault, which are designed for long-lived sessions with regular re-authentication.

Exam trap

The trap here is that candidates confuse the token's period (the renewal window) with a maximum lifetime, assuming the token expires after the period even if renewed, when in fact periodic tokens can be renewed indefinitely as long as the renewal occurs before the period ends.

How to eliminate wrong answers

Option B (72h) is wrong because it assumes a fixed maximum lifetime, but periodic tokens have no hard upper limit—they can be renewed indefinitely. Option C (48h) is wrong because it incorrectly interprets the renewal interval as the token's maximum lifetime, whereas the token's validity depends on the period (24h) and renewal before expiry. Option D (24h) is wrong because it confuses the token's period (the window for renewal) with a maximum lifetime; the token does not expire after 24h if renewed within that window.

Full explanation →

453

MCQeasy

A developer needs a token that can be used only 5 times and must expire after 24 hours, regardless of the number of uses. Which token creation method should be used to enforce these constraints?

A.Create a token directly with num_uses=5

B.Use a token role with num_uses=5 and ttl=24h

C.Create a token directly with ttl=24h

D.Create a periodic token with period set to 24h

AnswerB

Token roles allow explicit limits on both number of uses and time-to-live.

Why this answer

A token role with both `num_uses=5` and `ttl=24h` enforces both constraints: the token can be used only 5 times and will expire after 24 hours, regardless of which limit is reached first. Creating a token directly with only `num_uses` or only `ttl` would miss one constraint, and a periodic token ignores the `num_uses` limit entirely.

Exam trap

A common misconception is that a token created directly with `num_uses` or `ttl` alone can satisfy both constraints, or that periodic tokens can enforce a fixed use limit, when in fact only a token role with both parameters set achieves the combined behavior.

How to eliminate wrong answers

Option A is wrong because creating a token directly with `num_uses=5` sets a use limit but does not enforce a time-based expiration, so the token could remain valid indefinitely if not fully consumed. Option C is wrong because creating a token directly with `ttl=24h` sets a time-based expiration but does not limit the number of uses, allowing unlimited usage within the 24-hour window. Option D is wrong because a periodic token with `period=24h` extends the token's lifetime indefinitely as long as it is renewed before expiry, and it does not support a `num_uses` constraint, so it cannot enforce a fixed use limit.

Full explanation →

454

Matchingmedium

Match each Vault response wrapping feature to its description.

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

Concepts

Matches

Lifetime of the wrapping token

Single-use token to unwrap response

Token-scoped storage for wrapped data

Retrieve the original response

Why these pairings

In Vault, response wrapping uses a single-use token with a cubbyhole to store secrets, and the TTL determines its validity. Common confusions include thinking the token can be reused or that cubbyhole is a replicated storage engine.

Full explanation →

455

MCQmedium

A developer has a policy that grants 'create' capability on path 'secret/data/team/*'. They successfully create a new secret using 'vault kv put secret/data/team/db', but when they try to update the same secret with new data, they get a permission denied error. What is the most likely cause?

A.The developer does not have the 'create' capability on the parent path.

B.The policy does not include the 'update' capability, which is required for modifying existing secrets.

C.The policy needs the 'list' capability on the path.

D.The developer's token lacks the 'sudo' capability for updates.

AnswerB

KV v2 requires separate 'update' capability for modifications.

Why this answer

In Vault, the 'kv put' command performs a 'create' operation when the secret does not exist, but an 'update' operation when it does. The policy only grants 'create' capability on 'secret/data/team/*', which allows the initial write but not subsequent modifications. To update an existing secret, the policy must also include the 'update' capability on the same path, as Vault's ACL system enforces separate capabilities for creating and updating secrets.

Exam trap

A common misconception in Vault is that 'kv put' is a single operation, when in fact Vault treats the first write as 'create' and subsequent writes as 'update', requiring separate capabilities in the policy.

How to eliminate wrong answers

Option A is wrong because the developer successfully created the secret, which requires 'create' capability on the exact path 'secret/data/team/db' — the parent path 'secret/data/team/*' is irrelevant since the policy already covers the child path. Option C is wrong because the 'list' capability is only needed for listing secrets under a path (e.g., 'vault kv list'), not for updating an existing secret. Option D is wrong because Vault does not require 'sudo' capability for updates; 'sudo' is a special capability for certain privileged operations (e.g., writing to 'sys/') and is unrelated to KV secret updates.

Full explanation →

456

MCQhard

After rotating the 'payment-key', Vault successfully decrypts data encrypted with the old key (v1). What is the most likely reason the decryption succeeded?

A.The old key version is retained and used for decryption when the ciphertext references that version.

B.The old key version is automatically deleted after rotation, but the ciphertext contains the key version and is decrypted by the new key.

C.The ciphertext contains the original plaintext, so decryption simply extracts it.

D.The plaintext is stored in Vault during encryption, so decryption retrieves the stored plaintext.

AnswerA

Vault retains old key versions for decryption, and the ciphertext includes the version identifier, allowing decryption with the appropriate key.

Why this answer

A is correct because Vault uses key versioning: when a key is rotated, the old key version (v1) is retained for decryption purposes. The ciphertext includes metadata referencing the key version used for encryption, so Vault automatically selects the correct old key version to decrypt data encrypted before rotation. This ensures backward compatibility without re-encrypting existing data.

Exam trap

HashiCorp often tests the misconception that key rotation invalidates old ciphertext, but the trap here is that candidates assume the old key is deleted or replaced, when in fact Vault retains it for decryption based on ciphertext metadata.

How to eliminate wrong answers

Option B is wrong because Vault does not automatically delete the old key version after rotation; it retains it for decryption, and the new key cannot decrypt data encrypted with the old key due to different cryptographic material. Option C is wrong because ciphertext does not contain the original plaintext; it contains encrypted data that requires the correct key and algorithm to decrypt. Option D is wrong because Vault does not store plaintext during encryption; it only stores ciphertext and metadata, and decryption is a cryptographic operation, not a retrieval of stored plaintext.

Full explanation →

457

Multi-Selecthard

Which of the following are valid ways to authenticate to Vault? (Select all that apply.)

Select 4 answers

A.SAML 2.0

B.GitHub personal access token

C.Kubernetes auth

D.LDAP authentication

E.AWS EC2 instance metadata

AnswersA, B, C, D

Vault does not support SAML directly; it supports OpenID Connect.

Why this answer

All of SAML 2.0, GitHub personal access token, Kubernetes auth, and LDAP authentication are valid Vault authentication methods. The SAML auth method (via plugin) enables integration with identity providers; the GitHub auth method uses personal access tokens to authenticate based on team membership; Kubernetes auth allows authentication using a Kubernetes Service Account Token; and LDAP authentication provides integration with LDAP directories. AWS EC2 instance metadata is not a direct Vault authentication method, though Vault's AWS auth method can use EC2 metadata for authentication.

Exam trap

A common mistake is to assume that only built-in auth methods like token, LDAP, or Kubernetes are valid, while forgetting that plugin-based methods like SAML and external integrations like GitHub are also officially supported. This question tests knowledge of the breadth of supported auth methods.

Full explanation →

458

MCQhard

A Vault policy includes the following statement: path "secret/data/+/app" { capabilities = ["read"] }. Which paths would match this policy? (Assume KV v2)

A.secret/data/team-a/app/db

B.secret/data/team-a/team-b/app

C.secret/data/app

D.secret/data/team-a/app

AnswerD

Team-a is one segment, matching the +.

Why this answer

In Vault KV v2, the path structure is `secret/data/<path>`, and the `+` glob matches a single path segment. The policy `secret/data/+/app` matches exactly one segment between `data/` and `/app`. Option D, `secret/data/team-a/app`, has a single segment `team-a` before `app`, so it matches.

Options with additional segments (A, B) or missing the required segment (C) do not match.

Exam trap

The glob pattern `+` matches exactly one path segment. In KV v2, the path must include the `data/` prefix. Candidates may mistakenly believe that `+` can match multiple segments (like `*`) or that the `data/` prefix is not required, but this question tests both concepts.

How to eliminate wrong answers

Option A is wrong because `secret/data/team-a/app/db` has two segments after `data/` (`team-a/app/db`), and the `+` glob matches only one segment, so the extra `/db` segment causes a mismatch. Option B is wrong because `secret/data/team-a/team-b/app` has three segments after `data/` (`team-a/team-b/app`), exceeding the single-segment match of `+`. Option C is wrong because `secret/data/app` has zero segments between `data/` and `app`; the `+` requires exactly one segment, so this path does not match.

Full explanation →

459

MCQmedium

Refer to the exhibit. A user with this policy can successfully read credentials but cannot renew the lease. What is the missing capability?

A.'list' on sys/leases/.

B.'renew' on the secret path.

C.'sudo' on sys/leases/.

D.'update' on sys/leases/renew.

AnswerD

This capability is required to perform lease renewal.

Why this answer

The user can read credentials but cannot renew the lease because the policy grants 'read' and 'list' capabilities on the secret path, but renewing a lease requires the 'update' capability on the 'sys/leases/renew' endpoint. This endpoint is used to extend the lifetime of a lease, and without 'update' access, the renewal request is denied.

Exam trap

HashiCorp often tests the distinction between capabilities on the secret path versus the system lease path, leading candidates to mistakenly think 'read' or 'list' on the secret path is sufficient for renewal.

How to eliminate wrong answers

Option A is wrong because 'list' on 'sys/leases/' allows listing active leases but does not grant the ability to renew a specific lease; renewal requires a different endpoint and capability. Option B is wrong because 'renew' is not a valid capability in Vault's policy language; capabilities are 'create', 'read', 'update', 'delete', 'list', and 'sudo', and the renewal action is mapped to 'update' on the 'sys/leases/renew' path. Option C is wrong because 'sudo' on 'sys/leases/' provides elevated privileges for certain operations but does not specifically grant the 'update' capability needed for lease renewal; 'sudo' is a modifier that bypasses ACL checks but still requires the appropriate capability on the endpoint.

Full explanation →

460

MCQmedium

A Vault administrator is troubleshooting an issue where after a network outage, the Vault cluster is sealed and cannot be unsealed. The cluster has 5 nodes using Integrated Storage. The administrator runs `vault status` on each node and receives 'sealed' response. The administrator suspects that the cluster lost quorum during the outage. The administrator checks the Raft configuration and finds that there are 3 voter nodes and 2 non-voter nodes. Which action should the administrator take to recover the cluster?

A.Manually unseal all nodes simultaneously.

B.Use `vault operator raft remove-peer` to remove the non-voter nodes.

C.Use `vault operator raft recover` on one of the non-voter nodes.

D.Use `vault operator raft recover` on a voter node to create a new cluster.

AnswerD

Raft recover on a voter node restores quorum.

Why this answer

When a Vault cluster with Integrated Storage loses quorum (more than half of voter nodes are unavailable), the cluster cannot unseal because Raft requires a quorum of voters to elect a leader and process operations. Since all 5 nodes are sealed and the cluster has 3 voters, the outage likely caused the loss of at least 2 voters, breaking quorum. The correct recovery procedure is to use `vault operator raft recover` on a voter node, which creates a new single-node cluster with the existing data, allowing the administrator to then unseal and rejoin other nodes.

Exam trap

HashiCorp often tests the distinction between voter and non-voter roles in Raft; the trap here is assuming that any node can be used for recovery, when in fact only a voter node can bootstrap a new cluster because non-voters lack the quorum-critical state.

How to eliminate wrong answers

Option A is wrong because manually unsealing all nodes simultaneously does not restore Raft quorum; the cluster still lacks a leader and cannot process operations. Option B is wrong because `vault operator raft remove-peer` is used to remove a peer from the Raft configuration when the node is unreachable but quorum still exists; here quorum is lost, so the command will fail or be ineffective. Option C is wrong because `vault operator raft recover` must be run on a voter node, not a non-voter; non-voters do not participate in quorum and cannot bootstrap a new cluster.

Full explanation →

461

MCQhard

An organization uses the AWS secrets engine to generate IAM users for each application. They want to ensure that if a Vault server is compromised, the attacker cannot use the AWS secrets engine configuration to gain access to the AWS account. Which additional security measure should be implemented?

A.Enable Vault's seal wrapping to encrypt the engine configuration

B.Store the AWS access key used by the engine in a separate Vault instance

C.Use a dedicated Vault server for the AWS engine

D.Use a non-root IAM user with minimal privileges for the engine and restrict the engine's role policies to the minimum needed

AnswerD

This limits what the attacker can do with the engine's credentials.

Why this answer

The core principle of least privilege ensures that even if the Vault server is compromised, the attacker can only perform actions allowed by the minimal IAM policy attached to the non-root user. This limits the blast radius, preventing the attacker from gaining full administrative access to the AWS account. The AWS secrets engine uses the configured IAM credentials to create temporary IAM users, so restricting those credentials to only the necessary permissions is the most effective mitigation.

Exam trap

HashiCorp often tests the misconception that encryption or isolation (seal wrapping, separate instances) is sufficient to protect against credential abuse, when in reality the underlying IAM permissions are the critical control.

How to eliminate wrong answers

Option A is wrong because seal wrapping encrypts the engine configuration at rest and in transit, but it does not limit the permissions of the underlying AWS credentials; if the Vault server is compromised, the attacker can still use the decrypted credentials to perform any action allowed by the IAM policy. Option B is wrong because storing the AWS access key in a separate Vault instance does not prevent an attacker who compromises the primary Vault server from using the engine's configuration to call the AWS API; the attacker would still have access to the credentials via the engine's storage backend. Option C is wrong because using a dedicated Vault server for the AWS engine does not reduce the risk; if that dedicated server is compromised, the attacker still has full access to the AWS credentials configured in the engine.

Full explanation →

462

MCQhard

A Vault cluster has several policies. One policy, "app-policy", contains: path "secret/data/app/*" { capabilities = ["create", "update"] }. Another policy, "admin-policy", includes: path "secret/data/app/db" { capabilities = ["deny"] }. A token is attached with both policies. Can the token write to "secret/data/app/db"?

A.No, because the paths conflict.

B.No, because deny takes precedence over allow.

C.Yes, because policies are additive.

D.Yes, because the first policy allows create/update.

AnswerB

Deny always takes precedence, so the token cannot write to that path.

Why this answer

B is correct because in Vault, the 'deny' capability takes precedence over all other capabilities. When a token has multiple policies attached, Vault evaluates all matching paths and applies the most restrictive result. Since 'admin-policy' explicitly denies access to 'secret/data/app/db', the token cannot write to that path, regardless of the 'create' and 'update' capabilities granted by 'app-policy'.

Exam trap

A common pitfall in Vault is assuming that policies are purely additive, overlooking that a 'deny' capability in any matching policy overrides all other capabilities.

How to eliminate wrong answers

Option A is wrong because path conflicts are resolved by capability precedence, not by blocking the operation outright; Vault uses a most-restrictive model where 'deny' overrides all allows. Option C is wrong because while policies are additive for non-conflicting capabilities, 'deny' is not additive—it is an absolute override that negates any allow on the same path. Option D is wrong because the first policy's 'create' and 'update' capabilities are overridden by the explicit 'deny' in the second policy; Vault does not use a first-match or additive model when 'deny' is present.

Full explanation →

463

MCQeasy

An engineer wants to list all tokens associated with a specific token accessor. Which API endpoint should be used?

A.auth/token/lookup-accessor

B.auth/token/accessors/

C.auth/token/lookup

D.auth/token/list

AnswerA

This returns token details for the given accessor.

Why this answer

The correct endpoint is `auth/token/lookup-accessor`. This endpoint is used to retrieve the details of a single token given its accessor. A token accessor is a non-sensitive reference that allows operations like lookup and revocation without exposing the token ID.

The other options are incorrect: `auth/token/accessors/` is not a valid Vault endpoint; `auth/token/lookup` retrieves token details using the token itself or its accessor, but not specifically by accessor; and `auth/token/list` lists all token accessors but does not retrieve details for a specific accessor.

Exam trap

The Vault exam often tests the distinction between `auth/token/lookup` (which retrieves token details by token ID or accessor) and `auth/token/lookup-accessor` (which retrieves token details specifically by accessor). Candidates may confuse the two or incorrectly think that `lookup-accessor` returns a list of tokens, but it actually returns details of a single token.

How to eliminate wrong answers

Option B is wrong because `auth/token/accessors/` is not a valid Vault API endpoint; the correct path uses `lookup-accessor` as a sub-action. Option C is wrong because `auth/token/lookup` retrieves token properties (like policies and TTL) for a given token or accessor, but does not list all tokens associated with a specific accessor. Option D is wrong because `auth/token/list` lists all token accessors in the token store, not those associated with a particular accessor.

Full explanation →

464

MCQhard

A company uses HashiCorp Vault in production to manage secrets for its microservices. One microservice, 'order-svc', authenticates via AppRole and receives a service token with a TTL of 24 hours and a max TTL of 48 hours. Over the past few days, operations teams report that 'order-svc' fails to renew its token after approximately 23 hours, causing authentication failures. The token lookup shows the token is still alive with about 1 hour of TTL remaining, but renewal attempts return a 'permission denied' error. The Vault audit logs show the renewal request is reaching Vault and being denied. The token's policies include 'path "auth/token/renew-self" { capabilities = ["update"] }'. The token was created with the default options. What is the most likely cause of this failure?

A.The token's parent token has been revoked, making it an orphan

B.The token is a batch token and cannot be renewed

C.The token has already been renewed up to its max TTL, so further renewal would exceed the max

D.The token's num_uses has reached zero

AnswerC

The max TTL of 48 hours has been nearly reached after multiple renewals, so the next renewal is denied.

Why this answer

The token's max TTL of 48 hours has been reached after repeated renewals. Each renewal extends the token's TTL up to the max TTL, and once that limit is hit, further renewal attempts are denied with a 'permission denied' error, even if the current TTL still shows remaining time. The token lookup showing 1 hour of TTL left indicates the token is still valid, but the renewal is blocked because it would exceed the configured max TTL.

Exam trap

A common trap in HashiCorp Vault exams is the distinction between a token's current TTL (remaining lifetime) and its max TTL (cumulative lifetime), leading candidates to believe a token with remaining TTL can always be renewed, when in fact the max TTL is the binding constraint.

How to eliminate wrong answers

Option A is wrong because revoking the parent token does not cause a 'permission denied' error on renewal; it would instead cause the token to become orphaned and renewal might fail with a different error (e.g., 'token not found' or 'invalid token'), not a permission denied. Option B is wrong because batch tokens cannot be renewed at all and would fail immediately with a 'permission denied' or 'not a renewable token' error, but the token in question is a service token (which is renewable by default) and the audit logs show the renewal request is reaching Vault and being denied, not rejected outright. Option D is wrong because if the token's num_uses had reached zero, the token would be immediately invalidated and lookup would show it as expired or revoked, not still alive with 1 hour of TTL remaining.

Full explanation →

465

MCQeasy

A junior administrator is writing a shell script that will be used by other team members to retrieve static secrets from Vault. The secrets are stored in the KV v2 secrets engine mounted at `secret/`. One particular secret, `credentials`, is located under the path `secret/data/credentials`. The administrator has already authenticated using the Vault CLI with a token that has read access specifically to that path. The environment variables `VAULT_ADDR` and `VAULT_TOKEN` are set correctly to point to the Vault server at `https://vault.example.com:8200` and the valid token. The script needs to run the correct command to retrieve the secret and output its key-value pairs for use by an application. Which command should the administrator include in the script?

A.vault kv get secret/data/credentials

B.vault read secret/data/credentials

C.vault read secret/credentials

D.vault kv get secret/credentials

AnswerD

Correct command; the CLI abstracts the /data/ prefix for KV v2 engines.

Why this answer

`vault kv get secret/credentials` is the proper command for the KV v2 secrets engine. The KV v2 engine automatically appends `/data/` to the path when reading secrets, so specifying the full path `secret/data/credentials` would result in a double `/data/` prefix, causing a 404 error. Since the environment variables are set and the token has read access, this command will retrieve the secret and output its key-value pairs.

Exam trap

A common pitfall in Vault exams is confusing KV v1 and KV v2 path handling. With `vault kv get`, Vault automatically appends `/data/` to the path, so using the full path `secret/data/credentials` would cause a double `/data/` and fail. Candidates often use `vault read` for KV v2 secrets, which requires the full `/data/` path, or incorrectly omit the mount path.

How to eliminate wrong answers

Option A is wrong because `vault kv get secret/data/credentials` includes the `/data/` segment in the path, which the KV v2 engine already appends internally, resulting in an incorrect path `secret/data/data/credentials` and a 404 error. Option B is wrong because `vault read secret/data/credentials` uses the legacy `vault read` command, which is not the recommended method for KV v2; it would also double the `/data/` segment and fail. Option C is wrong because `vault read secret/credentials` omits the required `/data/` segment for KV v2, causing the command to fail as the secret is stored under `secret/data/credentials`.

Full explanation →

466

Multi-Selecteasy

A policy must allow a user to write a new version of an existing secret in a KV v2 secrets engine. Which TWO capabilities are required on the 'data/' path?

Select 1 answer

A.delete

B.list

C.read

D.update

E.create

AnswersD

Correct. 'Update' allows writing a new version of an existing secret.

Why this answer

In KV v2, writing a new version of an existing secret uses the 'data/' endpoint with a POST/PATCH request. The 'update' capability is sufficient for modifying an existing secret. The 'create' capability is only needed when the secret path does not already exist.

Since the stem specifies an 'existing secret', only 'update' is required. Therefore, only one capability is needed, not two.

Exam trap

A common pitfall is to assume that 'create' is always required alongside 'update' for KV v2 writes. However, when the secret already exists, 'update' alone grants permission to write new versions. The exam may present a question where 'create' is unnecessary if the context explicitly states the secret exists.

Full explanation →

467

MCQeasy

A DevOps engineer creates the configuration above. After testing, they notice that the generated database credentials are not being revoked after the TTL expires. What is the most likely cause?

A.The creation_statements do not include the REVOKE command

B.The role definition has a syntax error in the creation_statements

C.The database configuration uses a connection_url with template variables but provides static admin credentials, not root rotation

D.The secrets engine is enabled at a path other than 'database/'

AnswerC

Without root credentials rotation, Vault cannot revoke dynamically created users because it uses the same admin credentials to manage them. The root credentials should be rotated first.

Why this answer

The database secrets engine requires root credential rotation to enable automatic revocation of generated credentials. When the `connection_url` uses template variables like `{{username}}` and `{{password}}` but the admin credentials are static (not rotated via `rotate_root`), Vault cannot track the actual root password. Without root rotation, Vault lacks the ability to execute `REVOKE` commands after TTL expiry because it cannot authenticate to the database with the current root credentials to perform cleanup.

Exam trap

HashiCorp often tests the misconception that `creation_statements` control both creation and revocation, or that the secrets engine path affects functionality, when the real issue is the missing root rotation step that enables Vault to maintain a valid admin session for cleanup operations.

How to eliminate wrong answers

Option A is wrong because the `creation_statements` are used to create the database user, not to revoke it; revocation is handled by the `revocation_statements` field in the role definition, and the absence of `REVOKE` in `creation_statements` is irrelevant. Option B is wrong because a syntax error in `creation_statements` would cause the role to fail at user creation, not silently fail to revoke credentials after TTL expiry. Option D is wrong because the secrets engine path does not affect credential revocation behavior; Vault can manage revocation regardless of the mount path as long as the engine is properly configured.

Full explanation →

468

Multi-Selectmedium

Which TWO of the following are valid use cases for the Transit secrets engine? (Select exactly 2.)

Select 2 answers

A.Signing and verifying data

B.Encrypting data in transit without exposing the encryption key

C.Storing encryption keys

D.Storing encrypted data at rest

E.Managing X.509 certificates

AnswersA, B

Transit supports signing and verification operations.

Why this answer

The Transit secrets engine is designed to perform cryptographic operations on data without exposing the encryption keys to the client. Option A is correct because the engine supports signing and verifying data using HMAC or asymmetric keys, allowing clients to verify integrity and authenticity without handling the private key. Option B is correct because the engine can encrypt data in transit (e.g., via API calls) while the encryption key remains securely stored within Vault, never leaving the server.

Exam trap

HashiCorp often tests the distinction between 'performing cryptographic operations' (Transit) and 'storing secrets or keys' (KV), so the trap here is that candidates confuse the Transit engine's ability to store keys internally with the use case of storing keys for external retrieval.

Full explanation →

469

MCQmedium

A security team wants to issue tokens that can be used for exactly 10 API calls, after which they must be renewed. Which two token parameters should be set on the token role?

A.period and num_uses

B.ttl and renewable

C.ttl and num_uses

D.num_uses and renewable

AnswerB

Correct: ttl and renewable allow the token to be used for a duration and then be renewed, though it does not enforce exactly 10 uses.

Why this answer

To meet the requirement that tokens can be used for exactly 10 API calls and then be renewed, you must avoid setting `num_uses` because tokens with `num_uses` set cannot be renewed. Instead, set `ttl` to a short duration (e.g., 1 minute) and `renewable` to true. This allows the token to be used for a limited time (though not exactly 10 calls) and be renewed repeatedly.

While this does not enforce exactly 10 calls, it aligns with the constraint that `num_uses` prevents renewal, making this the only viable pair among the options.

Exam trap

Candidates often assume that `num_uses` combined with `renewable` allows renewal after use count exhaustion. However, in Vault, setting `num_uses` makes a token non-renewable regardless of the `renewable` flag. The correct pair to allow renewal (while sacrificing exact use count) is `ttl` and `renewable`.

How to eliminate wrong answers

Option A is wrong because `period` is used for periodic tokens (e.g., time-based rotation) and does not limit the number of uses; combining `period` and `num_uses` would create a token that expires after a time period or after a number of uses, but it does not prevent renewal. Option B is wrong because `ttl` sets a time-to-live, not a use count, and `renewable` alone does not cap the number of API calls; a token with a long TTL and renewable=true could be used indefinitely. Option C is wrong because while `num_uses` limits the call count, `ttl` only adds a time constraint; without setting `renewable` to false, the token could be renewed before the TTL expires, allowing more than 10 uses.

Full explanation →

470

MCQeasy

An admin needs to store a configuration value that is unique to each Vault client and must not be shared. Which secrets engine should they use?

A.Cubbyhole

B.AWS

C.KV v2 at a client-specific path

D.Transit

AnswerA

Cubbyhole provides per-token isolated storage.

Why this answer

The Cubbyhole secrets engine creates a private, ephemeral storage space that is scoped to the requesting token. Each token gets its own isolated cubbyhole, and no other client or token can read or write to it, even with root privileges. This makes it the only built-in engine that guarantees a configuration value is unique to each Vault client and cannot be shared.

Exam trap

HashiCorp often tests the misconception that KV v2 with strict ACLs provides the same isolation as Cubbyhole, but the trap is that KV v2 is path-based and policy-dependent, whereas Cubbyhole is inherently token-scoped and cannot be accessed by any other token, even with root privileges.

How to eliminate wrong answers

Option B is wrong because the AWS secrets engine is designed to generate dynamic AWS IAM credentials or manage static AWS secrets, and it has no concept of per-client isolation — any client with the correct policy can access the same path. Option C is wrong because KV v2 at a client-specific path relies on ACL policies to restrict access, but it does not enforce token-scoped isolation; a misconfigured policy or a token with broader permissions could read another client's path, and the data persists even after the token expires. Option D is wrong because the Transit engine handles encryption and decryption operations (e.g., encrypting data in transit or at rest) and does not store configuration values at all; it is a cryptographic operations engine, not a storage engine.

Full explanation →

471

MCQhard

A security policy requires that encryption keys used in transit must never leave Vault's memory. However, development teams need to perform encryption offline in CI/CD pipelines. How can this be accomplished?

A.Use exportable keys and export them

B.Use Vault's transit encrypt with context

C.Use Vault's ciphertext rewrap

D.Use Vault's datakey endpoint to get a wrapped key that can be unwrapped offline

E.It is not possible; keys must stay in Vault

AnswerD

The datakey response includes a ciphertext that can be decrypted later to retrieve the data key for local encryption.

Why this answer

Vault's `datakey` endpoint generates a data encryption key (DEK) that is wrapped by a Vault-managed key. The wrapped DEK can be safely stored and used offline in CI/CD pipelines, while the unwrapped key material never leaves Vault's memory — the DEK is unwrapped only when needed, and the wrapping key remains in Vault. This satisfies the policy requirement that encryption keys used in transit must never leave Vault's memory, as the DEK itself is not a transit key but a data key that can be used offline.

Exam trap

The trap here is that candidates may think offline encryption is impossible if keys cannot leave Vault, but Vault's datakey endpoint provides a wrapped key that can be used offline without exposing the underlying transit key.

How to eliminate wrong answers

Option A is wrong because exportable keys would allow the raw key material to leave Vault's memory, directly violating the security policy. Option B is wrong because Vault's transit encrypt with context only encrypts data within Vault's memory; it does not provide a wrapped key for offline use in CI/CD pipelines. Option C is wrong because ciphertext rewrap is used to rotate encryption keys without decrypting data, not to provide offline encryption capabilities.

Option E is wrong because Vault's datakey endpoint provides a mechanism to achieve offline encryption while keeping the wrapping key secure in Vault.

Full explanation →

472

MCQmedium

This Vault agent configuration section is incomplete. What is missing for the AWS auto-auth method to function correctly?

A.The configuration needs a 'region' parameter

B.The role name 'my-role' is invalid

C.The method type should be 'iam' instead of 'aws'

D.AWS credentials must be provided via environment variables or instance metadata

AnswerD

Vault's AWS auth method requires AWS credentials to authenticate to the AWS API.

Why this answer

The AWS auth method in Vault requires valid AWS credentials to authenticate against AWS STS. These credentials can be provided via environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) or automatically retrieved from instance metadata when running on an EC2 instance. Without them, Vault cannot sign the STS request to verify the caller's identity, causing authentication to fail.

Exam trap

HashiCorp often tests the misconception that the AWS auth method requires explicit IAM credentials in the Vault configuration file, when in fact credentials are provided by the client at authentication time, not stored in the server configuration.

How to eliminate wrong answers

Option A is wrong because the 'region' parameter is optional for the AWS auth method; Vault can infer the region from the instance metadata or environment variable AWS_DEFAULT_REGION. Option B is wrong because 'my-role' is a valid role name; the role name is arbitrary and does not need to match any AWS resource name. Option C is wrong because 'aws' is the correct method type for the AWS auth method; 'iam' is not a valid Vault auth method type—the AWS auth method uses IAM principals internally but is configured as type 'aws'.

Full explanation →

473

MCQeasy

A Vault cluster uses Consul for HA. After a brief network partition, a standby node loses contact with the active node. What does the standby node do after a timeout?

A.It becomes the active node.

B.It seals itself.

C.It continues to serve requests.

D.It replicates data from the storage backend.

AnswerB

Standby nodes seal themselves after losing contact with the active node to maintain data consistency.

Why this answer

In a Vault cluster using Consul for high availability, only the active node serves requests. When a standby node loses contact with the active node due to a network partition, it cannot verify the active node's health or its own leadership status. After a configurable timeout (default 10 seconds), the standby node seals itself to prevent serving stale or inconsistent data, ensuring data integrity and security.

Exam trap

The trap here is that candidates assume a standby node will automatically take over as active during a partition, but Vault prioritizes safety over availability by sealing the standby to avoid split-brain scenarios.

How to eliminate wrong answers

Option A is wrong because Vault uses a leader election mechanism via Consul; a standby node cannot become active without confirming the previous active node is down, and during a network partition it cannot safely assume leadership. Option C is wrong because only the active node serves client requests; standby nodes are passive and do not handle any API or unseal operations. Option D is wrong because replication from the storage backend is a background process handled by the active node; standby nodes do not initiate replication and sealing halts all operations, including replication.

Full explanation →

474

MCQmedium

Refer to the exhibit. What seal mechanism is configured for this Vault instance?

A.AWS KMS auto-unseal

B.HSM seal via PKCS#11

C.Shamir seal with default shares

D.No seal; Vault is in insecure mode

AnswerA

The seal block specifies AWS KMS.

Why this answer

The exhibit shows a Vault instance configured with `seal "awskms"` and a `region` and `kms_key_id` specified. This indicates that AWS KMS is used as the auto-unseal mechanism, where Vault delegates the unsealing process to AWS Key Management Service, eliminating the need for manual Shamir key shares.

Exam trap

HashiCorp often tests the distinction between default Shamir sealing and external auto-unseal mechanisms; the trap here is that candidates see a Vault configuration and assume it uses the default Shamir seal, missing the explicit `seal "awskms"` directive that overrides it.

How to eliminate wrong answers

Option B is wrong because HSM seal via PKCS#11 requires a hardware security module and configuration with `seal "pkcs11"`, not the `awskms` seal shown in the exhibit. Option C is wrong because Shamir seal with default shares is the default seal mechanism when no external seal is configured, but the exhibit explicitly shows `seal "awskms"`, overriding the default. Option D is wrong because Vault never runs in an insecure mode; it always requires a seal mechanism, and the exhibit confirms a seal is configured.

Full explanation →

475

MCQmedium

Refer to the exhibit. What is the purpose of the -field=ciphertext flag in this command?

A.It sets the ciphertext field for encryption.

B.It enables field-level encryption.

C.It specifies the encryption key name.

D.It outputs the command result to a file named ciphertext.

E.It instructs Vault to only return the ciphertext field from the response.

AnswerE

This is the correct behavior of the -field flag.

Why this answer

The `-field=ciphertext` flag in a Vault command instructs the CLI to extract and return only the value of the `ciphertext` key from the JSON response object. This is a standard Vault output filtering mechanism that allows users to isolate a specific field without parsing the full response, which is especially useful in scripting and automation.

Exam trap

HashiCorp often tests the distinction between output filtering (`-field`) and actual encryption configuration, leading candidates to confuse the flag with setting encryption parameters or enabling field-level encryption.

How to eliminate wrong answers

Option A is wrong because the flag does not set or configure the ciphertext field for encryption; it filters the output to show only that field. Option B is wrong because field-level encryption is a separate concept involving encrypting individual data fields within a record, not a CLI output filter. Option C is wrong because the encryption key name is specified via a different parameter (e.g., `-key` or `key_name`), not the `-field` flag.

Option D is wrong because the `-field` flag does not redirect output to a file; file output is achieved with shell redirection (`>`) or the `-output` flag.

Full explanation →

476

MCQeasy

A security engineer wants to ensure that all requests to Vault are logged for compliance. Which component must be configured?

A.Secrets Engine

B.Storage Backend

C.Audit Device

D.Auth Method

AnswerC

Logs all requests to Vault.

Why this answer

An audit device is the Vault component responsible for logging all requests and responses to a specified destination (e.g., syslog, file, socket). It must be enabled and configured to meet compliance requirements for recording every interaction with Vault. Without an audit device, Vault does not generate any persistent logs of API calls.

Exam trap

HashiCorp often tests the distinction between components that perform actions (secrets engines, auth methods) versus components that record actions (audit devices), leading candidates to confuse a functional component with a logging component.

How to eliminate wrong answers

Option A is wrong because a secrets engine (e.g., KV, AWS, database) manages the lifecycle of secrets but does not log requests; it is a target for operations, not a logging mechanism. Option B is wrong because a storage backend (e.g., Consul, Raft, file) persists Vault's encrypted data and configuration but does not capture request/response audit trails. Option D is wrong because an auth method (e.g., token, LDAP, OIDC) authenticates users or machines but does not produce compliance logs of subsequent Vault operations.

Full explanation →

477

Multi-Selectmedium

Which THREE are required for Vault to encrypt data at rest? (Choose three.)

Select 3 answers

A.Audit device

B.Barrier encryption key

C.Storage backend

D.Seal mechanism

E.Authentication method

AnswersB, C, D

The key used to encrypt and decrypt data stored in the backend.

Why this answer

The barrier encryption key is the master key used to encrypt and decrypt the Vault data encryption key (DEK), which in turn encrypts all data written to the storage backend. Without this key, Vault cannot protect data at rest because the DEK would be stored in plaintext. It is a fundamental component of Vault's security architecture, ensuring that even if the storage backend is compromised, the data remains encrypted.

Exam trap

HashiCorp often tests the misconception that authentication methods or audit devices are involved in data encryption at rest, when in fact they serve orthogonal purposes (identity verification and logging, respectively) and are not part of the encryption pipeline.

Full explanation →

478

MCQeasy

An administrator wants to write a secret 'myapp' with value 'password=pass123' to the KV v2 secret engine mounted at 'secret/'. Which command should they use?

A.vault kv write secret/myapp password=pass123

B.vault kv create secret/myapp password=pass123

C.vault kv put secret/myapp password=pass123

D.vault write secret/myapp password=pass123

AnswerC

This is the correct syntax for KV v2 put.

Why this answer

`vault kv put` is the proper command to write or update a secret in the KV v2 secrets engine. The KV v2 engine requires the `put` subcommand to create or overwrite a secret at the specified path, and the syntax `vault kv put secret/myapp password=pass123` correctly writes the key-value pair to the path `secret/myapp` under the mounted engine at `secret/`.

Exam trap

HashiCorp often tests the distinction between KV v1 (`vault write`) and KV v2 (`vault kv put`) commands, and the trap here is that candidates mistakenly use the generic `vault write` command (which works for KV v1 but not for KV v2) or invent non-existent subcommands like `write` or `create` under `vault kv`.

How to eliminate wrong answers

Option A is wrong because `vault kv write` is not a valid subcommand; the KV v2 engine uses `put` for writing secrets, not `write`. Option B is wrong because `vault kv create` is not a valid subcommand; the KV v2 engine does not have a `create` subcommand—secrets are written with `put` and optionally checked for existence with `get` or `metadata`. Option D is wrong because `vault write` targets the generic Vault API endpoint (used for KV v1 or other backends) and does not use the KV v2-specific subcommand structure; for KV v2, the correct CLI approach is `vault kv put`.

Full explanation →

479

MCQhard

A team has set up automatic key rotation on a transit key. After rotation, encrypted data that was encrypted with the previous key version can no longer be decrypted. What is the most likely cause?

A.The key was deleted

B.The key's min_decryption_version is set too high

C.The key's min_encryption_version is set too high

D.The team used the 'rewrap' operation incorrectly

E.The key is not exportable

AnswerB

If min_decryption_version is higher than the version used for encryption, decryption requests are rejected.

Why this answer

The `min_decryption_version` setting on a transit key in Vault's transit secrets engine controls the minimum key version that can be used to decrypt ciphertext. If this value is set too high (e.g., to the current version), older key versions are effectively disabled for decryption, causing any data encrypted with a previous key version to become undecryptable. This is a common misconfiguration when automating key rotation without properly managing version policies in Vault.

Exam trap

Vault often tests the distinction between `min_encryption_version` and `min_decryption_version` in the transit engine, trapping candidates who confuse the two or assume that key rotation automatically invalidates old decryption capabilities.

How to eliminate wrong answers

Option A is wrong because deleting the key would make all data encrypted with any version of that key permanently undecryptable, not just data encrypted with the previous version. Option C is wrong because `min_encryption_version` controls which key version can be used for new encryption operations, not decryption of existing ciphertext. Option D is wrong because the `rewrap` operation (e.g., `ReEncrypt` in AWS KMS) is used to re-encrypt data under a new key version without exposing plaintext; using it incorrectly would not cause decryption failures for data encrypted with the previous version.

Option E is wrong because the exportability of a key affects whether the key material can be exported from the service, not whether ciphertext can be decrypted using the key versions stored within the service.

Full explanation →

480

MCQmedium

Refer to the exhibit. After executing these commands, what is the expected behavior?

A.The key is automatically rotated every 30 days

B.The ciphertext is base64 encoded, and the plaintext is base64 decoded automatically

C.The decryption command requires the key version to be specified

D.The encryption operation will fail because the key type 'aes256-gcm96' is incorrect

AnswerC

Correct. When decrypting data encrypted with a previous key version, the key version must be specified in the decryption request, otherwise the latest version is used and decryption may fail.

Why this answer

In the Vault Transit secrets engine, when a key has multiple versions (e.g., after rotation), the decryption command requires the key version to be specified to ensure the correct key is used. If the version is not specified, Vault defaults to the latest version, which may not match the version used for encryption, leading to decryption failure. Therefore, option C is correct.

Exam trap

Candidates may think decryption works without specifying key version, but Vault Transit requires the key version to be specified when decrypting data that was encrypted with a previous key version.

How to eliminate wrong answers

Option A is wrong because key rotation in Vault is not automatic based on time; it requires explicit `vault write -f transit/keys/my-key/rotate` commands or a configured rotation period via `rotation_period`, not a default 30-day auto-rotation. Option C is wrong because the decryption command does not require the key version to be specified; Vault automatically uses the latest key version for decryption unless a specific version is explicitly provided via the `ciphertext` field or the `version` parameter. Option D is wrong because `aes256-gcm96` is a valid key type in Vault's transit secrets engine, representing AES-256 encryption with GCM and a 96-bit nonce, so the encryption operation will succeed.

Full explanation →

481

Multi-Selecteasy

Which TWO of the following are features of the AWS secrets engine compared to the Azure secrets engine?

Select 2 answers

A.Supports federation via SAML with Azure AD

B.Provides native integration with Azure Key Vault for key management

C.Allows connection to AWS via IAM instance profiles

D.Can generate IAM users with custom policies

E.Can generate STS temporary credentials for cross-account access

AnswersD, E

AWS secrets engine creates IAM users and attaches policies.

Why this answer

The AWS secrets engine can dynamically generate IAM users with custom policies attached, allowing fine-grained access control for applications. Option E is correct because the engine can generate STS temporary credentials for cross-account access, enabling secure, time-limited access to AWS resources in different accounts.

Exam trap

HashiCorp often tests the distinction between the AWS and Azure secrets engines, and the trap here is confusing the AWS engine's ability to generate IAM users and STS tokens with Azure-specific features like SAML federation or Key Vault integration.

Full explanation →

482

MCQmedium

An organization uses Kubernetes pods to access Vault. They want to avoid hardcoding any secrets in the pod definition. Which authentication method should they use?

A.LDAP

B.Kubernetes

C.Username & Password

D.AppRole

AnswerB

Kubernetes auth uses the pod's service account token, no hardcoded secrets.

Why this answer

The Kubernetes authentication method is correct because it allows pods to authenticate to Vault using their service account token, which is automatically mounted into the pod. This eliminates the need to hardcode any secrets in the pod definition, as Vault verifies the token against the Kubernetes API server and issues a temporary Vault token based on the pod's identity.

Exam trap

HashiCorp often tests the misconception that AppRole is the best choice for automated workloads, but the trap here is that AppRole still requires a SecretID to be stored somewhere (e.g., a Kubernetes Secret), whereas Kubernetes auth uses the pod's own identity to eliminate any hardcoded secrets entirely.

How to eliminate wrong answers

Option A is wrong because LDAP authentication requires a username and password or LDAP bind credentials, which would still need to be stored in the pod definition or an external secret store, defeating the purpose of avoiding hardcoded secrets. Option C is wrong because Username & Password authentication requires embedding static credentials in the pod definition or environment variables, directly violating the requirement to avoid hardcoding secrets. Option D is wrong because AppRole requires a RoleID and a SecretID; while the RoleID can be injected via annotations, the SecretID is a sensitive credential that must be stored securely (e.g., in a Kubernetes secret), which still involves hardcoding or managing secrets outside Vault's native pod identity integration.

Full explanation →

483

Multi-Selectmedium

Which TWO of the following are valid capabilities that can be specified in a Vault policy?

Select 2 answers

A.create

B.write

C.sudo

D.rename

E.update

AnswersA, E

'create' is a valid capability.

Why this answer

In Vault policies, capabilities define the allowed actions on paths. The `create` capability permits creating new data at a path without needing to read existing data, which is distinct from `update` that allows modifying existing data. Both `create` and `update` are valid, separate capabilities in Vault's policy system.

Exam trap

HashiCorp often tests the distinction between `write` (which is not a valid capability) and the correct pair `create` and `update`, leading candidates to incorrectly select `write` as a catch-all for data modification.

Full explanation →

484

Multi-Selecteasy

Which TWO statements about batch tokens are true?

Select 2 answers

A.They are lightweight and support a high creation rate.

B.They cannot be used with a use-limit.

C.They support explicit max TTL.

D.They have a TTL.

E.They are renewable.

AnswersA, B

Correct. Batch tokens are lightweight and optimized for high creation rates.

Why this answer

Batch tokens are designed to be lightweight and support a high creation rate, ideal for ephemeral workloads. Option B is correct because batch tokens cannot be used with a use-limit; use-limits are only supported by service tokens. Options C, D, and E are incorrect: batch tokens do not support explicit max TTL (C), they do not have a TTL as they derive their lifetime from the parent token (D), and they are not renewable (E).

Exam trap

A common misconception is that batch tokens are fully featured like service tokens, but they lack support for explicit max TTL, renewal, and individual revocation, making them suitable only for specific use cases.

Full explanation →

485

Multi-Selecteasy

A DevOps team is setting up a Vault cluster for the first time. They plan to use AWS KMS for auto-unseal and Consul as the storage backend. As part of the architecture, which TWO components are essential for the Vault server to start and serve requests?

Select 2 answers

A.A public CA certificate

B.A storage backend

C.A configured seal mechanism

D.A 4096-bit encryption key

E.A load balancer

AnswersB, C

Vault requires a storage backend to persist secrets and configuration; Consul serves this purpose.

Why this answer

B is correct because Vault requires a storage backend to persist data such as secrets, policies, and tokens. Without a configured storage backend (e.g., Consul), the Vault server cannot initialize or serve requests, as it has no place to store or retrieve state. The storage backend is the foundation for all Vault operations, including high-availability coordination.

Exam trap

A common misconception is that the seal mechanism alone is sufficient for Vault to start, but the storage backend is equally essential because it holds the encrypted master key and all persistent data.

Full explanation →

486

MCQeasy

Refer to the exhibit. A user wants to write a secret 'db_password' with value 's3cret' to this secrets engine. Which CLI command should be used?

A.vault write shared/db_password value=s3cret

B.vault write shared/data/db_password value=s3cret

C.vault write shared/metadata/db_password value=s3cret

D.vault write shared/config/db_password value=s3cret

AnswerB

This is correct because in Vault's KV v2 secrets engine, secrets are written to the 'data' sub-path. The command 'vault write shared/data/db_password value=s3cret' targets the data endpoint for the secret 'db_password' under the 'shared' mount.

Why this answer

In Vault's KV v2 secrets engine, secrets are stored under the 'data' path. The correct CLI command to write a secret is 'vault write shared/data/db_password value=s3cret', which targets the data endpoint for the secret 'db_password' in the 'shared' mount.

Exam trap

HashiCorp often tests the distinction between KV v1 and v2 paths, and the trap here is that candidates assume the secret can be written directly to the mount path (e.g., 'shared/db_password') without the '/data/' prefix, which only works in KV v1.

How to eliminate wrong answers

Option A is wrong because 'vault write shared/db_password' targets the root of the mount, not the data path, and KV v2 requires the '/data/' prefix to write secret data. Option C is wrong because 'vault write shared/metadata/db_password' is used for metadata operations (like configuring versions or deletion settings), not for writing the secret value itself. Option D is wrong because 'vault write shared/config/db_password' is not a valid path; 'config' is used for engine configuration (e.g., max versions), not for individual secrets.

Full explanation →

487

MCQmedium

A Vault administrator notices that the audit log file on the Vault server is filling up the disk. What is the best course of action to prevent disk full issues?

A.Disable audit logging to reduce disk usage.

B.Switch to a syslog audit device.

C.Increase the disk size of the Vault server.

D.Configure the file audit device with log rotation.

AnswerD

Rotation manages disk space effectively.

Why this answer

Configuring log rotation on the file audit device allows the Vault server to automatically archive or delete old audit logs based on size or time thresholds, preventing the disk from filling up while retaining necessary audit data. This is the recommended approach in Vault for managing disk space without disabling security auditing or relying on external infrastructure changes.

Exam trap

HashiCorp often tests the misconception that disabling or redirecting audit logs is an acceptable solution for disk management, when in fact the correct approach is to manage log growth through rotation while maintaining audit functionality.

How to eliminate wrong answers

Option A is wrong because disabling audit logging removes the ability to track and monitor all API requests and operations, which is a critical security requirement for compliance and forensic analysis. Option B is wrong because switching to a syslog audit device does not inherently prevent disk full issues; it simply redirects logs to an external syslog server, which could still fill up its own disk or cause log loss if the syslog server is unavailable. Option C is wrong because increasing disk size is a temporary, reactive fix that does not address the root cause of unbounded log growth and may not be feasible in all environments.

Full explanation →

488

MCQmedium

A user receives an error 'invalid ciphertext' when trying to decrypt data. The ciphertext was created by another Vault instance. What is the most likely issue?

A.Different key names

B.The Vault instance is sealed

C.Different key types

D.The ciphertext includes key version info that doesn't match

E.The user lacks permissions to decrypt

AnswerD

Transit ciphertext is tied to a specific key version; if that version is missing, decryption fails.

Why this answer

Vault's transit secrets engine appends key version information to the ciphertext by default. When decrypting, Vault checks that the key version embedded in the ciphertext matches a version of the key that exists in the destination Vault instance. If the ciphertext was created by a different Vault instance with a different key version history, the version embedded in the ciphertext will not correspond to any known key version, causing the 'invalid ciphertext' error.

Exam trap

HashiCorp often tests the misconception that 'invalid ciphertext' errors are caused by permission issues or key name mismatches, when in fact the error is specifically triggered by a version mismatch in the ciphertext header that prevents the decryption key from being derived.

How to eliminate wrong answers

Option A is wrong because the error 'invalid ciphertext' is not caused by key name mismatches; a key name mismatch would result in a 'key not found' or 'permission denied' error, not an invalid ciphertext error. Option B is wrong because a sealed Vault instance cannot perform any cryptographic operations at all, so the user would receive a 'Vault is sealed' error, not an 'invalid ciphertext' error. Option C is wrong because different key types (e.g., AES256-GCM96 vs.

ChaCha20-Poly1305) would cause a decryption failure, but Vault would typically return a 'key type mismatch' or 'unsupported key type' error, not a generic 'invalid ciphertext' error. Option E is wrong because insufficient permissions would result in a 'permission denied' or 'forbidden' HTTP 403 error, not an 'invalid ciphertext' error, which is a cryptographic validation failure.

Full explanation →

489

MCQhard

A DevOps team uses Vault's transit engine to encrypt secrets in CI/CD pipelines. They report that encryption operations are failing with 'permission denied' errors. The team has a policy granting 'create' and 'update' capabilities on the transit key path. What is the most likely missing capability?

A.The 'read' capability is missing.

B.The 'encrypt' capability is missing.

C.The 'delete' capability is missing.

D.The 'list' capability is missing.

AnswerB

Encrypt capability is required for encryption operations.

Why this answer

The Vault transit engine uses distinct capabilities for key management versus data operations. 'Create' and 'update' allow managing the key itself (e.g., creating or rotating the key), but encryption of data requires the 'encrypt' capability on the transit key path. Without 'encrypt', the API call to encrypt data fails with a 'permission denied' error, even if the key exists and is properly configured.

Exam trap

HashiCorp often tests the misconception that 'write' or 'create' capabilities on a key path implicitly grant the ability to encrypt data, when in fact Vault requires explicit 'encrypt' and 'decrypt' capabilities for data-plane operations.

How to eliminate wrong answers

Option A is wrong because 'read' capability allows retrieving key metadata or configuration, not performing encryption operations; missing 'read' would cause a different error (e.g., 'permission denied' on read requests, not encrypt). Option C is wrong because 'delete' capability is for removing the key entirely, which is unrelated to encrypting data; its absence would not affect encryption operations. Option D is wrong because 'list' capability is for enumerating keys under a path, not for encrypting data; missing 'list' would only block listing operations, not encryption.

Full explanation →

490

MCQeasy

An organization wants to encrypt data at rest in a cloud storage bucket. They plan to use Vault's transit engine to generate a data key and then encrypt the data locally. Which transit endpoint should they use to get a data key?

A.POST /v1/transit/datakey/plaintext/my-key

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

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

D.POST /v1/transit/datakey/ciphertext/my-key

AnswerA

Returns both plaintext and ciphertext data key.

Why this answer

The correct endpoint to retrieve a data key that can be used for local client-side encryption is POST /v1/transit/datakey/plaintext/my-key. This endpoint returns both the plaintext data key (for local encryption) and the ciphertext version of the key (for secure storage alongside the encrypted data). The 'plaintext' in the path indicates that the response includes the key in plaintext form, which is necessary for performing encryption locally.

Exam trap

HashiCorp often tests the distinction between 'datakey/plaintext' and 'datakey/ciphertext' endpoints, where candidates mistakenly choose the ciphertext-only endpoint thinking it provides the key for local encryption, but it actually omits the plaintext key required for that purpose.

How to eliminate wrong answers

Option B is wrong because POST /v1/transit/encrypt/my-key is used to encrypt an existing piece of data using Vault's transit engine, not to generate a new data key. Option C is wrong because POST /v1/transit/decrypt/my-key is used to decrypt ciphertext that was previously encrypted by the transit engine, not to generate a data key. Option D is wrong because POST /v1/transit/datakey/ciphertext/my-key returns only the ciphertext version of the data key, not the plaintext key needed for local encryption; this endpoint is used when the client only needs to store the key and does not need to perform local encryption.

Full explanation →

491

MCQhard

A Vault administrator configures an AWS secrets engine role with credential_type=iam_user and attaches a policy that allows creating EC2 instances. A developer generates credentials and uses them to launch an EC2 instance. Later the lease expires and Vault revokes the IAM user. What happens to the EC2 instance?

A.The instance continues to run because IAM user revocation does not affect running instances

B.The instance fails with a permission error

C.The instance is immediately terminated

D.The instance is stopped after a grace period

AnswerA

Correct; the instance uses its instance profile.

Why this answer

When Vault revokes an IAM user, it deletes the IAM user credentials, but this does not affect resources already launched by that user. The EC2 instance runs under its own instance profile and is not tied to the IAM user's session after launch. AWS does not retroactively terminate or stop instances based on IAM user revocation; the instance continues to run until explicitly stopped or terminated.

Exam trap

HashiCorp often tests the misconception that revoking IAM credentials will immediately impact running resources, but in AWS, IAM revocation only affects future API calls, not existing instances.

How to eliminate wrong answers

Option B is wrong because the instance does not fail with a permission error — the instance's runtime operations rely on its attached IAM role (if any) or the instance's own metadata, not the original IAM user's credentials. Option C is wrong because AWS does not immediately terminate instances when the launching IAM user is revoked; there is no such lifecycle dependency. Option D is wrong because there is no grace period or automatic stop mechanism triggered by IAM user revocation — the instance remains running indefinitely.

Full explanation →

492

MCQhard

A Vault cluster has a token with the following policy: path "secret/data/dev/*" { capabilities = ["read", "list"] }. The token is used to read a secret at "secret/data/dev/password". The read succeeds. Later, the token tries to read "secret/data/prod/password". What happens?

A.Fails with a system error.

B.Succeeds because token has read capability on all secrets.

C.Succeeds because the token can list and read any path.

D.Fails because the token needs an explicit policy for "secret/data/prod/".

AnswerD

The token's policy only covers "dev/*", not "prod/*".

Why this answer

Vault policies are path-based and deny by default. The token's policy only grants 'read' and 'list' capabilities on paths matching 'secret/data/dev/*', so any attempt to access 'secret/data/prod/password' is not covered by that policy. Without an explicit policy allowing access to the 'prod' path, the request is denied by Vault's default deny behavior.

Exam trap

A common misconception is that a token with read capability on one path can read any secret, but Vault's policy model requires explicit path matching for each access attempt.

How to eliminate wrong answers

Option A is wrong because a denied request due to missing policy does not produce a system error; Vault returns a permission denied response (HTTP 403). Option B is wrong because Vault tokens do not have implicit read capability on all secrets; capabilities are strictly defined by attached policies. Option C is wrong because the token's 'list' and 'read' capabilities are scoped only to the 'secret/data/dev/*' path, not to any arbitrary path.

Full explanation →

493

Multi-Selectmedium

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

Select 2 answers

A.AppRole requires a secret ID, while Kubernetes auth does not require any secret.

B.Kubernetes auth can only be used within the same cluster as Vault, while AppRole can be used remotely.

C.Both support response wrapping for secure delivery of credentials.

D.Kubernetes auth authenticates using a service account JWT token, whereas AppRole uses a RoleID and SecretID.

E.AppRole supports CIDR restrictions on the secret ID, but Kubernetes auth does not.

AnswersD, E

Correct key difference.

Why this answer

Kubernetes authentication works by having Vault validate a Kubernetes service account JWT token against the Kubernetes TokenReview API, while AppRole authentication requires a RoleID (which identifies the role) and a SecretID (which acts as a credential). The SecretID can be a generated value or a wrapped response, but the JWT token in Kubernetes auth is the sole credential presented to Vault.

Exam trap

HashiCorp often tests the misconception that Kubernetes auth requires no secret at all, when in fact the JWT token is a secret credential, and that AppRole cannot be used remotely, when both methods can operate across network boundaries if properly configured.

Full explanation →

494

Multi-Selectmedium

Which THREE are valid operations in the Vault transit secrets engine? (Choose three.)

Select 3 answers

A.issue

B.revoke

C.rewrap

D.decrypt

E.encrypt

AnswersC, D, E

Rewrap updates ciphertext to a newer key version.

Why this answer

The Vault transit secrets engine provides encryption as a service, and its core operations are encrypt, decrypt, rewrap, and datakey generation. Rewrap is valid because it decrypts ciphertext and re-encrypts it with the latest key version without exposing the plaintext to the caller, maintaining security during key rotation.

Exam trap

HashiCorp often tests candidates by mixing terms from different Vault secrets engines (e.g., PKI 'issue/revoke' with transit 'encrypt/decrypt') to see if you can distinguish the specific operations each engine supports.

Full explanation →

495

MCQmedium

A security administrator wants to create a policy that allows a service to renew its own token and list its own token capabilities, but not create new tokens. Which policy statements should be included?

A.path "auth/token/renew-self" { capabilities = ["update"] }; path "auth/token/capabilities-self" { capabilities = ["read"] }

B.path "auth/token/renew-self" { capabilities = ["create"] }; path "auth/token/lookup-self" { capabilities = ["read"] }

C.path "auth/token/renew-self" { capabilities = ["update"] }; path "auth/token/capabilities-self" { capabilities = ["update"] }

D.path "auth/token/renew" { capabilities = ["update"] }; path "auth/token/capabilities" { capabilities = ["read"] }

AnswerA

This is correct: renew-self uses update, capabilities-self uses read.

Why this answer

It uses the correct endpoints and capabilities: update for renew-self and read for capabilities-self. Option B uses create for renew-self, which is incorrect (renew-self requires update). Option C uses update for capabilities-self, which is wrong (capabilities-self requires read).

Option D uses non-self endpoints (renew and capabilities) which would allow renewing or checking capabilities of any token, granting broader privileges than intended.

Full explanation →

496

MCQhard

An application's token is failing to renew, and the logs show 'token not renewable'. The token was created with a TTL of 24h and no explicit max TTL. What is the most likely cause?

A.The token was created with the renewable flag set to false

B.The token has been renewed too many times, exceeding its TTL

C.The token accessor is invalid

D.The token's max TTL has been reached

AnswerA

If renewable=false, Vault rejects renewal requests.

Why this answer

The error 'token not renewable' occurs when a token is created with the `renewable` flag explicitly set to `false`. Even though the token has a TTL of 24h and no explicit max TTL, the absence of the renewable flag means the token cannot be renewed at all. Vault tokens are renewable by default, but if the application or operator sets `renewable=false` during creation, the token will expire after its TTL and cannot be extended.

Exam trap

In HashiCorp Vault, the 'token not renewable' error indicates the token was created with `renewable=false`. A common trap is confusing this with max TTL or expiration, but the renewable flag is a separate attribute that must be set to true for renewal to be allowed.

How to eliminate wrong answers

Option B is wrong because the error message 'token not renewable' is not related to the number of renewals; a token can be renewed many times as long as its max TTL (which defaults to 32 days if not set) has not been reached. Option C is wrong because an invalid token accessor would produce an error like 'invalid accessor' or 'token not found', not 'token not renewable'. Option D is wrong because the token has no explicit max TTL, so the default max TTL (32 days) applies, and a 24h TTL token would not hit that limit after a single renewal failure.

Full explanation →

497

Drag & Dropmedium

Drag and drop the steps to perform a Vault disaster recovery using the replication feature 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

Initialize clusters, enable primary replication, generate token, enable secondary, promote if needed.

Full explanation →

498

Multi-Selecthard

Which three characteristics are true about Vault's storage backend and seal mechanisms? (Choose three.)

Select 3 answers

A.Auto-unseal using a cloud KMS eliminates the need for unseal keys entirely.

B.Consul as a storage backend requires Consul's own gossip protocol for leader election.

C.The Shamir seal requires multiple unseal keys to be entered before Vault can operate.

D.HSM seals can be used to auto-unseal Vault while also providing a hardware root of trust.

E.Integrated Storage uses Raft consensus and can be used in production for both HA and DR.

AnswersC, D, E

Shamir splits the master key into shards.

Why this answer

The Shamir seal splits the master key into multiple key shares, requiring a threshold number of these shares to be entered during the unseal process before Vault can decrypt its data encryption key and become operational. This ensures that no single individual can unseal Vault, providing a distributed trust model.

Exam trap

HashiCorp often tests the misconception that auto-unseal eliminates unseal keys entirely, when in fact it only automates the unseal process while still relying on an encrypted master key stored in the storage backend.

Full explanation →

HashiCorp Vault Associate VA-003 (VA-003) — Questions 451–498