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

Multi-Selecthard

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

Select 2 answers

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

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

C.Keys can be exported and used in external applications

D.Only the root token can manage keys

E.Key rotation is handled centrally without downtime

AnswersB, E

Transit performs cryptographic operations server-side, so applications submit plaintext or ciphertext and receive the result; the key material never leaves Vault. This satisfies the stem's benefit by removing key exposure from application memory, config files and host compromise.

Why this answer

Option B is correct because Vault's transit engine performs cryptographic operations on behalf of the client: the application sends plaintext (or ciphertext) to Vault's encrypt/decrypt endpoints, and Vault returns the result, so the application never handles or even sees the underlying key material. Option E is correct because the transit engine supports centralized key management, including key rotation via the `rotate` endpoint, which creates a new key version while retaining old versions for decryption, allowing rotation without application changes or downtime. Option A is incorrect because the whole point of the transit engine is that the key never leaves Vault's storage and is not held in application memory.

Option C is incorrect because transit keys are non-exportable by design (exportable keys must be explicitly enabled and are generally discouraged). Option D is incorrect because key management in the transit engine is governed by Vault policies and tokens with appropriate capabilities, not restricted solely to the root token.

Exam trap

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

Full explanation →

MCQhard

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

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

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

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

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

AnswerA

Transit key versioning decouples encryption from decryption: new writes use the latest key version, while older versions remain available to decrypt existing ciphertext. This satisfies the 30-day rotation requirement without downtime, since applications never need to re-encrypt stored data.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQhard

A security architect is designing authentication for an internal tool that must verify a user's hardware-backed token on a smart card before granting access to secrets. The tool already has a PKI issuing client certificates to each user, and the architect wants Vault to validate the client certificate chain during login. Which auth method should be used, and what is the key configuration requirement?

A.Username & Password auth, with the smart card PIN used as the Vault password and the certificate serial as the username.

B.JWT auth, with the smart card's certificate serial number embedded as a claim in a JWT signed by the internal PKI.

C.Cert auth, with the trusted CA certificate uploaded so Vault can validate the presented client certificate against that CA.

D.TLS certificate auth, with the certificate's private key imported into Vault so Vault can re-sign the client's requests.

AnswerC

The Cert auth method authenticates clients by validating a TLS client certificate against one or more trusted CA certificates configured on the mount. Uploading the issuing CA lets Vault verify the chain presented during the TLS handshake, and the role's allowed_common_names or required_extensions map the verified identity to policies, matching the smart-card-backed certificate requirement.

Why this answer

Cert auth is purpose-built to authenticate clients from their TLS client certificates by validating the chain against a trusted CA configured on the mount. The architect must upload the issuing CA certificate and define role bindings such as allowed_common_names so the verified certificate maps to Vault policies, which aligns with the smart-card PKI already in place.

Exam trap

The trap here is believing Vault needs the client's private key to validate a certificate, when Cert auth only validates the presented chain against a trusted CA.

Full explanation →

MCQhard

A security team encrypts records with a transit key and stores the resulting ciphertext. Months later they rotate the key several times. An application now needs to read old records, and the team also wants future writes to use only the newest key version without breaking decryption of the legacy rows. What is the accurate behavior of the transit engine in this situation?

A.Decryption of old ciphertext fails after rotation, so every stored record must be re-encrypted with the new key version.

B.The application must call the rewrap endpoint on every stored record before any decryption can succeed after a rotation.

C.Old ciphertext decrypts normally because the version prefix selects the correct key version, and new encrypt calls automatically use the latest version.

D.Rotation deletes older key versions by default, so only ciphertext produced after the most recent rotation can be decrypted.

AnswerC

The transit engine prefixes ciphertext with the key version, so decryption looks up the matching retained version automatically. After rotation, the newest version becomes the default for new encrypt operations, meaning legacy rows stay readable while fresh writes use the rotated key. This is the designed rotation model and requires no application-side version tracking.

Why this answer

Transit ciphertext carries its key version, and Vault keeps prior versions available for decryption by default. Rotation therefore changes which version new encryptions use while leaving existing data readable. Rewrapping is an optional forward-migration step, not a requirement, and rotation does not purge older versions.

Exam trap

The trap here is believing that rotating a key makes previously encrypted data undecryptable, when version retention is specifically designed to prevent that outcome.

Full explanation →

MCQeasy

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

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

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

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

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

AnswerD

Vault's transit engine exposes encryption at /v1/transit/encrypt/<key-name>, so the named key 'payment-key' is appended as the final path segment. A POST to that endpoint submits plaintext and returns ciphertext, matching the existing key's encryption-allowed configuration.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQhard

A security team must delegate policy management to a group of operators without giving them the ability to grant themselves capabilities on protected paths such as 'sys/*' or 'auth/token/*'. Which combination of policy rules best implements this delegation safely?

A.Grant 'create' and 'update' on 'sys/policies/acl/*' and additionally restrict the operators through a Sentinel or policy-as-code layer that rejects stanzas referencing 'sys/*' or 'auth/token/*'.

B.Grant 'create' and 'update' on 'sys/policies/acl/*' plus 'read' on 'sys/policies/acl', and rely on Vault's default behavior that operators can only write policies they themselves could exercise.

C.Grant 'create' and 'update' on 'sys/policies/acl/*' and require operators to authenticate with a token that has a short TTL, since Vault re-evaluates policy contents against the author's ACL at token creation time.

D.Grant 'sudo' on 'sys/policies/acl/*' along with 'create' and 'update', because the sudo capability makes Vault validate that submitted policies do not exceed the author's own privileges.

AnswerA

Vault's ACL system does not constrain the contents of a policy an operator may write, so write access to the policy endpoint is inherently a path to privilege escalation unless an external guard inspects the submitted document. Adding a policy-as-code or Sentinel validation layer that rejects protected path stanzas closes that gap while still allowing day-to-day policy authoring.

Why this answer

