Courseiva

HashiCorp Vault Associate VA-003 (VA-003) — Questions 1–75

366 questions total · 5pages · All types, answers revealed

Take a mock examExam hub

Page 1 of 5

Page 2
1
MCQmedium

A Vault operator deploys a single Vault server using Integrated Storage (Raft) as the storage backend. After initializing Vault, the operator notices that the server is marked as sealed and cannot serve requests. The operator has the unseal keys but wants to understand the architectural reason why Vault starts sealed after initialization. Which statement best explains why Vault is sealed immediately after initialization?

A.Vault is sealed because the TLS certificate for the API listener has not been configured, and Vault refuses to serve requests without encryption in transit.
B.Vault's security barrier is active by default; initialization generates the master key and unseal keys, but the master key must be provided via unseal keys to decrypt the barrier and access storage.
C.The Integrated Storage backend automatically seals Vault after initialization to prevent unauthorized access until the root token is used.
D.Vault requires a quorum of Raft peers to unseal automatically, and with only one node, quorum cannot be achieved.
AnswerB

Initialization creates the master key, which encrypts the barrier, and splits it into unseal keys using Shamir's Secret Sharing. Until a threshold of unseal keys is provided, the master key cannot be reconstructed, so the barrier remains sealed. This design ensures that even if storage is compromised, data stays encrypted. The operator must run vault operator unseal with enough keys to transition to an unsealed state.

Why this answer

Vault's security barrier encrypts all data before it reaches the storage backend. During initialization, Vault generates a master key and splits it into unseal keys. The barrier remains sealed until a threshold of unseal keys is provided to reconstruct the master key.

This ensures that storage alone is insufficient to access secrets. The other options confuse Raft quorum, root token usage, or TLS with the unsealing mechanism.

Exam trap

The trap here is assuming that Raft quorum or root token usage automatically unseals Vault, when unsealing is solely about reconstructing the master key via unseal keys.

Full explanation →
2
MCQeasy

An application needs to read a secret using the Vault API after authenticating with an AppRole RoleID and SecretID. The application has already obtained a Vault token. Which API endpoint should be called to read a secret at 'secret/data/myapp' with the token?

A.GET /v1/secret/metadata/myapp
B.POST /v1/auth/approle/login
C.GET /v1/secret/myapp
D.GET /v1/secret/data/myapp
AnswerD

KV v2 secrets are read through the data/ segment of the mount path, so the token-bearing GET request must target /v1/secret/data/myapp. Omitting data/ hits the metadata endpoint instead, satisfying the stem's requirement to read the secret value.

Why this answer

After authentication, the application already has a Vault token and needs to read a secret from the KV v2 secrets engine. The correct API endpoint for reading a secret from the KV v2 engine is GET /v1/secret/data/myapp, where 'secret' is the mount path and 'data' is the sub-path for KV v2 operations. The token is passed in the X-Vault-Token header, not in the URL.

Exam trap

HashiCorp often tests the distinction between KV v1 and KV v2 API paths, specifically that KV v2 requires '/data/' in the path to read secrets, while KV v1 uses a flat path without '/data/'.

How to eliminate wrong answers

Option A is wrong because GET /v1/secret/metadata/myapp is used to read metadata (like version info) of a KV v2 secret, not the secret data itself. Option B is wrong because POST /v1/auth/approle/login is the endpoint for authenticating with AppRole RoleID and SecretID to obtain a Vault token, but the question states the application has already obtained a token, so this step is unnecessary. Option C is wrong because GET /v1/secret/myapp is the endpoint for the KV v1 secrets engine, which does not support versioning and uses a different path structure; the question implies KV v2 (since the path includes 'data'), and using KV v1 endpoint would fail or return incorrect data.

Full explanation →
3
MCQeasy

A security engineer is onboarding a new application team to Vault. The team needs to understand how Vault manages the lifecycle of secrets issued by the database secrets engine. The engineer explains that Vault attaches a lease to dynamic secrets and that the lease defines the secret's validity period. Which statement accurately describes the relationship between a lease and a dynamic secret?

A.A lease is a static configuration setting on the secrets engine that applies the same TTL to every secret issued from that mount.
B.A lease is metadata that records the secret's validity period, renewal eligibility, and revocation behavior, and it is created alongside the dynamic secret.
C.A lease is a client-side token stored by the application that must be presented to Vault before the secret can be used.
D.A lease is created only when an administrator manually enables lease tracking on a secrets engine mount.
AnswerB

Every dynamic secret issued by Vault is accompanied by a lease that stores its TTL, renewability, and revocation instructions. This metadata lets Vault track the secret and automatically revoke it when the lease expires, ensuring credentials do not persist beyond their intended lifetime. The lease is the authoritative record of the secret's lifecycle.

Why this answer

Vault issues dynamic secrets together with a lease that records the secret's time-to-live, whether it can be renewed, and how it should be revoked. This server-side metadata is what allows Vault to automatically revoke credentials when they are no longer valid, which is a core security benefit of using dynamic secrets over static credentials.

Exam trap

The trap here is assuming a lease is a static mount configuration or a client-side artifact, rather than a per-secret server-side metadata record created at issuance.

Full explanation →
4
MCQmedium

A Vault operator is examining the architecture of a Vault cluster and wants to understand how client requests are routed to the active node. Which component is responsible for forwarding requests from standby nodes to the active node?

A.The standby nodes automatically forward client requests to the active node using the cluster's internal forwarding mechanism.
B.The storage backend, such as Integrated Storage (Raft), handles request forwarding between nodes.
C.The load balancer must be configured to route all requests only to the active node, as standby nodes cannot forward requests.
D.The active node polls standby nodes for pending requests and pulls them for processing.
AnswerA

In a Vault HA cluster, standby nodes can receive client requests but cannot process writes. They forward requests to the active node using the cluster's internal forwarding mechanism, which is built into Vault. This allows clients to connect to any node without needing to know which is active. The forwarding is transparent to the client.

Why this answer

Standby nodes in a Vault HA cluster forward client requests to the active node using Vault's internal forwarding mechanism. This allows clients to connect to any node, simplifying configuration and improving availability. The active node processes the request and returns the response through the standby node.

Exam trap

The trap here is assuming that a load balancer must always route to the active node, or that the storage backend handles forwarding, when Vault itself provides request forwarding.

Full explanation →
5
MCQmedium

A platform team manages a fleet of on-premises Linux servers that are not joined to any cloud provider or Active Directory domain. They want each server to authenticate to Vault automatically at boot without embedding a long-lived token in a configuration file. The team already maintains an internal PKI that issues X.509 certificates to every server. Which authentication method should they enable to meet these requirements with the least new infrastructure?

A.Enable the aws auth method and bind each server to an IAM role so it can call STS GetCallerIdentity during login.
B.Enable the approle auth method and distribute a role_id and secret_id to each server's configuration file.
C.Enable the cert auth method and configure a trusted CA certificate so each server presents its PKI-issued certificate during login.
D.Enable the ldap auth method and point it at the internal directory where each server has a service account.
AnswerC

The cert auth method validates the client certificate presented during the TLS handshake against a CA certificate configured on the mount. Because the internal PKI already issues certificates to every server, the team reuses existing infrastructure rather than deploying new credential stores or cloud integrations. This satisfies the requirement of automatic, token-free authentication at boot.

Why this answer

Certificate authentication leverages the PKI certificates the servers already possess, so no new credential distribution channel is needed. During the TLS handshake the server presents its certificate, and Vault validates it against the trusted CA configured on the cert mount. This yields automatic, secret-free login for on-premises hosts that have no cloud identity.

Exam trap

The trap here is assuming that any machine-to-machine method works everywhere, when cloud identity methods like aws auth only function for workloads that actually have a cloud-issued identity.

Full explanation →
6
MCQeasy

A small startup wants to run Vault in a development environment with minimal operational overhead. They need to store secrets in memory only, without any persistence. Which storage backend should they choose?

A.Integrated Storage (Raft) backend
B.In-memory storage backend
C.Consul storage backend
D.File storage backend
AnswerB

The in-memory backend stores all secrets solely in RAM with no disk writes, so nothing persists across restarts. This matches the requirement for zero persistence and minimal operational overhead, making it ideal for ephemeral development environments.

Why this answer

The in-memory storage backend stores all data in RAM with no persistence to disk, making it ideal for development environments where secrets must be lost on restart and operational overhead must be minimized. It requires no configuration, no external dependencies, and no data management, perfectly matching the requirement for minimal overhead and memory-only storage.

Exam trap

HashiCorp often tests the misconception that Integrated Storage (Raft) is the default or simplest backend, but candidates must recognize that Raft is persistent and requires cluster management, whereas the in-memory backend is the only option that guarantees zero persistence and minimal overhead.

How to eliminate wrong answers

Option A is wrong because Integrated Storage (Raft) is a persistent, highly available backend that writes data to disk and requires a cluster of nodes, adding operational overhead and violating the 'no persistence' requirement. Option C is wrong because the Consul storage backend relies on an external Consul cluster for persistence and high availability, introducing additional infrastructure and operational complexity. Option D is wrong because the File storage backend persists data to the filesystem on disk, which contradicts the requirement for memory-only storage with no persistence.

Full explanation →
7
MCQmedium

A development team wants to encrypt sensitive data before storing it in a database. They don't want to manage encryption keys themselves. Which secrets engine should they use?

A.PKI
B.Transit
C.AWS
D.KV v2
AnswerB

The transit secrets engine encrypts plaintext supplied by the application and returns ciphertext for database storage, while Vault retains and rotates the keys. This satisfies the requirement that the development team never manages encryption keys themselves.

Why this answer

The Transit secrets engine is designed to encrypt data in transit or at rest without exposing the encryption keys to the client. It performs cryptographic operations (encrypt/decrypt) on data sent to Vault, so the development team never manages or stores the keys themselves. This matches the requirement to avoid key management while encrypting sensitive data before database storage.

Exam trap

HashiCorp often tests the distinction between 'storing secrets' (KV v2) and 'encrypting data without managing keys' (Transit), leading candidates to mistakenly choose KV v2 because they associate it with 'secrets' rather than the specific encryption workflow.

How to eliminate wrong answers

Option A (PKI) is wrong because PKI generates and manages X.509 certificates for TLS/SSH authentication, not for encrypting arbitrary data payloads. Option C (AWS) is wrong because the AWS secrets engine generates dynamic AWS IAM credentials or manages static AWS secrets, but it does not provide encryption-as-a-service for application data. Option D (KV v2) is wrong because KV v2 stores plaintext secrets (like passwords or API keys) in a key-value store; it does not encrypt data on behalf of clients or offload key management.

Full explanation →
8
MCQhard

A role in Vault's database secrets engine is configured with default_ttl=30m and max_ttl=2h. An application requests credentials and then successfully renews the lease twice, each time receiving the full default TTL. What is the longest total time the credential can remain valid from its original issue time?

A.2 hours
B.4 hours
C.1 hour 30 minutes
D.Unlimited, as long as the application renews before each expiry
AnswerA

max_ttl caps the total lifetime of a lease regardless of how many times it is renewed. Each renewal may grant up to the default TTL, but the expiration can never be pushed beyond two hours from the original issue time, so that is the absolute ceiling for this credential.

Why this answer

The max_ttl on the role is the hard ceiling on a lease's total lifetime from issuance. Renewals can extend expiration in increments up to the default TTL, but the expiration manager refuses to push past max_ttl, after which the application must obtain brand-new credentials through the creds endpoint.

Exam trap

The trap here is multiplying the default TTL by the number of renewals or assuming renewals can continue forever, instead of recognizing max_ttl as an absolute cap from issue time.

Full explanation →
9
MCQmedium

A Vault operator accidentally revoked a token that was used to lease many database credentials. What happens to the leases associated with that token?

A.All leases are immediately revoked.
B.The leases become orphaned and will never be revoked.
C.Vault automatically renews the leases with a new token.
D.The leases continue until their natural expiration.
AnswerA

Vault ties every lease to its parent token, so revoking that token cascades to its entire lease tree. All database credential leases issued under it are immediately revoked, forcing clients to re-authenticate and obtain fresh credentials.

