HashiCorp Vault Associate VA-003 VA-003 Questions 226–300 | Page 4/5

226

MCQhard

An admin wants to list all enabled authentication methods using the Vault API. Which curl command is correct?

A.curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auths

B.curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auth

C.curl -X POST -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auth

D.curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/auth

AnswerB

Listing enabled auth methods requires a GET to the sys/auth endpoint with a valid X-Vault-Token header. This command supplies the token and targets the correct path, satisfying the requirement to enumerate all enabled authentication methods through the Vault API.

Why this answer

The Vault API endpoint to list all enabled authentication methods is a GET request to `/v1/sys/auth`. This endpoint returns a map of all enabled auth methods, and the command uses the correct HTTP method (GET) and the required `X-Vault-Token` header for authentication.

Exam trap

HashiCorp often tests the exact API endpoint path and HTTP method, so the trap here is confusing the `/v1/sys/auth` endpoint with the non-existent `/v1/sys/auths` or the incorrect `/v1/auth` path, or assuming a POST request is needed when a GET is correct.

How to eliminate wrong answers

Option A is wrong because `/v1/sys/auths` is not a valid Vault API endpoint; the correct path is `/v1/sys/auth` (without the trailing 's'). Option C is wrong because it uses `-X POST` instead of the required GET method; the `/v1/sys/auth` endpoint only supports GET and DELETE operations, not POST. Option D is wrong because `/v1/auth` is not a valid API path; the correct base path for listing auth methods is `/v1/sys/auth`.

Full explanation →

227

MCQhard

A security team wants to ensure that database credentials generated by Vault are never renewed and have a fixed lifespan of 30 minutes. They configure the role with default_ttl=30m and max_ttl=30m, and set renewable=false. However, they find that some users are able to renew the leases anyway. What could be the reason?

A.The renewable flag requires the role to be updated after existing leases are issued.

B.The renewable flag is not respected when max_ttl equals default_ttl.

C.The renewable flag is only applicable to token auth methods, not secrets engines.

D.The lease's renewable property is controlled by the client token's renewable status.

AnswerA

The renewable flag is evaluated when a lease is issued, so leases created before the role update retain their original renewability. Existing leases must be revoked or allowed to expire for the non-renewable setting to take effect.

Why this answer

The `renewable=false` setting on a Vault role only affects newly issued leases; it does not retroactively apply to leases that were already issued before the role was updated. Since the security team configured the role after some users had already obtained credentials, those existing leases retain their original `renewable=true` property, allowing users to renew them despite the new role setting. Vault enforces the `renewable` flag at lease creation time, not dynamically during renewal requests.

Exam trap

The trap in Vault is that the `renewable` flag on a role only affects new leases issued after the role update, not existing leases. Candidates often incorrectly assume that changing the role setting immediately prevents renewals, but Vault applies the flag at lease creation time.

How to eliminate wrong answers

Option B is wrong because the `renewable` flag is fully independent of TTL values; setting `max_ttl` equal to `default_ttl` does not override or disable the `renewable` flag. Option C is wrong because the `renewable` flag is applicable to both token auth methods and secrets engines (e.g., database, AWS, PKI) when generating dynamic credentials; it is not limited to token auth methods. Option D is wrong because the lease's `renewable` property is controlled by the role configuration of the secrets engine that issued the lease, not by the client token's `renewable` status; the client token's renewability is a separate concern.

Full explanation →

228

MCQeasy

A small development team wants engineers to log in to Vault with a username and password stored directly in Vault, without integrating any external directory or identity provider. Which authentication method should the administrator enable to satisfy this requirement?

A.github

B.ldap

C.userpass

D.okta

AnswerC

The userpass auth method stores usernames and password hashes inside Vault itself, so it works without any external directory or identity provider. Administrators create users with vault write auth/userpass/users/<name> password=... and assign policies per user. This matches the team's desire for a self-contained credential store with minimal integration effort.

Why this answer

Userpass is the built-in method that keeps usernames and password hashes inside Vault's storage backend, requiring no external directory or identity service. Administrators manage users and their policies directly through the auth mount, which fits a small team that wants simple, self-contained authentication with minimal setup.

Exam trap

The trap here is treating any username-and-password method as equivalent, when ldap and okta both depend on external systems while userpass stores credentials internally.

Full explanation →

229

Multi-Selecteasy

Which TWO statements are true about batch tokens?

Select 2 answers

A.Batch tokens can be renewed to extend their lifetime

B.Batch tokens cannot be renewed or revoked

C.Batch tokens are not stored in Vault's storage backend

D.Batch tokens can be looked up using the lookup endpoint

AnswersB, C

Batch tokens are stateless and cannot be renewed or revoked individually; revocation only occurs by letting them expire or by rotating the signing key. This satisfies the stem's requirement for a true statement about batch token lifecycle limitations.

Why this answer

Option B is correct because batch tokens are designed as lightweight, self-contained tokens that cannot be renewed or revoked once issued; they simply expire at the end of their fixed TTL. Option C is correct because batch tokens are not persisted in Vault's storage backend—they are encrypted blobs whose validity is verified without a storage lookup, which is what makes them scalable and cheap to create. Option A is incorrect because batch tokens have a fixed lifetime and cannot be renewed, unlike service tokens.

Option D is incorrect because batch tokens cannot be looked up via the lookup endpoint; lookup operations require a storage-backed token, which batch tokens are not.

Exam trap

The Vault exam often tests the misconception that all Vault tokens support renewal and lookup, but batch tokens are explicitly excluded from these operations due to their stateless, non-persistent nature.

Full explanation →

230

MCQmedium

A security team wants to audit all tokens created by a specific authentication method. They need to list all tokens and retrieve details such as creation time, TTL, and policies. Which Vault command should they use?

A.vault token create -list

B.vault list auth/token/accessors

C.vault token lookup

D.vault read auth/token/accessors

AnswerB

`vault list auth/token/accessors` lists all token accessors, which can then be used with `vault token lookup` to retrieve details for each token. This is the standard way to enumerate tokens and audit their properties. It provides a list of accessors without exposing the tokens themselves, which is a security best practice.

Why this answer

To audit tokens, administrators can list all token accessors using `vault list auth/token/accessors`. Each accessor can then be used with `vault token lookup` to retrieve detailed information about the corresponding token. This approach avoids exposing the actual token IDs while still allowing comprehensive auditing of token properties such as creation time, TTL, and policies.

Exam trap

The trap here is confusing the command to list token accessors with the command to read a specific token's details, or attempting to use a non-existent flag like `-list`.

Full explanation →

231

MCQhard

A security engineer enables the Transit secrets engine at 'transit/' and creates an encryption key named 'payments' with `vault write -f transit/keys/payments`. The engineer then wants to rotate the key so that new data is encrypted with a new key version while existing ciphertext can still be decrypted. Which command accomplishes this without invalidating existing ciphertext?

A.vault write -f transit/keys/payments/trim min_available_version=2

B.vault write -f transit/keys/payments/rotate

C.vault write transit/keys/payments/config rotation_period=24h

D.vault write transit/keys/payments/rewrap ciphertext=<ciphertext>

AnswerB

The rotate endpoint generates a new key version for the named key and sets it as the current version for future encrypt operations. Existing ciphertext remains decryptable because Vault retains previous key versions and embeds the version in the ciphertext. This command is the supported way to perform key rotation in the Transit secrets engine without re-encrypting all data.

Why this answer

Transit key rotation creates a new key version and designates it for future encryption, while retaining prior versions so existing ciphertext can still be decrypted. The rotate endpoint performs this immediately. Automatic rotation via a rotation period is a separate configuration and does not trigger an instant new version.

Rewrap and trim serve different purposes and do not create a new key version.

Exam trap

The trap here is confusing automatic rotation configuration with an immediate rotation, or mistaking rewrap for the operation that creates a new key version.

Full explanation →

232

MCQmedium

An operator runs vault lease list and sees many expired leases. Why are expired leases still listed?

A.The leases are not actually expired.

B.The operator has a permission to see expired leases.

C.Vault keeps expired leases for auditing until cleaned up by garbage collection.

D.Expired leases are never removed.

AnswerC

Expired leases persist because Vault retains them for auditing purposes until garbage collection removes them. This satisfies the stem's observation that `vault lease list` shows expired entries: the audit trail requirement means leases are not deleted immediately upon expiry, but only when the garbage collection process later reclaims them.

Why this answer

Vault does not immediately remove expired leases; they are cleaned up by a periodic garbage collection process. Until then, they may appear in listing.

Full explanation →

233

MCQmedium

An application needs to obtain short-lived, time-limited credentials to access an external database using username/password authentication. Which secrets engine should be used?

A.KV v2 secrets engine

B.Database secrets engine

C.Consul secrets engine

D.Identity secrets engine

AnswerB

The database secrets engine dynamically generates unique, short-lived database credentials on demand, then automatically revokes them at lease expiry. This directly satisfies the stem's requirement for time-limited credentials using username/password authentication against an external database, rather than issuing static long-lived passwords that persist until manually rotated.

Why this answer

The Database secrets engine is designed specifically to generate short-lived, dynamic credentials for databases, including external databases accessed via username/password authentication. It creates unique, time-limited usernames and passwords on-the-fly, which are automatically revoked after a configurable TTL, meeting the requirement for temporary credentials.

Exam trap

HashiCorp often tests the distinction between static secret storage (KV) and dynamic secret generation (Database, AWS, etc.), so the trap here is assuming that any secrets engine can produce time-limited credentials, when only engines like Database, AWS, or PKI are designed for dynamic, lease-based credentials.

How to eliminate wrong answers

Option A is wrong because the KV v2 secrets engine stores static secrets (like fixed passwords or API keys) and does not generate dynamic, time-limited credentials; it simply retrieves stored values without any built-in expiration or rotation mechanism. Option C is wrong because the Consul secrets engine generates dynamic credentials for Consul services (e.g., ACL tokens) and is not designed for database username/password authentication. Option D is wrong because the Identity secrets engine manages entity and group identities within Vault, not external database credentials; it handles aliases and policies, not dynamic secret generation.

Full explanation →

234

Multi-Selectmedium

An organization is creating Vault policies to manage access to secrets across multiple application teams. According to HashiCorp best practices, which two approaches should be taken when designing policies? (Choose two.)

Select 2 answers

A.Avoid using negative capabilities (deny) when possible.

B.Grant maximum permissions initially and then restrict as needed.

C.Use a single all-encompassing policy for each environment.

D.Use path templating to incorporate entity metadata.

E.Name policies based on the application or team they serve.

AnswersD, E

Templating reduces duplication and ties access to identity attributes.

Why this answer

HashiCorp recommends using path templating with entity metadata (e.g., {{identity.entity.metadata.team}}) to dynamically scope policies to specific teams or applications. This approach reduces policy sprawl and ensures that permissions are automatically applied based on the authenticated entity's attributes, aligning with the principle of least privilege.

Exam trap

HashiCorp often tests candidates' understanding that Vault policies are purely additive (no deny) and that path templating is a key best practice for scaling policy management across multiple teams, tempting candidates to select 'avoid deny' or 'single policy' due to familiarity with other IAM systems.

Full explanation →

235

MCQmedium

An operator needs to create a periodic token with a period of 36 hours. Which command should they use?

A.vault token create -period=36h

B.vault token create -period=36h -explicit-max-ttl=36h

C.vault token create -ttl=36h

D.vault token create -explicit-max-ttl=36h

AnswerA

The -period flag on vault token create establishes a periodic token, and 36h sets the renewal period the stem demands. Periodic tokens have no maximum TTL, so they renew indefinitely provided the period does not exceed the system max_lease_ttl.

Why this answer

The `vault token create -period=36h` command creates a periodic token with a specified renewal period of 36 hours. Periodic tokens have no explicit TTL; their lifetime is tied to the renewal period, and they can be renewed indefinitely as long as the parent token is valid. This matches the requirement for a token that automatically extends its lifetime every 36 hours.

Exam trap

HashiCorp often tests the distinction between `-period` (for periodic tokens) and `-ttl` (for fixed-lifetime tokens), leading candidates to confuse the two and incorrectly choose `-ttl` when a renewable periodic token is required.

How to eliminate wrong answers

Option B is wrong because adding `-explicit-max-ttl=36h` imposes a hard upper limit on the token's lifetime, which contradicts the purpose of a periodic token that should be renewable indefinitely without a fixed maximum. Option C is wrong because `-ttl=36h` creates a non-periodic token with a fixed TTL of 36 hours, after which it expires and cannot be renewed beyond that time. Option D is wrong because `-explicit-max-ttl=36h` alone creates a token with a hard maximum lifetime but no periodic renewal behavior, so it does not meet the requirement for a periodic token.

Full explanation →

236

MCQeasy

A DevOps team wants to authenticate to Vault using short-lived tokens without storing a secret in their CI/CD pipeline. Which authentication method best meets this requirement?

A.JWT/OIDC

B.AWS IAM

C.AppRole

D.Username & Password

AnswerA

JWT/OIDC auth has the CI/CD pipeline present its platform-issued identity token, which Vault validates against the provider's signing keys. The resulting Vault token is short-lived, so no static secret is stored in the pipeline, meeting the requirement.

Why this answer

JWT/OIDC authentication allows a DevOps pipeline to exchange a signed JSON Web Token (JWT) from an external identity provider (e.g., GitHub Actions, GitLab CI) for a short-lived Vault token. This eliminates the need to store a long-lived secret in the CI/CD pipeline because the JWT is dynamically generated by the CI platform and validated by Vault using the OIDC provider's public keys. The resulting Vault token has a configurable TTL, typically minutes, aligning with the requirement for short-lived credentials.

Exam trap