Because Vault treats a policy document as opaque content and does not verify that the author could exercise the capabilities being granted, write access to the policy endpoint is effectively administrative. Safe delegation therefore requires an external validation layer that inspects submitted stanzas and rejects protected paths, rather than relying on sudo, TTLs or imagined self-escalation checks.

Exam trap

The trap here is assuming Vault enforces that policy authors cannot grant more than they themselves hold, a property that does not exist in the ACL system.

Full explanation →

MCQmedium

A platform team runs a nightly batch job that authenticates to Vault with the AppRole auth method and receives a token with a 30-minute TTL. The job occasionally overruns and hits 'permission denied' errors mid-run. The team wants the token to stay valid as long as the job keeps working, without the job re-authenticating. Which token attribute should the AppRole role be configured with when the token is issued?

A.Set token_explicit_max_ttl to 24h on the AppRole role

B.Set token_period to 30m on the AppRole role so the token is a periodic token

C.Increase the token_ttl to 24h and disable renewal on the AppRole role

D.Set token_no_default_policy to true on the AppRole role

AnswerB

A periodic token has no absolute lifetime cap and can be renewed indefinitely as long as it is renewed before each period elapses. Setting token_period on the AppRole role issues tokens of that period, letting the batch job renew continuously without re-authenticating. This directly matches the requirement that the token stay valid as long as the job keeps working.

Why this answer

The requirement is a token that stays valid as long as it keeps being renewed, which is exactly the behavior of a periodic token. Configuring token_period on the AppRole role makes issued tokens periodic, so the nightly job can renew indefinitely before each period lapses instead of being cut off by a fixed TTL or an absolute maximum lifetime.

Exam trap

The trap here is assuming that a longer token_ttl or an explicit_max_ttl makes a token effectively unlimited, when only a periodic token removes the absolute lifetime cap.

Full explanation →

MCQeasy

A security engineer is reviewing Vault's architecture and asks about the component that stores the actual encrypted data. Which Vault component is responsible for persisting encrypted secrets and configuration data?

A.The token store, which manages client tokens and their associated policies and metadata.

B.The storage backend, such as Integrated Storage (Raft) or Consul, which stores encrypted data at rest.

C.The audit device, which logs all requests and responses and stores them in a persistent file or syslog.

D.The seal mechanism, which holds the master key and unseal keys in memory during operation.

AnswerB

The storage backend is where Vault persists all encrypted data, including secrets, policies, and configuration. Vault supports various backends like Integrated Storage (Raft), Consul, and file. The data is encrypted by the barrier before being written, so the storage backend only sees ciphertext. This separation of storage and encryption is a core security principle.

Why this answer

The storage backend is the component that persists encrypted data at rest. Vault encrypts all data via the barrier before writing to the storage backend, which can be Integrated Storage (Raft), Consul, or a file system. This ensures that even if the storage is compromised, the data remains confidential.

Exam trap

The trap here is confusing the storage backend with audit devices or the token store, which have different roles in Vault's architecture.

Full explanation →

MCQeasy

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

A.The ciphertext of "hello"

B.Both the key name and the ciphertext

C.A reference to the key

D.The plaintext "hello" in raw bytes

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

AnswerE

The transit engine's encrypt endpoint requires the plaintext field to be base64-encoded, since the API transports binary-safe data. Sending the raw string "hello" is rejected; the base64 form is mandatory for the request to succeed.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Full explanation →

MCQeasy

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

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

B.vault secrets enable kv-v2 team-alpha

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

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

AnswerA

The -path flag sets the mount point while kv-v2 selects the versioned key-value engine, enabling it at team-alpha. This satisfies the scenario by mounting KV v2 at the exact requested path rather than the default secret/ location.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQhard

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

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

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

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

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

AnswerA

Disaster Recovery Replication is asynchronous, so writes acknowledged by the primary may not have reached the DR secondary before the failure. Promotion exposes that gap, explaining the missing secret data without any corruption or misconfiguration.

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQhard

A consulting firm deploys Vault to multiple tenants. Each tenant uses the OIDC auth method with its own identity provider, but the security team observes that users from one tenant occasionally receive policies intended for another tenant. The OIDC mounts were configured separately, and each uses a distinct default_role. Which configuration issue most likely explains the cross-tenant policy assignment?

A.The user_claim and groups_claim settings on each role resolve to values that collide across tenants, and Vault maps them to the same external group aliases.

B.Each OIDC mount uses the same bound_issuer value, so tokens from either provider are treated as originating from a single issuer.

C.The OIDC discovery URL for one tenant was entered with a trailing slash, causing claim parsing to fall back to defaults.

D.The OIDC role's bound_audiences value includes an audience shared by both identity providers.

AnswerA

When OIDC roles map group claims to external groups, Vault creates group aliases on the identity backend. If two tenants produce the same claim value, the alias collides and the group's policies are applied to users from both tenants. Distinct mounts and default roles do not prevent this, because the identity group alias is global to the namespace rather than scoped to the auth mount.

Why this answer

Identity group aliases created from OIDC group claims are stored on the identity backend and are not isolated per auth mount. When claim values coincide across tenants, Vault treats them as the same external group and attaches that group's policies to all matching users. Auditing the user_claim and groups_claim values, and namespacing alias names, resolves the collision.

Exam trap

The trap here is assuming that separate OIDC mounts provide complete tenant isolation, when identity group aliases derived from claims are actually shared across mounts within the same namespace.

Full explanation →

MCQeasy

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

A.KV secrets engine

B.AWS secrets engine

C.Database secrets engine

D.PKI secrets engine

AnswerC

The database secrets engine dynamically generates unique, short-lived MySQL credentials on demand, eliminating static passwords. It satisfies the stem's requirement for dynamic, short-lived database credentials by issuing them through a configured database role, with automatic revocation on lease expiry. Static or KV engines cannot generate per-request credentials tied to a lease.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQmedium

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

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

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

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

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

AnswerA

PKI roles bind issuance to permitted domains and key parameters, so a per-service role with its own allowed domains lets each service obtain only its own CN certificate. This satisfies the requirement for multiple CNs while enforcing least privilege at issuance.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQeasy

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

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

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

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

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