Why this answer

In Vault, tokens are the root of identity and authorization for all associated leases. When a token is revoked, Vault immediately revokes all leases created using that token, including database credential leases, because the token's lifecycle governs the leases it has created. This ensures that no credentials remain valid after the token is revoked, maintaining security.

Exam trap

HashiCorp often tests the misconception that leases have independent lifetimes or that Vault might orphan or auto-renew leases, when in fact the token's revocation is the authoritative trigger for immediate lease cleanup.

How to eliminate wrong answers

Option B is wrong because Vault does not orphan leases; it actively tracks the parent token for each lease and revokes them when the token is revoked. Option C is wrong because Vault does not automatically renew leases with a new token; lease renewal requires the original token or a token with sufficient privileges, and revocation is a terminal action. Option D is wrong because leases are tied to the token's lifecycle, not independent; they do not continue to natural expiration once the token is revoked.

Full explanation →
10
MCQhard

A platform team wants Kubernetes pods to authenticate to Vault by presenting their service account token, with Vault verifying the token's validity against the Kubernetes API and checking the pod's namespace and service account name. Which auth method should the team enable?

A.JWT auth method
B.AppRole auth method
C.Cert auth method
D.Kubernetes auth method
AnswerD

The Kubernetes auth method accepts a service account JWT, calls the Kubernetes TokenReview API to validate it, and then checks the bound namespace and service account against the role configuration. This exactly matches the requirement to verify tokens against the Kubernetes API and enforce namespace and service account constraints.

Why this answer

The Kubernetes auth method is purpose-built for this case: it validates the service account JWT through the Kubernetes TokenReview API and enforces role constraints such as namespace and service account name. Generic JWT auth cannot perform the Kubernetes-specific token review, and methods like AppRole or cert auth rely on entirely different credentials.

Exam trap

The trap here is confusing Kubernetes auth with generic JWT auth, since both involve a token, but only Kubernetes auth performs TokenReview and namespace/service account binding.

Full explanation →
11
MCQhard

An e-commerce application integrates with Vault's transit secrets engine to encrypt sensitive customer data before storing it in a database. The operations team regularly rotates the encryption key (my-key) for compliance. Recently, after a rotation, some old ciphertexts could not be decrypted, causing data retrieval failures. The team checked the key configuration and found that the key version used for encryption (version 2) is still present, but decryption fails with an error: 'decryption key version is not available for decryption'. They verified that the ciphertext includes the key version. What is the most likely cause and resolution?

A.The 'suppress_decryption' parameter was enabled on the transit mount, blocking decryption. Disable it.
B.The key was exported and reimported, losing the version history. Re-create the key from scratch.
C.The ciphertext was corrupted during storage. The only solution is to re-encrypt all data with the current key version.
D.The 'min_decryption_version' is set to 3, preventing decryption with version 2. Set it to 2 to allow decryption.
AnswerD

Setting `min_decryption_version` to 3 archives versions below it, so version 2 ciphertexts fail with exactly that error despite the version still existing. Lowering it to 2 restores decryption of older data while retaining rotation, satisfying the compliance requirement without re-encrypting existing records.

Why this answer

The error 'decryption key version is not available for decryption' indicates that the key version used to encrypt the data (version 2) is present but not allowed for decryption. In Vault's transit secrets engine, the `min_decryption_version` parameter controls the lowest key version that can decrypt data. If it is set to 3, version 2 ciphertexts cannot be decrypted.

Setting `min_decryption_version` to 2 resolves the issue by permitting decryption with version 2.

Exam trap

HashiCorp often tests the distinction between key version presence and decryption permission, where candidates mistakenly assume that if the key version exists, decryption should always work, overlooking the `min_decryption_version` constraint.

How to eliminate wrong answers

Option A is wrong because `suppress_decryption` is not a valid parameter on the transit mount; the correct parameter is `disable_decryption` on the key, but that would block all decryption, not just for a specific version. Option B is wrong because exporting and reimporting a key would create a new key with a fresh version history, but the existing ciphertexts would still reference the old key version, and the error would be about missing key material, not a decryption version restriction. Option C is wrong because ciphertext corruption would typically produce a different error (e.g., 'invalid ciphertext' or HMAC mismatch), not a specific message about decryption key version unavailability.

Full explanation →
12
Multi-Selectmedium

A Vault operator wants to manage lease durations for secrets issued by a PKI secrets engine. Which two actions can they take to affect the lease duration of certificates?

Select 2 answers
A.Set the 'default_lease_ttl' on the auth method used to log in.
B.Set the 'max_lease_ttl' on the auth method used to log in.
C.Configure the 'ttl' parameter in the PKI role definition.
D.Set the 'lease_duration' parameter in the PKI role definition.
E.Set the 'default_lease_ttl' on the PKI secrets engine mount.
AnswersC, E

The PKI role's ttl parameter sets the default lease duration for certificates issued under that role, so adjusting it directly controls how long issued certificates remain valid. This is the supported mechanism for influencing lease duration at issuance time.

Why this answer

Option C is correct because the PKI role definition accepts a 'ttl' parameter that sets the default lease duration for certificates issued under that role, overriding the mount's default when specified. Option E is correct because setting 'default_lease_ttl' on the PKI secrets engine mount establishes the baseline lease duration for certificates issued by that mount when the role does not specify its own TTL. Options A and B are incorrect because 'default_lease_ttl' and 'max_lease_ttl' on an auth method govern the lifetime of the auth method's own tokens, not the leases of certificates issued by a PKI secrets engine.

Option D is incorrect because 'lease_duration' is not a valid parameter in a PKI role definition; the correct parameter is 'ttl' (along with 'max_ttl').

Exam trap

The trap here is that candidates confuse the 'default_lease_ttl' on the mount (which is a fallback) with the role-level 'ttl' (which is the direct control), or mistakenly think auth method lease settings apply to secrets engine leases.

Full explanation →
13
Multi-Selecthard

A Vault administrator is designing a disaster-recovery runbook for dynamic secrets and needs to document the ways leases can be terminated or cleaned up. Which two statements correctly describe lease revocation behavior in Vault? (Choose two.)

Select 2 answers
A.Revoking a token revokes the leases of secrets that were created using that token, in addition to the token itself.
B.Deleting the lease record from Vault's storage with a storage operation leaves the external credential valid until its natural expiry.
C.Revoking a lease automatically revokes every other lease issued by the same secrets engine mount.
D.Once a lease is revoked, the same lease ID can be renewed again if the client still holds it.
E.Revoking a lease for a dynamic secret also removes the corresponding credential at the external system through the secrets engine.
AnswersA, E

Vault tracks parent-child relationships between tokens and the leases they spawn. Revoking a token cascades to its child leases, which is why offboarding a service account cleans up its dynamic credentials. This cascade behavior is a core reason to issue per-application tokens rather than sharing one, so revocation boundaries stay meaningful.

Why this answer

Token revocation cascades to the leases that token created, and revoking a dynamic secret's lease instructs the secrets engine to delete the external credential. Revocation is scoped rather than mount-wide, revoked leases cannot be revived, and normal revocation cleans up the external system instead of merely dropping Vault's record.

Exam trap

The trap here is conflating lease revocation with mount-wide cleanup and assuming a revoked lease can still be renewed, when it is permanently dead and scoped only to itself or its prefix.

Full explanation →
14
MCQhard

A Vault operator runs 'vault token lookup s.abc123' and sees that the token type is 'service', renewable is true, but the ttl is 30m and creation_ttl is 1h. The token has num_uses set to 0. What is the most likely explanation for the discrepancy between ttl and creation_ttl?

A.The token has renewable set to false
B.The token type is service, so it cannot be renewed
C.30 minutes have elapsed since the token was created
D.The token has been used and num_uses decremented
AnswerC

The ttl field reports remaining time, while creation_ttl records the original lifetime. A ttl of 30m against a creation_ttl of 1h means 30 minutes have elapsed since issuance, so the token is simply counting down from its initial hour.

Why this answer

The token's current TTL (30m) is shorter than its creation_ttl (1h) because 30 minutes have already elapsed since the token was issued. The TTL dynamically decreases as time passes, while creation_ttl remains fixed at the original value set at token creation. This is normal behavior for a renewable service token with num_uses=0.

Exam trap

HashiCorp often tests the distinction between creation_ttl (static) and ttl (dynamic), trapping candidates who confuse a reduced TTL with a non-renewable token or usage decrement.

How to eliminate wrong answers

Option A is wrong because the token's renewable attribute is explicitly shown as true in the lookup output, so it cannot be the cause of a reduced TTL. Option B is wrong because service tokens are fully renewable by default; the token type does not prevent renewal. Option D is wrong because num_uses is set to 0, meaning the token has no usage limit and does not decrement; the TTL reduction is purely time-based, not usage-based.

Full explanation →
15
MCQhard

A Vault administrator needs to create a policy that grants users read access only to the secrets that belong to their own team. The team membership is stored in an external identity provider and mapped to Vault entity aliases. The administrator wants to use a templated policy that references the entity's metadata. Which policy syntax accomplishes this goal?

A.path "secret/data/{{identity.entity.metadata.team}}/*" { capabilities = ["read", "list"] }
B.path "secret/data/{{entity.metadata.team}}/*" { capabilities = ["read", "list"] }
C.path "secret/data/{{.team}}/*" { capabilities = ["read", "list"] }
D.path "secret/data/{{identity.entity.aliases.team}}/*" { capabilities = ["read", "list"] }
AnswerA

The templated path interpolates identity.entity.metadata.team, so each user's entity metadata resolves to their own team's secret path. This grants read and list capabilities only within that team's namespace, satisfying the requirement for per-team access scoped by external identity provider membership.

Why this answer

It uses the proper templating syntax `{{identity.entity.metadata.team}}` to reference the `team` metadata key stored on the Vault entity. This allows the policy to dynamically grant read and list access to the path `secret/data/<team>/*`, ensuring users only see secrets belonging to their own team as defined by the external identity provider.

Exam trap

Vault often tests the distinction between entity metadata and alias metadata, and the trap here is that candidates confuse `{{identity.entity.metadata}}` with `{{identity.entity.aliases}}` or use invalid shorthand like `{{entity.metadata}}` or `{{.team}}`.

How to eliminate wrong answers

Option B is wrong because it uses `{{entity.metadata.team}}` which is not valid ACL policy templating syntax; the correct prefix must be `identity.entity.metadata`. Option C is wrong because `{{.team}}` is a shorthand used in Consul templates, not in Vault ACL policies, and does not reference entity metadata. Option D is wrong because `{{identity.entity.aliases.team}}` incorrectly attempts to access a metadata key directly under aliases; team membership is stored in entity metadata, not in the alias object itself.

Full explanation →
16
MCQhard

An administrator receives an access denied error when trying to use the token accessor to revoke a token. The administrator's token has the following policy capabilities: path "auth/token/revoke-accessor" { capabilities = ["create", "update"] }. What is the issue?

A.The administrator lacks the 'sudo' capability on that path
B.The administrator's token does not have any capabilities on the path
C.The path requires 'create' and 'update' but not 'sudo'
D.The accessor path is incorrect; it should be auth/token/accessors/revoke
AnswerA

Revoking a token via its accessor requires the `sudo` capability on `auth/token/revoke-accessor`, regardless of `create` or `update` grants. Vault's token store enforces this elevated privilege because accessor-based revocation bypasses knowledge of the token ID itself, so the policy must explicitly include `sudo` to satisfy that constraint.

Why this answer

The `auth/token/revoke-accessor` endpoint requires the `sudo` capability in addition to `create` or `update`. In Vault, certain sensitive token management operations, such as revoking a token by its accessor, are protected by the `sudo` privilege to prevent unauthorized revocation. Without `sudo`, the administrator receives an access denied error even though they have `create` and `update` capabilities on the path.

Exam trap

A common misconception is that having 'create' and 'update' capabilities on a path is sufficient for all operations on that path, but in Vault certain sensitive endpoints like 'auth/token/revoke-accessor' also require the 'sudo' capability.

How to eliminate wrong answers