HashiCorp often tests the misconception that AppRole is the best choice for CI/CD because it is designed for machine authentication, but the trap is that AppRole still requires storing a role_id and secret_id, which are long-lived secrets unless using response wrapping, and the question explicitly prohibits storing any secret.

How to eliminate wrong answers

Option B (AWS IAM) is wrong because it requires the CI/CD pipeline to have access to AWS IAM credentials (access key and secret key) or an IAM role with a trust policy, which still involves storing a secret or assuming a role that may not be short-lived. Option C (AppRole) is wrong because it requires a secret_id and role_id to be stored in the pipeline; while secret_id can be wrapped or have a TTL, the role_id is typically static and must be securely stored, contradicting the 'without storing a secret' requirement. Option D (Username & Password) is wrong because it requires storing a static password in the pipeline, which is a long-lived secret and violates the short-lived token requirement.

Full explanation →

237

MCQhard

A security architect is designing a Vault deployment where the root key must never exist in plaintext outside of memory and must be split among five key holders. After initialization, the architect wants to ensure that no single administrator can unseal the vault alone. Which Vault architectural feature directly enforces this requirement?

A.Auto-unseal using a cloud KMS, which stores the master key in a hardware security module (HSM).

B.The recovery key mechanism, which allows a quorum of operators to generate a new root token.

C.Shamir's Secret Sharing with a threshold greater than one, configured during initialization.

D.Seal Wrap, which encrypts the master key with a hardware-backed key before writing it to storage.

AnswerC

Shamir's Secret Sharing splits the master key into key shares and requires a threshold number of shares to reconstruct it. By setting a threshold greater than one, no single key holder can unseal the vault. This directly enforces the separation of duties and ensures the root key never exists in plaintext outside memory.

Why this answer

Shamir's Secret Sharing is the core Vault feature that splits the master key into shares and requires a threshold to reconstruct it. By setting a threshold greater than one, the architect ensures that multiple key holders must cooperate to unseal the vault, directly meeting the separation-of-duties requirement.

Exam trap

The trap here is confusing auto-unseal or Seal Wrap with key splitting; those features change how the key is protected, not how many people are needed to unseal.

Full explanation →

238

MCQeasy

A developer wants to log in to Vault from a terminal by supplying a username and password that Vault stores and manages internally, without relying on any external identity system. Which auth method should be enabled?

A.Token auth method

B.OIDC auth method

C.Userpass auth method

D.LDAP auth method

AnswerC

The Userpass auth method stores usernames and password hashes inside Vault itself, allowing users to log in with credentials Vault manages. It requires no external identity provider, which matches the developer's need for a self-contained username and password login from the CLI.

Why this answer

Userpass keeps user records and password hashes within Vault, so it delivers exactly the self-contained username and password login described. LDAP and OIDC both depend on external systems, and token auth only consumes a pre-existing token rather than authenticating a user with credentials.

Exam trap

The trap here is overlooking that Userpass stores credentials inside Vault, while LDAP looks similar at login time but always delegates validation to an external directory.

Full explanation →

239

MCQmedium

A platform team runs Vault with a transit secrets engine mount at transit/. An application requests a new data encryption key with a 30-minute TTL, and the returned lease_id is recorded by the app. Twenty minutes later, the app calls the renew endpoint for that lease. The mount was configured with max_lease_ttl of 1h. What is the maximum TTL the lease can be extended to by this renewal?

A.The lease can be renewed indefinitely as long as the client keeps renewing before expiration, because transit keys have no maximum lifetime.

B.The lease can be renewed only up to the original 30-minute TTL, because transit leases cannot be extended beyond creation TTL.

C.The lease can be renewed up to 1 hour total from its original creation time, because the mount's max_lease_ttl caps the cumulative lease lifetime.

D.The lease can be renewed to 30 minutes from the moment of the renewal call, giving it a total lifetime of 50 minutes.

AnswerC

Vault caps a lease's total lifetime at the mount's max_lease_ttl, which here is 1h. Renewal can extend the remaining time, but it cannot push the lease past that cumulative limit from creation. Since the lease was created 20 minutes ago, a renewal can extend it only to the 1-hour mark, after which it expires and must be re-created.

Why this answer

A renewable lease is bounded by the mount's max_lease_ttl, which acts as a cumulative ceiling measured from lease creation. Renewal can extend the lease's expiration toward that ceiling but never beyond it. With a 1-hour max and 20 minutes already elapsed, the lease can be renewed only to the 1-hour mark, after which it must be reissued.

Exam trap

The trap here is assuming a renewal adds a fresh TTL interval from the renewal moment instead of counting against the mount's cumulative max_lease_ttl.

Full explanation →

240

MCQeasy

Refer to the exhibit. A user with this policy tries to write a new secret to "secret/data/production/db". What will happen?

A.The write succeeds if the secret already exists.

B.The write succeeds because the path matches.

C.The write fails because the policy only allows read on production.

D.The write fails because the user does not have list capability.

AnswerC

The policy grants only read capability on the production path, so any write operation is denied by Vault's default-deny posture. Creating a secret at "secret/data/production/db" requires create or update capability on that exact path, which the policy omits, causing the write to fail.

Why this answer

The policy only grants 'read' capability on the 'secret/data/production/*' path, which allows reading secrets but not creating or updating them. Writing a new secret requires 'create' or 'update' capabilities (or 'write' which encompasses both). Since the policy lacks these capabilities, the write operation fails regardless of whether the secret already exists.

Exam trap

A common misunderstanding in HashiCorp Vault is that path matching alone is sufficient for an operation to succeed, overlooking that each capability (e.g., read, create, update) must be explicitly granted in the policy.

How to eliminate wrong answers

Option A is wrong because even if the secret already exists, the policy does not grant 'update' capability, so the write fails. Option B is wrong because the path matches, but capability matching is also required; the policy only allows 'read', not 'write'. Option D is wrong because the failure is due to missing 'create'/'update' capability, not missing 'list' capability; 'list' is irrelevant for a write operation.

Full explanation →

241

MCQeasy

An administrator wants to allow human users to authenticate using their corporate Active Directory credentials. Which authentication method should they enable?

A.Token auth

B.GitHub auth

C.Userpass auth

D.LDAP auth

AnswerD

LDAP auth lets Microsoft Entra ID validate credentials directly against on-premises Active Directory domain controllers, so users sign in with their existing corporate AD accounts without separate cloud passwords. This satisfies the stem's requirement for authenticating human users via corporate Active Directory credentials, unlike token-based or federated methods.

Why this answer

LDAP (Lightweight Directory Access Protocol) authentication allows integration with corporate Active Directory by binding to the directory service using a user's credentials. This enables centralized authentication against existing AD user objects without duplicating accounts in the Vault system.

Exam trap

HashiCorp often tests the misconception that 'LDAP auth' is only for Unix/Linux systems, when in fact it is the standard protocol for integrating with Microsoft Active Directory for user authentication.

How to eliminate wrong answers

Option A is wrong because token auth is used for machine-to-machine authentication via pre-shared tokens, not for human users authenticating with corporate credentials. Option B is wrong because GitHub auth is an OAuth-based method for authenticating with GitHub identities, not for corporate Active Directory. Option C is wrong because userpass auth stores credentials locally in Vault's backend, requiring manual user management and not integrating with external directory services like Active Directory.

Full explanation →

242

Multi-Selecthard

Which THREE are best practices when selecting authentication methods for different use cases?

Select 3 answers

A.Use AppRole for automated CI/CD pipelines.

B.Use token auth as the sole method for all users and machines.

C.Use AWS IAM auth for EC2 instances running in AWS.

D.Use Kubernetes auth for pods in any environment.

E.Use LDAP auth for human users with Active Directory.

AnswersA, C, E

AppRole assignments suit automated CI/CD pipelines because they grant application permissions without interactive sign-in, satisfying the non-interactive workload constraint. Unlike delegated scopes, which require a signed-in user context, app roles let the pipeline authenticate as itself via client credentials, avoiding stored user passwords or MFA prompts.

Why this answer

Option A is correct because AppRole is purpose-built for machine-to-machine authentication: it issues a RoleID and SecretID that a CI/CD pipeline can deliver programmatically, and its response-wrapping and secret-ID lifecycle controls make it the recommended method for automated, non-interactive workloads. Option C is correct because AWS IAM auth lets an EC2 instance present its instance profile credentials to Vault, which verifies the AWS-signed request via STS, so no static Vault credentials need to be stored on the instance. Option E is correct because LDAP auth binds directly to a directory such as Active Directory, allowing human users to authenticate with their existing AD credentials and inherit group-based policies, which is the standard approach for enterprise human access.

Option B is not a best practice because making token auth the sole method for everyone ignores stronger, purpose-specific methods and forces manual token distribution and lifecycle management, increasing leakage risk. Option D is not a best practice as stated because Kubernetes auth is only appropriate for pods running in a Kubernetes cluster that Vault is configured to trust; using it 'in any environment' is impossible where no Kubernetes service account token or Vault Kubernetes auth role exists.

Exam trap

HashiCorp often tests the misconception that a single authentication method can be universally applied, or that a method designed for a specific platform (like Kubernetes auth) can be used in any environment, leading candidates to select overly broad or insecure options like B or D.

Full explanation →

243

MCQhard