AnswerB

The policy grants read capability on the secret/data/engineering/db-pass path, so the token can retrieve that secret's data. Reading requires the read capability on the exact path, which this policy explicitly permits, satisfying the stem's action requirement.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

Multi-Selecthard

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

Select 3 answers

A.PUT /v1/auth/token/roles

B.POST /v1/auth/token/renew

C.DELETE /v1/auth/token/revoke

D.POST /v1/auth/token/create

E.GET /v1/auth/token/lookup

AnswersB, D, E

POST /v1/auth/token/renew is a valid token lifecycle endpoint, satisfying the stem's requirement for token-related actions. It renews an existing token before expiry, extending the session without full re-authentication. This matches the operator's need to manage token lifecycle operations alongside revoke and lookup endpoints.

Why this answer

In HashiCorp Vault's token auth method, POST /v1/auth/token/renew (option B) is correct because token renewal is performed by submitting a token (and optional increment) to the renew endpoint, which extends the token's TTL. POST /v1/auth/token/create (option D) is correct because new tokens are minted by POSTing parameters such as policies, TTL, and renewable flags to the create endpoint. GET /v1/auth/token/lookup (option E) is correct because looking up a token's metadata (policies, TTL, display name) is a read operation against the lookup endpoint, typically using the X-Vault-Token header or the token as a parameter.

Option A is wrong because token roles are managed under /v1/auth/token/roles using POST to create, GET to read, and DELETE to remove, not PUT. Option C is wrong because revoking a token is done with POST /v1/auth/token/revoke (or /revoke-self, /revoke-orphan), not DELETE.

Exam trap

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

Full explanation →

MCQmedium

An application stores user profile documents in a database and must encrypt field values with Vault's transit engine. A reviewer notes that anyone with the application's token could still send arbitrary ciphertext to the decrypt endpoint and read the result. The team wants to limit blast radius if the token leaks. Which transit engine capability best reduces this risk?

A.Set a short TTL on the transit key so it expires and can no longer decrypt.

B.Rely on the audit log to detect misuse after the fact and alert on decrypt calls from unexpected tokens.

C.Use a Vault policy that grants only 'encrypt' capability on the key path, and issue decrypt rights to a separate, more tightly scoped identity.

D.Enable 'exportable=true' so the team can move the key to a hardware security module and remove it from Vault.

AnswerC

Transit capabilities are separated by endpoint, so a policy can allow 'encrypt' on the key's encrypt path while denying decrypt entirely. If the application's token leaks, the attacker can only produce ciphertext, not recover plaintext. Splitting decryption to a distinct identity with its own policy enforces least privilege and directly shrinks the blast radius.

Why this answer

The transit engine authorizes each endpoint path independently, so a token can be given encrypt-only rights. That means a leaked application token cannot decrypt stored ciphertext, and decryption can be reserved for a separate identity. Exporting keys or relying on post-hoc auditing does not prevent the misuse the reviewer described.

Exam trap

The trap here is treating audit logging as a preventive control, when it only records activity after a token has already succeeded in decrypting data.

Full explanation →

MCQhard

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

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

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

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

D.Encrypt the unseal key file with a strong password

AnswerB

Cloud auto-unseal delegates the unseal key to an external KMS, so the root key never resides on the Vault server's filesystem. Root access alone then cannot retrieve it; the attacker would also need KMS credentials and permissions. This directly satisfies the stem's constraint of preventing unseal-key theft via server compromise.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQeasy

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

A.KV v2 secrets engine

B.AWS secrets engine

C.Database secrets engine

D.Transit secrets engine

AnswerA

KV v2 stores static key-value pairs and replaces the deprecated generic engine, satisfying the migration constraint. It adds versioning, metadata and soft-delete, letting the operator retain prior secret versions and recover deleted data. Enable it at a chosen path, then migrate existing generic secrets into it.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQhard

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

A.The secondary cluster has not enabled performance standby.

B.The replication filter is excluding certain paths.

C.The cluster is in 'primary_failover' mode.

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

AnswerB

Performance Replication asynchronously streams data to secondaries, and replication filters determine which paths replicate. Excluding paths means those reads never reach eu-west-1, so clients there see stale or missing values until the filter is corrected.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQhard

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

A.role_type

B.credential_type

C.inline_policy

D.arn

AnswerD

The `arn` parameter specifies the Amazon Resource Name of the IAM role that Vault assumes via STS to generate dynamic credentials. Without it, the AWS secrets engine cannot identify which role to assume, so role creation fails. This directly satisfies the stem's requirement for the essential parameter enabling IAM role assumption.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQeasy

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

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

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

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

D.POST /v1/transit/random

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

AnswerA

Vault's transit secrets engine exposes encryption as a service under the transit/ path, and the encrypt endpoint takes the key name as a path parameter. POST /v1/transit/encrypt/my-key submits plaintext to the named key my-key and returns ciphertext, satisfying the named-key requirement.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Full explanation →

MCQmedium

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

A.It is destroyed because cas_required is true

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

C.It is permanently deleted immediately

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

AnswerB

A KV v2 delete marks the version as deleted by writing a deletion marker, removing it from reads. The underlying data remains, so the version can be undeleted unless it is destroyed or its metadata removed.

Why this answer

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

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

Full explanation →

MCQmedium

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

A.The bind credentials are incorrect

B.The userpass auth method is still enabled

C.LDAP groups are not mapped to Vault policies

D.The LDAP server is unreachable

AnswerC

LDAP authentication resolves group membership from directory attributes, and Vault applies policies only when those groups are mapped via the groups parameter. Without that mapping, users authenticate successfully but receive only the default policy, so their intended policies never apply.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

100

Multi-Selectmedium

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

Select 2 answers

A.Senlin

B.Consul Template

C.Vault Agent

D.Barrier

E.Seal

AnswersD, E

The barrier is Vault's core security mechanism: data in the storage backend stays encrypted until unsealed with unseal keys, separating storage from trust. This satisfies the stem by naming a genuine architectural component, distinct from pluggable storage and audit devices.