Option B is wrong because the administrator's token does have capabilities on the path (`create` and `update`), so the issue is not a complete lack of capabilities. Option C is wrong because the path does require `sudo` in addition to `create` and `update`; the statement that it does not require `sudo` is incorrect. Option D is wrong because the accessor path is correct as `auth/token/revoke-accessor`; the suggested path `auth/token/accessors/revoke` does not exist in Vault's API.

Full explanation →
17
MCQeasy

A security team wants to allow applications to authenticate to Vault without storing any secrets in configuration files. The applications run on AWS EC2 instances with an IAM role attached. Which Vault authentication method leverages the EC2 instance metadata to obtain credentials?

A.GCP IAM authentication
B.Userpass authentication
C.AppRole authentication
D.AWS IAM authentication
AnswerD

AWS IAM authentication has Vault verify the instance's signed PKCS#7 metadata document against AWS, issuing a token without stored secrets. This satisfies the constraint that applications on EC2 with an attached IAM role authenticate using instance metadata rather than configuration-file credentials.

Why this answer

AWS IAM authentication (option D) is correct because it allows applications running on EC2 instances with an attached IAM role to authenticate to Vault without storing any secrets. The Vault client uses the EC2 instance metadata service (IMDS) to retrieve the instance identity document and its signature, which are then presented to Vault. Vault verifies these credentials against the AWS API, confirming the instance's identity and IAM role, thereby enabling secure, secretless authentication.

Exam trap

HashiCorp often tests the distinction between authentication methods that require pre-shared secrets (like AppRole) versus those that leverage cloud instance metadata (like AWS IAM), leading candidates to mistakenly choose AppRole because it is commonly associated with machine authentication.

How to eliminate wrong answers

Option A is wrong because GCP IAM authentication is designed for Google Cloud Platform instances, not AWS EC2, and relies on GCP instance metadata and service accounts. Option B is wrong because Userpass authentication requires a username and password to be provided at login, which would still need to be stored or transmitted as a secret, contradicting the requirement to avoid storing secrets. Option C is wrong because AppRole authentication requires a RoleID and a SecretID; while the RoleID can be supplied via configuration, the SecretID must be securely delivered (e.g., via a trusted orchestrator), and it does not leverage EC2 instance metadata for credential retrieval.

Full explanation →
18
Multi-Selecteasy

Which TWO authentication methods are designed for human users? (Choose two.)

Select 2 answers
A.AWS
B.Kubernetes
C.AppRole
D.OIDC
E.Userpass
AnswersD, E

OIDC authenticates human users through an external identity provider's browser-based login flow, issuing tokens tied to a person's identity. This satisfies the stem's requirement for human-oriented methods, unlike machine-oriented approaches such as AppRole or AWS IAM auth.

Why this answer

OIDC (Option D) is correct because it is an authentication method built for human users, allowing them to authenticate through an external OpenID Connect identity provider (e.g., Okta, Azure AD, Google) using browser-based SSO flows rather than static secrets. Userpass (Option E) is also correct because it is Vault's native username-and-password method intended for interactive human logins, where credentials are stored as password hashes and can be rotated by the user. By contrast, AWS (Option A) is a machine-oriented method that authenticates workloads using AWS IAM credentials or instance metadata, not people.

Kubernetes (Option B) is likewise designed for pods and service accounts to authenticate via Kubernetes ServiceAccount tokens, not human users. AppRole (Option C) is a machine-to-machine method that issues RoleID and SecretID credentials for automated applications, so it is not intended for human authentication.

Exam trap

HashiCorp often tests the distinction between authentication methods designed for human users versus machine/application identities, and the trap here is that candidates may confuse 'AppRole' (a machine auth method) with a human-oriented method due to its name suggesting a role for a person.

Full explanation →
19
MCQmedium