A company uses Vault's Kubernetes authentication method to provide secrets to pods. Pods in the 'production' namespace need to read secrets from the path 'secret/data/app/prod'. The administrator has created a Vault role that maps the service account to a policy with capabilities ['read', 'list'] on path 'secret/data/app/*'. However, pods report 'permission denied' when trying to read the secrets. The administrator verifies that the service account has the correct Vault role attached and that the Vault token is being used correctly. What is the most likely cause?

A.The Vault mount for 'secret' is KV v1, so the path should be 'secret/app/prod' without 'data'.

B.The policy should include the 'sudo' capability.

C.The pods are using a token with insufficient TTL.

D.The Vault role is not bound to the correct Kubernetes namespace.

AnswerA

KV v2 inserts a mandatory `data/` segment between the mount and the secret path, so a policy written for the v2 layout cannot match a v1 mount. The role's policy grants `secret/data/app/*`, which never matches the actual v1 path `secret/app/prod`, producing the permission denied. Correcting the path to omit `data` resolves it.

Why this answer

The most likely cause is that the Vault mount for 'secret' is using KV v1, which does not use the 'data' segment in the path. The policy is written with 'secret/data/app/*' (KV v2 path), but because the mount is KV v1, the actual path is 'secret/app/prod'. This path mismatch leads to 'permission denied' because the policy does not apply to the correct path.

Exam trap

HashiCorp Vault often tests the distinction between KV v1 and KV v2 path structures, trapping candidates who assume all 'secret' mounts use the same path format without checking the engine version.

How to eliminate wrong answers

Option B is wrong because the 'sudo' capability is not required for reading secrets; it is used for privileged operations like updating mount configurations or policies, not for standard read/list actions. Option C is wrong because insufficient TTL would cause token expiration, not a 'permission denied' error; the token is being used correctly as verified, so TTL is not the issue. Option D is wrong because the administrator has already verified that the service account has the correct Vault role attached, implying the role binding to the Kubernetes namespace is correct; the error stems from path structure, not namespace binding.

Full explanation →

244

Multi-Selecthard

An organization uses Vault's AWS secrets engine to generate temporary IAM credentials. The Vault administrator has set the default lease TTL on the AWS mount to 15 minutes. A developer creates a role with role TTL of 30 minutes and explicit max TTL of 1 hour. Which TWO statements are true regarding the lease behavior for credentials generated under this role?

Select 2 answers

A.The initial lease duration will be 30 minutes (the role TTL).

B.The lease can be renewed up to a total lifetime of 1 hour (explicit max TTL).

C.The lease can be renewed indefinitely up to the system max TTL.

D.The initial lease duration will be 15 minutes (the default lease TTL).

E.The lease duration is the minimum of default lease and role TTL.

AnswersA, B

The role TTL overrides the mount's default lease TTL, so credentials issued under this role receive an initial lease of 30 minutes rather than the mount's 15-minute default. The explicit max TTL of 1 hour caps renewal, not the initial issuance, satisfying the stem's role-level TTL constraint.

Why this answer

Option A is correct because when a role specifies its own TTL, that role TTL overrides the mount's default lease TTL, so the initial lease duration for credentials generated under this role is 30 minutes. Option B is correct because the role's explicit max TTL of 1 hour caps the total lifetime of the lease, meaning renewals can extend it only up to that 1-hour maximum. Option D is incorrect because the 15-minute default lease TTL applies only when the role does not define its own TTL.

Option C is incorrect because an explicit max TTL prevents indefinite renewal and overrides the system max TTL. Option E is incorrect because Vault does not take the minimum of the default lease TTL and role TTL; the role TTL takes precedence for the initial lease duration.

Exam trap

HashiCorp often tests the distinction between initial lease duration (role TTL) and total allowable lifetime (explicit max TTL), and the trap here is assuming the default mount TTL or a minimum calculation governs the initial lease when a role TTL is explicitly configured.

Full explanation →

245

MCQeasy

A developer needs to authenticate to Vault from a CI/CD pipeline running on an on-premises server. The pipeline cannot use cloud provider identities or Kubernetes. The security team wants to avoid embedding long-lived Vault tokens in the pipeline scripts. Which authentication method is most appropriate?

A.AppRole auth method

B.Username & Password auth method

C.GitHub auth method

D.OIDC auth method

AnswerA

AppRole is designed for machine-to-machine authentication and is ideal for CI/CD pipelines. It uses a role_id and secret_id, which can be delivered securely and have short TTLs. This avoids embedding long-lived tokens. The pipeline can retrieve a secret_id dynamically (e.g., from a trusted orchestrator) and authenticate to get a short-lived Vault token.

Why this answer

AppRole is purpose-built for machine-to-machine authentication, including CI/CD pipelines. It uses a role_id and secret_id that can be delivered securely and have short TTLs, avoiding long-lived tokens. Other methods either require interactive user flows or static credentials unsuitable for the scenario.

Exam trap

The trap here is selecting OIDC because it sounds modern, but OIDC is for human users, not headless CI/CD pipelines.

Full explanation →

246

MCQhard

During an audit, it is discovered that a single AppRole role is used by hundreds of applications, and it is impossible to revoke access for a single compromised application without affecting others. What should be done to improve the security posture?

A.Create a unique AppRole role for each application

B.Schedule periodic secret ID rotation

C.Reduce the token TTL to 1 minute

D.Add CIDR bindings to the AppRole role

AnswerA

Splitting the shared role into one AppRole per application isolates each SecretID, so revoking a single compromised application's role no longer invalidates credentials used by the other hundreds of applications. This directly resolves the stem's stated inability to revoke access individually.

Why this answer

Creating a unique AppRole role for each application ensures that each application has its own set of credentials (RoleID and SecretID). This allows you to revoke access for a single compromised application by deleting or disabling its specific AppRole role, without impacting other applications. This directly addresses the core issue of shared credentials and provides granular access control.

Exam trap

The trap here is that candidates often choose secret rotation (Option B) as a security best practice, but they fail to recognize that rotation does not solve the fundamental problem of shared credentials and lack of isolation between applications.

How to eliminate wrong answers

Option B is wrong because periodic secret ID rotation does not solve the problem of a single compromised application affecting others; all applications still share the same role, so rotating the secret ID would disrupt all applications simultaneously. Option C is wrong because reducing the token TTL to 1 minute only limits the lifespan of tokens, but it does not isolate applications; a compromised application could still continuously re-authenticate and access resources, and revoking its access would still require revoking the entire role. Option D is wrong because adding CIDR bindings restricts the source IP addresses that can authenticate, but if multiple applications share the same role and originate from different IPs, this could block legitimate traffic; more importantly, it does not allow selective revocation for a single compromised application.

Full explanation →

247

MCQeasy

A developer needs to encrypt a short configuration string with the Vault transit secrets engine. The transit engine is mounted at `transit/` and a key named `app-config` has already been created. Which single CLI command correctly sends the plaintext to Vault for encryption?

A.vault write transit/app-config/encrypt plaintext=config.txt

B.vault write transit/encrypt/app-config plaintext=$(base64 -w0 config.txt)

C.vault encrypt transit/app-config plaintext=config.txt

D.vault write transit/encrypt/app-config plaintext=config.txt

AnswerB

The transit encrypt endpoint is `transit/encrypt/<key-name>`, and the `plaintext` parameter must be base64-encoded before it is submitted. Using `base64 -w0` produces a single-line base64 value suitable for the request, so this command reaches the correct key and supplies a valid payload.

Why this answer

The transit engine exposes encryption at `transit/encrypt/<key-name>`, and the payload's `plaintext` field must be base64-encoded. Supplying the correctly ordered path along with a base64-encoded value is what allows Vault to return a `ciphertext` field. The other candidates fail because they either misuse the CLI, reverse the path structure, or omit the required base64 encoding.

Exam trap

The trap here is forgetting that transit plaintext must be base64-encoded before it is sent, not passed as a raw string or filename.

Full explanation →

248

MCQeasy

A platform team wants to provide applications with short-lived AWS credentials that are automatically revoked when their lease expires, without managing long-term IAM users. They also need to allow the applications to assume a role for cross-account access. Which secrets engine should the team enable and configure?

A.The AWS secrets engine with an IAM user type role

B.The AWS secrets engine with an access key type role

C.The AWS secrets engine with a federation token type role

D.The AWS secrets engine with an assumed role type role

AnswerD

The assumed role type uses STS AssumeRole to issue temporary credentials that automatically expire with the lease, and it supports cross-account access when the role's trust policy allows it. This matches both the short-lived requirement and the cross-account assumption need without creating persistent IAM users.

Why this answer

The AWS secrets engine's assumed_role credential type issues STS temporary credentials by assuming a role, so leases expire naturally and cross-account access works when the target role trusts the Vault-provided identity. This avoids the operational overhead of IAM user creation and deletion while supporting the cross-account pattern described.

Exam trap

The trap here is conflating IAM user creation with role assumption, when only the assumed_role credential type provides STS temporary credentials suitable for cross-account access.

Full explanation →

249

MCQmedium

A platform team runs Vault 1.15 with an integrated storage backend. They have enabled the KV v2 secrets engine at the path 'apps/'. A developer deletes the secret at 'apps/data/webapp/db-creds' using `vault kv delete apps/webapp/db-creds`, then immediately reads it back with `vault kv get apps/webapp/db-creds`. What does the developer observe?

A.The read returns a 404 with 'no value found' because the latest version is soft-deleted and no data is returned by default.

B.The read returns the previous version of the secret because soft-delete only marks the latest version as deleted.

C.The read returns a permission denied error because the developer lacks the 'undelete' capability on the path.

D.The read returns the data normally because soft delete only takes effect after a subsequent write operation.

AnswerA

In KV v2, `vault kv delete` performs a soft delete that marks the latest version as deleted. Subsequent reads of the path return HTTP 404 with no data unless a specific non-deleted version is requested. The secret data remains recoverable, but the default read does not surface it, matching the observed 404 behavior.

Why this answer

KV v2 separates delete from destroy. The `vault kv delete` command performs a soft delete on the latest version, so a normal read returns 404 and no data. The data is still present in storage and can be recovered with `vault kv undelete` or by reading a specific version that was not deleted.

Understanding this distinction is essential for safe secret lifecycle management.

Exam trap

The trap here is assuming that a soft delete behaves like a hard destroy and permanently removes the data, or conversely that a normal read still returns the deleted value.

Full explanation →

250

MCQeasy

A developer created a token and wants to ensure that the token can only be used to read secrets from the 'secret/data/production' path. Which policy attachment approach should be used?

A.Set the token's metadata to restrict access

B.Use a root token and restrict its use via a policy

C.Create a policy with read capability on 'secret/data/production' and attach it to the token

D.Set the token type to service and it will automatically restrict access

AnswerC

Attaching a policy granting only read capability on 'secret/data/production' to the token scopes its permissions to that exact path, satisfying the least-privilege constraint. Vault evaluates the token's attached policies, so no broader capability is inherited.

Why this answer

Vault uses policies to define fine-grained access control, and the only way to restrict a token to read secrets from a specific path is to create a policy with the appropriate capabilities (e.g., 'read' on 'secret/data/production') and attach that policy to the token at creation time. Tokens themselves do not inherently carry path restrictions; they inherit permissions solely from attached policies.

Exam trap

HashiCorp often tests the misconception that token metadata or token type can enforce access restrictions, when in fact only policies attached to the token define what paths and operations are allowed.

How to eliminate wrong answers

Option A is wrong because token metadata is used for audit and identity purposes, not for enforcing access control; Vault does not evaluate metadata to allow or deny API requests. Option B is wrong because a root token has unrestricted access to all paths and policies cannot restrict a root token—root tokens bypass all policy checks by design. Option D is wrong because the token type (service vs. batch) determines lifecycle and revocation behavior, not access permissions; a service token still requires an attached policy to define what it can read.

Full explanation →

251

Multi-Selecthard

A Vault administrator wants to minimize the impact of a single node failure in a three-node Raft cluster. Which TWO actions will help? (Choose two.)

Select 2 answers

A.Set `disable_clustering` to true.

B.Use a load balancer to distribute client requests.

C.Configure monitoring to detect and replace failed nodes quickly.

D.Enable `retry_join` on all nodes with addresses of peers.

E.Enable `performance_standby` on all nodes.

AnswersC, D

Rapid detection and replacement shortens the window in which the cluster operates with reduced redundancy, directly limiting a single node failure's impact. Raft tolerates one failure in three nodes, so prompt replacement restores quorum resilience before a second failure causes outage. Monitoring alone does not prevent failure but satisfies the stem's minimisation constraint.

Why this answer

Option C is correct because fast detection and replacement of a failed node shortens the window in which the three-node Raft cluster has reduced fault tolerance, restoring quorum redundancy quickly. Option D is correct because configuring `retry_join` with peer addresses lets a restarted or replaced node automatically rejoin the Raft cluster without manual intervention, which directly minimizes the impact of a node failure. Option A is wrong because setting `disable_clustering` to true disables Raft clustering entirely, which would eliminate the cluster's redundancy rather than protect it.

Option B is wrong because a load balancer only distributes client traffic and does not address Raft node failure or quorum recovery. Option E is wrong because `performance_standby` nodes are non-voting replicas that do not participate in Raft quorum, so they do not mitigate the loss of a voting node's fault tolerance.

Exam trap

A common mistake in Vault Raft clusters is to think that a load balancer or enabling performance standby enhances fault tolerance against node failures. In fact, Vault's Raft consensus requires quorum, and retry_join ensures automatic reconnection after a node recovers. Load balancers help with traffic distribution but do not affect cluster availability from a Raft perspective.

Full explanation →

252

Multi-Selecthard

Which TWO of the following are valid methods to enable a secrets engine at a non-default path in Vault?

Select 2 answers

A.vault secrets enable -custom-path=my-aws aws

B.vault write sys/mounts/my-aws type=aws

C.vault secrets enable -path=my-aws aws

D.vault secrets enable -mount-path=my-aws aws

E.vault secrets enable my-aws aws

AnswersB, C

Writing to `sys/mounts/my-aws` with `type=aws` enables the AWS secrets engine at the custom path `my-aws`, satisfying the non-default path constraint. The mount path is the final segment of the endpoint, so this registers the engine there rather than at the default `aws` location.

Why this answer

Option B is correct because writing directly to the sys/mounts/<path> endpoint with type=<engine> is the underlying API operation that enables a secrets engine at a custom path, so `vault write sys/mounts/my-aws type=aws` mounts the AWS engine at my-aws. Option C is correct because the CLI `vault secrets enable` command accepts the `-path` flag to specify a non-default mount path, so `vault secrets enable -path=my-aws aws` enables the AWS secrets engine at my-aws. Option A is incorrect because `-custom-path` is not a valid flag for `vault secrets enable`.

Option D is incorrect because `-mount-path` is not a recognized flag; the correct flag is `-path`. Option E is incorrect because `vault secrets enable my-aws aws` passes my-aws as the engine type rather than a path, and the CLI does not accept a positional path argument in that form.

Exam trap

Vault's CLI supports two distinct methods for enabling secrets engines: the higher-level 'vault secrets enable' command and the lower-level 'vault write' on the sys/mounts endpoint. The exam often tests whether candidates know both methods and the correct flag names.

Full explanation →

253

MCQmedium

A developer needs to generate a new certificate for an internal web service using the PKI secrets engine. A role named 'webserver' has been created. What is the correct command to issue the certificate?

A.vault write pki/webserver/issue

B.vault write pki/webserver/cert common_name=web.example.com

C.vault read pki/cert/webserver

D.vault write pki/issue/webserver common_name=web.example.com

AnswerD

Issuing through pki/issue/<role> uses the named role's parameters to generate a certificate and private key, returning them directly. This satisfies the scenario because the webserver role supplies the configuration and common_name sets the requested identity.

Why this answer

The PKI secrets engine uses the path `pki/issue/<role_name>` to issue certificates. The `vault write` command sends a POST request to this endpoint with the required `common_name` parameter, which generates a new certificate signed by the CA associated with the 'webserver' role.

Exam trap

HashiCorp often tests the exact API path structure, where candidates mistakenly assume the role name is part of the path before 'issue' (e.g., `pki/role/issue`) or confuse the issue endpoint with the read endpoint for existing certificates.

How to eliminate wrong answers

Option A is wrong because `pki/webserver/issue` is not a valid endpoint; the correct path is `pki/issue/webserver`. Option B is wrong because `pki/webserver/cert` is not a valid endpoint for issuing certificates; it incorrectly appends 'cert' to the role name. Option C is wrong because `vault read pki/cert/webserver` retrieves an existing certificate by serial number or ID, not issue a new one, and 'webserver' is a role name, not a certificate identifier.

Full explanation →

254

MCQmedium

A Vault administrator wants to allow a CI/CD pipeline to create short-lived tokens for deployment jobs. The pipeline itself authenticates with a periodic token. Which token type should the pipeline use to create tokens for jobs, considering the jobs need to be independent and not affected by the pipeline token's lifecycle?

A.Service tokens with explicit max TTL

B.Orphan tokens

C.Periodic tokens

D.Batch tokens

AnswerB

Orphan tokens have no parent, so they survive independently of the pipeline token's expiry or revocation. This satisfies the requirement that job tokens remain unaffected by the pipeline token's lifecycle, unlike child tokens, which are revoked with their parent.

Why this answer

Orphan tokens are the correct choice because they allow the CI/CD pipeline to create child tokens that are not tied to the parent token's lifecycle. When a periodic token creates an orphan token, the child token remains valid even if the parent token is revoked or expires, ensuring deployment jobs are independent and not affected by the pipeline token's lifecycle.

Exam trap

HashiCorp often tests the misconception that all child tokens are automatically orphaned or that periodic tokens can create independent child tokens, but the trap is that only explicitly orphaned tokens break the parent-child chain, while default token creation maintains a hierarchical dependency.

How to eliminate wrong answers

Option A is wrong because service tokens with explicit max TTL are still parent-child tokens; if the parent token is revoked, the child token is also revoked, so the jobs would be affected by the pipeline token's lifecycle. Option C is wrong because periodic tokens are used for long-lived, renewable tokens with a fixed lifetime, not for creating short-lived tokens for jobs; they also create parent-child relationships by default. Option D is wrong because batch tokens are lightweight, non-renewable tokens that cannot create child tokens at all, so they cannot be used to generate tokens for deployment jobs.

Full explanation →

255

MCQmedium

A developer wants to encrypt a password before storing it in a database. The encryption must be deterministic so that the same plaintext always produces the same ciphertext. Which encryption mode should be used in the transit secrets engine?

A.chacha20-poly1305

B.convergent-encryption

C.aes128-gcm96

D.aes-gcm

E.padding

AnswerB

Convergent encryption derives the nonce from the plaintext and context, making output deterministic.

Why this answer

The transit secrets engine in Vault supports convergent encryption, which is a deterministic encryption mode where the same plaintext and context always produce the same ciphertext. This is achieved by using the plaintext itself as part of the encryption key derivation, ensuring repeatable output. The question specifically requires deterministic encryption, making convergent encryption the correct choice.

Exam trap

HashiCorp often tests the misconception that any AES-GCM mode is deterministic, but in practice, AES-GCM requires a unique nonce for each encryption, making it non-deterministic unless combined with convergent encryption or a fixed nonce (which would break security guarantees).

How to eliminate wrong answers

Option A is wrong because chacha20-poly1305 is an authenticated encryption algorithm, not a mode that provides deterministic output; it uses a nonce, so the same plaintext produces different ciphertexts each time. Option C is wrong because aes128-gcm96 is an AEAD algorithm that requires a unique nonce for each encryption, making it non-deterministic. Option D is wrong because aes-gcm is a generic algorithm that, without a fixed nonce, produces different ciphertexts for the same plaintext; Vault's transit engine does not support deterministic AES-GCM without convergent encryption.

Option E is wrong because padding is a data transformation technique, not an encryption mode, and does not provide deterministic encryption by itself.

Full explanation →

256

MCQeasy

Which of the following best describes a Vault lease?

A.A permission to access a path.

B.A time-limited agreement that governs the lifecycle of a secret.

C.A contract to use a secret for a certain duration.

D.The actual secret value.

AnswerB

Vault leases bind every secret to a defined TTL and renewal or revocation cycle, so credentials expire automatically rather than persisting indefinitely. This time-bound lifecycle directly satisfies the question's focus on a time-limited agreement governing secrets.

Why this answer

A Vault lease is a time-bound agreement that governs the lifecycle of a secret, including its validity period, renewal, and revocation. When a secret is read from Vault, it is returned with a lease ID and a lease duration (TTL), after which the secret is automatically revoked unless renewed. This ensures that secrets are not valid indefinitely, reducing the risk of exposure.

Exam trap

HashiCorp often tests the distinction between the lease itself (the lifecycle management agreement) and the secret value, leading candidates to mistakenly choose Option D because they think the lease is the actual secret.

How to eliminate wrong answers

Option A is wrong because a Vault lease is not merely a permission to access a path; permissions are defined by policies attached to tokens or auth methods, not by leases. Option C is wrong because a lease is not a contract to use a secret for a certain duration; it is a technical mechanism that automatically manages the secret's lifecycle, including renewal and revocation, not a contractual agreement. Option D is wrong because the actual secret value is the data returned by Vault (e.g., a password or API key), while the lease is the metadata (lease ID, TTL, renewable flag) that controls that secret's lifecycle.

Full explanation →

257

MCQhard

A Vault administrator is writing a policy that uses a templated path to allow each user to access their own secrets. The policy is: path "secret/data/users/{{identity.entity.id}}/*" { capabilities = ["read", "list"] } When a user with entity ID "1234" attempts to read 'secret/data/users/1234/profile', they receive a permission denied error. The secret exists, and the user's token has this policy attached. What is the most likely reason for the failure?

A.Templated policies are only supported in Vault Enterprise, not in Vault Open Source.

B.The policy path uses 'identity.entity.id' but the token is not associated with an entity, so the template cannot be resolved.

C.The template variable 'identity.entity.id' is incorrect; it should be 'identity.entity.id' without the curly braces.

D.The policy must use 'identity.entity.name' instead of 'identity.entity.id' to match the user's entity ID.

AnswerB

Templated policies rely on the token being associated with an entity. If the token is not linked to an entity (e.g., a token created without an entity), the template variable cannot be resolved, and the path becomes invalid, resulting in a permission denied error. The user must have an entity and the token must be tied to it.

Why this answer

Templated policies require the token to be associated with an entity. If the token lacks an entity association, the template variable cannot be resolved, and Vault denies access. The user must have an entity in the identity store, and the token must be linked to that entity.

This is a common oversight when using templated policies.

Exam trap

The trap here is assuming that templated policies work with any token, when in fact they require the token to be associated with an entity for the template to resolve.

Full explanation →

258

MCQhard

A Vault administrator manages a high-availability cluster with Integrated Storage (Raft) and three nodes. The cluster is healthy with one active node and two standby nodes. The administrator needs to perform a planned upgrade of the active node. Before stepping down, the administrator wants to ensure that the standby nodes are ready to take over and that no data loss occurs. Which action should the administrator take to safely transfer leadership?

A.Stop the Vault service on the active node and wait for the standby nodes to detect the failure and elect a new leader automatically.

B.Manually update the cluster configuration to designate a specific standby node as the new leader using the vault operator raft configuration command.

C.Run vault operator step-down on the active node to trigger a leader election and transfer leadership to a standby node.

D.Use the vault operator raft snapshot save command to create a snapshot, then restore it on a standby node to promote it to active.

AnswerC

The vault operator step-down command forces the active node to give up leadership, triggering a new election among the standby nodes. This is the recommended way to safely transfer leadership during maintenance. The command ensures that the active node finishes in-flight requests and that the new leader is elected from a healthy standby. This minimizes downtime and maintains cluster availability.

Why this answer

In a Raft cluster, leadership is transferred gracefully using vault operator step-down. This command causes the active node to stop accepting writes, complete pending operations, and trigger an election. Standby nodes then elect a new leader.

This process avoids abrupt termination and ensures cluster availability. Other methods like stopping the service or restoring snapshots are disruptive and not designed for planned maintenance.

Exam trap

The trap here is thinking that stopping the Vault service or restoring a snapshot is a safe way to transfer leadership, when the graceful method is vault operator step-down.

Full explanation →

259

MCQmedium

An operator manages a Vault cluster where several auth methods are enabled at different paths. A developer reports that logging in with the Kubernetes auth method succeeds, but the resulting token has no permissions. The operator confirms the role exists and the service account JWT is valid. Which configuration element is most likely missing?

A.The Kubernetes auth method was enabled at a non-default path, so the policies attached to the role are unreachable.

B.The Vault server's service account lacks RBAC permission to read the TokenReview API in the Kubernetes cluster.

C.The Vault token TTL is shorter than the Kubernetes service account token lifetime, causing immediate expiry.

D.A bound_service_account_names or bound_service_account_namespaces restriction that does not match the workload, or a role that grants no policies.

AnswerD

A Kubernetes auth role must bind the incoming service account JWT to expected service account names and namespaces; if those bindings do not match the pod, login is rejected. Conversely, if the bindings match but the role lists no token_policies, Vault issues a token with only default policy rights, producing the reported no-permissions symptom even though authentication appears to succeed.

Why this answer

A successful Kubernetes login that yields an unprivileged token points to role configuration: either the service account bindings silently exclude the workload, or the role carries no token_policies. Verifying bound_service_account_names, bound_service_account_namespaces, and the role's policy list resolves both variants of the problem.

Exam trap

The trap here is assuming a successful login implies correct authorization, when a role can authenticate a workload yet attach no policies to the issued token.

Full explanation →

260

Multi-Selectmedium

A CI pipeline authenticates to Vault using the AppRole auth method and needs to obtain a token non-interactively. The pipeline has a role_id and a secret_id but cannot use an interactive login prompt. Which TWO methods can the pipeline use to authenticate and receive a token? (Choose two.)

Select 2 answers

A.`vault secrets enable -path=approle approle`

B.`vault login -method=approle role_id=<id> secret_id=<sid>`

C.`vault auth enable approle`

D.`vault write auth/approle/login role_id=<id> secret_id=<sid>`

E.`vault operator init -key-shares=1 -key-threshold=1`

AnswersB, D

The vault login command supports the -method flag, and approle is a registered auth method that accepts role_id and secret_id as parameters. This produces a token and stores it in the local token helper, which is convenient for subsequent CLI calls. It is a valid non-interactive path for the CI pipeline to authenticate and receive a token.

Why this answer

AppRole is designed for machine authentication, and both the direct write to auth/approle/login and the vault login -method=approle invocation accept role_id and secret_id and return a client token. The login subcommand additionally stores the token in the local token helper for later CLI calls. The remaining options are administrative or cluster operations that do not authenticate a workload, and one of them targets a secrets engine path rather than the AppRole auth method.

Exam trap

The trap here is confusing the one-time administrative step of enabling the AppRole auth method with the per-run authentication call that actually returns a token to the pipeline.

Full explanation →

261

MCQmedium

A security architect is designing a service that uses the Vault transit engine to encrypt records. The architect wants to limit the blast radius if an application token is stolen. The application only ever writes new encrypted records and never needs to read them back. Which transit policy capability set should be granted to the application token?

A.encrypt only on the transit key path

B.read on the transit key path and encrypt capability

C.encrypt and decrypt on the transit key path

D.sudo on the transit key path

AnswerA

Restricting the token to encrypt means a stolen token can only produce new ciphertext, not reveal existing plaintext. This directly limits blast radius for a write-only application. Vault policies are capability based, so listing encrypt without decrypt on the key path enforces this separation cleanly.

Why this answer

Vault policies separate capabilities per path, so a write-only application should receive only encrypt on the specific transit key. Withholding decrypt means compromised credentials cannot expose stored plaintext. Least privilege for encryption as a service is expressed by granting exactly the capabilities the client needs on the narrowest path, rather than bundling decrypt or administrative capabilities.

Exam trap

The trap here is treating encrypt and decrypt as an inseparable pair, when Vault policies allow granting only encrypt for write-only clients.

Full explanation →

262

MCQeasy

A company uses Vault to manage secrets for multiple applications. A new security policy requires that all human users authenticate using LDAP and that all machine-to-machine authentication uses AppRole. An administrator has configured an LDAP auth method at 'ldap/' and an AppRole at 'approle/'. The administrator creates a role 'web-app' with a secret ID TTL of 30 days and a token TTL of 1 hour. After deploying the web application, the application successfully logs in using the AppRole role ID and secret ID, retrieves a token, and reads secrets. However, after 1 hour, the application begins receiving 'permission denied' errors when trying to read secrets. The application logs show that it is using the same token obtained during initial login. Which action should the administrator take to resolve this issue?

A.Increase the secret ID TTL to 60 days so the application can re-authenticate less frequently.

B.Set the token TTL to 0 (unlimited) so the token never expires.

C.Have the application re-authenticate with the AppRole using the same secret ID after the token expires.

D.Configure the application to renew the token before it expires by calling the 'auth/token/renew' endpoint.

AnswerD

Renewing via `auth/token/renew` extends the existing token's lease without requiring re-authentication, matching the one-hour token TTL that caused the permission denied errors. The application must call this endpoint before expiry, since the token is renewable by default and the AppRole secret ID TTL of 30 days is irrelevant here.

Why this answer

The application's token has a TTL of 1 hour, and once it expires, Vault will reject any further requests using that token. The application must renew the token before it expires by calling the 'auth/token/renew' endpoint, which extends the token's lifetime (up to the maximum TTL configured on the role). This is the standard pattern for long-running applications using short-lived tokens.

Exam trap

HashiCorp often tests the distinction between secret ID TTL and token TTL, leading candidates to confuse the two and incorrectly choose options that modify the secret ID or re-authenticate instead of renewing the token.

How to eliminate wrong answers

Option A is wrong because increasing the secret ID TTL does not affect the token's lifetime; the secret ID is only used during initial authentication to obtain a token, and the token's TTL is independent. Option B is wrong because setting the token TTL to 0 (unlimited) violates the security policy requiring short-lived tokens and is not a recommended practice; Vault's default maximum TTL also limits this. Option C is wrong because re-authenticating with the same secret ID after the token expires would work, but it is inefficient and unnecessary; the application should instead renew the existing token to avoid the overhead of re-authentication and to maintain a continuous session.

Full explanation →

263

MCQmedium

An administrator wants to mount the AWS secrets engine at 'aws' path using the API. Which request is correct?

A.PUT /v1/sys/mounts/aws with body {"type":"aws"}

B.POST /v1/sys/auth/aws with body {"type":"aws"}

C.POST /v1/sys/mounts/aws with body {"type":"aws"}

D.POST /v1/sys/mounts/aws with body {"type":"aws-secrets"}

AnswerC

Mounting via the API requires POST to /v1/sys/mounts/aws, with the engine type supplied in the JSON body as {"type":"aws"}. This satisfies the stem's constraint of mounting the AWS secrets engine at the 'aws' path, since sys/mounts handles enablement and the path segment defines the mount point.

Why this answer

Mounting a secrets engine in Vault is performed via a POST request to the `/v1/sys/mounts/<path>` endpoint with a JSON body containing the `"type"` field set to the engine's type identifier. For the AWS secrets engine, the type is `"aws"`, and the path is specified in the URL as `aws`. The POST method is required for creating a new mount, while PUT is used for tuning an existing mount.

Exam trap

HashiCorp often tests the distinction between POST (create) and PUT (update/tune) for Vault API endpoints, and candidates confuse the mount path with auth method paths or use an incorrect type string like 'aws-secrets' instead of the official 'aws'.

How to eliminate wrong answers

Option A is wrong because it uses the PUT method, which is reserved for tuning an existing mount (e.g., updating configuration or adjusting default lease TTLs), not for creating a new mount; creating a mount requires POST. Option B is wrong because it targets the `/v1/sys/auth/aws` endpoint, which is used for enabling an auth method (like LDAP or AppRole), not for mounting a secrets engine; secrets engines are mounted under `/v1/sys/mounts/`. Option D is wrong because it specifies `"type":"aws-secrets"` in the body, but the correct type identifier for the AWS secrets engine is `"aws"`; `"aws-secrets"` is not a valid Vault engine type.

Full explanation →

264

Drag & Dropmedium

Drag and drop the steps to configure Vault's database secrets engine with PostgreSQL into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence for configuring Vault's database secrets engine with PostgreSQL is: first enable the secrets engine, then configure the database connection, then create a role that defines the credential generation parameters, then generate credentials, and finally revoke the lease when done. This order ensures all prerequisites are met at each step.

Full explanation →

265

MCQmedium

A company uses OIDC auth for human users. After the OIDC provider rotates its signing keys, some users report that they cannot authenticate. The Vault logs show that the OIDC response validation fails. What is the most likely cause?

A.The OIDC role is misconfigured

B.The client's OIDC token is expired

C.The OIDC provider is down

D.Vault's OIDC cache has old JWKS keys

AnswerD

Vault caches the provider's JWKS to validate OIDC ID token signatures, and that cache persists until its TTL expires. After key rotation, cached keys no longer match the token's `kid`, so signature validation fails until Vault refetches the JWKS. This directly explains the validation failures affecting some users immediately after rotation.

Why this answer

When an OIDC provider rotates its signing keys, Vault must fetch the new JWKS (JSON Web Key Set) to validate the token signature. Vault caches the JWKS for performance, and if the cache still holds the old keys, signature validation fails for tokens signed with the new key. This matches the symptom of OIDC response validation failing immediately after a key rotation.

Exam trap

HashiCorp often tests the distinction between token expiration (which is a time-based claim validation) and key rotation (which is a cryptographic signature validation failure), leading candidates to incorrectly choose the expired token option when the real issue is stale cached keys.

How to eliminate wrong answers

Option A is wrong because the OIDC role configuration (e.g., allowed redirect URIs, bound claims) does not change when the provider rotates keys; a misconfigured role would cause consistent failures, not a sudden failure after key rotation. Option B is wrong because an expired token would produce a different error (e.g., 'token is expired' or 'token used before issued'), not a generic OIDC response validation failure, and the issue is tied to key rotation timing. Option C is wrong because if the OIDC provider were down, Vault would not be able to fetch the JWKS at all, leading to a connection timeout or discovery failure, not a signature validation failure on a response that was received.

Full explanation →

266

MCQmedium

A developer wants to ensure that their application automatically renews its secret leases before expiration. Which approach is recommended?

A.Set the lease TTL to infinite.

B.Use a cron job to call vault lease renew periodically.

C.Use Vault agent with a template and renew capability.

D.Use periodic tokens with auto-renewal.

AnswerC

Vault Agent runs alongside the application, authenticates automatically, and its template stanza renders secrets to a file while renewing the lease before expiry. This satisfies the requirement for automatic renewal without embedding renewal logic in application code.

Why this answer

Vault Agent's template and renew capability is the recommended approach because it automatically manages the lifecycle of dynamic secrets, including renewing leases before they expire. Vault Agent runs as a sidecar or daemon and uses its built-in renewer to periodically extend the lease TTL, ensuring the application always has a valid secret without manual intervention or external scheduling.

Exam trap

HashiCorp often tests the distinction between renewing a token (which can use periodic tokens) versus renewing a secret lease (which requires Vault Agent or explicit lease renewal), causing candidates to mistakenly choose periodic tokens for secret lease renewal.

How to eliminate wrong answers

Option A is wrong because setting the lease TTL to infinite is not supported by Vault; leases always have a finite TTL defined by the secret engine's default or maximum, and infinite TTL would violate security best practices by never forcing rotation. Option B is wrong because using a cron job to call vault lease renew is brittle and not recommended; it introduces a single point of failure, lacks awareness of lease expiration timing, and does not handle Vault Agent's automatic renewal or template rendering. Option D is wrong because periodic tokens with auto-renewal are used for long-lived tokens, not for renewing secret leases; secret leases (e.g., database credentials, AWS IAM keys) require explicit lease renewal via the /sys/leases/renew endpoint, and periodic tokens do not automatically renew those leases.

Full explanation →

267

MCQmedium

A platform team stores application configuration and credentials in a KV v2 secrets engine mounted at 'kv/'. A developer deleted version 3 of the secret 'kv/app/db' by running 'vault kv delete kv/app/db'. Two days later, the security team asks the developer to recover that version because it contained a valid certificate. The developer runs 'vault kv get -version=3 kv/app/db' and receives an error that the version has been deleted. What must the developer do to recover version 3?

A.Run 'vault kv rollback -version=3 kv/app/db' to revert the secret to version 3.

B.Run 'vault kv metadata get kv/app/db' to retrieve the deleted version from metadata.

C.Run 'vault kv undelete -versions=3 kv/app/db' to restore the deleted version.

D.Run 'vault kv patch kv/app/db' to restore the missing version from the patch history.

AnswerC

The 'vault kv undelete' command restores soft-deleted versions of a KV v2 secret. Because a delete operation on KV v2 only marks the version as deleted rather than destroying it, running undelete with the specific version number makes version 3 readable again via 'vault kv get -version=3'. This is the designed recovery path for accidental deletes within the retention window.

Why this answer

In KV v2, a delete operation is a soft delete that marks a version as deleted but keeps the data until it is destroyed or removed by the 'delete_version_after' setting. The 'vault kv undelete' command reverses that soft delete for the specified versions, making the data readable again. Rollback and patch both create new versions instead of restoring the old one, and metadata get only returns metadata.

Exam trap

The trap here is confusing soft delete with permanent destruction, leading to the belief that a deleted KV v2 version can only be recovered by writing the data again or that undelete is unavailable.

Full explanation →

268

MCQmedium

A DevOps team is deploying Vault in a Kubernetes cluster. They want to ensure that when a pod starts, it can obtain a short-lived Vault token without human intervention. Which Vault architecture component should they use?

A.Audit Device

B.Storage Backend (Consul)

C.Vault Agent sidecar

D.Vault CLI with token helper

AnswerC

The Vault Agent sidecar runs alongside the application pod, authenticates via Kubernetes service account and writes a short-lived Vault token to a shared volume. This satisfies the requirement for automatic, non-interactive token acquisition at pod startup.

Why this answer

The Vault Agent sidecar runs alongside the application container in the same pod, automatically authenticating to Vault and retrieving a short-lived token. This eliminates the need for human intervention by handling the authentication lifecycle (e.g., using Kubernetes auth method) and renewing or re-authenticating as needed, ensuring the application always has a valid token.

Exam trap

HashiCorp often tests the misconception that a storage backend or audit device can provide authentication tokens, when in fact they serve entirely different roles in Vault's architecture.

How to eliminate wrong answers

Option A is wrong because an Audit Device logs all requests and responses to Vault for security monitoring, but it does not provide tokens or handle authentication for pods. Option B is wrong because the Storage Backend (e.g., Consul) is used for persisting Vault's encrypted data and cluster state, not for issuing tokens to applications. Option D is wrong because the Vault CLI with a token helper is an interactive tool requiring a human to authenticate and manage tokens, which does not meet the requirement for automated, non-interactive token retrieval at pod startup.

Full explanation →

269

MCQmedium

A Vault administrator wants to allow users to authenticate using their corporate Active Directory credentials. Which authentication method should they enable?

A.Okta

B.AppRole

C.Userpass

D.LDAP

AnswerD

LDAP binds Vault directly to Active Directory, letting users authenticate with their existing corporate domain credentials rather than separate Vault tokens. This satisfies the stem's requirement for Active Directory-backed authentication, since LDAP queries AD as the identity source. Microsoft Entra ID would not meet the on-premises AD constraint here.

Why this answer

LDAP (Lightweight Directory Access Protocol) is the correct choice because it enables Vault to authenticate users against an external corporate Active Directory (AD) server. Vault's LDAP auth method binds to the AD directory using a service account, then validates user credentials via a simple bind operation, allowing seamless integration with existing corporate identity infrastructure.

Exam trap

HashiCorp often tests the misconception that any external identity provider (like Okta) is the default choice for AD integration, but the question specifically asks for the authentication method that directly uses corporate Active Directory credentials, which is LDAP.

How to eliminate wrong answers

Option A is wrong because Okta is a third-party identity provider (IdP) that uses OIDC/SAML, not a direct authentication method for Active Directory; it would require additional configuration and is not the native AD integration method. Option B is wrong because AppRole is a machine-to-machine authentication method that uses role IDs and secret IDs, designed for applications and automation, not for human users with corporate credentials. Option C is wrong because Userpass is a built-in Vault auth method that stores usernames and passwords locally within Vault's internal storage, not against an external corporate Active Directory.

Full explanation →

270

MCQeasy

A cloud operations team needs Vault to issue short-lived credentials for an external MySQL database. They want Vault to create and revoke users dynamically based on a role. Which secrets engine should they enable and configure?

A.The PKI secrets engine

B.The Transit secrets engine

C.The KV v2 secrets engine

D.The database secrets engine

AnswerD

The database secrets engine generates dynamic database credentials by connecting to the database and creating users based on role configuration. It supports creation and revocation statements, lease management, and multiple database plugins including MySQL. This matches the requirement for short-lived, dynamically generated credentials for an external MySQL database.

Why this answer

Dynamic database credentials are the core use case of the database secrets engine. It connects to the database with configured credentials, creates users per role using creation statements, and revokes them when the lease expires. KV v2 stores static secrets, Transit performs cryptographic operations, and PKI issues certificates, so none of those provide dynamic database users.

Exam trap

The trap here is assuming that storing a database password in KV v2 is equivalent to dynamic credential generation, when it only provides static secrets.

Full explanation →

271

Multi-Selectmedium

A company is deploying Vault in a Kubernetes environment. Which three components are essential for a production-ready Vault on Kubernetes? (Choose three.)

Select 3 answers

A.A ConfigMap to store Vault configuration including unseal keys.

B.A persistent volume claim for each Vault pod for storage.

C.A service account with appropriate RBAC to interact with the Kubernetes API.

D.An Ingress controller to expose Vault externally.

E.A StatefulSet to manage Vault pods with stable network identities.

AnswersB, C, E

Integrated Storage persists Raft data locally, so each Vault pod needs its own persistent volume claim. Without it, pod restarts lose cluster state, breaking production durability and quorum. The claim satisfies the requirement for durable, per-pod storage.

Why this answer

Option B is correct because Vault requires durable storage for its data (the integrated storage/Raft backend or a configured storage stanza), and in Kubernetes a PersistentVolumeClaim per Vault pod ensures data survives pod restarts and rescheduling. Option C is correct because Vault's Kubernetes auth method and auto-unseal/agent injector workflows need a ServiceAccount bound to RBAC roles so Vault can authenticate to and call the Kubernetes API (e.g., TokenReview, SubjectAccessReview). Option E is correct because Vault's Raft integrated storage requires stable pod identities and ordered startup, which a StatefulSet provides via stable network IDs (pod-0, pod-1) and persistent volume templates.

Option A is not correct because unseal keys must never be stored in a ConfigMap; ConfigMaps are for non-sensitive configuration, and unseal keys are highly sensitive secrets handled via manual unseal, auto-unseal with a KMS, or secure secret stores. Option D is not correct because an Ingress controller is only needed to expose Vault externally and is not essential for a production-ready Vault cluster, which can be accessed via internal Services or port-forwarding.

Exam trap

HashiCorp often tests the misconception that unseal keys can be stored in a ConfigMap for convenience, but the exam expects you to recognize that this violates Vault's security model and is never production-ready.

Full explanation →

272

Multi-Selectmedium

A company uses Vault transit to encrypt secrets. They want to periodically rotate the encryption key to comply with compliance requirements. Which TWO actions should be taken? (Choose two.)

Select 2 answers

A.Update the min_decryption_version to the newest version immediately.

B.Export the key and re-encrypt all data manually.

C.Rewrap all existing ciphertext with the new key version.

D.Delete old key versions after rotation.

E.Rotate the key using Vault's key rotation endpoint.

AnswersC, E

Rewrapping re-encrypts existing ciphertext under the new key version without exposing plaintext, satisfying the compliance requirement that data previously encrypted with the retired version remains readable. Vault's `rewrap` endpoint decrypts with the old version and re-encrypts with the latest, so historical ciphertext stays accessible after rotation.

Why this answer

Option E is correct because Vault's transit secrets engine supports key rotation via the `rotate` endpoint (e.g., `vault write -f transit/keys/<key_name>/rotate`), which creates a new key version while retaining older versions for decrypting existing ciphertext. Option C is correct because after rotation, existing ciphertext still references older key versions, so `rewrap` (e.g., `vault write transit/rewrap/<key_name> ciphertext=<...>`) re-encrypts the data under the latest key version without exposing the plaintext, satisfying periodic rotation compliance. Option A is wrong because immediately setting `min_decryption_version` to the newest version would make ciphertext encrypted with older versions undecryptable, breaking access to existing data.

Option B is wrong because exporting the key defeats the purpose of Vault transit (keys never leave Vault) and manual re-encryption is unnecessary since `rewrap` handles it. Option D is wrong because deleting old key versions would render existing ciphertext undecryptable and is not required for rotation.

Exam trap

HashiCorp often tests the misconception that you must delete old key versions immediately after rotation, but the correct practice is to keep them until all ciphertext is rewrapped to avoid data loss.

Full explanation →

273

MCQmedium

An administrator is configuring a new PKI secrets engine at pki/ to issue TLS certificates for internal services. The security team requires that the intermediate CA certificate and its private key are generated inside Vault, and that the root CA remains offline. Which command should the administrator run to create the intermediate CA and generate a CSR for signing by the offline root?

A.vault write pki/root/generate/internal common_name="Internal Intermediate CA"

B.vault write pki/intermediate/set-signed certificate=@intermediate.crt

C.vault write pki/intermediate/generate/exported common_name="Internal Intermediate CA"

D.vault write pki/intermediate/generate/internal common_name="Internal Intermediate CA"

AnswerD

The generate/internal endpoint creates a new private key and CSR inside Vault, storing the private key securely and returning the CSR for the offline root to sign. This matches the requirement that the intermediate key never leaves Vault, enabling the root CA to remain air-gapped while still establishing a chain of trust.

Why this answer

Generating the intermediate inside Vault with the internal variant keeps the private key within Vault's storage barrier while returning only a CSR, which the offline root can sign. Importing the signed certificate afterward completes the chain. This workflow satisfies both the key-containment policy and the offline-root requirement without ever exposing the intermediate private key.

Exam trap

The trap here is assuming that any generate endpoint produces a CSR, when only the internal variant keeps the private key inside Vault while the exported variant deliberately returns it.

Full explanation →

274

Multi-Selectmedium

A Vault administrator is reviewing token behaviors and needs to understand which actions are possible with a token's accessor. Which two statements about token accessors are true? (Choose two.)

Select 2 answers

A.An accessor can be used to create child tokens with the same policies.

B.An accessor can be used to revoke the token.

C.An accessor can be used to renew the token if the token is renewable.

D.An accessor can be used to authenticate to Vault and access secrets.

E.An accessor can be used to look up the token's properties, such as its policies and TTL.

AnswersB, E

Vault allows revocation of a token using its accessor. This is a powerful feature for administrators who need to revoke a token without knowing the token string itself. For example, if a token is leaked, an administrator can use the accessor to revoke it, provided they have the necessary permissions. The accessor provides a way to manage tokens without exposing the token value, balancing security and control.

Why this answer

Token accessors provide a way to manage tokens without exposing the token string. They can be used to look up a token's metadata and to revoke the token. They cannot be used to renew the token, create child tokens, or authenticate to Vault.

This design allows administrators to audit and revoke tokens while minimizing the risk of token leakage. The correct statements are that an accessor can be used for lookup and for revocation.

Exam trap

The trap here is assuming that an accessor grants the same capabilities as the token itself, but an accessor is only for lookup and revocation, not for authentication or renewal.

Full explanation →

275

Matchingmedium

Match each Vault auth method to its authentication mechanism.

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

Concepts

Matches

RoleID and SecretID

Username/password against LDAP server

Static or periodic tokens

Service account token

JSON Web Token / OpenID Connect

Why these pairings

Token auth uses a single-use token; Userpass uses username/password; AppRole uses RoleID/SecretID. Common confusions involve swapping these definitions.

Full explanation →

276

MCQmedium

A token with a policy granting 'write' on 'secret/team-alpha/*' is unable to write to 'secret/team-alpha/db-creds' in a KV v2 engine. What is the most likely cause?

A.The token is not a root token

B.The token's TTL has expired

C.The token has a conflicting policy from a parent token

D.The policy path should be 'secret/data/team-alpha/*' for KV v2

AnswerD

KV v2 inserts a `data/` segment into every API path, so a policy written against the v1 layout never matches the request. The token's `secret/team-alpha/*` rule therefore grants nothing on `secret/data/team-alpha/db-creds`, producing the permission denial. Rewriting the path as `secret/data/team-alpha/*` restores the required write capability.

Why this answer

D is correct because in Vault's KV v2 engine, the actual data path is prefixed with 'data/' after the mount path. A policy granting 'write' on 'secret/team-alpha/*' targets the metadata path, not the data path. To write secrets, the policy must use 'secret/data/team-alpha/*' to match the correct API endpoint.

Exam trap

The trap here is that candidates assume the policy path should match the mount path directly, overlooking the mandatory 'data/' prefix in KV v2, which HashiCorp Vault tests to ensure understanding of Vault's path structure differences between engines.

How to eliminate wrong answers

Option A is wrong because a root token is not required to write to a KV v2 path; a properly scoped policy with the correct path is sufficient. Option B is wrong because an expired TTL would cause a permission denied error due to token invalidity, not a path mismatch, and the question states the token is unable to write, not that it is expired. Option C is wrong because conflicting policies from a parent token would result in a denial based on the most restrictive policy, but the core issue here is the incorrect path, not a policy conflict.

Full explanation →

277

Multi-Selectmedium

An administrator is reviewing Vault token policies and wants to ensure that tokens created by a specific application cannot be renewed and have a fixed lifetime. Which two token configurations should be applied?

Select 2 answers

A.Set max_ttl on the role to a very large value.

B.Set renewable to false.

C.Set ttl on the token to 0.

D.Set explicit_max_ttl on the token to match the desired TTL.

E.Set no_default_policy to true.

AnswersB, D

Setting renewable to false prevents any client from extending the token's life via renewal, so the token expires at its initial TTL. This directly satisfies the fixed-lifetime constraint, since no renewal path exists to push expiry beyond the issued duration.

Why this answer

Option B is correct because setting renewable to false on the token (or its role) prevents the token from being renewed, directly satisfying the requirement that tokens cannot be renewed. Option D is correct because setting explicit_max_ttl to match the desired TTL caps the token's total lifetime at a fixed value, ensuring a fixed lifetime even if renewal were otherwise possible. Together, renewable=false and explicit_max_ttl enforce both non-renewability and a hard expiration.

Option A is wrong because a very large max_ttl would extend, not fix, the token's lifetime. Option C is wrong because a ttl of 0 typically means no expiration or default behavior, not a fixed lifetime. Option E is wrong because no_default_policy only controls whether the default policy is attached, which is unrelated to renewal or lifetime.

Exam trap

In HashiCorp Vault, candidates often confuse `ttl` with `explicit_max_ttl` on token roles. Setting `ttl` to 0 means the token uses a system default, not a fixed lifetime, while `explicit_max_ttl` enforces an absolute ceiling that cannot be overridden by renewal.

Full explanation →

278

MCQhard

A company deploys Vault in a production environment with three nodes using Integrated Storage (Raft). They have configured Performance Replication to a secondary datacenter. The primary datacenter experiences a complete outage. After restoring the primary, they promote the secondary to primary. However, they notice that some secrets written to the primary just before the outage are missing in the secondary. The replication status shows no errors. What is the most likely cause and correct action?

A.Accept the data loss and continue with the secondary as primary

B.Restore the primary from backup to recover missing secrets

C.Failback to the original primary after restoring it

D.Re-promote the original primary and use it as the new primary

AnswerA

Performance Replication is asynchronous, so secrets written to the primary immediately before the outage may not have replicated. With no errors reported, the secondary's data is simply behind; that unreplicated data cannot be recovered, so accepting the loss and continuing is the only viable action.

Why this answer

Performance Replication in Vault is asynchronous, meaning there is no guarantee that all writes to the primary are replicated to the secondary before a failure. When the primary experiences a complete outage, any secrets written just before the outage that had not yet been acknowledged by the secondary are permanently lost. Since the replication status shows no errors, the system is consistent up to the last replicated point, and the only correct action is to accept the data loss and continue with the promoted secondary as the new primary.

Exam trap

The trap here is that candidates assume Vault's Performance Replication guarantees zero data loss because the replication status shows no errors, but they fail to recognize that it is asynchronous, allowing a small window of unreplicated writes just before the outage.

How to eliminate wrong answers

Option B is wrong because restoring the primary from backup would reintroduce stale data and potentially cause conflicts with the promoted secondary, and it does not recover the missing secrets that were never replicated. Option C is wrong because failing back to the original primary after restoring it would require the original primary to catch up with the secondary, but the missing secrets were never on the secondary, so they cannot be recovered through failback. Option D is wrong because re-promoting the original primary as the new primary would ignore the fact that the secondary has already been promoted and is now the authoritative source; this would cause a split-brain scenario and data inconsistency.

Full explanation →

279

MCQmedium

A team is adopting Vault and wants to organize secrets by application and environment (e.g., production, staging). What is the best practice for secrets engine path naming?

A.Use hierarchical paths like 'app/env/secret'

B.Use a single path like 'secrets/' for simplicity

C.Use the same path for all applications but separate with prefixes like 'app1-'

D.Use random UUIDs to avoid guessing

AnswerA

Hierarchical paths such as 'app/env/secret' map directly onto Vault's path-based policy model, letting each application-environment pair receive a distinct ACL boundary. This satisfies the stem's requirement to organise secrets by both application and environment, since policies and audit logs can then be scoped precisely to, say, 'payments/production/*' without overlapping other environments.

Why this answer

Hierarchical paths like 'app/env/secret' are the best practice because they allow Vault's ACL policies to apply fine-grained access control at each level of the path. This structure maps directly to the organization's application and environment boundaries, enabling least-privilege access without complex policy rules. It also simplifies secret rotation and auditing by keeping related secrets logically grouped.

Exam trap

HashiCorp often tests the misconception that flat or prefix-based naming is simpler and therefore better, but the trap is that Vault's ACL engine is path-based and hierarchical paths are required for proper policy isolation and least-privilege access control.

How to eliminate wrong answers

Option B is wrong because using a single flat path like 'secrets/' prevents any granular access control; all policies would apply to the entire path, violating the principle of least privilege. Option C is wrong because using prefixes like 'app1-' on a shared path still forces all secrets under one policy scope, making it impossible to restrict access to specific applications or environments without cumbersome regex-based policies. Option D is wrong because random UUIDs make secrets unmanageable and impossible to organize by application or environment; they also break the human-readable path structure that Vault policies rely on for clear, maintainable access rules.

Full explanation →

280

MCQmedium

A Vault administrator wants to configure a role for dynamic secrets with a default TTL of 1 hour and a max TTL of 4 hours. They also want to allow renewal but only up to the max TTL. Which configuration achieves this?

A.default_ttl=1h, max_ttl=4h, renewable=false

B.default_ttl=4h, max_ttl=1h, renewable=true

C.default_ttl=1h, max_ttl=4h, renewable=true

D.default_ttl=1h, max_ttl=4h, renewable=true, ttl=1h

AnswerC

Setting default_ttl=1h and max_ttl=4h with renewable=true lets tokens be renewed repeatedly, but Vault caps each renewal at the max_ttl ceiling, so the lease cannot outlive four hours. This satisfies both the one-hour default and the four-hour renewal limit.

Why this answer

It sets the default TTL to 1 hour, the maximum TTL to 4 hours, and enables renewal (renewable=true). In Vault, dynamic secret leases can be renewed up to the max_ttl, so with this configuration the initial lease is 1 hour, and each renewal extends the lease until the total lifetime reaches 4 hours, after which no further renewals are allowed.

Exam trap

A common trap is confusing the order of default_ttl and max_ttl. Remember that default_ttl sets the initial lease duration, while max_ttl limits the total lifetime including renewals. Also, renewable=true must be set to allow renewal up to the max_ttl.

How to eliminate wrong answers

Option A is wrong because renewable=false prevents any renewal, so the lease would expire after 1 hour and cannot be extended to the max TTL of 4 hours. Option B is wrong because it sets default_ttl=4h and max_ttl=1h, which is invalid—the default TTL cannot exceed the max TTL; Vault would reject this configuration or cap the default to the max. Option D is wrong because it includes an extra ttl=1h parameter, which is not a valid role parameter for dynamic secrets (the correct parameters are default_ttl and max_ttl); adding an undefined parameter may cause an error or be ignored, but the core issue is that it introduces confusion without adding value.

Full explanation →

281

MCQmedium

An administrator wants to create a policy that grants the ability to list all authentication methods enabled on the Vault server. Which path and capability are required?

A.path "sys/auth" { capabilities = ["list"] }

B.path "sys/auth" { capabilities = ["read", "list"] }

C.path "sys/auth" { capabilities = ["read"] }

D.path "auth/*" { capabilities = ["list"] }

AnswerA

Listing enabled auth methods queries the sys/auth endpoint, which enumerates mounted authentication backends. The list capability on that path is the minimum privilege required; read or sudo would not permit enumerating mounts, and other paths expose unrelated secrets.

Why this answer

Option A. To list all enabled authentication methods, the required path is 'sys/auth' with the 'list' capability. The 'list' action returns the names of all auth methods.

Option B is incorrect because it includes 'read', which is unnecessary and not required for listing. Option C is also incorrect because it only has 'read', which would only retrieve a specific method if the name is known. Option D uses a wildcard 'auth/*', which would grant list capability on all sub-paths under 'auth/', but the standard path for listing auth methods is 'sys/auth'.

Therefore, option A is the most precise and correct.

Full explanation →

282

MCQmedium

A team maintains a shared policy that many tokens reference. An administrator needs to add a new path stanza to the policy while preserving every existing rule, without risking a typo that silently removes access. Which approach is correct?

A.Edit the existing HCL to append the new stanza, then run 'vault policy write shared-policy shared-policy.hcl' to replace the policy with the complete updated document.

B.Delete the policy with 'vault policy delete shared-policy', recreate it with the additional stanza, and let Vault reattach it to all dependent tokens automatically.

C.Run 'vault policy write shared-policy -' and pipe in only the new stanza, because Vault merges the submitted document with the stored policy.

D.Run 'vault policy patch shared-policy' with the new stanza, since the patch subcommand performs a partial update of an existing policy.

AnswerA

Because policy write performs a full replacement, the safe procedure is to start from the current complete document, add the new stanza, and submit the whole file. The stored policy then contains the old rules plus the addition, and dependent tokens continue to work with their existing ACLs.

Why this answer

Policy writes in Vault are full replacements, not merges or patches. The reliable method is to retrieve the current document, append the new stanza locally, and write the complete file back so every prior rule is preserved. Deleting and recreating the policy does not propagate changes to already-issued tokens, and no patch subcommand exists.

Exam trap

The trap here is expecting merge or patch semantics from the policy write command, when it actually overwrites the entire stored document.

Full explanation →

283

MCQeasy

An administrator wants to allow users to authenticate to Vault using their existing corporate GitHub accounts. Which authentication method should be enabled?

A.LDAP

B.Okta

C.Username & password (userpass)

D.GitHub

AnswerD

GitHub auth lets users authenticate with existing corporate GitHub accounts via OAuth, mapping GitHub team membership to Vault policies. It directly satisfies the requirement to reuse corporate GitHub credentials rather than issuing separate Vault credentials.

Why this answer

The GitHub authentication method in Vault allows users to authenticate using their existing corporate GitHub accounts by mapping GitHub teams to Vault policies. This is the only option that directly integrates with GitHub's OAuth-based authentication flow, enabling single sign-on without requiring additional directory services or identity providers.

Exam trap

HashiCorp often tests the distinction between 'direct integration' (GitHub auth method) and 'federation via an identity provider' (Okta, LDAP), leading candidates to confuse Okta or LDAP as valid options for GitHub authentication.

How to eliminate wrong answers

Option A is wrong because LDAP is used for authenticating against an LDAP directory (e.g., Active Directory or OpenLDAP), not against GitHub accounts. Option B is wrong because Okta is a third-party identity provider that integrates via OIDC/SAML, not a direct GitHub authentication method. Option C is wrong because username & password (userpass) is a built-in Vault auth method for local users, not for federating with external GitHub accounts.

Full explanation →

284

MCQhard

A platform team must let a batch job encrypt large files, up to several gigabytes each, using Vault transit. Sending entire files to Vault would exhaust request size limits and add latency. Which approach correctly uses the transit engine while keeping key material inside Vault?

A.Enable `exportable=true` on the transit key, export it, and use the exported key material to encrypt files locally.

B.Generate a data key with `transit/datakey/plaintext/<key>`, encrypt the file locally with that data key, and store the returned wrapped key alongside the ciphertext.

C.Use `transit/rewrap` to convert the plaintext file into ciphertext in a single call.

D.Call `transit/encrypt/<key>` once per file and pass the file bytes base64-encoded in the request body.

AnswerB

The `datakey` endpoint returns a high-entropy data key in plaintext and wrapped form. The application uses the plaintext data key locally for symmetric encryption of the file, then discards it and stores only the wrapped key. Because the wrapping key never leaves Vault, the data key can later be unwrapped via `transit/decrypt` to recover the file.

Why this answer

For large payloads, Vault recommends envelope encryption: the transit engine generates a data key, the application encrypts the file locally with that data key, and only the wrapped data key is stored or transmitted. The wrapping key remains inside Vault and is used later to unwrap the data key for decryption. Sending whole files to transit, exporting key material, or misusing rewrap all fail the size, security, or correctness requirements.

Exam trap

The trap here is treating the transit encrypt endpoint as a general-purpose file encryptor instead of recognizing that large data belongs in an envelope-encryption pattern.

Full explanation →

285

MCQeasy

What command is used to view the remaining time on a lease?

A.vault lease lookup <lease_id>

B.vault lease info <lease_id>

C.vault status <lease_id>

D.vault read <lease_id>

AnswerA

The vault lease lookup command retrieves a lease's metadata, including its expiry time and remaining TTL, given the lease ID. This directly answers the requirement to view how much time remains before the lease expires.

Why this answer

The correct command to view the remaining time on a lease is `vault lease lookup <lease_id>`. This command retrieves the lease metadata, including the issue time, duration (TTL), and remaining time, directly from the Vault server. It is the standard method for inspecting lease details without extending or modifying the lease.

Exam trap

HashiCorp often tests the distinction between `vault lease lookup` and `vault read`, where candidates mistakenly think `vault read` can inspect lease details because it is used to read secrets, but lease metadata requires a dedicated lease API command.

How to eliminate wrong answers

Option B is wrong because `vault lease info` is not a valid Vault CLI command; the correct subcommand is `lookup`. Option C is wrong because `vault status` displays the seal status and HA state of the Vault server, not lease information. Option D is wrong because `vault read` is used to read secrets or data from a path, not to inspect lease metadata; it would attempt to read the path as a secret, which would fail or return unrelated data.

Full explanation →

286

MCQmedium

A company wants to securely store database credentials for a dynamic application that spins up new instances frequently. They need to ensure each instance gets a unique, time-limited username/password pair with minimal operational overhead. Which approach should they use?

A.Enable the database secrets engine and configure role-based dynamic credential generation

B.Use the transit secrets engine to encrypt the static credentials and distribute them

C.Use the PKI secrets engine to issue certificates for database authentication

D.Store the credentials in KV v2 and have each instance read them

AnswerA

Configuring the database secrets engine with role-based dynamic credential generation lets Vault mint a unique username/password pair per instance on demand, each tied to a lease that expires automatically. This satisfies the frequent-instance, time-limited and minimal-overhead constraints, since no static credentials are stored or rotated manually.

Why this answer

The database secrets engine in HashiCorp Vault is designed specifically for dynamic credential generation, creating unique, time-limited username/password pairs on-demand for each instance. This approach minimizes operational overhead by automating credential lifecycle management, including automatic revocation after the TTL expires, which aligns perfectly with the requirement for frequently spinning up instances.

Exam trap

HashiCorp often tests the distinction between secrets engines that generate dynamic credentials (database secrets engine) versus those that manage static secrets (KV v2) or provide encryption (transit) or certificates (PKI), leading candidates to confuse the purpose of each engine.

How to eliminate wrong answers

Option B is wrong because the transit secrets engine is used for encryption/decryption of data in transit, not for generating dynamic credentials; encrypting static credentials still requires manual rotation and does not provide unique, time-limited pairs per instance. Option C is wrong because the PKI secrets engine issues X.509 certificates for TLS/mTLS authentication, not username/password pairs, and database authentication typically does not use certificates unless the database supports certificate-based auth (e.g., MySQL with SSL), which is not the stated requirement. Option D is wrong because storing credentials in KV v2 (Key-Value version 2) provides static secrets that must be manually rotated and shared across instances, failing to deliver unique, time-limited credentials and increasing operational overhead for credential management.

Full explanation →

287

MCQmedium

An organization uses the Transit secrets engine to encrypt sensitive files. They want to rotate the encryption key regularly without re-encrypting all existing files. Which feature allows this?

A.Key versioning

B.Key derivation

C.Key ttl

D.Convergent encryption

AnswerA

Key versioning lets the Transit secrets engine retain prior key versions, so ciphertext keeps a reference to the version that encrypted it. New writes use the latest version, while existing files decrypt under their original version — satisfying rotation without re-encrypting stored data.

Why this answer

The Transit secrets engine in Vault supports key versioning, which allows you to rotate the encryption key by creating a new version while keeping older versions available for decryption of existing ciphertext. This means you can regularly rotate the key without needing to re-encrypt all previously encrypted files, as each ciphertext is tagged with the key version used to encrypt it.

Exam trap

HashiCorp often tests the distinction between key rotation (which preserves access to old ciphertext via versioning) and key expiration (which invalidates the key entirely), leading candidates to confuse 'key ttl' with a rotation mechanism.

How to eliminate wrong answers

Option B (Key derivation) is wrong because key derivation is a process that generates a unique encryption key per input plaintext using a key derivation function (KDF), but it does not provide a mechanism to rotate the master key without re-encrypting existing data. Option C (Key ttl) is wrong because key TTL (time-to-live) sets an expiration time for a key, but it does not enable rotation without re-encryption; once the TTL expires, the key becomes unusable, forcing re-encryption if the data must remain accessible. Option D (Convergent encryption) is wrong because convergent encryption derives the encryption key from the hash of the plaintext, making it deterministic and unsuitable for key rotation—changing the key would break the ability to decrypt existing ciphertext.

Full explanation →

288

MCQmedium

An operator configures a PKI role with allow_any_name=true and max_ttl=72h. A user requests a certificate with common_name='admin.example.com' and ttl=48h. What is the resulting TTL?

A.24h

B.72h

C.48h

D.48h if allowed_domains matches, else error

AnswerC

The requested 48h falls below the role's max_ttl ceiling of 72h, so Vault issues the certificate with the shorter value. allow_any_name only governs name validation, not duration; it does not override the TTL constraint. The effective TTL is therefore the requested 48h, satisfying the max_ttl limit.

Why this answer

The `max_ttl` setting on the PKI role defines the upper bound for certificate validity, but the user-requested TTL (48h) is within that bound (72h). The `allow_any_name=true` parameter permits any common name without restriction, so the certificate is issued with the requested TTL of 48h. The resulting TTL is the lesser of the requested TTL and the role's `max_ttl`, which in this case is 48h.

Exam trap

HashiCorp often tests the misconception that `max_ttl` overrides a shorter requested TTL, leading candidates to pick the max_ttl value (72h) instead of understanding that the requested TTL is honored if it is within the limit.

How to eliminate wrong answers

Option A is wrong because 24h would only result if the requested TTL were subtracted from max_ttl or if a default TTL were applied, but no such subtraction or default is specified; the role's max_ttl is an upper limit, not a deduction. Option B is wrong because 72h is the max_ttl, but the user explicitly requested a shorter TTL (48h), and the PKI role honors the requested TTL as long as it does not exceed max_ttl. Option D is wrong because `allow_any_name=true` bypasses the `allowed_domains` check entirely, so no matching is required; the certificate is issued regardless of domain, and the TTL remains 48h.

Full explanation →

289

MCQeasy

What is the purpose of the `storage` stanza in a Vault server configuration file?

A.Defines where Vault stores encrypted data.

B.Defines the encryption algorithm for secrets.

C.Defines the seal mechanism.

D.Defines the listener address.

AnswerA

The storage stanza tells Vault which backend holds its encrypted data, such as Integrated Storage, Consul or a file path. It defines persistence only; encryption keys and unsealing are handled separately by the seal stanza.

Why this answer

The `storage` stanza in a Vault server configuration file defines the backend where Vault stores all encrypted data, including secrets, tokens, and metadata. This backend can be a file system, Consul, Raft, or other supported storage backends, and it is the persistent layer that holds the encrypted data after it has been processed by the seal mechanism. Without a properly configured `storage` stanza, Vault cannot persist any data and will fail to start.

Exam trap

HashiCorp often tests the distinction between the `storage` stanza (where data is stored) and the `seal` stanza (how data is encrypted), leading candidates to confuse the purpose of these two separate configuration blocks.

How to eliminate wrong answers

Option B is wrong because the encryption algorithm for secrets is not defined in the `storage` stanza; it is determined by the seal mechanism (e.g., using AES-256-GCM by default) and is not configurable in the storage stanza. Option C is wrong because the seal mechanism is defined in the `seal` stanza (e.g., `seal "awskms"` or `seal "shamir"`), not in the `storage` stanza. Option D is wrong because the listener address is defined in the `listener` stanza (e.g., `listener "tcp" { address = "127.0.0.1:8200" }`), which configures the network interface and port for API requests, not the storage backend.

Full explanation →

290

MCQeasy

A Vault administrator is explaining the role of the storage backend in Vault's architecture. A new team member asks where Vault stores its encrypted data and what the storage backend is responsible for. Which statement accurately describes the storage backend's role?

A.The storage backend provides authentication and authorization services for Vault clients.

B.The storage backend is responsible for encrypting and decrypting data before it is written to disk.

C.The storage backend manages the unseal keys and distributes them to Vault nodes during initialization.

D.The storage backend stores encrypted data and provides durability, but it does not perform encryption or decryption.

AnswerD

The storage backend's primary role is to durably store the encrypted data that Vault writes. It does not perform any cryptographic operations; encryption and decryption are done by Vault's security barrier before data reaches the backend. This separation ensures that even if the storage backend is compromised, the data remains encrypted and unreadable without the unseal keys.

Why this answer

Vault's storage backend is responsible for durably storing encrypted data. It does not perform encryption, decryption, or key management; those are handled by Vault's security barrier and core. The backend simply persists the ciphertext.

This design allows Vault to support various storage backends like Integrated Storage, Consul, or file, while maintaining a consistent security model. The separation of concerns ensures that storage compromise does not lead to data exposure.

Exam trap

The trap here is assuming that the storage backend handles encryption, when in fact encryption is performed by Vault's security barrier before data is stored.

Full explanation →

291

MCQeasy

A user forgets to renew their token before it expires. What happens to the token and its associated leases?

A.The token becomes invalid but can be renewed within a grace period

B.The token is revoked and all its leases are revoked

C.The token is automatically renewed for another period

D.The token remains active but read-only

AnswerB

Expiry automatically revokes the token, and Microsoft Entra ID propagates that revocation to every lease issued against it, so no lease outlives its parent token. This satisfies the stem's forgotten-renewal scenario: without renewal, the token lapses and all associated leases are revoked together, preventing orphaned leases.

Why this answer

When a Vault token expires, it is immediately revoked by the system, and all associated leases (e.g., dynamic secrets, wrapped responses) are also revoked. There is no grace period for renewal after expiration; the token must be renewed before its TTL expires. This behavior is enforced by Vault's lease management system, which ties secret lifetimes directly to token validity.

Exam trap

HashiCorp often tests the misconception that Vault provides a grace period or automatic renewal for tokens, but in reality, token expiration is absolute and requires explicit client-side renewal before the TTL ends.

How to eliminate wrong answers

Option A is wrong because Vault does not provide a grace period for token renewal after expiration; once the TTL is exceeded, the token is immediately revoked and cannot be renewed. Option C is wrong because Vault never automatically renews tokens; renewal must be explicitly requested by the client or a renewal process (e.g., via the API or a sidecar). Option D is wrong because an expired token is revoked entirely, not placed into a read-only state; Vault has no 'read-only' token mode after expiration.

Full explanation →

292

Multi-Selectmedium

An operations team manages Vault leases for dynamic database credentials. They need to extend the life of an active lease without issuing a new credential, and they also want to confirm the lease's remaining time before doing so. Which two commands or operations should they use? (Choose two.)

Select 2 answers

A.vault lease lookup database/creds/app-role/abc123

B.vault lease revoke database/creds/app-role/abc123

C.vault lease renew database/creds/app-role/abc123

D.vault write database/creds/app-role

E.vault token renew -accessor <accessor-id>

AnswersA, C

The vault lease lookup command returns details about a lease, including its issue time, expiration time, and remaining TTL. This is the correct way to confirm how much time is left before attempting a renewal. It is a read-only operation and does not alter the lease.

Why this answer

To extend an active lease without issuing new credentials, use vault lease renew with the lease ID. To check how much time remains before renewal, use vault lease lookup, which reports the lease's expiration and TTL. Together these operations let the team confirm the remaining lifespan and then extend the existing lease in place.

Exam trap

The trap here is confusing token renewal or credential reissuance with secret lease renewal, when only vault lease renew extends the existing secret lease.

Full explanation →

293

MCQmedium

A company is running Vault in production with a single active node and two standby nodes using Integrated Storage. The operations team notices that after a network partition, one of the standby nodes becomes unavailable for a few minutes. Upon recovery, the node rejoins the cluster. However, the active node's performance degrades temporarily. What is the most likely cause?

A.The standby node caused a leadership election upon reconnection.

B.The standby node was not using a seal wrapping key, causing re-encryption of all data.

C.The standby node's recovery caused Raft snapshot installation, leading to temporary I/O load on the active node.

D.The standby node forced a full data sync from the active node, consuming resources.

AnswerC

Raft snapshot installation is the mechanism: a partitioned standby that falls behind the leader's log must receive a full snapshot on rejoin. Applying that snapshot forces the active node to read and stream state, creating temporary disk I/O contention that degrades its performance.

Why this answer

When a standby node reconnects after a network partition, the Raft consensus protocol may require the node to catch up on missed log entries. If the log gap is large, the active node initiates a snapshot installation, which involves reading and sending a compressed snapshot of the Raft state. This process causes significant I/O and CPU load on the active node, temporarily degrading its performance.

Exam trap

HashiCorp often tests the misconception that a reconnecting standby node triggers a leadership election or a full data sync, when in reality Raft uses snapshot installation to efficiently catch up followers, which can cause temporary performance degradation on the active node.

How to eliminate wrong answers

Option A is wrong because a standby node rejoining does not trigger a leadership election; elections only occur when the active node fails or becomes unreachable. Option B is wrong because seal wrapping keys are used for encrypting the unseal key or root token, not for re-encrypting all data; re-encryption of all data is not a standard behavior upon node reconnection. Option D is wrong because Raft does not force a full data sync from the active node; it uses log replication and snapshot installation to bring the node up to date, which is more efficient than a full sync.

Full explanation →

294

Multi-Selecthard

Which THREE steps are required to configure the database secrets engine for generating dynamic credentials?

Select 3 answers

A.Create a role that maps to the database user and permissions

B.Configure a policy to allow users to read credentials from the role

C.Configure the database connection with connection details and credentials

D.Tune the engine's default TTL

E.Enable the database secrets engine

AnswersA, C, E

Creating a role maps Vault's dynamic credential generation to a specific database user template and permission set, satisfying the requirement to define what credentials are issued. Without a role, the database secrets engine has no blueprint for creating users, so this step is mandatory for generating dynamic credentials.

Why this answer

Option E is correct because the database secrets engine must first be enabled (e.g., `vault secrets enable database`) before any connections or roles can be created. Option C is correct because you must configure a database connection (`vault write database/config/<name>`) with the plugin, connection URL, and privileged credentials Vault uses to create dynamic users. Option A is correct because a role (`vault write database/roles/<name>`) defines the SQL statements and mappings that generate the dynamic credentials with the appropriate permissions.

Option B is not required for generating credentials, since it only governs authorization to read them, and Option D is optional tuning rather than a required configuration step.

Exam trap

HashiCorp often tests the distinction between required configuration steps and optional or subsequent steps, so the trap here is that candidates mistakenly include tuning TTL or writing policies as mandatory steps when they are not part of the core three-step configuration sequence (enable, configure connection, create role).

Full explanation →

295

Multi-Selecteasy

Which two of the following are valid lease operations? (Choose two.)

Select 2 answers

A.vault lease renew

B.vault lease create

C.vault lease delete

D.vault lease generate

E.vault lease revoke

AnswersA, E

This is a valid command to renew leases.

Why this answer

`vault lease renew` is a valid Vault CLI command used to extend the lifetime of a lease before it expires. In HashiCorp Vault, leases are associated with dynamic secrets (e.g., database credentials, AWS IAM keys) and must be periodically renewed to maintain access. The `renew` operation is a core lease lifecycle operation supported by the Vault API and CLI.

Exam trap

HashiCorp often tests the distinction between lifecycle operations that are explicitly supported (renew, revoke) versus operations that are not part of the Vault CLI (create, delete, generate), leading candidates to assume all CRUD-like verbs are valid.

Full explanation →

296

MCQhard

An administrator wants to ensure that a token created by a user cannot be used after 24 hours, even if the user tries to renew it. What should the administrator do?

A.Use a periodic token with a period of 24h

B.Create an orphan token with a TTL of 24h

C.Use a batch token

D.Set explicit max TTL on the token to 24h

AnswerD

Setting an explicit max TTL of 24h caps the token's total lifetime regardless of renewal attempts, satisfying the requirement that it cannot be used beyond 24 hours. Renewals cannot extend past the max TTL, unlike a renewable TTL alone.

Why this answer

Setting an explicit max TTL on the token to 24h ensures that the token's lifetime cannot be extended beyond 24 hours, even if the user attempts to renew it. In Vault, the `explicit_max_ttl` parameter overrides any renewal requests, enforcing a hard upper limit on the token's validity. This directly addresses the requirement that the token cannot be used after 24 hours, regardless of renewal attempts.

Exam trap

The trap here is that candidates confuse TTL (time-to-live, which can be extended via renewal) with explicit max TTL (which sets a hard, non-renewable expiration), leading them to choose periodic or orphan tokens that allow indefinite renewal.

How to eliminate wrong answers

Option A is wrong because a periodic token with a period of 24h can be renewed indefinitely as long as the renewal occurs within the period, allowing the token to exist beyond 24 hours. Option B is wrong because an orphan token with a TTL of 24h can still be renewed before expiration, extending its lifetime beyond the initial 24-hour window. Option C is wrong because a batch token is designed for high-throughput, short-lived operations and does not inherently enforce a hard maximum lifetime; it can be renewed or have its TTL extended unless explicitly constrained.

Full explanation →

297

MCQmedium

Refer to the exhibit. A Vault administrator configures a three-node cluster with the above configuration on all nodes (with appropriate node_id). After starting all nodes, the administrator unseals node2 and node3. Node1 remains sealed. What will be the cluster state?

A.Nodes 2 and 3 will each try to become leader, causing a split-brain.

B.Node1 will automatically join the cluster once unsealed.

C.Nodes 2 and 3 will form a quorum and elect a leader; Node1 will be a standby when unsealed.

D.The cluster will be unavailable because Node1 is sealed.

AnswerC

Two unsealed voters constitute a quorum in a three-node Raft cluster, so nodes 2 and 3 elect a leader and serve requests. Node1, still sealed, cannot vote or participate and becomes a standby once unsealed.

Why this answer

In a Vault cluster, a quorum requires a majority of nodes to be unsealed and available. With three nodes, the quorum size is 2. Nodes 2 and 3, both unsealed, form a quorum and elect a leader among themselves.

Node1, though sealed, is still a cluster member; once unsealed, it will join as a standby node, not as a leader, because the leader election has already occurred.

Exam trap

HashiCorp often tests the misconception that a sealed node makes the entire cluster unavailable, but the key is that Vault only requires a quorum of unsealed nodes for cluster operation, not all nodes.

How to eliminate wrong answers

Option A is wrong because Vault uses Raft consensus, which prevents split-brain by requiring a majority (quorum) for leader election; two nodes cannot both become leader as they will coordinate via Raft. Option B is wrong because Node1 will not automatically join the cluster once unsealed; it will join as a standby node only after being unsealed, but it does not automatically unseal itself. Option D is wrong because the cluster remains available as long as a quorum of nodes (2 out of 3) is unsealed; Node1 being sealed does not make the cluster unavailable.

Full explanation →

298

MCQhard

An organization needs to store secrets with versioning support, allowing rollback to previous secret values. Which KV secrets engine version should be enabled?

A.KV v3

B.KV v1

C.KV v2

D.Transit secrets engine

AnswerC

KV v2 stores secret metadata alongside data, retaining a configurable number of prior versions per secret. This directly satisfies the rollback requirement: `vault kv rollback` or reading `secret/data/<path>?version=N` restores an earlier value. KV v1 overwrites in place with no version history, so it cannot meet the stem's constraint.

Why this answer

KV v2 is the correct choice because it provides versioning support for secrets, allowing users to retrieve and rollback to previous secret values. KV v1 stores secrets without versioning, and the Transit secrets engine is designed for encryption/decryption operations, not secret storage with versioning.

Exam trap

HashiCorp often tests the misconception that KV v3 exists or that the Transit secrets engine can handle versioned secret storage, leading candidates to choose those incorrect options.

How to eliminate wrong answers

Option A is wrong because KV v3 does not exist in Vault; the KV secrets engine has only two versions (v1 and v2). Option B is wrong because KV v1 stores secrets without versioning, so it cannot support rollback to previous values. Option D is wrong because the Transit secrets engine is used for encryption as a service, not for storing secrets with versioning capabilities.

Full explanation →

299

Multi-Selecteasy

Which TWO are core components of Vault's architecture?

Select 2 answers

A.Seal

B.Storage backend

C.Audit device

D.Auth method

E.Replication

AnswersA, B

The seal is a core architectural component: it wraps the root key and controls whether Vault can decrypt the barrier. When sealed, Vault cannot read storage or serve requests; unsealing reconstructs the root key from threshold shares, enabling operation.

Why this answer

Option A (Seal) is correct because the seal/unseal mechanism is a fundamental architectural component of Vault: Vault always starts in a sealed state, and the master key (protected by the unseal keys or auto-unseal KMS) must be used to decrypt the encryption key so Vault can read its data — this barrier is intrinsic to Vault's core design. Option B (Storage backend) is correct because Vault's architecture is built around a pluggable storage backend (e.g., Integrated Storage/Raft, Consul, File) that persists encrypted data; without a configured storage backend Vault cannot function, making it a core component. Option C (Audit device) is not a core architectural component but an optional, enable-able feature for logging requests and responses to destinations like file or syslog.

Option D (Auth method) is a pluggable security feature (e.g., token, userpass, LDAP, AppRole) that authenticates clients but is not part of the base architecture. Option E (Replication) is an optional enterprise capability (performance/DR replication) for scaling and disaster recovery, not a core component.

Exam trap

HashiCorp often tests the distinction between core architectural components (Seal and Storage Backend) and optional or pluggable features (audit devices, auth methods, replication), leading candidates to mistakenly select features that are critical for operation but not part of the minimal core architecture.

Full explanation →

300

Multi-Selecteasy

Which TWO of the following are valid methods to authenticate to Vault using the CLI without using a token? (Choose two.)

Select 2 answers

A.vault login -method=userpass username=joe password=pass

B.vault login -method=ldap username=joe password=pass

C.vault auth -method=ldap username=joe password=pass

D.vault write auth/userpass/login/joe password=pass

E.vault token create -policy=default

AnswersA, B

The userpass auth method exchanges static credentials for a Vault token, satisfying the requirement to authenticate without an existing token. The CLI `vault login -method=userpass` call submits the username and password to the userpass auth backend, which validates them against its configured store and returns a client token.

Why this answer

Option A is correct because `vault login -method=userpass username=joe password=pass` invokes the userpass auth method's login endpoint and returns a Vault token, allowing CLI authentication without supplying an existing token. Option B is correct because `vault login -method=ldap username=joe password=pass` performs the same token-issuing login flow against the LDAP auth method, which is a valid non-token authentication path. Option C is not valid because `vault auth` is used to enable, disable, and tune auth methods, not to log in and obtain a token.

Option D is not the documented CLI login workflow; while it resembles a raw API write to the userpass login path, the CLI's supported non-token login mechanism is `vault login -method=...`. Option E is incorrect because `vault token create` requires an existing token with sufficient permissions and creates a new token rather than authenticating without one.

Exam trap

HashiCorp often tests the distinction between the `vault login` command (which performs tokenless authentication) and the `vault write` command (which requires an existing token), leading candidates to mistakenly choose D as a valid tokenless method because it appears to send credentials directly.

Full explanation →

HashiCorp Vault Associate VA-003 (VA-003) — Questions 226–300