Why this answer

The Barrier (D) is a core Vault architectural component: it is the cryptographic layer that ensures data written to the storage backend is encrypted, and all requests must pass through the barrier before reaching the storage backend. The Seal (E) is also a core Vault component: it is the mechanism that protects the barrier's encryption key, and Vault starts in a sealed state where it cannot decrypt data until it is unsealed with the required unseal keys or auto-unseal mechanism. Consul Template (B) is an external HashiCorp tool that can render templates from Vault data, but it is not part of Vault's internal architecture.

Vault Agent (C) is an optional client-side helper for authentication and caching, not a core architectural component of the Vault server. Senlin (A) is an OpenStack clustering service and has no relation to Vault's architecture.

Exam trap

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

Full explanation →

101

MCQeasy

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

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

B.vault auth userpass username=alice password=secret

C.vault token create -policy=userpass

D.vault authenticate userpass username=alice password=secret

AnswerA

`vault login -method=userpass` authenticates against the userpass auth method, passing `username` and `password` as method-specific parameters. This satisfies the stem's requirement to authenticate a user with a username and password, unlike `vault auth` or token-based commands that target different auth methods.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

102

MCQmedium

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

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

B.Enable performance standby nodes.

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

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

AnswerA

Raft integrated storage provides automatic leader election: nodes hold a replicated log and elect a leader via consensus quorum. When the active node fails, remaining nodes detect the lost heartbeat and promote a new leader without operator action, satisfying the no-manual-intervention failover constraint across the three data centres.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

103

MCQmedium

A platform team uses Vault to issue short-lived tokens to external contractors. The security policy requires that every contractor token must be traceable back to the contractor's identity, and that a token can never be renewed beyond its initial TTL. The team creates tokens with the default settings. A contractor later reports that their token stopped working after its TTL expired, but they were able to renew it several times before that. Which token parameter should the team have configured to enforce the policy?

A.Set the token's explicit max TTL to the same value as its initial TTL.

B.Create the token with the display-name parameter set to the contractor's identity and an explicit max TTL equal to the initial TTL.

C.Set the token's period to a fixed value and enable renewal.

D.Create the token with the no-default-policy option and attach a custom policy.

AnswerB

The display-name parameter allows operators to associate a human-readable identity with the token, satisfying traceability. Setting an explicit max TTL equal to the initial TTL ensures that even if the token is renewed, it cannot be renewed past that maximum lifetime. Together, these settings enforce both the traceability and the non-renewal-beyond-initial-TTL requirements described in the policy.

Why this answer

To enforce the policy, the token must be traceable to the contractor and must not be renewable beyond its initial TTL. The display-name parameter provides traceability by linking the token to a specific identity. An explicit max TTL set to the same value as the initial TTL caps the total lifetime, so renewals cannot extend it.

Other parameters like period or no-default-policy do not satisfy both requirements simultaneously.

Exam trap

The trap here is assuming that setting a max TTL alone satisfies traceability, or that periodic tokens can be used to enforce a hard lifetime limit.

Full explanation →

104

MCQhard

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

A.The connection string is incorrect

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

C.The database engine is not enabled

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

AnswerB

Vault verifies the PostgreSQL server's TLS certificate against its own CA bundle during connection setup. An untrusted or self-signed certificate produces exactly this x509 error, satisfying the stem's failure at config-write time, before any credential or role logic executes.

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

105

MCQhard

A database secrets engine is configured at database/ with a connection to PostgreSQL and a role named app-readonly. The role uses creation_statements to create a user with a random password and a TTL of one hour. An application retrieves credentials and uses them successfully, but after the lease expires the database user still exists and can log in. Which configuration change should the administrator make to ensure the user is removed when the lease ends?

A.Enable the database secrets engine with a root rotation schedule to force user cleanup.

B.Set the role's credential_type to static_role and rely on automatic revocation.

C.Increase the default_ttl on the role to match the maximum_ttl so the lease never expires.

D.Add revocation_statements to the role that drop the user, and ensure the connection user has permission to execute them.

AnswerD

Revocation is driven by revocation_statements on the role, which Vault executes when the lease expires or is revoked. If they are missing or the connection user lacks privileges, the database user persists. Adding appropriate DROP USER statements and granting the connection user permission resolves the lingering-user problem.

Why this answer

Dynamic database credentials are cleaned up by executing the role's revocation_statements when the lease is revoked or expires. If those statements are absent or the connection user lacks the privilege to run them, the created user remains. Supplying correct DROP USER statements and ensuring the connection user can execute them restores proper lifecycle management.

Exam trap

The trap here is assuming that lease expiration alone deletes the database user, when Vault depends on revocation_statements and the connection user's privileges to perform the cleanup.

Full explanation →

106

MCQeasy

A Vault administrator needs to delegate the ability to create tokens to a user without granting full administrative privileges. Which token type should the administrator create for the user to allow them to create tokens with specific policies?

A.A batch token

B.A service token with a policy that includes the 'create' capability on the 'auth/token/create' path.

C.An orphan token

D.A root token

AnswerB

A service token is a standard Vault token that can be assigned policies. By attaching a policy that allows the 'create' capability on the 'auth/token/create' path, the user can create tokens with specific policies (as allowed by the policy). This delegates token creation without granting full administrative privileges, adhering to least privilege.

Why this answer

Delegating token creation requires a token that can be assigned policies allowing the creation of tokens. A service token with a policy that permits the 'create' capability on the token creation endpoint enables the user to create tokens with specified policies. This approach follows the principle of least privilege by limiting the user's abilities to exactly what is needed.

Exam trap

The trap here is assuming that any token type can create tokens, but batch tokens cannot have children and root tokens are too privileged.

Full explanation →

107

Multi-Selectmedium

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

Select 2 answers

A.vault set

B.vault put

C.vault push

D.vault write

E.vault kv put

AnswersD, E

`vault write` sends data to a specified path, storing it as a new secret version or creating the path if absent. It satisfies the stem's requirement to write data, accepting key-value pairs as arguments and returning the written metadata. This makes it one of the two valid commands for persisting data in Vault.