A team is migrating from a monolithic application to microservices. Each microservice needs to authenticate to Vault using its own AppRole. The security team wants to enforce that each AppRole can only read secrets from its own dedicated path (e.g., service-a can only read from 'services/service-a/*', service-b from 'services/service-b/*'). They have created the AppRoles and policies. However, during testing, they notice that service-a can read secrets from service-b's path. The administrator checks the policy for service-a and sees it has a 'capabilities' list on 'services/service-a/*' and also 'services/service-b/*' by mistake. They correct the policy, but the issue persists. What is the most likely reason that service-a still has access?

A.The policy still contains an error that grants access to the wrong path
B.The policy update has not been applied to the Vault cluster yet
C.The service-a token has a second policy attached that grants access to service-b
D.The token was issued before the policy was corrected and still carries the old policy version; it must be replaced or renewed to get the updated permissions
AnswerD

Vault tokens embed a snapshot of their policies at issuance; policy edits do not retroactively alter existing tokens. Service-a's token still holds the pre-correction policy granting services/service-b/*, so it must be reissued or renewed to inherit the corrected policy.

Why this answer

Vault tokens are immutable once issued; they carry a snapshot of the policies at the time of creation. Correcting the policy on the Vault server does not retroactively update existing tokens. Service-a's token was issued before the policy fix and still contains the old policy that granted access to 'services/service-b/*'.

The token must be replaced (revoked and re-issued) or renewed to pick up the updated policy permissions.

Exam trap

HashiCorp often tests the misconception that policy updates are immediately enforced on all existing tokens, when in fact tokens carry a snapshot of policies at issuance and require re-issuance to reflect changes.

How to eliminate wrong answers

Option A is wrong because the administrator already corrected the policy, so the policy itself no longer contains the error; the issue is with the token's cached policies, not the current policy definition. Option B is wrong because policy updates in Vault are applied immediately to the server; there is no 'apply' step or propagation delay for policy changes. Option C is wrong because while a second policy could grant access, the question states the administrator checked the policy for service-a and corrected it, implying no other policy was mentioned; the most likely cause is the token's cached policies, not an additional attached policy.

Full explanation →
20
MCQeasy

A DevOps team wants to automate authentication to Vault for Jenkins jobs running on AWS EC2 instances. Which authentication method is most appropriate and secure for this use case without storing long-lived credentials?

A.GitHub personal access token
B.AWS IAM auth
C.AppRole
D.Username & password (userpass)
AnswerB

AWS IAM auth lets each EC2 instance present its instance profile credentials to Vault, which verifies them against AWS STS and returns a short-lived Vault token. No long-lived secrets are stored on the Jenkins hosts, satisfying the constraint.

Why this answer

AWS IAM auth is the most appropriate and secure method because it allows Jenkins jobs running on EC2 instances to authenticate to Vault using the instance's AWS IAM role without storing any long-lived credentials. The EC2 instance obtains temporary AWS credentials via the instance metadata service (IMDS), and Vault validates these against AWS STS to issue a short-lived Vault token. This eliminates the need to manage static secrets or tokens in Jenkins job configurations.

Exam trap

HashiCorp often tests the misconception that AppRole is the best choice for automated workloads, but the trap here is that AppRole still requires storing a secret ID, whereas AWS IAM auth eliminates all long-lived credentials by leveraging the EC2 instance's IAM role and temporary AWS credentials.

How to eliminate wrong answers

Option A is wrong because a GitHub personal access token is a long-lived static credential that must be stored securely, violates the requirement of not storing long-lived credentials, and is not designed for AWS EC2 instance authentication to Vault. Option C is wrong because AppRole requires a secret ID and role ID to be provisioned and stored, which are long-lived credentials that must be managed securely, and does not leverage the EC2 instance's IAM role for automatic credential rotation. Option D is wrong because username & password (userpass) authentication requires storing static credentials in Jenkins, which are long-lived and pose a security risk, and does not integrate with AWS IAM roles or instance metadata.

Full explanation →
21
MCQhard

A token with a policy that explicitly denies 'read' on 'secret/engineering/private' is issued. The same token also has another policy that grants 'read' on 'secret/engineering/*'. What is the result when the token tries to read 'secret/engineering/private'?

A.The read succeeds because the grant from the wildcard policy is more permissive
B.The read fails because the policies conflict and Vault defaults to deny
C.The read succeeds because the token has a separate policy that grants read
D.The read fails because the explicit deny on the specific path takes precedence
AnswerD

Vault evaluates all attached policies together, and an explicit deny always overrides any grant. The deny on secret/engineering/private therefore wins over the wildcard read on secret/engineering/*, so the read request fails despite the broader grant.

Why this answer

D is correct because Vault's policy evaluation uses a deny-overrides model: any explicit deny on a specific path takes precedence over any allow, even if the allow is more permissive or from a wildcard. The explicit deny on 'secret/engineering/private' blocks the read, regardless of the broader grant on 'secret/engineering/*'.

Exam trap

Vault uses a deny-overrides model: any explicit deny on a specific path takes precedence over any allow, even if the allow is more permissive or from a wildcard. The explicit deny on 'secret/engineering/private' blocks the read, regardless of the broader grant on 'secret/engineering/*'.

How to eliminate wrong answers

Option A is wrong because Vault does not use a 'most permissive wins' model; explicit denies always override allows, even wildcard allows. Option B is wrong because Vault does not default to deny on policy conflict; it explicitly evaluates denies first and denies the action. Option C is wrong because the token does have a grant, but the explicit deny on the exact path overrides that grant, causing the read to fail.

Full explanation →
22
MCQeasy

Refer to the exhibit. What operation was performed on the secret "mysecret"?

A.Write
B.Read
C.Delete
D.List
AnswerB

The exhibit shows a read operation against the secret path, returning the stored key-value data without modifying or destroying it. Reading retrieves the secret's contents and metadata, which matches the operation recorded in the audit output for mysecret.

Why this answer

The exhibit shows a Vault CLI command that retrieves the value of a secret at the path 'secret/mysecret'. The 'vault read' command is used to read data from Vault's key-value store, returning the stored value. Since the command 'vault read secret/mysecret' is executed, the operation performed is a Read, making option B correct.

Exam trap

HashiCorp often tests the distinction between 'vault read' and 'vault list', where candidates confuse listing keys under a path with reading the actual secret value, leading them to incorrectly select 'List' instead of 'Read'.

How to eliminate wrong answers

Option A is wrong because 'Write' would correspond to a 'vault write' command, which stores or updates a secret, not retrieves it. Option C is wrong because 'Delete' would require a 'vault delete' command, which removes the secret from the path. Option D is wrong because 'List' would use a 'vault list' command, which enumerates keys under a path, not retrieve a specific secret's value.

Full explanation →
23
MCQmedium

A Vault administrator is troubleshooting a Vault cluster using integrated storage (Raft). The cluster has three nodes: node1 (active), node2 (standby), and node3 (standby). The administrator runs `vault operator raft list-peers` and sees that node3 is listed as a non-voter. What is the most likely reason for node3 being a non-voter?

A.Node3 has a different Vault version than the other nodes, so it is automatically demoted to a non-voter.
B.Node3 is configured as a performance standby, which prevents it from being a voter.
C.Node3 was recently added to the cluster and has not yet been promoted to a voter by autopilot.
D.Node3 is a standby node and therefore cannot be a voter in the Raft configuration.
AnswerC

When a new node is added to a Vault Raft cluster, it initially joins as a non-voter. Autopilot then monitors its health and, after a stabilization period, promotes it to a voter if the cluster needs more voters. This gradual promotion ensures that a new node does not disrupt the cluster's quorum if it is unhealthy or slow. The non-voter status is temporary until autopilot promotes it.

Why this answer

In Vault's integrated storage, when a new node joins the cluster, it starts as a non-voter. Autopilot is responsible for promoting non-voters to voters once they are healthy and stable. This prevents a new, potentially unstable node from affecting the cluster's quorum.

Therefore, node3 is likely a recently added node that has not yet been promoted to voter by autopilot.

Exam trap

The trap here is assuming that standby status prevents Raft voting, when in fact standby nodes are normally voters and non-voter status is a temporary state for new nodes.

Full explanation →
24
MCQhard

A Vault administrator is configuring a new Vault cluster with Integrated Storage (Raft). The administrator wants to ensure that the cluster can tolerate the failure of one node without data loss and that writes remain available. What is the minimum number of nodes required, and what is the recommended configuration for high availability?

A.Three nodes, with one active and two standby nodes, because Raft requires a quorum of (N/2)+1 nodes to commit writes.
B.Two nodes, with one active and one standby, because Raft only needs a majority to elect a leader and two nodes provide a majority if one fails.
C.One node, because Integrated Storage (Raft) can operate in a single-node cluster and still provide high availability through automatic failover to a standby.
D.Five nodes, with one active and four standby, because Raft requires an odd number of nodes and five is the minimum for production.
AnswerA

Raft uses a quorum to commit writes. With three nodes, a quorum is two, so one node can fail and the cluster remains available for writes. One node becomes the active leader, and the other two are standbys that can take over if the leader fails. This provides both fault tolerance and high availability.

Why this answer

For a Vault cluster using Integrated Storage (Raft) to tolerate one node failure and maintain write availability, a minimum of three nodes is required. Raft uses a quorum of (N/2)+1 nodes to commit writes; with three nodes, a quorum is two, so one failure is tolerated. One node acts as the active leader, and the others are standbys.

Exam trap

The trap here is assuming that two nodes provide redundancy, but Raft requires a majority quorum, so two nodes cannot tolerate a failure.

Full explanation →
25
MCQeasy

A new engineer authenticates to Vault and receives a token. The engineer's manager asks which policies are attached to that token and when it will expire, so the team can plan a permissions review. Which command should the engineer run to display this information about their own token?

A.vault auth list
B.vault token lookup
C.vault secrets list
D.vault token create
AnswerB

vault token lookup with no argument inspects the token currently in use and returns its policies, TTL, creation time, renewability, and accessor. This gives the engineer exactly the policy list and expiry details the manager requested. It is a read-only operation that requires no special privileges beyond possessing the token.

Why this answer

Token inspection is performed with vault token lookup, which returns the token's policies, TTL, renewability, and accessor when run against the current token. That directly supplies the policy list and expiration information needed for the review, without creating new tokens or querying unrelated auth and secrets mounts.

Exam trap

The trap here is reaching for commands that list auth methods or secrets engines, which describe mount configuration rather than the attributes of a specific token.

Full explanation →
26
MCQeasy

A security team needs to grant a service account the ability to read secrets from the path 'secret/data/backup' and also to update the secret at that same path. Which policy correctly implements this requirement?

A.path "secret/backup" { capabilities = ["read", "update"] }
B.path "secret/data/backup" { capabilities = ["read", "create"] }
C.path "secret/data/backup/*" { capabilities = ["read", "update"] }
D.path "secret/data/backup" { capabilities = ["read", "update"] }
AnswerD

This policy grants read and update capabilities on the exact path secret/data/backup. In Vault, update capability allows modifying an existing secret, which includes creating a new version or changing the secret data. This matches the requirement to read and update the secret at that path.

Why this answer

For KV v2 secrets, reading and updating a secret at a specific path requires capabilities read and update on secret/data/<path>. The update capability allows modifying an existing secret, which is necessary here. Using create instead of update would not allow modifying an existing secret.

Specifying the exact path without a wildcard ensures least privilege.

Exam trap

The trap here is confusing create and update capabilities; create allows writing a new secret but not modifying an existing one, while update is required to change an existing secret.

Full explanation →
27
MCQmedium

A platform team stores KV v2 secrets under the mount 'kv-prod'. They need a policy that lets an application read only the metadata (not the underlying secret values) for every path under 'kv-prod/apps/', including the ability to enumerate keys. Which policy stanza satisfies this requirement?

A.path "kv-prod/data/apps/*" { capabilities = ["read", "list"] }
B.path "kv-prod/metadata/apps/*" { capabilities = ["read"] }
C.path "kv-prod/metadata/apps/*" { capabilities = ["read", "list"] }
D.path "kv-prod/apps/*" { capabilities = ["read", "list"] }
AnswerC

On a KV v2 mount the metadata endpoint is reached at '<mount>/metadata/<path>'. Granting read and list on kv-prod/metadata/apps/* lets the client list keys and inspect version metadata such as created_time and current_version, while never touching the data endpoint that returns secret values. This is exactly the least-privilege requirement described.

Why this answer

KV v2 splits each secret into a data endpoint that returns values and a metadata endpoint that returns version information. To inspect versions without exposing secret material, the policy must target the metadata path and include list so the prefix can be enumerated. Pointing the stanza at the data path leaks values, and omitting list breaks key discovery.

Exam trap

The trap here is assuming the KV v1 path layout still applies, so the policy is written against the bare mount path instead of the metadata sub-path that KV v2 actually uses.

Full explanation →
28
MCQmedium

An application stores ciphertext produced by a Vault transit key named `orders` in a database. The security team rotates the key with `vault write -f transit/keys/orders/rotate`. After rotation, the application reports that decryption of previously stored records fails. The key was never deleted or reconfigured. What is the most likely cause?

A.The application must re-encrypt all existing records with the new key version before decryption is possible.
B.The application stripped or altered the `vault:vN:` version prefix from the stored ciphertext.
C.The application is decrypting with the wrong key name because rotation renamed the key.
D.Rotation automatically deletes the previous key version, so old ciphertext can never be decrypted.
AnswerB

Transit ciphertext carries a version prefix such as `vault:v1:`. Vault uses that prefix to select the correct historical key version during decryption. If the application trimmed, truncated, or otherwise modified the stored ciphertext, Vault cannot identify the version and decryption fails even though all key versions are still present.

Why this answer

Transit ciphertext embeds the key version in a prefix like `vault:v1:`, and Vault relies on that prefix to choose which key version decrypts the data. Rotation adds a new version without invalidating old ones, so decryption normally continues to work. When it fails after rotation while the key still exists, the prefix has usually been stripped or corrupted in storage, removing Vault's ability to identify the correct version.

Exam trap

The trap here is blaming rotation for breaking decryption, when the real issue is treating the version prefix as disposable metadata.

Full explanation →
29
Multi-Selectmedium

A user wants to view information about their current token, including its policies and TTL. Which TWO CLI commands can be used?

Select 2 answers
A.vault read auth/token/lookup-self
B.vault token list
C.vault write auth/token/lookup
D.vault token info
E.vault token lookup
AnswersA, E

The lookup-self endpoint returns metadata about the calling token itself, including its attached policies, TTL and renewal status. Reading auth/token/lookup-self therefore satisfies the requirement to inspect the current token without needing its accessor or a privileged token.

Why this answer

Option A, `vault read auth/token/lookup-self`, is correct because it reads the `auth/token/lookup-self` endpoint, which returns details about the token used to make the request, including its policies, TTL, and other metadata. Option E, `vault token lookup`, is correct because it queries the same token lookup functionality through the CLI and, when run without a token argument, displays information about the current token such as policies and TTL. Option B, `vault token list`, is incorrect because it lists accessor values of tokens rather than showing details of the current token.

Option C, `vault write auth/token/lookup`, is incorrect because the lookup endpoint is read-oriented and requires a token parameter; writing to it without a token does not return current-token information. Option D, `vault token info`, is incorrect because it is not a valid Vault CLI command.

Exam trap

HashiCorp often tests the distinction between `vault token lookup` (which works for self-lookup without arguments) and `vault token info` (which does not exist), trapping candidates who assume a generic 'info' subcommand exists across all CLI tools.

Full explanation →
30
MCQhard

A security team needs to create a Vault policy that allows a token to read secrets under 'secret/data/finance/*' but explicitly denies access to 'secret/data/finance/salaries'. The policy must also allow listing all secrets under 'secret/data/finance/'. Which policy definition correctly achieves this?

A.path "secret/data/finance/*" { capabilities = ["read", "list"] } path "secret/data/finance/salaries" { capabilities = ["read", "list"] allowed_parameters = { "deny" = [] } }
B.path "secret/data/finance/*" { capabilities = ["read", "list"] } path "secret/data/finance/salaries" { capabilities = ["read"] }
C.path "secret/data/finance/*" { capabilities = ["read", "list"] denied_parameters = ["salaries"] }
D.path "secret/data/finance/*" { capabilities = ["read", "list"] } path "secret/data/finance/salaries" { capabilities = ["deny"] }
AnswerD

This policy grants read and list on all paths under finance, then explicitly denies access to the salaries path. In Vault, a deny capability takes precedence over any other capability, even if a more specific path rule grants access. The order of path blocks does not matter; the deny rule overrides. This correctly restricts access to salaries while allowing everything else.

Why this answer

Vault policies use a deny capability that overrides any other capability on a path. To deny access to a specific path while allowing a broader wildcard, you create a separate path block for the denied path with capabilities = ["deny"]. The order of blocks is irrelevant because Vault evaluates all matching paths and deny always wins.

This is the correct and supported method.

Exam trap

The trap here is thinking that a more specific path with allow capabilities overrides a wildcard deny, but in Vault deny always takes precedence regardless of path specificity.

Full explanation →
31
Multi-Selectmedium

Which THREE steps are required to configure the database secrets engine for a MySQL database?

Select 3 answers
A.Enable the database secrets engine
B.Create a role that specifies the SQL statements for credential creation
C.Generate a root certificate for the database
D.Tune the mount to set default TTL for all roles
E.Configure a connection with the MySQL plugin and connection details
AnswersA, B, E

Enabling the database secrets engine at a path mounts it so Vault can generate dynamic database credentials. This is the mandatory first step before configuring a MySQL connection and a role, which the remaining required steps then build upon.

Why this answer

Option A is correct because the database secrets engine must first be enabled at a mount path (e.g., `vault secrets enable database`) before any database configuration can occur. Option B is correct because a role defines the SQL statements Vault uses to create and revoke credentials, along with the associated connection and credential type, and is required for Vault to dynamically generate database credentials. Option E is correct because Vault needs a configured database connection specifying the MySQL plugin (e.g., `mysql-database-plugin`), connection URL, and credentials so it can communicate with the MySQL instance.

Option C is not required because Vault's database secrets engine does not need a root certificate generated for the database; it authenticates using configured credentials. Option D is not required because TTLs can be set on the role itself, and tuning the mount's default TTL is optional rather than a mandatory configuration step.

Exam trap

HashiCorp often tests the distinction between required configuration steps and optional tuning or security enhancements, leading candidates to include steps like tuning TTL or generating certificates as mandatory when they are not.

Full explanation →
32
MCQmedium

A platform team runs a Vault cluster where many applications obtain dynamic AWS credentials from the aws secrets engine. During an incident, an operator needs to stop all credential usage tied to a compromised IAM role without disrupting other roles. The operator has a root token and wants to revoke every lease associated with that specific role. Which approach accomplishes this?

A.Delete the AWS IAM role directly in AWS and wait for Vault leases to expire naturally.
B.Disable the aws secrets engine mount, which immediately revokes all leases issued by that mount.
C.Run vault lease revoke -prefix aws/creds/<role-name> to revoke all leases under that role's path.
D.Run vault token revoke -self to revoke the token that requested the credentials.
AnswerC

The vault lease revoke command supports the -prefix flag, which revokes every lease whose ID begins with the given path. Using aws/creds/<role-name> targets only leases issued for that role, leaving other roles' credentials intact. This is the precise, scoped way to revoke a set of leases during an incident.

Why this answer

The vault lease revoke command with the -prefix flag revokes all leases whose IDs share a given path prefix. Because AWS dynamic credentials are issued under aws/creds/<role-name>, using that prefix scopes the revocation to the compromised role only, achieving rapid containment without tearing down the secrets engine or affecting other roles.

Exam trap

The trap here is reaching for mount disablement or AWS-side deletion when a scoped lease revocation by path prefix is the precise and least disruptive action.

Full explanation →
33
MCQmedium

A CI/CD pipeline needs to generate thousands of short-lived tokens each day for jobs that run for at most 5 minutes. The tokens should not be renewable or revocable individually. Which token type should be used?

A.Orphan tokens
B.Service tokens
C.Batch tokens
D.Periodic tokens
AnswerC

Batch tokens suit this pipeline because they are non-renewable and cannot be individually revoked, matching the stated constraint. They are issued by a batch token role, are not persisted to storage, and carry a fixed TTL, so thousands of short-lived five-minute job tokens can be generated cheaply without per-token lifecycle management overhead.

Why this answer

Batch tokens are designed for high-volume, short-lived workloads where tokens are generated in batches and have a configurable TTL (time-to-live). They cannot be renewed or revoked individually, making them ideal for CI/CD pipelines that need thousands of tokens per day for jobs lasting at most 5 minutes.

Exam trap

The Vault exam often tests the distinction between token types by emphasizing 'short-lived' and 'non-renewable'—candidates may confuse batch tokens with periodic tokens because both can have short TTLs, but periodic tokens are renewable and individually revocable, while batch tokens are not.

How to eliminate wrong answers

Option A is wrong because orphan tokens are not a standard Vault token type; the term refers to tokens that have lost their parent due to revocation, which is not a design pattern for generating short-lived tokens. Option B is wrong because service tokens are long-lived tokens used for machine-to-machine authentication and are renewable and revocable individually, which contradicts the requirement for non-renewable, non-revocable tokens. Option D is wrong because periodic tokens are designed to be renewed automatically at set intervals and are revocable individually, making them unsuitable for short-lived, non-renewable use cases.

Full explanation →
34
Multi-Selecthard

Which THREE of the following are true about the KV v2 secrets engine? (Select exactly 3.)

Select 3 answers
A.It does not support deletion of secrets.
B.It supports check-and-set operations for concurrent updates.
C.It does not support undoing changes.
D.It supports metadata like created_time and deletion_time.
E.It supports versioning of secrets.
AnswersB, D, E

KV v2 implements check-and-set semantics: writes supply a version number, and Vault rejects the write if the stored version differs, preventing lost updates. This satisfies the concurrency requirement by detecting conflicting concurrent modifications rather than silently overwriting them.

Why this answer

Option B is correct because the KV v2 secrets engine supports check-and-set (CAS) operations: when writing a secret you can supply the cas parameter with the expected current version, and the write fails if the version has changed, preventing lost updates during concurrent modifications. Option D is correct because KV v2 stores rich metadata for each secret version, including fields such as created_time, deletion_time, destroyed, and version, retrievable via the metadata endpoint (e.g., GET secret/metadata/<path>). Option E is correct because KV v2's defining feature is versioning: each write creates a new numbered version, allowing retrieval of specific versions and configuration of max_versions.

Option A is wrong because KV v2 does support deletion, including soft deletion (delete) and permanent destruction (destroy) of specific versions. Option C is wrong because KV v2 supports undoing changes through versioning: you can read an earlier version and write it back, or use the undelete operation to restore a soft-deleted version.

Exam trap

HashiCorp often tests the misconception that KV v2 cannot delete or undo changes, when in fact it supports soft delete, destroy, and version rollback, and the trap is that candidates confuse KV v2 with the older KV v1 engine which lacks versioning and CAS.

Full explanation →
35
MCQhard

A large enterprise runs Vault in a high-availability cluster with integrated storage (Raft). They notice that read requests are not being evenly distributed across nodes, causing some nodes to have high load. They want to offload read operations to standby nodes. What feature should they enable to achieve this?

A.Enable performance standby nodes
B.Configure a load balancer with a round-robin algorithm
C.Enable read replicas on standby nodes
D.Increase the number of Raft nodes to distribute reads
AnswerA

Performance standby nodes serve read-only requests forwarded from the active node, distributing read load across the cluster. This offloads read operations to standbys, evening distribution and reducing pressure on heavily loaded nodes in the Raft HA cluster.

Why this answer

Performance standby nodes are a Vault Enterprise feature designed to handle read requests without participating in the Raft consensus write quorum. By enabling this, read operations are offloaded to standby nodes, distributing the load evenly and reducing the burden on the active cluster nodes. This directly addresses the uneven read distribution and high load on specific nodes.

Exam trap

HashiCorp often tests the misconception that a standard load balancer or adding more Raft nodes can solve read distribution issues, but the correct solution is the Vault Enterprise-specific performance standby nodes feature, which is designed exactly for this purpose.

How to eliminate wrong answers

Option B is wrong because configuring a load balancer with round-robin does not change Vault's internal read distribution; all nodes still handle reads equally, and without performance standby nodes, standby nodes do not serve read requests in a Raft cluster. Option C is wrong because Vault does not support read replicas; this is a database concept, not applicable to Vault's integrated storage architecture. Option D is wrong because increasing the number of Raft nodes only adds more nodes to the write quorum, which can actually increase write latency and does not offload reads to standby nodes—all Raft nodes still participate in read handling equally.

Full explanation →
36
MCQhard

An administrator notices that after revoking a specific lease, the underlying database credential is still accessible. What is the most likely cause?

A.The revocation script failed to delete the database user.
B.The secret engine caches credentials.
C.The lease ID was incorrect.
D.The lease was renewed after revocation.
AnswerA

Revoking a lease removes the credential from Vault's lease database but does not automatically drop the corresponding database user. If the revocation script fails to delete that user, the credential remains valid at the database layer.

Why this answer

When a lease is revoked in Vault, the revocation script associated with the database secret engine is responsible for deleting or disabling the corresponding database user. If that script fails (e.g., due to insufficient permissions, network issues, or a bug in the script), the underlying credential remains active in the database, even though the lease is no longer valid in Vault. This is a common operational issue where the lease lifecycle and the actual credential lifecycle become out of sync.

Exam trap

HashiCorp often tests the misconception that lease revocation automatically guarantees the underlying resource is destroyed, but the trap is that revocation only manages the Vault-side lease metadata, not the external resource, which depends on the success of the configured revocation script.

How to eliminate wrong answers

Option B is wrong because Vault's database secret engine does not cache credentials; each lease corresponds to a unique database user created dynamically, and revocation directly invokes the script to remove that user. Option C is wrong because if the lease ID were incorrect, Vault would return an error or not find the lease, but the question states the lease was successfully revoked, meaning the lease ID was valid. Option D is wrong because once a lease is revoked, it cannot be renewed; renewal is only possible before revocation, and attempting to renew after revocation would fail.

Full explanation →
37
MCQmedium

A security team must immediately invalidate every dynamic database credential issued under a specific role named app-readonly, across all database mounts, without knowing individual lease IDs. Which Vault command accomplishes this?

A.vault secrets disable database
B.vault lease revoke -prefix database/creds/app-readonly
C.vault lease revoke -force database/creds/app-readonly
D.vault token revoke -accessor app-readonly
AnswerB

The -prefix flag revokes every lease whose ID begins with the given path, which includes all leases generated by that role. This is the intended bulk revocation mechanism when individual lease IDs are unknown, and it also instructs the database secrets engine to drop the corresponding users at the database.

Why this answer

Revoking by prefix targets all leases under the role's creds path in one operation and triggers the secrets engine to remove the corresponding database accounts. Forcing deletion skips backend cleanup, token revocation is scoped to tokens rather than roles, and disabling the mount destroys configuration the team still needs.

Exam trap

The trap here is reaching for mount-level or token-level revocation when the requirement is role-scoped bulk revocation, which the prefix flag handles precisely.

Full explanation →
38
MCQhard

An administrator configures a database secrets engine with a role that uses 'creation_statements' and 'revocation_statements'. However, when a lease expires, the database user is not revoked. What is the most likely cause?

A.The revocation statement is incorrect
B.The connection string is invalid
C.The database user has been manually deleted
D.The lease duration is set too high
AnswerA

Vault executes the role's revocation statement when a lease expires; if that statement is malformed or targets the wrong user, revocation silently fails. This satisfies the stem's scenario where the database user persists after lease expiry despite creation working correctly.

Why this answer

The most likely cause is that the revocation statement is incorrect. When a lease expires, Vault executes the SQL statement defined in `revocation_statements` to delete or disable the database user. If this statement has a syntax error, references a non-existent table, or fails to match the user created by `creation_statements`, the revocation will silently fail, leaving the user active in the database.

Exam trap

HashiCorp often tests the misconception that lease duration or connection health is the root cause of revocation failures, when in reality the revocation SQL statement itself is the most common point of failure.

How to eliminate wrong answers

Option B is wrong because an invalid connection string would prevent Vault from connecting to the database entirely, causing both creation and revocation to fail, not just revocation on lease expiry. Option C is wrong because if the database user was manually deleted, revocation would have nothing to revoke, but the question states the user is not revoked, implying the user still exists. Option D is wrong because a lease duration set too high would only delay the revocation event; it would not prevent revocation from occurring when the lease eventually expires.

Full explanation →
39
Multi-Selectmedium

Which TWO of the following are true about token accessors?

Select 2 answers
A.Accessors are the token value
B.Accessors should be used in audit logs instead of token values
C.Accessors are unique identifiers for tokens
D.Accessors can be used to renew the token
AnswersB, C

Token accessors are one-way hashes derived from token values, so they uniquely identify a token without exposing its secret. Logging accessors satisfies the audit requirement to trace token issuance and use while preventing credential leakage, since the original token cannot be reconstructed from the hash.

Why this answer

Token accessors are designed to be used in audit logs as a safe alternative to the actual token value. This prevents sensitive token data from being exposed in logs while still allowing correlation of events to a specific token. Option C is correct because an accessor is a unique identifier that references a token without revealing the token's secret value.

Exam trap

A common misconception is that an accessor is the token value itself or that it can perform token lifecycle operations like renewal, when in reality it is only a read-only reference for identification and auditing.

Full explanation →
40
Multi-Selecthard

Which three statements about lease renewal are correct? (Choose three.)

Select 3 answers
A.A lease can be renewed indefinitely.
B.Renewing a lease increments the lease number.
C.A lease can be renewed up to the max_lease_ttl.
D.Lease renewal requires 'sudo' capability.
E.The renew operation can extend the lease TTL.
AnswersB, C, E

Each renewal increases the lease number, visible in lease details.

Why this answer

In Vault, each lease renewal increments the lease number (a monotonically increasing counter) to track the renewal history. This allows clients and Vault to detect replay attacks or stale renewals, as the lease ID remains the same but the lease number changes with each successful renew operation.

Exam trap

HashiCorp often tests the misconception that lease renewal is unlimited or requires elevated privileges, when in fact it is bounded by max_lease_ttl and only needs the lease ID and appropriate token capabilities.

Full explanation →
41
MCQmedium

An application team is using a batch token to authenticate to Vault for a long-running data processing job. The token was created with a TTL of 8 hours and no explicit max TTL. After 4 hours, the application attempts to renew the token but receives an error. What is the most likely reason for the renewal failure?

A.The token's max TTL is less than 8 hours.
B.The token's TTL has already expired.
C.The token is a batch token, which cannot be renewed.
D.The token does not have a renewable flag set.
AnswerC

Batch tokens are designed to be lightweight and stateless; they do not support renewal. Once issued, they remain valid until their TTL expires, but they cannot be extended. In this scenario, the application's attempt to renew a batch token fails because batch tokens are inherently non-renewable, regardless of the remaining TTL.

Why this answer

Batch tokens are a special type of Vault token that are not persisted to storage and are designed for high scalability. They are not renewable, meaning they cannot be extended beyond their initial TTL. In this scenario, the application's attempt to renew the batch token fails because batch tokens do not support renewal, regardless of the remaining TTL.

Exam trap

The trap here is assuming that any token with a TTL can be renewed if it has not expired, but batch tokens are an exception.

Full explanation →
42
MCQeasy

An application needs to encrypt sensitive data before storing it in a database. The security team wants to use Vault's encryption as a service to avoid managing encryption keys. Which Vault secrets engine should they enable?

A.AWS
B.KV v2
C.Consul
D.Transit
E.PKI
AnswerD

The transit secrets engine provides encryption as a service, performing cryptographic operations while Vault holds and manages the keys. This satisfies the team's requirement to avoid managing encryption keys themselves, since plaintext is submitted to Vault and ciphertext returned, with no key material ever exposed to the application.

Why this answer

The Transit secrets engine is designed specifically for encryption as a service, allowing applications to encrypt and decrypt data without ever having direct access to the encryption keys. The keys are stored and managed entirely within Vault, which meets the security team's requirement to avoid managing encryption keys themselves.

Exam trap

HashiCorp often tests the distinction between a secrets engine that stores secrets (KV v2) and one that processes cryptographic operations (Transit), leading candidates to mistakenly choose KV v2 because they think 'storing encrypted data' is the same as 'encrypting data'.

How to eliminate wrong answers

Option A is wrong because the AWS secrets engine is used to generate dynamic AWS credentials (access keys), not to perform encryption operations. Option B is wrong because KV v2 is a key-value store for static secrets, not an encryption engine; it stores data as-is without providing encrypt/decrypt API endpoints. Option C is wrong because the Consul secrets engine generates Consul API tokens for service mesh access, not encryption services.

Option E is wrong because the PKI secrets engine generates X.509 certificates for TLS/SSL, not for encrypting arbitrary data.

Full explanation →
43
MCQmedium

A DevOps team uses Vault to store database credentials via the database secrets engine. They notice that after the default lease duration, applications receive errors when trying to connect. The team wants to ensure that applications automatically renew leases before expiration. What should they do?

A.Schedule a cron job to periodically read new credentials.
B.Set a longer default TTL on the role.
C.Use Vault Agent to renew the secret.
D.Set a longer max TTL on the mount.
AnswerC

Vault Agent runs alongside the application, authenticating to Vault and automatically renewing the database credential lease before expiry, so connections no longer fail at the default lease duration. This satisfies the requirement for automatic renewal without embedding renewal logic in application code.

Why this answer

Vault Agent is designed to automatically handle secret renewal and lifecycle management. It runs as a sidecar or daemon that periodically checks the lease duration and renews it before expiration, ensuring applications always have valid credentials without manual intervention or custom scripting.

Exam trap

The trap here is that candidates often confuse extending the TTL (options B and D) with automating renewal, but Vault requires explicit renewal logic or a tool like Vault Agent to handle the renewal process automatically.

How to eliminate wrong answers

Option A is wrong because scheduling a cron job to read new credentials does not renew the existing lease; it creates a new lease each time, which can lead to orphaned leases and does not address the automatic renewal requirement. Option B is wrong because setting a longer default TTL on the role only extends the initial lease duration but does not automate renewal; the application would still need to handle renewal logic or risk expiration after the longer TTL. Option D is wrong because setting a longer max TTL on the mount only defines the upper limit for lease durations, not the actual renewal behavior; it does not automate the renewal process and may still result in expiration if the application does not renew.

Full explanation →
44
MCQmedium

An application authenticates to Vault using the AppRole auth method and needs to retrieve the token's remaining TTL and renewable status programmatically. The application already has a valid token and calls the lookup-self endpoint. Which response fields should it read to determine whether the token can be renewed and how long it remains valid?

A.lease_duration and renewable
B.ttl and renewable
C.creation_time and expire_time
D.num_uses and policies
AnswerB

The lookup-self response includes a `ttl` field giving the remaining lifetime in seconds and a `renewable` boolean indicating whether the token can be renewed. Reading these two fields lets the application decide when to renew or re-authenticate. This directly answers the requirement to determine renewability and remaining validity.

Why this answer

The token lookup-self response exposes `ttl` (remaining seconds) and `renewable` (boolean). An application reading these two fields can decide whether to renew the token before it expires or to re-authenticate. Timestamps, use counts, and policies are informative but do not answer the renewability and remaining-lifetime question on their own.

Exam trap

The trap here is reading `lease_duration` from a token lookup response, when the token-specific field is `ttl` and the renewability flag is `renewable`.

Full explanation →
45
MCQmedium

Refer to the exhibit. A user with this policy attempts to read 'secret/data/team/admin'. What will happen?

A.Read succeeds because the first path allows read.
B.Read fails because the path does not exist.
C.Read fails because deny overrides the broader path.
D.Read succeeds if the user also has sudo capability.
AnswerC

A deny capability on `secret/data/team/admin` takes precedence over any broader `secret/data/team/*` grant, because Vault evaluates policies with deny winning regardless of path specificity or rule order. The read therefore fails, satisfying the stem's constraint that the narrower deny path overrides the wider allow.

Why this answer

Vault's policy evaluation uses a deny-by-default model where explicit deny rules override any allow rules. The policy first allows read on 'secret/data/team/*' but then explicitly denies read on 'secret/data/team/admin'. Since the deny rule is more specific and matches the exact path, it takes precedence, causing the read operation to fail.

Exam trap

HashiCorp often tests the misconception that broader allow rules automatically grant access to all sub-paths, but the trap here is that an explicit deny on a more specific path always overrides the broader allow, and candidates mistakenly think sudo can bypass deny rules.

How to eliminate wrong answers

Option A is wrong because it ignores the explicit deny rule; in Vault, a deny on a more specific path overrides a broader allow. Option B is wrong because the path 'secret/data/team/admin' does exist in the policy context; the failure is due to the deny rule, not a missing path. Option D is wrong because sudo capability in Vault allows bypassing ACL path restrictions but does not override explicit deny rules; sudo only applies to path capabilities, not to deny enforcement.

Full explanation →
46
Multi-Selectmedium

A platform team is standardizing on the transit secrets engine for application-level encryption and wants to understand what the engine can and cannot do before rollout. Which TWO statements accurately describe transit engine behavior? (Choose two.)

Select 2 answers
A.The engine can generate a data key that returns both a plaintext key and a wrapped copy, so the caller may encrypt large payloads locally.
B.Deleting a transit key immediately makes all ciphertext ever produced with it permanently undecryptable in every deployment mode.
C.The engine stores the plaintext payloads it encrypts so that administrators can audit what data was protected.
D.Ciphertext produced by the encrypt endpoint includes the key version, so data encrypted before a rotation can still be decrypted afterward.
E.Encrypting the same plaintext twice with the same key always yields identical ciphertext, which is required for indexing.
AnswersA, D

The datakey endpoint returns a newly generated key in both plaintext and ciphertext-wrapped forms. The caller uses the plaintext to encrypt a large payload locally and stores the wrapped form alongside it, later asking Vault to decrypt the wrapped key. This pattern suits data too large to send through the encrypt endpoint efficiently.

Why this answer

Transit ciphertext carries a key version so rotation does not break decryption of existing data, and the datakey endpoint supports envelope encryption for payloads too large for the encrypt endpoint. The engine deliberately does not store plaintext or ciphertext, and its default encryption is randomized rather than deterministic, so the claims about audit retention and identical ciphertext do not hold.

Exam trap

The trap here is assuming transit encryption is deterministic by default, when identical plaintext normally produces different ciphertext unless convergent encryption is explicitly enabled.

Full explanation →
47
Multi-Selecteasy

Which TWO statements are true when troubleshooting a failed Vault CLI command?

Select 2 answers
A.Run 'vault token lookup' to verify the token is valid and has the expected policies.
B.Run 'vault write' to test if the token can write to a path.
C.Run 'vault login' to re-authenticate and obtain a new token if needed.
D.Run 'vault status' to check if the server is reachable.
E.Run 'vault read' to test if any secret is accessible.
AnswersA, C

Token lookup returns the token's policies, TTL and renewal status, so an authentication or permission failure can be traced to an expired token or missing policy. This directly satisfies the stem's need to verify token validity and expected policies before retrying the command.

Why this answer

Option A is correct because 'vault token lookup' inspects the current token's metadata, including its TTL, renewal status, and attached policies, which directly verifies whether the token is valid and authorized as expected. Option C is correct because if the token is expired, revoked, or missing, 'vault login' re-authenticates against the configured auth method and issues a fresh token so subsequent CLI commands can succeed. Option B is not a general troubleshooting step since 'vault write' mutates data at a path and requires knowing a valid path and payload, so it is not a reliable diagnostic.

Option D is not among the marked answers because 'vault status' only reports seal and HA state, not token or policy validity, and it can succeed even when the token is the actual problem. Option E is likewise not marked because 'vault read' depends on a specific existing path and permissions, making it an unreliable test of general accessibility.

Exam trap

HashiCorp often tests the misconception that `vault status` is the first troubleshooting step for any CLI failure, but it only verifies server reachability and seal state, not token or permission issues.

Full explanation →
48
Multi-Selecthard

A Vault policy must allow a service to read secrets from "secret/data/app" and also be able to renew its own token. Which two policy statements are necessary and sufficient for this requirement? (Select two.)

Select 2 answers
A.path "secret/data/app" { capabilities = ["read"] }
B.path "auth/token/renew-self" { capabilities = ["update"] }
C.path "auth/token/renew" { capabilities = ["update"] }
D.path "secret/data/app/*" { capabilities = ["read"] }
E.path "sys/auth" { capabilities = ["read"] }
AnswersA, B

Grants read capability on the exact KV v2 data path, satisfying the secret-retrieval half of the requirement. Without this statement the service cannot fetch credentials, so it is necessary; the token-renewal half is covered separately by the renew-self path.

Why this answer

The policy must grant read access to the specific path 'secret/data/app' for the service to retrieve secrets. Option B is correct because renewing a token requires the 'update' capability on the 'auth/token/renew-self' endpoint, which allows the service to extend its own token's TTL without needing broader token management privileges.

Exam trap

HashiCorp Vault often tests the distinction between 'auth/token/renew-self' and 'auth/token/renew', where candidates mistakenly choose the broader 'renew' path instead of the self-service endpoint, overlooking the requirement for the service to renew only its own token.

Full explanation →
49
MCQhard

A Vault cluster uses Integrated Storage. During a planned upgrade, the administrator wants to minimize downtime. Which upgrade strategy should be used?

A.Upgrade all nodes at once
B.Perform a rolling upgrade one node at a time
C.Stop all nodes, upgrade, then start
D.Add new upgraded nodes then remove old ones
AnswerB

Integrated Storage replicates data across all nodes, so a rolling upgrade drains and updates one node at a time while the remaining nodes maintain quorum and continue serving requests. This satisfies the requirement to minimise downtime during the planned upgrade.

Why this answer

Integrated Storage (Raft-based) requires a quorum of nodes to maintain cluster availability. A rolling upgrade, where each node is upgraded one at a time, ensures that the cluster never loses quorum (more than half of the nodes remain online and functional), minimizing downtime while the upgrade proceeds.

Exam trap

HashiCorp often tests the misconception that stopping all nodes or upgrading all at once is acceptable for a clustered system, but the trap is that candidates overlook the critical requirement of maintaining Raft quorum to avoid cluster unavailability and potential data loss.

How to eliminate wrong answers

Option A is wrong because upgrading all nodes at once would temporarily remove all nodes from the cluster, causing a complete loss of quorum and total downtime until the upgrade finishes. Option C is wrong because stopping all nodes before upgrading eliminates the cluster entirely, resulting in maximum downtime and no high availability during the process. Option D is wrong because adding new upgraded nodes then removing old ones is a blue/green deployment strategy that is not natively supported by Integrated Storage without manual reconfiguration and data rebalancing, and it introduces unnecessary complexity and risk of data inconsistency.

Full explanation →
50
Multi-Selectmedium

Which two commands can be used to manually revoke leases? (Choose two.)

Select 2 answers
A.vault secrets disable <path>
B.vault token revoke <token>
C.vault lease revoke <lease_id>
D.vault lease renew <lease_id>
E.vault lease revoke -prefix <prefix>
AnswersC, E

vault lease revoke with a specific lease_id terminates that single lease immediately, invalidating its associated token or secret. This satisfies the stem's requirement for manual revocation of an individual lease rather than bulk or prefix-based revocation.

Why this answer

Option C, `vault lease revoke <lease_id>`, is correct because it directly revokes a single lease by its lease ID, immediately invalidating the associated secret and removing it from Vault's lease tracking. Option E, `vault lease revoke -prefix <prefix>`, is correct because the `-prefix` flag revokes all leases whose IDs begin with the given prefix, enabling bulk revocation of leases under a path or hierarchy. Option A, `vault secrets disable <path>`, is not a lease-revocation command; it disables a secrets engine at the given path, which revokes leases as a side effect but is not the manual lease-revocation operation asked for.

Option B, `vault token revoke <token>`, revokes a token and its child tokens, not leases directly. Option D, `vault lease renew <lease_id>`, extends a lease's TTL rather than revoking it.

Exam trap

In the HashiCorp Vault exam, candidates often confuse lease revocation with token revocation, leading them to mistakenly choose `vault token revoke` (option B) when the question specifically asks about leases, not tokens.

Full explanation →
51
MCQeasy

What is the purpose of the Seal/Unseal process in Vault architecture?

A.To delete old secrets
B.To rotate the encryption key
C.To back up the storage backend
D.To enable Vault to process requests
AnswerD

Vault starts sealed, holding the master key encrypted and unable to decrypt stored data. Unsealing reconstructs that key in memory, which is the prerequisite for servicing any API request; until unsealed, Vault returns errors and processes nothing.

Why this answer

The Seal/Unseal process in Vault is a security mechanism that protects the encryption key used to encrypt data at rest. When Vault starts, it is in a sealed state and cannot process any requests until it is unsealed by providing a threshold number of unseal keys (shards). Unsealing decrypts the master key in memory, allowing Vault to access the storage backend and serve API requests.

Option D is correct because the primary purpose is to enable Vault to process requests after a secure startup.

Exam trap

HashiCorp often tests the misconception that Seal/Unseal is about key rotation or backup, when in reality it is a startup security gate that prevents Vault from processing requests until the master key is decrypted in memory.

How to eliminate wrong answers

Option A is wrong because deleting old secrets is handled by secret lifecycle policies, TTLs, or manual revocation, not by the Seal/Unseal process. Option B is wrong because encryption key rotation is a separate operation (e.g., using `vault rotate` or automatic key rotation policies) and does not involve the unsealing workflow. Option C is wrong because backing up the storage backend is an operational task (e.g., snapshotting the file system or database) and is unrelated to the cryptographic unsealing mechanism.

Full explanation →
52
MCQhard

After a Vault migration, some leases are no longer valid and cause errors. What is the best way to force a cleanup of all leases under a specific mount without affecting other mounts?

A.Restart Vault servers
B.Disable and re-enable the secret engine
C.Use vault lease revoke -prefix <mount>
D.Reduce the mount's max_lease_ttl to 0
AnswerC

The -prefix flag revokes every lease whose ID begins with the given mount path, clearing all stale leases under that mount in one operation. Scoping by prefix confines the cleanup to the affected mount, leaving leases on other mounts untouched.

Why this answer

The `vault lease revoke -prefix <mount>` command is specifically designed to revoke all leases associated with a given mount path without affecting other mounts. This command iterates through all leases under that prefix and forces their revocation, cleaning up invalid leases efficiently. It is the targeted, non-disruptive approach for lease cleanup in Vault.

Exam trap

Candidates often think that restarting Vault or disabling/re-enabling a mount is the simplest way to clear leases, but the trap here is that these actions are either ineffective or overly destructive, while the `revoke -prefix` command provides a precise, non-disruptive solution.

How to eliminate wrong answers

Option A is wrong because restarting Vault servers does not force cleanup of leases; leases persist in storage and will be re-evaluated on restart, not removed. Option B is wrong because disabling and re-enabling the secret engine is overly disruptive, as it removes all secrets and configuration for that mount, not just leases, and may cause data loss or service interruption. Option D is wrong because reducing the mount's `max_lease_ttl` to 0 only affects future lease creation and renewal, not existing leases; it does not force revocation of current invalid leases.

Full explanation →
53
MCQeasy

An organization has two Vault clusters in different geographic regions and wants to replicate secrets from the primary cluster to the secondary cluster for disaster recovery. Which Vault replication feature should they use?

A.Cluster replication
B.Active Directory replication
C.Disaster Recovery (DR) replication
D.Performance replication
AnswerC

Disaster Recovery replication asynchronously mirrors the primary cluster's data to a secondary cluster in a separate region, providing warm standby failover. This satisfies the stem's requirement to replicate secrets across geographic regions for disaster recovery, unlike performance replication, which scales read throughput rather than enabling regional failover.

Why this answer

Disaster Recovery (DR) replication is the correct Vault feature for replicating secrets from a primary cluster to a secondary cluster in a different geographic region for disaster recovery. DR replication copies all data, including secrets, policies, and tokens, in a one-way direction from primary to secondary, ensuring the secondary cluster can be promoted if the primary fails. This is distinct from performance replication, which is designed for load distribution and allows writes on both sides.

Exam trap

HashiCorp often tests the distinction between DR replication and Performance replication, trapping candidates who confuse the two by assuming Performance replication can also serve as a disaster recovery solution, when in fact it allows writes on both sides and is not designed for failover scenarios.

How to eliminate wrong answers

Option A is wrong because 'Cluster replication' is not a Vault feature; Vault uses 'Replication' as a core feature with specific modes (DR and Performance), and there is no standalone 'Cluster replication' mode. Option B is wrong because Active Directory replication is a Microsoft technology for synchronizing directory data across domain controllers, not a Vault feature. Option D is wrong because Performance replication is intended for scaling read operations across clusters in different datacenters, allowing writes on both sides, which is not suitable for a strict disaster recovery scenario where a single authoritative primary is required.

Full explanation →
54
MCQeasy

A DevOps team needs to provide temporary database credentials to applications without storing long-lived passwords. Which secrets engine should they use?

A.KV v2 secrets engine
B.PKI secrets engine
C.Database secrets engine
D.Transit secrets engine
AnswerC

The database secrets engine dynamically generates short-lived credentials on demand, eliminating stored passwords. It satisfies the temporary-credentials constraint by issuing unique usernames and passwords per request with a lease TTL, after which Vault automatically revokes them. This removes long-lived static secrets entirely, unlike static key-value storage.

Why this answer

The Database secrets engine is designed to generate dynamic, short-lived database credentials on demand, allowing applications to access databases without storing long-lived passwords. It creates unique credentials for each request and automatically revokes them after a configurable TTL, meeting the requirement for temporary access without persistent secrets.

Exam trap

HashiCorp often tests the distinction between static secret storage (KV v2) and dynamic secret generation (Database engine), leading candidates to mistakenly choose KV v2 because they think of it as the default secrets engine for any credential.

How to eliminate wrong answers

Option A is wrong because the KV v2 secrets engine stores static secrets (like passwords or API keys) in a key-value store; it does not generate dynamic, temporary credentials or enforce automatic rotation/revocation. Option B is wrong because the PKI secrets engine generates X.509 certificates for TLS/SSL authentication, not database credentials. Option D is wrong because the Transit secrets engine provides encryption-as-a-service (encrypt/decrypt data in transit or at rest) but does not generate or manage database credentials.

Full explanation →
55
MCQeasy

What happens when a lease reaches its TTL?

A.The lease is marked as expired and can no longer be renewed.
B.The lease is automatically renewed.
C.The secret is automatically revoked.
D.The lease is deleted from storage.
AnswerA

Once a lease hits its TTL, the system transitions it to an expired state, and renewal is no longer permitted. This satisfies the stem's constraint by ensuring stale leases cannot be extended, forcing the holder to acquire a fresh lease instead.

Why this answer

When a lease reaches its Time-To-Live (TTL), it becomes expired and cannot be renewed. Vault does not automatically delete the lease from storage at the moment of TTL expiry; rather, the lease is marked as expired and is eventually garbage-collected. This cleanup is separate from revocation of the underlying secret, which must be performed explicitly or via a different mechanism.

Exam trap

Candidates often mistakenly think that a lease reaching its TTL triggers revocation of the underlying secret, when in fact Vault only marks the lease as expired and relies on separate revocation logic for the actual secret.

How to eliminate wrong answers

Option A is wrong because a lease that reaches its TTL is not marked as expired and left in storage; it is deleted entirely, and Vault does allow renewal before the TTL expires, not after. Option B is wrong because leases are not automatically renewed; renewal must be explicitly requested by the client before the TTL expires. Option C is wrong because the secret associated with the lease is not automatically revoked when the lease reaches its TTL; revocation is a separate action that can occur before or after TTL, but at TTL the lease is simply deleted, and the secret may still be valid if it has a longer lifetime.

Full explanation →
56
Matchingmedium

Match each Vault audit device to its output destination.

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

Concepts
Matches

Writes to a local file

Sends to system syslog

Sends to a TCP or UDP endpoint

Publishes to Kafka topic

Why these pairings

The correct matches are: File writes to a local file, Syslog sends to syslog, Socket sends to a TCP/UDP endpoint. Common confusions mix the output destinations.

Full explanation →
57
MCQeasy

A security engineer needs to choose an authentication method for a set of microservices running in a Kubernetes cluster that require short-lived secrets. The method should leverage the pod's identity. Which method is best?

A.AppRole auth
B.Token auth
C.LDAP auth
D.Kubernetes auth
AnswerD

Kubernetes auth lets workloads exchange their pod-bound service account token for short-lived Vault tokens, so no static secret is stored. This directly satisfies the stem's requirement to leverage the pod's identity and issue short-lived secrets, unlike AppRole or token methods that rely on pre-shared credentials.

Why this answer

Kubernetes auth is the best choice because it allows a pod to authenticate to Vault using its own service account token, which is automatically mounted and short-lived. This method directly leverages the pod's identity without requiring manual secret distribution, making it ideal for microservices in a Kubernetes cluster that need ephemeral credentials.

Exam trap

HashiCorp often tests the misconception that AppRole is suitable for Kubernetes workloads because it is 'machine-oriented,' but they ignore that AppRole does not leverage the pod's native identity and requires out-of-band secret distribution.

How to eliminate wrong answers

Option A is wrong because AppRole auth requires a pre-shared RoleID and a generated SecretID, which are not inherently short-lived or tied to a pod's identity, and managing these for many microservices adds operational overhead. Option B is wrong because Token auth relies on static, long-lived tokens that must be manually distributed and rotated, contradicting the requirement for short-lived secrets and pod identity. Option C is wrong because LDAP auth is designed for user or machine authentication against an LDAP directory, not for Kubernetes pod identities, and it does not integrate with the pod's service account token.

Full explanation →
58
MCQeasy

Refer to the exhibit. Which authentication method is currently enabled for production applications?

A.Token
B.LDAP
C.AppRole
D.Userpass
AnswerC

AppRole is a machine-oriented auth method where the enabled roles on the production mount determine access. Its presence as the configured method for production applications satisfies the exhibit's requirement to identify the currently enabled authentication method.

Why this answer

The exhibit shows that the production applications are configured with the 'AppRole' authentication method, which is indicated by the presence of a RoleID and SecretID in the application configuration. AppRole is a machine-oriented authentication method in HashiCorp Vault that allows applications to authenticate using a pair of credentials (RoleID and SecretID), making it suitable for automated, non-human workflows. The other methods listed (Token, LDAP, Userpass) are either human-centric or not configured for these applications.

Exam trap

HashiCorp often tests the distinction between human-centric authentication methods (LDAP, Userpass) and machine-centric methods (AppRole, Token), and the trap here is that candidates mistakenly choose Token because it is simpler, overlooking that AppRole is specifically designed for production applications requiring dynamic, role-based credentials.

How to eliminate wrong answers

Option A is wrong because Token authentication uses a single static token, which is less secure and not designed for dynamic application workloads where credentials should be rotated or have limited lifetimes. Option B is wrong because LDAP authentication is used for human users authenticating against an external directory service (e.g., Active Directory), not for machine-to-machine authentication in production applications. Option D is wrong because Userpass authentication requires a username and password, which is intended for interactive human logins and not suitable for automated application authentication without additional secret management.

Full explanation →
59
MCQhard

An organization uses Vault to issue certificates via the PKI secrets engine. They have set the default lease TTL on the PKI mount to 72h, and the role's ttl to 24h. A user requests a certificate with a requested TTL of 48h. What will be the actual TTL of the issued certificate?

A.The request will be rejected because the requested TTL exceeds the role's ttl.
B.48h
C.24h
D.72h
AnswerC

Vault caps the issued certificate's TTL at the smallest applicable value. The role's ttl of 24h overrides both the mount's 72h default and the requested 48h, so the certificate is issued with a 24h TTL.

Why this answer

(24h) because when a certificate request is made, Vault applies the most restrictive TTL among the role's configured `ttl`, the mount's default lease TTL, and the requested TTL. Here, the role's `ttl` of 24h is the shortest, so it overrides both the requested 48h and the mount default of 72h, resulting in a certificate with a 24-hour validity.

Exam trap

The trap here is that candidates often assume the requested TTL is honored as long as it is within the mount's default lease TTL, overlooking that the role's ttl is the authoritative cap and that Vault silently truncates rather than rejects the request.

How to eliminate wrong answers

Option A is wrong because the requested TTL of 48h does not exceed the role's ttl of 24h; it exceeds it, but Vault does not reject the request—it silently caps the TTL to the role's maximum. Option B is wrong because Vault does not honor a requested TTL that is longer than the role's configured ttl; the role's ttl acts as a hard upper limit. Option D is wrong because the mount's default lease TTL of 72h is a system-wide fallback, not a per-role cap; the role's ttl takes precedence over the mount default when it is shorter.

Full explanation →
60
MCQmedium

A token has the properties shown in the exhibit. A user attempts to use this token to write a secret to 'secret/data/myapp'. The token fails with a permission denied error. What is the most likely cause?

A.The token has an explicit max TTL of 0s, which prevents write operations.
B.The token's policies do not grant write capability on the target path.
C.The token is a service token but the write operation requires a batch token.
D.The token is orphaned, so it cannot be used for write operations.
AnswerB

The token’s attached policies lack a `create` or `update` capability on `secret/data/myapp`, so Vault denies the write despite valid authentication. Vault authorises every request by evaluating the token’s policies against the exact path and operation; without a matching rule granting write, the request fails with permission denied.

Why this answer

The token's policies define the access control rules for paths in Vault. Since the user received a permission denied error when attempting to write to 'secret/data/myapp', the most likely cause is that the token's attached policies do not include a 'write' or 'create' capability on that specific path. Policies are evaluated based on the path and the requested operation, and without the appropriate capability, the request is denied regardless of other token properties.

Exam trap

HashiCorp often tests the misconception that token properties like TTL, type, or parentage affect permissions, when in reality only the attached policies determine what operations a token can perform on a given path.

How to eliminate wrong answers

Option A is wrong because a max TTL of 0s does not prevent write operations; it means the token has no explicit maximum lifetime, or it may be set to use the system default, but TTL does not affect permission to write. Option C is wrong because both service tokens and batch tokens can perform write operations if their policies allow it; the token type does not inherently restrict write capability. Option D is wrong because an orphaned token (one with no parent) can still be used for write operations as long as its policies grant the required capabilities; being orphaned does not revoke permissions.

Full explanation →
61
MCQeasy

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

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

KV v2 stores secrets under a versioned key structure, retaining configurable historical versions so any prior value can be retrieved or rolled back. This directly satisfies the stem's versioning and rollback requirements for static API keys, unlike dynamic engines that generate short-lived credentials and keep no version history.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
62
MCQmedium

A Vault operator needs to let an on-premises LDAP directory's groups map directly to Vault policies, but the directory does not implement any OIDC or SAML endpoints. Which auth method should the operator enable to authenticate users against that directory?

A.GitHub auth method
B.SAML auth method
C.LDAP auth method
D.OIDC auth method
AnswerC

The LDAP auth method binds directly to an LDAP server over the LDAP protocol, allowing users to authenticate with their directory credentials and groups to be mapped to Vault policies. It does not require OIDC or SAML endpoints, so it fits a directory that only exposes standard LDAP bind operations.

Why this answer

The LDAP auth method is designed to authenticate against an LDAP directory using standard bind operations and can map directory groups to Vault policies. Because the directory lacks OIDC or SAML capabilities, methods built on those protocols cannot be used, and a cloud-specific method like GitHub auth is unrelated to the on-premises directory.

Exam trap

The trap here is assuming any federated identity method can consume an LDAP directory, when only the LDAP auth method speaks the LDAP protocol directly.

Full explanation →
63
MCQmedium

An operator inspects a Vault policy and finds a rule granting read on database/creds/reporting. Applications using tokens bound to this policy can fetch credentials but receive permission denied when they attempt to extend them. Which capability must be added to the policy to allow lease renewal?

A.create on sys/leases/renew
B.sudo on database/creds/reporting
C.read on sys/leases/lookup
D.update on sys/leases/renew
AnswerD

Lease renewal is an update operation against sys/leases/renew, so a policy needs the update capability on that path for the token to extend a lease. Read on the creds path only permits generating credentials; it grants nothing on the renewal endpoint, which explains the permission denied errors observed.

Why this answer

Renewing a lease is an update to the sys/leases/renew endpoint, so the policy must grant update there. Reading lease metadata, using sudo on the generation path, or granting create instead of update all leave the renewal call unauthorized, which is exactly the failure the applications are hitting.

Exam trap

The trap here is assuming that read access to the credentials path also covers lease maintenance operations, when renewal is a separate update-authorized endpoint.

Full explanation →
64
MCQmedium

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

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

Raft requires a majority quorum to commit writes. Isolating the active node leaves the two standby nodes forming a quorum of three, so they elect a new leader and continue accepting writes while the old active steps down.

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
65
MCQhard

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

A.Vault validates the token's scope.
B.Users must generate a personal access token with repo scope.
C.The GitHub token must include the team scope.
D.Map the GitHub team to a Vault policy in the auth method configuration.
AnswerD

Mapping the GitHub team to a Vault policy in the auth method configuration satisfies the team-membership constraint: Vault's GitHub auth method reads the user's team memberships from the GitHub API and assigns the mapped policy, so only members of that specific team receive the token's permissions.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
66
MCQeasy

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

A.The role 'readonly' does not exist
B.The database secrets engine is not mounted at 'database/'
C.The token does not have a policy allowing read on 'database/creds/readonly'
D.The field 'value' does not exist in the secret
AnswerC

A 403 from Vault means the token authenticated successfully but its attached policy lacks the required capability on that path. Read on 'database/creds/readonly' must be granted by a policy bound to the token; without it, Vault denies the request rather than returning 404.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
67
MCQmedium

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

A.The policy 'webapp-readonly' does not exist.
B.The admin did not assign any policies to the user.
C.The user 'dev1' does not exist.
D.The password is incorrect.
AnswerB

The Userpass auth method requires policies to be attached to the user account itself, not merely created as a standalone policy. Creating 'webapp-readonly' does not bind it to 'dev1'; the admin must associate that policy with the user via the userpass endpoint. Without this association, the issued token carries no policies, producing the permission denied error.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
68
MCQmedium

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

A.The token had sudo capabilities on the path
B.The token was a root token and cannot be revoked
C.The token was an orphan token and therefore immune to revocation
D.The secrets were from a KV v1 engine that does not use leases
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
69
MCQeasy

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

A.vault operator rekey
B.vault operator unseal
C.vault operator migrate
D.vault operator init
AnswerC

`vault operator migrate` moves Vault's storage backend data between configured backends, satisfying the migration from file storage to Consul. It reads all entries from the source and writes them to the destination, preserving keys and values. Run it offline with both stanzas defined in the configuration file.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
70
Multi-Selecthard

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

Select 2 answers
A.Enable audit logging on the mount to track secret access
B.Configure 'max_lease_ttl' to limit the maximum duration secrets can be valid
C.Set 'default_lease_ttl' to a low value appropriate for the secrets engine
D.Set a high default lease TTL to reduce renewals
E.Disable the 'default' policy for the mount to restrict access
AnswersB, C

Setting max_lease_ttl caps how long any credential issued by the mount can remain valid, forcing periodic renewal or reissuance. This satisfies the tuning requirement by bounding exposure if a secret leaks, rather than letting leases persist indefinitely.

Why this answer

Option B is correct because configuring 'max_lease_ttl' on a secrets engine mount caps the absolute lifetime of any secret issued by that mount, preventing clients from renewing or holding credentials indefinitely and thereby limiting exposure if a secret leaks. Option C is correct because setting 'default_lease_ttl' to a low value appropriate for the engine ensures that, absent an explicit request, issued secrets expire quickly, which is a core Vault best practice for reducing the blast radius of compromised credentials. Option A is not a mount-tuning best practice in this context; audit logging is enabled at the audit device level and records requests globally rather than being a per-mount tuning parameter.

Option D is incorrect because a high default lease TTL increases the window in which a leaked secret remains valid, contradicting the goal of tight lease lifetimes. Option E is incorrect because the 'default' policy is a global Vault policy attached to tokens, not something that is disabled per secrets engine mount.

Exam trap

VA-003 often tests the confusion between per-mount lease tuning parameters (default_lease_ttl, max_lease_ttl) and server-wide audit/policy settings, tempting candidates to pick audit logging or policy changes as 'tuning' best practices.

Full explanation →
71
MCQmedium

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

A.Configure the LDAP auth method for both pods and legacy VMs, creating service accounts in Active Directory for each application.
B.Configure the Kubernetes auth method on all clusters and also install a Vault sidecar on the legacy VMs to make them appear as pods.
C.Use AppRole as the sole authentication method for all workloads, generating secret IDs for each pod and VM.
D.Keep the Kubernetes auth method for pods (fixing the namespace-specific issue) and enable AppRole authentication for the legacy VMs, using response wrapping or trusted entities for SecretID delivery.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
72
MCQmedium

A company's CI system runs outside any cloud provider and must authenticate to Vault without embedding a long-lived secret in its build scripts. The security team wants the CI job to prove its identity using a credential that Vault validates against the CI platform itself. Which auth method best fits this requirement?

A.Token auth method
B.Cert auth method
C.JWT/OIDC auth method
D.Userpass auth method
AnswerC

JWT/OIDC auth lets the CI platform issue a signed JWT that Vault validates against the platform's JWKS or public key. The job presents this short-lived token instead of a static secret, and Vault checks claims such as audience and subject, satisfying the requirement without embedding long-lived credentials.

Why this answer

JWT/OIDC auth is the right fit because the CI platform can mint a short-lived signed JWT that Vault validates against the platform's keys, proving the job's identity without a stored static secret. Userpass and token auth both require long-lived credentials, and cert auth relies on a stored client certificate rather than a platform-issued token.

Exam trap

The trap here is assuming any non-password method avoids static secrets, when cert auth still requires a long-lived private key stored with the CI job.

Full explanation →
73
MCQeasy

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

A.GET /v1/auth/userpass/login/jdoe with header "password: p@ssw0rd"
B.PUT /v1/auth/userpass/login/jdoe with JSON body {"password":"p@ssw0rd"}
C.POST /v1/auth/userpass/login/jdoe?password=p@ssw0rd
D.POST /v1/auth/userpass/login/jdoe with JSON body {"password":"p@ssw0rd"}
AnswerD

The userpass auth method exposes a login endpoint scoped to the specific username, so the credential travels in the JSON body rather than the path. POST /v1/auth/userpass/login/jdoe satisfies the stem's requirement to authenticate jdoe with the supplied password, returning a Vault token on success.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
74
MCQeasy

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

A.The user's token has no default policy
B.The policy lacks 'read' capability
C.The path must be 'secret/metadata/*' for list
D.The secrets engine is not enabled
AnswerC

For KV version 2, list operations are served by the metadata path, not the data path. Granting list on secret/data/* cannot authorise listing, so the policy must instead allow list on secret/metadata/* for the keys to be enumerable.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
75
MCQmedium

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

A.The secret engine is not mounted at 'secret/'
B.The secret key does not exist
C.The token has expired
D.The token's policy does not grant read capability on that path
AnswerD

Vault returns 403 when the token's attached policy lacks a read capability matching the requested path. Since 'secret/data/app' is the exact path being read, the absence of that capability in the policy is the direct cause of the forbidden response.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

Page 1 of 5

Page 2

All pages

12345

Practice VA-003 by domain

Target a specific domain to shore up weak areas.

Compare and configure secrets enginesCompare authentication methodsCreate Vault policiesAssess Vault tokensManage Vault leasesUtilize Vault CLI and APIExplain encryption as a serviceExplain Vault architecture
See all domains with question counts →