Why this answer

Option D, `vault write`, is correct because it is the general-purpose Vault CLI command for writing data to a path, such as `vault write secret/foo bar=baz`, and it works across secrets engines including KV v1 and v2. Option E, `vault kv put`, is correct because it is the KV secrets engine subcommand specifically designed to write key-value data, e.g. `vault kv put secret/foo bar=baz`, and it handles KV v2 versioning automatically. The unmarked options do not belong: `vault set`, `vault put`, and `vault push` are not valid Vault CLI commands for writing data, so they would fail as unknown subcommands.

Exam trap

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

Full explanation →

108

MCQeasy

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

A.vault get kv/secret/mykey

B.vault retrieve kv/secret/mykey

C.vault show kv/secret/mykey

D.vault read kv/secret/mykey

AnswerD

`vault read` targets the KV version 1 API, returning the secret's data directly from the given path. For the `kv/secret/mykey` mount, this retrieves the stored value without requiring the `-field` flag or a `data/` path segment that KV version 2 mandates.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

109

MCQmedium

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

A.Service tokens

B.Periodic tokens

C.Batch tokens

D.Orphan tokens

AnswerC

Batch tokens are lightweight, non-renewable credentials designed for short-lived, ephemeral workloads such as CI jobs. They cannot be renewed, so they satisfy the stem's constraint of credentials that do not need renewal, unlike service tokens, which support renewal and carry heavier storage overhead.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

110

MCQeasy

A platform engineer has issued dynamic AWS credentials through Vault's AWS secrets engine and wants to extend the usable lifetime of that credential before it expires. Which Vault CLI command allows the engineer to request additional time on the lease?

A.vault lease renew <lease_id>

B.vault token renew <token>

C.vault write aws/creds/my-role ttl=1h

D.vault lease revoke <lease_id>

AnswerA

The vault lease renew command extends the lease of a secret that was already issued. When run against an AWS secrets engine lease, Vault asks the backend to extend the credential's validity, subject to the role's max_ttl. This directly matches the engineer's goal of gaining additional usable time before the credential expires.

Why this answer

Leases on dynamic secrets can be extended with vault lease renew, which asks the secrets engine to grant more time within the role's max_ttl boundary. Revoking destroys the credential, renewing a token affects authentication rather than the secret, and re-writing the creds path issues a separate credential instead of extending the current one.

Exam trap

The trap here is confusing token renewal with lease renewal, assuming that renewing the token also extends the lifetime of secrets issued under it.

Full explanation →

111

MCQhard

A security engineer is troubleshooting why a Vault token cannot be renewed. The token was created with a TTL of 4 hours and is renewable. After 2 hours, the engineer attempts to renew it using `vault token renew <token>` but receives the error: "lease not found". The engineer confirms the token is still valid and not expired. Which of the following is the most likely cause?

A.The token's TTL has been exceeded, causing Vault to delete the lease record.

B.The token's lease was revoked or expired, possibly due to a parent token revocation or lease cleanup, even though the token itself remains valid.

C.The token was created with the -no-default-policy flag, which disables renewal.

D.The token was created with a period but no explicit max TTL, and the period has not yet elapsed.

AnswerB

In Vault, tokens and their leases are related but distinct. A token can remain valid while its lease record is removed due to parent revocation, manual lease revocation, or a bug in lease management. The "lease not found" error indicates that Vault cannot find the lease to renew. This can happen if the token's parent was revoked, causing the child token's lease to be cleaned up, but the token itself might still be usable until its TTL expires. The engineer should check for revoked parent tokens or lease revocation events.

Why this answer

The "lease not found" error during token renewal typically means the lease record for the token is no longer present in Vault's storage. This can occur if the token's parent was revoked, which cascades to revoke child tokens and their leases, or if the lease was manually revoked or expired due to a separate lease ID. The token itself may still be within its TTL and appear valid, but without a lease, renewal is impossible.

The engineer should investigate recent revocations or lease cleanup operations.

Exam trap

The trap here is assuming that a valid token always has a renewable lease, but leases can be revoked independently, leading to "lease not found" even when the token is not expired.

Full explanation →

112

MCQeasy

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

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

B.It defines the maximum lifetime of a token.

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

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

AnswerA

A periodic token's period sets the initial TTL and is reset to that value on every renewal, so the token survives indefinitely provided it is renewed within each window. Without renewal it expires, satisfying the periodic-token behaviour the question describes.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

113

MCQmedium

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

A.Vault's Database secrets engine

B.Vault's PKI secrets engine

C.Vault's Transit secrets engine

D.Vault's Key Management Secrets Engine

AnswerC

The transit secrets engine offers encryption as a service, so applications call Vault's API to encrypt and decrypt while Vault manages and protects the keys. This minimises code changes and removes the burden of key management, satisfying both stated constraints.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

114

MCQeasy

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

A.There is no way to list all tokens.

B.`vault token list`

C.`vault list auth/token/accessors`

D.Both A and B

AnswerC

`vault list auth/token/accessors` queries the token store's accessor index, returning every active token's accessor ID without exposing the tokens themselves. This directly satisfies the stem's requirement to view all active tokens, since accessors enumerate the full set of live tokens in Vault's token auth method.

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

115

MCQeasy

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

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

B.The transit secrets engine for encrypting secrets.

C.Vault's storage encryption via the barrier.

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

AnswerC

Vault encrypts all data at rest in the storage backend using its barrier, an AES-GCM encryption layer wrapping every entry before it reaches Consul, Raft, or any other backend. This satisfies the requirement that static secrets remain encrypted within the storage layer itself.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

116

MCQhard

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

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

B.The ciphertext was generated by a different transit key

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

D.The application is using the wrong encryption algorithm

AnswerA

Vault's min_decryption_version blocks decryption of ciphertext produced by any key version below it. With version 3 ciphertext and the floor set to 4, the engine refuses the operation, directly explaining the failure despite version 5 being current.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

117

MCQmedium

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

A.LDAP authentication

B.OIDC authentication

C.Userpass authentication

D.Token authentication

AnswerB

OIDC authentication delegates login to an external identity provider via federated tokens, so Vault never stores or verifies passwords itself. This satisfies the stem's requirement that credentials reside in the IdP and Vault hold no passwords.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

118

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 uses eventually consistent replication across its infrastructure. A newly created IAM user or access key may not be usable for several seconds until that change propagates, so immediate authentication attempts can fail even though the credentials were generated successfully.

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 →

119

MCQmedium

A Vault operator needs to enable the `userpass` auth method at the path `auth/legacy-userpass` and then create a user named `svc-backup` with a password, all from a CI script. Which single command correctly enables the auth method at that custom path?

A.vault auth enable userpass -path=legacy-userpass

B.vault write sys/auth/legacy-userpass type=userpass

C.vault auth enable -path=legacy-userpass userpass

D.vault secrets enable -path=legacy-userpass userpass

AnswerC

`vault auth enable` accepts `-path` to mount an auth method at a custom path, and the final argument names the method type. This mounts userpass at `auth/legacy-userpass`, exactly as required. Subsequent user creation would target `auth/legacy-userpass/users/svc-backup`. It is the correct, non-interactive CLI form for the scenario.

Why this answer

The `vault auth enable` command mounts an auth method, and its `-path` flag sets a custom mount path so the method lives at `auth/legacy-userpass` rather than the default `auth/userpass`. The method type is the trailing positional argument. Using `vault secrets enable` targets secrets engines instead, and writing to `sys/auth` directly is the raw API path rather than the intended CLI interface.

Exam trap

The trap here is confusing `vault auth enable` with `vault secrets enable`, which mount auth methods and secrets engines respectively.

Full explanation →

120

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 least-privilege policy granting read on secret/engineering/* restricts the token to exactly that path subtree, then attaching it to the token scopes access accordingly. This satisfies the read-only, single-path constraint without granting broader capabilities elsewhere in the secrets engine.

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 →

121

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 authentication stores credentials directly in Vault, letting the developer log in with a username and password alone. It satisfies the stem's constraint of requiring no external identity provider, unlike OIDC or LDAP methods that delegate verification to Microsoft Entra ID or another directory service.

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 →

122

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

The Database secrets engine dynamically generates short-lived credentials on demand, eliminating static passwords. It satisfies the stem's requirement for automatic generation by creating unique database users per request and revoking them at lease expiry, rather than storing long-lived secrets in Microsoft Entra ID or a static key-value store.

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 →

123

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

The Kubernetes auth method validates a pod's service account JWT against the Kubernetes API, then returns a Vault token, so pods authenticate without any static secret stored in the container. This directly satisfies the stem's requirement for secretless pod authentication.

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 →

124

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

Consul tokens inherit a copy of their parent's policies at creation time; later changes to the parent do not propagate. The child therefore retains only 'default' and 'web-app', and the newly added 'logging' policy never applies to it.

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 →

125

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

Separate per-application policies keep each rule set minimal and auditable, while group aliases map identity-provider groups to those policies without duplicating rules per user. This satisfies least privilege and simplifies ongoing management as applications and team memberships change.

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 →

126

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

A successful LDAP bind followed by 'user not found in group' means credentials validated but group membership resolution failed. Vault's groupfilter and groupattr settings control how groups are queried and mapped, so incorrect values there prevent the user matching any group.

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 →

127

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

Templated policies interpolate identity entity metadata at request time, so {{identity.entity.metadata.team}} resolves to each user's team value. One policy then grants read and list on that team's path, eliminating per-team policies as new teams are added, satisfying the dynamic single-policy requirement.

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 →

128

Multi-Selecthard

A platform team is designing an encryption-as-a-service layer with the transit secrets engine for several internal applications. They want to minimize the amount of sensitive data that reaches application memory and reduce the operational cost of rotating keys. Which TWO design choices align with how the transit engine is intended to be used? (Choose two.)

Select 2 answers

A.Export the transit key and distribute copies to each application so they can encrypt without any runtime dependency on Vault.

B.Have applications call the encrypt and decrypt endpoints so plaintext never leaves the application but key material never reaches it.

C.Disable key versioning on all keys so that rotation does not create new versions that applications must track.

D.Generate a data key with the datakey endpoint, encrypt the payload locally with it, and store the wrapped key alongside the ciphertext.

E.Store the plaintext data key in the application's configuration file so services can reuse it across restarts and avoid extra Vault calls.

AnswersB, D

This is the core encryption-as-a-service pattern: the application submits plaintext to Vault and receives ciphertext, so the key stays protected inside Vault while the application retains control of its data. It also centralizes audit logging and lets policies govern which callers can encrypt or decrypt, which is exactly what the engine is designed to support.

Why this answer

The transit engine supports two complementary patterns: direct encrypt/decrypt calls that keep keys inside Vault, and envelope encryption using the datakey endpoint so bulk data is encrypted locally with a wrapped key stored alongside it. Both minimize key exposure and make rotation manageable. Exporting keys, disabling versioning, or persisting plaintext data keys all undermine those goals.

Exam trap

The trap here is assuming that reducing Vault round-trips justifies exporting or persisting key material, when the datakey endpoint already provides a safe way to encrypt locally.

Full explanation →

129

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

A SecretID is only a login credential; once exchanged for a token, that token has its own lifecycle and lease. Deleting the SecretID prevents future logins but does not revoke already-issued tokens, which require explicit revocation.

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 →

130

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 delegates the unseal key to AWS KMS, so each node must reach KMS at startup or after resealing. The partition blocks the standby's KMS calls, leaving it sealed, while the active node already holds its unsealed state and continues serving.

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 →

131

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

Setting a ttl of 1h on the specific database role overrides the engine's default lease TTL for credentials issued through that role only, enforcing the one-hour expiry without altering global defaults for other secrets or roles.

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 →

132

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

Vault caps every token's cumulative lifetime at explicit_max_ttl, regardless of how often it is renewed. Renewals extend the TTL but cannot push total age past 120h, so after 10 days (240h) the token is long expired.

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 →

133

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

The `vault status` output lists `n` as 5 and `t` as 3, meaning the master key is split into five shares via Shamir's Secret Sharing, with any three required to reconstruct it and unseal the vault. This directly satisfies the exhibit's unseal configuration constraint.

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 →

134

MCQeasy

A developer wants to inspect the metadata of the current Vault token, including its attached policies, TTL, and whether it is renewable, using a single CLI command. Which command should the developer run?

A.vault token renew

B.vault auth list

C.vault token capabilities

D.vault token lookup

AnswerD

`vault token lookup` with no argument inspects the calling token and returns its accessor, policies, TTL, renewable status, and other metadata. This matches the developer's need to see policies, TTL, and renewability in one command. It is the standard CLI command for examining the current token's properties.

Why this answer

The `vault token lookup` command retrieves metadata for the calling token when no token argument is supplied, exposing fields like `policies`, `ttl`, `renewable`, and `accessor`. It is a read-only operation with no side effects, unlike renewal. Commands such as `vault auth list` or `vault token capabilities` serve entirely different purposes and cannot report the token's policies and TTL.

Exam trap

The trap here is reaching for `vault token renew` to see TTL, when renewal mutates the token and does not list policies.

Full explanation →

135

MCQmedium

A Vault administrator is writing a policy for a monitoring tool that must be able to list all secrets under the 'secret/metadata/finance/' path and read the metadata of individual secrets, but must not read the secret data itself. Which policy snippet correctly grants only these permissions?

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

B.path "secret/metadata/finance/*" { capabilities = ["read"] }

C.path "secret/metadata/finance/*" { capabilities = ["list", "read"] }

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

AnswerC

This snippet grants list and read capabilities on the metadata path for all secrets under finance. In KV v2, metadata operations like listing and reading secret metadata are performed on the metadata/ path, so this precisely meets the requirement without granting access to the actual secret data.

Why this answer

In Vault's KV v2 secrets engine, metadata operations such as listing secrets and reading secret metadata are performed on the metadata/ path, while reading and writing secret data uses the data/ path. To allow listing and reading metadata without accessing secret data, the policy must grant list and read on secret/metadata/finance/*. The other options either target the wrong path or omit required capabilities.

Exam trap

The trap here is assuming that list and read on the data/ path will allow listing secrets and reading metadata, when in fact KV v2 separates metadata and data operations into distinct paths.

Full explanation →

136

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 with renewal disabled forces Vault to revoke the token automatically once it expires, so a stolen token becomes useless after that window regardless of attacker possession. This directly satisfies the requirement that compromise cannot extend token usability.

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 →

137

Multi-Selectmedium

A compliance team is evaluating the Vault transit secrets engine as encryption as a service for several internal applications. They want to confirm which statements accurately describe how the engine behaves. (Choose two.)

Select 2 answers

A.Enabling the transit engine requires Vault to be sealed and then unsealed before any key can be created.

B.The transit engine supports key rotation while retaining prior versions so previously produced ciphertext remains decryptable.

C.The transit engine stores plaintext copies of all encrypted data for audit and recovery purposes.

D.The transit engine can perform cryptographic operations on data without the caller ever receiving the encryption key.

E.Transit keys are exportable by default so applications can cache them locally for offline encryption.

AnswersB, D

Rotation adds a new key version, and ciphertext carries a version prefix that decrypt uses to select the correct version. Older versions are retained, so existing data continues to work without re-encryption. This is a core operational feature that lets teams rotate regularly without breaking applications or requiring mass rewrites of stored ciphertext.

Why this answer

The transit engine performs cryptographic operations inside Vault and returns only protected output, keeping keys non-exportable. It supports versioned key rotation so old ciphertext still decrypts, which is essential for long-lived data. It does not store plaintext, does not require sealing to mount, and does not export keys by default, so those statements misrepresent its security model and operational behavior.

Exam trap

The trap here is conflating encryption as a service with key export or plaintext retention, when transit keeps keys inside Vault and never stores plaintext.

Full explanation →

138

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

The PKI secrets engine dynamically issues X.509 certificates with short lifetimes, satisfying the requirement for on-demand credentials for external systems. Unlike static secrets, each certificate is generated per request and expires automatically, removing manual rotation. It therefore directly addresses dynamic credential generation for external endpoints.

Why this answer

The PKI secrets engine (A) is correct because it dynamically generates X.509 certificates and private keys on demand from configured roles, issuing short-lived credentials rather than storing static ones. The AWS secrets engine (C) is correct because it dynamically generates AWS IAM credentials (access key ID and secret access key) or STS tokens based on IAM policies, providing on-demand, lease-bound cloud credentials. The Database secrets engine (E) is correct because it dynamically creates unique database usernames and passwords for supported databases (e.g., MySQL, PostgreSQL) tied to a lease, eliminating shared static credentials.

The KV v2 secrets engine (B) is not appropriate here because it only stores and versions static key-value secrets and does not generate credentials. The Transit secrets engine (D) is not appropriate because it provides encryption-as-a-service (encrypt/decrypt/sign/verify) and does not issue credentials for external systems.

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 →

139

Drag & Dropmedium

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

Drag or tap steps into the slots.

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 →

140

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 AWS secrets engine role binds the managed policy ARNs to credentials it generates, so Vault attaches those policies to each IAM user it creates. Without a role specifying the policies, generated users receive no managed policy attachments.

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 →

141

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 its persistent backend; without it, the server cannot initialise its storage layer and fails at startup. Since the error appears immediately on start, the missing storage block is the most likely cause rather than listener or seal configuration.

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 →

142

MCQmedium

A platform team runs Vault in an on-premises data center. Their legacy monitoring appliance cannot present a TLS client certificate and has no cloud identity provider, but it does have a dedicated filesystem path where it can read a small configuration file written at deployment time. The team wants the appliance to authenticate on a schedule with credentials that can be issued per appliance, scoped by policy, and revoked without affecting other appliances. Which authentication method best fits this requirement?

A.JWT/OIDC

B.TLS Certificates

C.Username & Password

D.AppRole

AnswerD

AppRole is designed for machine-to-machine authentication where the client holds a RoleID and a SecretID, both of which can be delivered through a file on the appliance. Each appliance can receive its own AppRole role, bound to a policy, and revocation of that role or its SecretIDs invalidates only that appliance's access without disturbing other clients.

Why this answer

AppRole is the machine-oriented authentication method that issues each client a RoleID and a SecretID, both of which can be delivered through a file on the appliance. Roles are bound to policies, and SecretIDs can be revoked individually, allowing the platform team to isolate and revoke a single appliance without impacting others. The other methods require capabilities the appliance does not have.

Exam trap

The trap here is assuming that any method which can read credentials from a file is equivalent, when only AppRole is purpose-built for non-interactive machine identities with per-client RoleID and SecretID issuance.

Full explanation →

143

Multi-Selecthard

A cloud engineer is scripting against the Vault HTTP API and must authenticate, then read a KV v2 secret, using only `curl`. Which TWO request elements are required for the read to succeed? (Choose two.)

Select 2 answers

A.A GET to the path `/v1/secret/data/apps/web/config`.

B.The header `X-Vault-Request: true` on the request.

C.A POST to the path `/v1/secret/apps/web/config` with a JSON body.

D.The header `X-Vault-Namespace: root` on the request.

E.The header `X-Vault-Token: <token>` on the request.

AnswersA, E

For KV v2, reading data uses the `/v1/<mount>/data/<path>` endpoint with the HTTP GET method. The `/v1` prefix and the `data` segment are both required; hitting the metadata or mount-root path returns metadata or a 404 instead of the secret payload. This endpoint is what the CLI calls under the hood.

Why this answer

API reads require a valid token in the `X-Vault-Token` header and, for KV v2, a GET to the `/v1/<mount>/data/<path>` endpoint. The token authorizes the call against policy, while the data endpoint routes to the versioned secret store. Namespace and request-marker headers are situational and not required for a root-namespace read.

Exam trap

The trap here is reusing the KV v1 path shape or assuming a custom header like `X-Vault-Request` is needed, when KV v2 reads go through the `data` endpoint with only the token header.

Full explanation →

144

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 →

145

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

Vault evaluates all matching policies together, and any matching deny rule overrides grants regardless of specificity or order. The deny on that path therefore blocks the read even if another policy grants it, so access is refused.

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 →

146

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 issues short-lived tokens using a RoleID and SecretID delivered to the Jenkins pipeline, with no dependency on Kubernetes service accounts or cloud instance metadata. This suits an external CI/CD server needing temporary credentials to read secrets.

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 →

147

MCQmedium

An admin is troubleshooting a Vault cluster where some dynamic secrets leases are not being revoked after their TTL expires. The admin confirms that the TTLs are set correctly. Which Vault component is responsible for revoking expired leases?

A.The audit device

B.The expiration manager

C.The Vault storage backend

D.The secrets engine plugin

AnswerB

Vault's expiration manager is responsible for tracking lease TTLs and revoking leases when they expire. It runs as part of the Vault core and periodically checks for expired leases. If leases are not being revoked, the expiration manager may be disabled or malfunctioning, making it the correct component to investigate.

Why this answer

The expiration manager is the Vault internal component that tracks lease TTLs and triggers revocation when leases expire. If leases are not being revoked despite correct TTLs, the expiration manager is the primary suspect. It runs within the Vault core and coordinates with secrets engines to revoke credentials.

Other components like storage, audit, and secrets engines do not initiate revocation.

Exam trap

The trap here is assuming that the secrets engine or storage backend handles lease expiration, when in fact the expiration manager is the dedicated component for that task.

Full explanation →

148

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

The barrier performs cryptographic operations on data before it reaches the storage backend, deriving keys from the root key via the shamir seal. It sits between the storage layer and the outside world, ensuring plaintext never touches physical disk.

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 →

149

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

Vault's transit secrets engine performs cryptographic operations server-side, so applications send plaintext to Vault and receive ciphertext back without ever holding key material. This satisfies the stem's delegation benefit: encryption and decryption are offloaded, keys remain centrally managed, and no application-side key handling or storage is required.

Why this answer

Option B is correct because Vault's Encryption as a Service (via the transit secrets engine) lets applications send plaintext to Vault's encrypt/decrypt endpoints and receive ciphertext or plaintext back, so the app never stores or manages the cryptographic keys itself. Option C is correct because the transit engine natively supports automatic key rotation and key versioning, allowing old ciphertext to remain decryptable while new data uses the latest key version. Option A is not a benefit specific to Encryption as a Service, since encrypting data at rest in cloud storage is typically handled by storage-level or disk encryption rather than Vault's transit engine.

Option D is wrong because applications must have network connectivity to reach Vault's API for encryption and decryption operations. Option E is wrong because the transit engine supports both symmetric algorithms (such as AES-GCM) and asymmetric algorithms (such as RSA and ECDSA).

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 →

150

MCQeasy

A Vault admin needs to revoke all leases under the `database/creds/readonly` path without revoking leases from other paths. Which command should the admin use?

A.vault lease revoke -prefix database/creds/readonly

B.vault lease revoke -force database/creds/readonly

C.vault lease revoke database/creds/readonly

D.vault lease revoke -all database/creds/readonly

AnswerA

The `vault lease revoke -prefix` command revokes all leases whose IDs start with the given prefix. Specifying `database/creds/readonly` targets exactly the leases created by that role, leaving other paths untouched. This is the correct way to perform a scoped, bulk revocation of leases under a specific secrets engine path.

Why this answer

To revoke all leases under a specific secrets engine path, the admin must use `vault lease revoke -prefix <path>`. The `-prefix` flag tells Vault to revoke every lease whose ID begins with the given string, which effectively targets all leases generated by that path. Other flags either expect a full lease ID or revoke everything cluster-wide.

Exam trap

The trap here is confusing the `-prefix` flag with other flags or omitting it, leading to either an invalid lease ID error or an overly broad revocation.

Full explanation →

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