HashiCorp Certified: Vault Associate (003) Exam Questions

Correct answer: It verifies the identity of a user or machine and, on success, returns a Vault token used to authorize subsequent requests.
Before a client can interact with Vault, it must authenticate against an auth method; upon successful authentication, Vault generates a token tied to that identity, and all further requests are authorized using that token.

Why the other options are incorrect:
● It encrypts data stored in Vault’s secrets engines before it is written to the storage backend. — Encrypting data in transit/at rest is handled by Vault’s core storage encryption and the transit secrets engine, not by auth methods.
● It defines the TTL and renewal behavior for every secret lease issued by Vault. — Lease TTL/renewal is a property of secrets engines and tokens, not something an auth method itself defines.
● It replicates Vault’s configuration and data to a disaster-recovery cluster. — Replication is a separate Vault Enterprise feature unrelated to how clients authenticate.

Source: Authentication | Vault

Correct answer: AppRole
The approle auth method lets machines or applications authenticate using a RoleID (which selects the role) and a SecretID (a companion credential), making it ideal for CI/CD pipelines and other automated workflows where no human is available to type in credentials.

Why the other options are incorrect:
● Userpass — A simple username/password method aimed at human operators, not unattended automation.
● GitHub — Authenticates a human using their personal GitHub account/token, not a machine workload.
● OIDC — Delegates to an external identity provider’s interactive sign-in flow, which is designed for human browser-based login, not unattended machines.

Source: AppRole Auth Method | Vault

Correct answer: AWS
Vault’s auth documentation notes that some auth backends are targeted toward users while others are targeted toward machines. The AWS auth method lets EC2 instances and IAM principals authenticate using AWS-native credentials or instance metadata, a pattern built for machine workloads rather than interactive human logins.

Why the other options are incorrect:
● LDAP — Authenticates a human user against a directory service using their personal account credentials.
● Userpass — A simple username/password method intended for human operators, commonly used for local accounts.
● GitHub — Authenticates a human user via their own personal GitHub account.

Source: Authentication | Vault

Correct answer: Creating an identity entity with an alias for each auth method, so both logins map to one entity.
An entity represents a single user inside Vault, and an alias maps that user’s account on a specific auth method to the entity. Since a user may have accounts with multiple identity providers, Vault’s identity system ties those separate logins together into one entity for consistent policy enforcement and audit logging.

Why the other options are incorrect:
● Enabling the same auth method twice at two different mount paths. — This only adds more places to authenticate; it does not merge two different logins into one recognized identity.
● Setting identical token TTLs on both auth methods. — TTL configuration has no bearing on whether Vault recognizes two logins as the same person.
● Assigning the sudo capability to both auth methods’ default policy. — sudo controls access to root-protected API endpoints and has nothing to do with unifying identity across auth methods.

Source: Identity | Vault

Correct answer: POST /v1/auth/userpass/login/<username> with the password in the request body
The userpass auth method’s login endpoint is POST /auth/userpass/login/:username, where the username is part of the URL path and the password is supplied in the JSON request body. This endpoint does not require an existing X-Vault-Token header, since it is used for initial authentication.

Why the other options are incorrect:
● POST /v1/sys/auth/userpass/login with the username and password in the request body. — sys/auth/... is the path used to enable and manage the auth method mount itself, not to log in.
● GET /v1/auth/userpass/users/<username> with the password as a query parameter. — That endpoint manages a configured user’s stored settings; it is not a login endpoint and does not accept GET requests with a password query parameter.
● PUT /v1/auth/userpass/<username>/login with the password in the request body. — The username belongs after /login/, not before it, and this path does not match the documented endpoint.

Source: Userpass Auth Method (API) | Vault

Correct answer: vault write auth/approle/login role_id=<role_id> secret_id=<secret_id>
The official AppRole documentation shows logging in by writing directly to the method’s login endpoint with the role_id and secret_id, since AppRole is not one of the methods wired into the vault login -method= CLI helper.

Why the other options are incorrect:
● vault login -method=approle role_id=<role_id> secret_id=<secret_id> — vault login only supports its built-in list of auth helper methods (such as userpass, ldap, github, okta, cert); AppRole authentication is performed by writing to its login path instead.
● vault auth enable approle role_id=<role_id> secret_id=<secret_id> — vault auth enable only mounts the AppRole auth method at a path; it takes no role_id/secret_id and performs no login.
● vault token create -role=approle role_id=<role_id> secret_id=<secret_id> — vault token create issues a new token from the token store for an already-authenticated caller; it does not accept role_id/secret_id and cannot perform AppRole login.

Source: AppRole Auth Method | Vault

Correct answer: vault auth enable -path=my-userpass userpass
Auth methods are mounted with the vault auth enable command, and the -path flag lets the same method type be mounted more than once at different paths, each configurable independently — for example vault auth enable -path=my-auth userpass.

Why the other options are incorrect:
● vault write sys/auth/my-userpass type=userpass. — This is not the documented CLI form for enabling an auth method; sys/auth is the underlying API path, but mounting is done through the dedicated vault auth command group.
● vault secrets enable -path=my-userpass userpass. — vault secrets enable mounts a secrets engine, not an auth method; the two use separate command groups.
● vault login -method=userpass -path=my-userpass. — This attempts to log in against an auth method already mounted at that path; it does not create or enable the mount.

Source: Authentication | Vault

Correct answer: The user’s entity remains in the Vault external group until the user next authenticates or renews their token, since membership refreshes on login/renewal rather than instantly.
External groups automatically sync membership from an external system such as LDAP, but that sync happens during authentication or token renewal — Vault documentation notes that if a user is removed from the group in LDAP, they are not immediately removed from the corresponding external group in Vault.

Why the other options are incorrect:
● The user is removed from the Vault external group within seconds via a continuous background sync that Vault runs independently of login. — Vault does not continuously poll LDAP in the background; updates happen at login/renewal time, not instantly.
● External group membership is static once configured and can never change without manually editing the group in Vault. — External groups do update automatically over time; that is precisely what distinguishes them from internal groups, which require manual membership management.
● Removing the user from LDAP immediately revokes every Vault token already issued to that user. — Removing LDAP group membership does not automatically revoke tokens Vault has already issued.

Source: Identity | Vault

Correct answer: Because an empty or non-matching policy grants no access at all — only paths explicitly listed with capabilities are permitted.
Vault policies are deny by default, so an empty policy grants no permission in the system; access to any path must be explicitly granted via a path block and its capabilities.

Why the other options are incorrect:
● Because every new token is automatically assigned the root policy until an administrator explicitly downgrades it. — New tokens get the default policy (plus whatever is explicitly attached), never the powerful root policy by default.
● Because policies can only be written in JSON, never HCL, and JSON defaults every path to denied. — Policies can be written in either HCL or JSON; the file format has no bearing on deny-by-default behavior.
● Because Vault denies all requests whenever the audit log backend is temporarily unavailable, regardless of policy content. — That describes a separate availability safeguard, not how policy evaluation itself works.

Source: Policies | Vault

Correct answer: The * is a glob that matches everything after that point, so it grants read on both secret/data/apps/web and secret/data/apps/web/config.
In Vault policy paths, * is a glob allowed only as the last character of a path, and it matches everything beyond that point — including nested segments — not just a single path segment.

Why the other options are incorrect:
● The * matches exactly one path segment, so it grants read on secret/data/apps/web but not on secret/data/apps/web/config. — Matching a single segment is the behavior of the + wildcard, not *.
● The * must appear at the start of a path, so this policy is invalid and Vault will reject it when written. — * is valid only as a suffix at the end of a path, and the example path is a correctly formed, valid rule.
● The * only takes effect if the rule also includes a + character elsewhere in the same path. — * and + are independent wildcard syntaxes that can each be used on their own.

Source: Policies | Vault

Correct answer: The call is denied, because root-protected endpoints additionally require the sudo capability, which was not granted.
Some Vault API endpoints are root-protected and require the special sudo capability in addition to whatever operation capability (read, list, etc.) would otherwise apply; without sudo explicitly granted on that path, the request is denied.

Why the other options are incorrect:
● The call succeeds, because read capability alone is sufficient for every endpoint in Vault, root-protected or not. — Root-protected endpoints are a specific exception that require sudo on top of the normal capability.
● The call succeeds, because list capability implicitly grants sudo on any path it is paired with. — Capabilities are independent of one another; list never implies sudo.
● The call is recorded as successful in the audit log but silently returns no data instead of an error. — Vault returns an explicit permission-denied error for a disallowed request; it does not silently return empty data.

Source: Policies | Vault

Correct answer: No access — deny on a matching path always overrides any other capability granted to that same path by another policy.
When multiple policies attached to a token define capabilities for the same path, Vault combines them, but deny is the one capability that always takes precedence — a deny on a matching path blocks access regardless of what other policies grant.

Why the other options are incorrect:
● Read access — capabilities from multiple policies are purely additive, so the read granted by Policy A still applies. — Capabilities are generally additive across policies, but deny is the explicit exception that overrides everything else for that path.
● It depends on which policy was attached to the token first; whichever policy was attached first wins. — Policy evaluation does not depend on attachment order; deny wins unconditionally regardless of order.
● Vault refuses to evaluate the token at all and returns an internal server error. — Conflicting capabilities across policies are a normal, well-defined case that Vault resolves deterministically, not an error condition.

Source: Policies | Vault

Correct answer: Two separate rules — path "secret/data/teamb/*" { capabilities = ["read", "list"] } and path "secret/metadata/teamb/*" { capabilities = ["read", "list"] }.
The KV v2 secrets engine splits operations across two distinct sub-paths: reading a secret’s value goes through data/, while listing secrets goes through metadata/ (to list secrets for KV v2, a policy must grant list on the metadata/ path specifically). Scoping both rules to teamb/* with only read and list satisfies the requirement without exposing other teams’ data or allowing writes/deletes.

Why the other options are incorrect:
● A single rule, path "secret/*" { capabilities = ["read", "list"] }, since secret/data and secret/metadata are automatically covered by the top-level secret/ prefix. — This is overbroad: it grants read/list access to every team’s secrets under the mount, not just team b’s.
● Two rules, one for each path, each with capabilities = ["read", "list", "create", "update"], so the team can also fix mistakes in its own secrets. — This grants more than required; the scenario explicitly says the team must not create or update secrets.
● One rule, path "secret/data/teamb/*" { capabilities = ["read", "list"] }, since metadata-path capabilities are inherited automatically from the data path in KV v2. — Capabilities on data/ are not automatically inherited by metadata/; listing specifically requires a separate grant on the metadata/ path.

Source: KV Secrets Engine - Version 2 (API) | Vault

Correct answer: vault policy write teamb teamb-policy.hcl
Vault policies are created or updated from the CLI with the dedicated vault policy write <name> <path-to-policy-file> command, which uploads the named policy document to Vault.

Why the other options are incorrect:
● vault write sys/policy -path=teamb teamb-policy.hcl. — This is not valid syntax for uploading a policy; policy management has its own dedicated vault policy subcommand rather than a generic vault write call like this.
● vault policy apply teamb-policy.hcl --name=teamb. — There is no vault policy apply subcommand in the Vault CLI.
● vault auth enable -policy=teamb teamb-policy.hcl. — vault auth enable mounts an auth method; it has no -policy flag and does not create or upload policies.

Source: Policies | Vault

Correct answer: A batch token, because batch tokens are lightweight, require no persistent storage write, and are designed for exactly this kind of high-volume, short-lived, non-renewable use case.
Batch tokens are encrypted blobs that require no storage write to create, making them extremely lightweight and scalable, at the cost of not being renewable, manually revocable, or usable to create child tokens — a direct match for this high-volume, fire-and-forget scenario.

Why the other options are incorrect:
● A periodic service token, because periodic tokens are the lightest-weight token type Vault offers. — Periodic tokens are still service tokens, which require storage writes on creation; they are not the lightweight option here.
● A root token, because only root tokens can be issued at very high volume without hitting rate limits. — Request volume has nothing to do with needing root privileges, and root tokens should be tightly restricted, not issued routinely at scale.
● An orphan service token, because orphan status is required for any token used at high volume. — Orphan vs. non-orphan concerns parent/child revocation behavior, not request volume.

Source: Tokens | Vault

Correct answer: Revoke it immediately after initial configuration is done, since root tokens should only be used for bootstrapping or emergencies, not daily operations.
Root tokens carry the unrestricted root policy and should be extremely carefully guarded in production; HashiCorp recommends using one only for initial setup or emergencies and revoking it immediately afterward rather than keeping it in routine use.

Why the other options are incorrect:
● Set its TTL to the system maximum (32 days) and keep using it for routine administrative tasks going forward. — Root tokens by default can have an indefinite TTL, and the guidance is to revoke them after use, not to simply cap and keep using them routinely.
● Share it with every Vault administrator so that any of them can perform emergency operations at any time. — Widely distributing an unrestricted root token massively increases risk; best practice is to tightly guard it, not share it broadly.
● Convert it into a batch token so it can be used at higher volume without needing to be revoked. — Root privilege and token type (service/batch) are separate concepts, and an existing token cannot be “converted” between types; this does not address the revocation guidance.

Source: Tokens | Vault

Correct answer: The token accessor, a reference value that can be used to look up, renew, or revoke the token without exposing the token itself.
Every service token is issued with an accessor — a separate reference value that can be used to look up properties, renew, or revoke the token without ever needing the token’s own value. This lets a system like an orchestrator store only the accessor (tied to a job ID, for example) and use it to revoke the token instantly once the job completes.

Why the other options are incorrect:
● The token’s display_name, which can be looked up and deleted via the API. — display_name is a human-readable label for audit purposes; it is not a unique handle that can be used to revoke a specific token via the API.
● The token’s policies list, which can be edited after issuance to remove all access. — Capabilities policies carry are evaluated at request time, but editing a policy’s path rules is not the mechanism for revoking one specific issued token.
● The token’s entity_id, which can be deleted to invalidate every token tied to that entity. — Deleting an entity is a far more invasive, indirect approach and is not the standard mechanism Vault provides for revoking a single token.

Source: Tokens | Vault

Correct answer: The token’s total lifetime is still bounded by its max TTL, determined by the most restrictive of the system, mount, and auth method settings, recalculated at each renewal.
A token’s max TTL is dynamically calculated from the system max TTL (32 days by default), any mount-specific max TTL, and the auth method’s suggested values, with the most restrictive value applying; the current allowed max TTL is recalculated using current values at each renewal, placing a hard ceiling on the token’s total lifetime.

Why the other options are incorrect:
● The token can be renewed forever, since renewal always resets the TTL with no upper bound at all. — This contradicts the very purpose of a max TTL, which places a hard ceiling on total lifetime regardless of renewal.
● Renewal has no effect on TTL; the token still expires exactly 1 hour after it was first issued, no matter how many times it is renewed. — Renewal explicitly extends the TTL window; that is the entire purpose of the renew operation.
● Only root tokens have a max TTL; every other token can be renewed without limit as long as it is renewed before expiring. — The opposite is closer to true: root tokens can have an effectively indefinite TTL, while ordinary tokens are the ones bound by max TTL limits.

Source: Tokens | Vault

Correct answer: An orphan token has no parent token, so revoking some other token in the hierarchy will never cause the orphan token to be revoked along with it.
Tokens normally form parent-child hierarchies, and revoking a parent token revokes all of its descendants. An orphan token breaks this pattern by having no parent, so it forms the root of its own independent token tree and survives regardless of what happens to the token that created it.

Why the other options are incorrect:
● An orphan token cannot be used to read any secret, regardless of its attached policies. — Orphan status has nothing to do with read access, which is governed entirely by the token’s attached policies.
● An orphan token is automatically a batch token, while non-orphan tokens are always service tokens. — Orphan/non-orphan and service/batch are independent token properties; a service token can also be created as an orphan, for example via the create-orphan endpoint.
● An orphan token has no TTL and therefore never expires. — Orphan tokens remain subject to normal TTL and max TTL rules unless specifically configured otherwise; being orphaned does not by itself remove expiration.

Source: Tokens | Vault

Correct answer: Grant the caller access to the auth/token/create-orphan endpoint, which can create orphan tokens without requiring root or sudo capability.
The no_parent parameter on auth/token/create only has effect for a root or sudo caller, but Vault also exposes a dedicated auth/token/create-orphan endpoint specifically so that a non-root, non-sudo caller can create orphan tokens without needing elevated privileges.

Why the other options are incorrect:
● Grant the caller sudo capability on auth/token/create and have it set no_parent=true, since that is the only way to create an orphan token. — This works, but it is not the only way, and it unnecessarily requires sudo, which the scenario explicitly wants to avoid.
● Orphan tokens can only ever be created by a root token; there is no way to delegate this ability to a non-root caller. — False; create-orphan exists precisely to let non-root/non-sudo callers create orphan tokens.
● Give the caller the built-in root policy, since orphan token creation always requires unrestricted access. — This is far more privilege than needed and unnecessary given the dedicated endpoint.

Source: Token Auth Method (API) | Vault

Correct answer: Every other auth method (such as AppRole, LDAP, or Kubernetes) dynamically creates a token upon a successful login, mapping the external identity down to a standard Vault token.
Tokens originate from two sources: the token store (via auth/token/create) and external auth methods, which all map authentication down to dynamically created tokens that share the same underlying properties as manually created ones.

Why the other options are incorrect:
● Tokens can only ever be created through vault token create; no other mechanism issues Vault tokens. — This contradicts the documented fact that every auth method also issues a token on successful login.
● The Vault UI generates tokens locally in the browser without contacting the Vault server. — The UI is just a client; it still calls the Vault server’s login API and receives a server-issued token, it does not generate tokens itself.
● Secrets engines create a new Vault token automatically every time a dynamic secret is read. — Secrets engines issue secrets and leases (such as dynamic database credentials), not Vault authentication tokens.

Source: Tokens | Vault

Correct answer: A periodic token (which resets its TTL to a fixed period on every renewal) combined with an explicit_max_ttl, so renewal keeps it alive indefinitely in normal operation but it still cannot outlive the explicit hard cap.
A periodic token has its TTL reset to the configured period on each renewal, letting it stay alive as long as the system keeps actively renewing it. Pairing it with an explicit max TTL still gives the token a hard outer limit it cannot exceed, even if renewal stops happening correctly — exactly matching both requirements.

Why the other options are incorrect:
● A standard token with renewable=false, since disabling renewal is the only way to set an outer limit. — Disabling renewal entirely caps the token at its initial TTL, which fails the requirement that the service be able to keep it alive indefinitely during normal operation.
● A batch token, since batch tokens are specifically designed to be renewed forever without any cap. — Batch tokens are explicitly not renewable at all; they have a fixed, non-extendable TTL.
● A root token, since only root tokens can be configured to survive indefinitely. — Using a root token for a routine long-running service goes against the guidance to tightly restrict root token use, and it is unrelated to the periodic/explicit-max-TTL mechanism this scenario calls for.

Source: Tokens | Vault

Correct answer: It uniquely identifies this dynamic secret so it can later be renewed or revoked without needing the secret’s value itself.
Whenever Vault generates a secret that carries a lease, it returns a lease_id along with that secret. This ID is what commands such as vault lease renew and vault lease revoke operate on to manage the secret’s lifecycle, independent of the secret’s actual value (for example, the database username and password).

Why the other options are incorrect:
● It is the unique identifier of the Vault token that made the request, used for auditing API calls. — That describes a token’s identifier/accessor, not a lease ID; a single token can hold many leases, each with its own lease ID.
● It is a cache key the Vault client SDK uses to avoid re-reading the same secret path twice. — Vault does not provide client-side secret caching keyed off the lease ID; the lease ID exists purely for lease management operations.
● It is the encryption key version used to protect the secret while it is stored in Vault’s backend. — Key versioning is a concept from the Transit secrets engine, not a property of generic dynamic-secret leases.

Source: Lease, Renew, and Revoke

Correct answer: The -increment value is only a requested duration; the secrets engine or role configuration may shorten it, and Vault is not obligated to grant the exact value requested.
The -increment flag on vault lease renew is a hint, not a guarantee. The owning secrets engine (constrained, for example, by a role’s max_ttl) ultimately decides the actual renewed lease_duration, which can be shorter than what was requested.

Why the other options are incorrect:
● The -increment flag was misspelled and Vault silently fell back to the default TTL. — A misspelled flag produces a CLI usage error, not a successful renewal with a shortened duration.
● Vault only honors -increment values submitted through the UI, not the CLI. — The CLI and API both support a requested renewal increment identically; there is no UI-only restriction.
● The lease had already been revoked, so Vault returned a minimal fallback duration instead of an error. — Renewing a revoked lease returns an error (the lease cannot be found), not a successful response with a shorter duration.

Source: vault lease renew

Correct answer: vault lease revoke -prefix database/creds/readonly
The -prefix flag tells vault lease revoke to treat the given value as a path prefix and revoke every lease issued under it in one operation, which is exactly what’s needed to invalidate all leases issued through the readonly role without enumerating individual lease IDs.

Why the other options are incorrect:
● vault lease revoke database/creds/readonly — Without -prefix, vault lease revoke expects a single, exact lease ID; a role path alone will not match any individual lease.
● vault secrets disable database — This disables the entire database secrets engine mount, revoking every role’s secrets and deleting its configuration, which is far more disruptive than revoking leases for one role.
● vault token revoke -mode=path database/creds/readonly — vault token revoke operates on tokens, not leases, and the CLI has no -mode flag; this is not a valid way to revoke dynamic secret leases.

Source: vault lease revoke

Correct answer: vault lease renew will fail for this lease, and once the TTL expires Vault automatically revokes the secret through its own lease revocation process.
lease_renewable: false means the secret cannot be extended; calling vault lease renew against it fails. Vault still tracks the lease’s TTL internally and, once it expires, automatically revokes the underlying secret so it becomes invalid — a consumer must request a brand-new secret instead of extending the old one.

Why the other options are incorrect:
● The field is purely informational; vault lease renew will still succeed and silently reset the TTL. — A non-renewable lease causes the renew call to fail; the field directly governs renewal behavior, it isn’t cosmetic.
● The secret was issued without a lease at all, so it never expires. — A lease_renewable field only appears because a lease (with a TTL) exists; false only means it can’t be extended, not that no lease or TTL exists.
● Vault automatically converts the lease to renewable once the token that created it is renewed. — Renewing the parent token does not change the renewability of secrets it previously generated; that property is set by the secrets engine at issuance.

Source: Lease, Renew, and Revoke

Correct answer: The PKI secrets engine
The PKI secrets engine generates dynamic X.509 certificates, letting services obtain certificates without the manual process of creating a private key, CSR, and waiting on a CA, and it supports revoking issued certificates before they would naturally expire.

Why the other options are incorrect:
● The Transit secrets engine — Transit performs cryptographic operations like encrypt/decrypt and sign/verify as a service; it does not act as a certificate authority or issue X.509 certificates.
● The KV version 2 secrets engine — KV v2 only stores and versions static, arbitrary key/value data; it has no concept of issuing or revoking certificates.
● The TOTP secrets engine — TOTP generates time-based one-time passcodes for two-factor authentication, which is unrelated to certificate issuance.

Source: PKI Secrets Engine

Correct answer: A secrets engine is a component, mounted at a path, that stores, generates, or encrypts data, and determines how Vault responds to requests made to that path.
Secrets engines are the components that store, generate, or encrypt data in Vault. Each engine is mounted at a path, and Vault’s router sends any request matching that path prefix to the corresponding engine, which decides how to respond — whether that means reading stored static data or generating a fresh dynamic credential.

Why the other options are incorrect:
● A secrets engine is a Vault auth method that maps external identities to Vault tokens. — That describes an auth method (e.g., LDAP, AppRole), a separate Vault concept from secrets engines.
● A secrets engine is a replication mechanism that copies Vault’s audit log to a secondary cluster. — Audit devices handle audit logging, and cluster replication is a distinct Enterprise feature; neither is what a secrets engine does.
● A secrets engine is the physical storage backend, such as Raft or Consul, that persists Vault’s encrypted data. — The storage backend is a lower layer that persists Vault’s own encrypted data; secrets engines sit above it and don’t require any specific backend to function.

Source: Secrets engines

Correct answer: Dynamic secrets are generated on demand by a secrets engine and tied to a lease that controls their lifecycle, while static secrets are fixed values that Vault stores and serves as-is, such as values written to the KV secrets engine.
Some secrets engines connect to other systems and generate credentials dynamically on demand, each tied to a lease with a TTL that governs renewal and revocation. Others, like KV, simply store and return the data written to them, with no generation step and no lease-driven lifecycle by default.

Why the other options are incorrect:
● Static secrets always expire automatically after their lease TTL, while dynamic secrets never expire. — This reverses the truth: lease-driven TTLs and expiration apply to dynamic secrets, not to static values stored in an engine like KV.
● Dynamic secrets are only readable through the Vault UI, while static secrets are only readable through the API. — Both dynamic and static secrets are accessible through the CLI, API, and UI; there is no such access restriction.
● Static secrets require the database secrets engine, while dynamic secrets require the KV secrets engine. — This swaps the engines’ roles: the database secrets engine generates dynamic credentials, while KV stores static secrets.

Source: Secrets engines

Correct answer: The Transit secrets engine, used as encryption as a service so the application sends plaintext to be encrypted and stores only the returned ciphertext.
Transit handles cryptographic functions as a service without storing the data itself — relieving the application of needing to implement encryption correctly. The app sends plaintext to the transit/encrypt endpoint, stores the returned ciphertext in its own database, and later calls transit/decrypt to recover the plaintext.

Why the other options are incorrect:
● The database secrets engine, configured with dynamic credentials for the PostgreSQL instance. — That engine generates short-lived database login credentials; it has nothing to do with encrypting individual data fields.
● The KV version 2 secrets engine, storing each encrypted field as a versioned secret. — This would require Vault itself to hold the application’s data as stored secrets, which conflicts with the requirement that Vault not store the plaintext data.
● Response wrapping, so the application retrieves a single-use token containing the encrypted field. — Response wrapping is a mechanism for securely delivering a response once; it is not an encryption service for an application’s ongoing data.

Source: Transit Secrets Engine

Correct answer: Each credential is unique, short-lived, and automatically revoked at the end of its lease, which shrinks the exposure window and blast radius if a credential leaks.
The database secrets engine generates a unique username and password per request, tied to a lease with a TTL. Vault’s internal revocation system ensures the credential becomes invalid shortly after the lease expires, so instead of one long-lived password shared everywhere, each consumer holds a credential with a tightly bounded, auditable lifetime.

Why the other options are incorrect:
● Dynamic credentials are encrypted twice, once by Vault and once by the database engine, doubling their cryptographic strength. — There is no “double encryption” mechanism for dynamic database credentials; the security benefit comes from short lifetime and uniqueness, not extra encryption layers.
● Dynamic credentials bypass the database’s own authentication system entirely, so there is nothing for an attacker to steal. — Dynamic credentials still authenticate through the database’s normal login mechanism; they are a real, usable username and password while the lease is active.
● Dynamic credentials are stored permanently in the KV secrets engine so they can always be recovered if an application loses them. — Dynamic secrets are generated on demand via leases and are not persisted as static KV entries; a lost credential is replaced by requesting a new one, not recovered from storage.

Source: Database secrets engines

Correct answer: Response wrapping, which returns a single-use wrapping token backed by a cubbyhole instead of the raw secret, so a failed unwrap signals possible interception.
With response wrapping, Vault stores the actual response in a single-use token’s cubbyhole and hands back only the wrapping token. The next pipeline stage calls sys/wrapping/unwrap to retrieve the secret; because the token can be unwrapped exactly once, an unexpected “already unwrapped” error signals that someone else may have intercepted and consumed it first.

Why the other options are incorrect:
● Enabling the secret’s path with a shorter max-lease-ttl so any interception window is minimized. — A shorter TTL limits how long a leaked secret stays useful, but it does nothing to detect that an interception happened in the first place.
● Storing the secret in the KV version 2 engine and sharing its version number with the next stage. — Anyone who can read that KV path and version can retrieve the secret repeatedly, with no single-use protection or interception signal.
● Enabling the Transit secrets engine so the secret is HMAC-signed before being passed along. — An HMAC lets a recipient verify the data wasn’t tampered with, but it doesn’t provide single-use delivery or reveal whether an earlier party already read the secret.

Source: Response Wrapping

Correct answer: vault secrets enable -path=app-secrets -version=2 kv
vault secrets enable is the command used to enable a secrets engine; by default it mounts at a path matching the engine type, but the -path flag overrides that, and -version=2 selects the KV version 2 implementation of the kv engine type.

Why the other options are incorrect:
● vault kv enable -path=app-secrets kv-v2 — There is no enable action under the vault kv subcommand; vault kv is used to read/write/list KV data, not to mount the engine.
● vault secrets mount -path=app-secrets kv-v2 — mount is not a valid vault secrets subcommand; the correct subcommand to enable a new secrets engine is enable.
● vault auth enable -path=app-secrets kv — vault auth enable mounts authentication methods, not secrets engines; it operates against an entirely different part of Vault.

Source: vault secrets enable

Correct answer: vault kv get secret/myapp/config
vault kv get is KV-version-aware: for a KV v2 mount, it automatically inserts the data/ segment into the underlying API path (effectively reading secret/data/myapp/config), so operators can use the same simple path they used to write the secret, without manually accounting for the v2 path structure.

Why the other options are incorrect:
● vault read secret/myapp/config — vault read makes a raw API call and does not insert the data/ segment KV v2 requires, so without specifying the full secret/data/myapp/config path it will not return the secret as expected.
● vault secrets read secret/myapp/config — There is no read action under the vault secrets subcommand; vault secrets manages engine mounts (enable/disable/list/move/tune), not secret data.
● vault lease renew secret/myapp/config — This static KV secret has no lease to renew; vault lease renew only applies to leased, typically dynamic, secrets.

Source: vault kv get

Correct answer: The AWS secrets engine, configured to generate dynamic, short-lived IAM credentials on request.
The AWS secrets engine dynamically generates AWS access credentials on demand; the resulting IAM credentials are time-based and are automatically revoked when the associated Vault lease expires, meaning no long-lived access key needs to be stored anywhere.

Why the other options are incorrect:
● The KV version 2 secrets engine, storing a long-lived AWS access key pair as a static secret. — This is exactly the long-lived, stored-credential pattern the requirement is trying to avoid; KV v2 does not generate or rotate credentials.
● The Transit secrets engine, used to encrypt a pre-existing AWS access key before storing it. — Encrypting a long-lived key still leaves a long-lived key in existence; it doesn’t produce short-lived, automatically revoked credentials.
● The TOTP secrets engine, generating one-time codes to authenticate AWS API calls. — TOTP produces time-based one-time passcodes for multi-factor authentication flows; AWS API calls are not authenticated with TOTP codes.

Source: AWS Secrets Engine

Correct answer: The backend base64-encodes the plaintext, sends it to transit/encrypt/<key>, stores the returned ciphertext in its own database, and later sends that ciphertext to transit/decrypt/<key> to retrieve the plaintext.
Transit provides encryption as a service: it performs cryptographic operations on data handed to it but never stores that data. The application remains responsible for storing the ciphertext (in its own database), and it round-trips through transit/encrypt and transit/decrypt whenever it needs to protect or recover a value.

Why the other options are incorrect:
● The backend writes the plaintext to secret/data/ssn in the KV engine, and Vault automatically encrypts it before replicating it to the application’s own database. — KV stores secrets inside Vault itself and has no feature that replicates data out to an external application database; this also means Vault would be storing the plaintext, which the requirement rules out.
● The backend requests a wrapped response from sys/wrapping/wrap, and unwraps it directly from its database layer whenever the value is needed. — Response wrapping produces a single-use token meant for one-time secure delivery; it is not a repeatable encrypt/decrypt mechanism for ongoing application data.
● The backend calls transit/keys/<key>/rotate before every write so each social security number is encrypted with a brand-new key version. — rotate creates a new version of the named key itself; it is not an encryption call and isn’t meant to be invoked per write, and on its own it doesn’t encrypt any data.

Source: Transit Secrets Engine

Correct answer: A new key version is created and used for all new encryption requests going forward, while Vault can still decrypt ciphertext encrypted under earlier versions unless min_decryption_version is raised to exclude them.
Rotating a Transit key creates a new key version; after rotation, new plaintext requests are encrypted with that new version, identifiable from the vault:v<N>: prefix on the ciphertext. Older versions remain available for decryption — Vault picks the correct version automatically based on the ciphertext’s own version marker — until an operator explicitly raises min_decryption_version to retire them.

Why the other options are incorrect:
● All previously encrypted ciphertext becomes permanently undecryptable, since only the newest key version is retained. — Older key versions are kept (in the “working set” or archived) and remain usable for decryption by default; rotation does not immediately discard them.
● Vault automatically re-encrypts every existing ciphertext in the background using the new key version. — Vault does not proactively find and re-encrypt stored ciphertext on rotation; upgrading existing ciphertext to the newest version requires an explicit transit/rewrap call.
● The rotate operation fails unless every application using the key has first called transit/rewrap to clear out old ciphertext. — rotate has no such prerequisite; it succeeds independently of whether any ciphertext has been rewrapped.

Source: Transit Secrets Engine

Correct answer: Submit each ciphertext value to transit/rewrap/<key>, which re-encrypts it under the latest key version without ever exposing the plaintext.
The rewrap endpoint takes existing ciphertext and re-encrypts it under the current key version internally, without revealing the plaintext data to the caller. This lets an untrusted or lower-privileged process upgrade stored ciphertext to the newest key version while keeping the plaintext fully opaque throughout.

Why the other options are incorrect:
● Call transit/keys/<key>/rotate again for each piece of old ciphertext until it reports the latest version. — rotate only creates a new key version; it does not touch, read, or upgrade any already-stored ciphertext.
● Instruct each application to call transit/decrypt, then immediately transit/encrypt again, passing the plaintext through the operator’s terminal for verification. — Routing the recovered plaintext through the operator’s terminal directly exposes it to the operator, which the requirement explicitly forbids.
● Lower min_encryption_version to 0 so Vault transparently re-encrypts stored ciphertext the next time it is read. — min_encryption_version only controls which key versions are permitted for new encryption, signing, or HMAC operations; changing it does not trigger any re-encryption of previously stored ciphertext.

Source: Transit Secrets Engine

Correct answer: It reconstructs the unseal key, which Vault then uses to decrypt the root key
Vault’s encryption model is layered: an encryption key (the barrier key) protects all data in storage, a root key protects the encryption key, and the unseal key protects the root key. By default Vault splits the unseal key into multiple key shares using Shamir’s Secret Sharing. Supplying a threshold number of shares lets Vault reconstruct the unseal key in memory, which it then uses to decrypt the root key and, in turn, unseal the barrier so Vault can read and write data.

Why the other options are incorrect:
● It permanently deletes the barrier encryption key and generates a brand-new one — generating a new encryption key happens during a rekey operation (vault operator rekey), not during a normal unseal.
● It grants the operator a root token with permanent, unlimited access — a root token is only created during vault operator init (or via a separate generate-root workflow); unsealing does not issue any tokens.
● It promotes the node to become the active node in the HA cluster — active-node status is determined by acquiring a lock in the storage backend, a separate mechanism unrelated to the unseal threshold.

Source: Seal/Unseal

Correct answer: 5 total shares; 3 required to unseal
When no key-share options are specified, Vault’s default Shamir configuration generates 5 key shares with an unseal threshold of 3, meaning any 3 of the 5 shares, typically distributed to different trusted operators, can be combined to unseal the cluster.

Why the other options are incorrect:
● 3 total shares; 5 required to unseal — reverses the actual defaults, and a threshold can never exceed the total number of shares that exist.
● 1 total share; 1 required to unseal — this would defeat the purpose of Shamir’s Secret Sharing by concentrating unseal authority in a single share, which is not Vault’s default behavior.
● 5 total shares; 5 required to unseal — sets the threshold equal to the total share count, which is a valid custom configuration but not the out-of-the-box default.

Source: Seal/Unseal

Correct answer: Recovery keys
With auto-unseal, Vault delegates the actual unseal operation to a trusted external service (such as AWS KMS, Azure Key Vault, or an HSM), so operators no longer supply unseal key shares at startup. Vault still generates a set of recovery keys, split via Shamir’s Secret Sharing by default, which operators use for sensitive administrative actions such as generating a new root token or performing a rekey.

Why the other options are incorrect:
● The VAULT_TOKEN environment variable — this holds a client authentication token for CLI requests and has no role in unseal or recovery operations.
● The AWS KMS key policy alone, with no keys held by operators — cloud IAM/KMS policy controls who can use the KMS key to auto-unseal, but administrative operations like root-token generation still require operator-held recovery keys.
● The original Shamir key shares generated at initial setup, which remain valid — once auto-unseal is configured, the original Shamir unseal keys are no longer used; recovery keys take over their administrative role.

Source: Seal/Unseal

Correct answer: VAULT_CACERT
VAULT_CACERT points the Vault CLI to the path of a PEM-encoded CA certificate file, which the CLI uses to verify the TLS certificate presented by the Vault server. This lets the CLI trust a private CA for that specific connection without touching the host’s system-wide trust store.

Why the other options are incorrect:
● VAULT_TOKEN — supplies the Vault-issued token used to authenticate CLI requests; it has nothing to do with verifying the server’s TLS certificate.
● VAULT_ADDR — sets the address (URL) of the Vault server the CLI should talk to, not how its certificate is validated.
● VAULT_SKIP_VERIFY — disables TLS certificate verification altogether, which is insecure and discouraged in production, rather than specifying a CA to trust.

Source: Vault Commands (CLI) — Environment Variables

Correct answer: It successfully acquires a distributed lock within the storage backend
In Vault’s HA model, every node in the cluster races to grab a lock in the shared storage backend (Integrated Storage/Raft, Consul, etc.). The node that wins becomes the active node and services all requests; the rest become standby nodes that forward or redirect requests to the active node until the lock is released.

Why the other options are incorrect:
● It is manually designated as active in the server’s configuration file before startup — Vault does not use static configuration to pick the active node; election is dynamic and based on the storage lock.
● It is simply the node with the lowest IP address in the cluster — Vault has no such IP-based selection mechanism for leadership.
● It is assigned by HashiCorp Cloud Platform, regardless of how the cluster is deployed — lock-based leader election is a core Vault mechanism used by self-managed clusters themselves, not something externally imposed only by HCP.

Source: Vault High Availability

Correct answer: Integrated Storage (Raft), because it is built directly into Vault and removes the need for a separate storage cluster while still supporting HA
Integrated Storage, based on the Raft consensus protocol, is embedded in the Vault binary itself. It stores data directly on the Vault server hosts, requires no additional external software, reduces operational complexity (one less network hop and one less system to monitor), and fully supports high availability — which is why HashiCorp recommends it for most new deployments.

Why the other options are incorrect:
● The file backend, because it persists data to local disk and supports HA out of the box — the file storage backend does not support HA and is documented as unsuitable for production use.
● The inmem backend, because in-memory storage offers the lowest possible latency for production traffic — inmem storage is non-persistent (all data is lost on restart) and is intended only for development and testing, never production.
● Consul, because it has been HashiCorp’s default storage recommendation since Vault’s original release — Consul was the recommended backend before Vault 1.4, but it requires operating a wholly separate Consul cluster, and Integrated Storage is now the recommended default.

Source: Storage Backends

Correct answer: So that no single individual holds enough information alone to unseal Vault, enforcing a trust model that requires multiple operators to cooperate
Shamir’s Secret Sharing distributes trust: the unseal key is split into shares, and a threshold number of distinct shares, typically held by different trusted individuals, must be supplied together before Vault can unseal. This prevents any one person from unilaterally unsealing Vault or being individually responsible for protecting the entire unseal key.

Why the other options are incorrect:
● So that Vault can run with multiple active nodes processing writes to storage at the same time — Vault HA uses a single active node with standbys at any given time; this is unrelated to how the unseal key is split.
● So that each key share can independently decrypt a different secrets engine mounted in Vault — shares must be combined together to reconstruct one unseal key; they do not individually map to separate secrets engines.
● So that Vault automatically rotates its barrier encryption key on a fixed schedule — key rotation is a separate, operator-triggered action (vault operator rekey), not an automatic effect of splitting the unseal key via Shamir.

Source: Seal/Unseal

Correct answer: Tokens and leases
Performance Replication shares configuration, policies, and secrets engine mounts with secondaries so they can serve most read-heavy traffic locally. However, tokens and leases are highly dynamic, so each performance secondary creates and manages its own tokens and leases rather than replicating the primary’s. A client generally must re-authenticate against the specific cluster it is talking to.

Why the other options are incorrect:
● Policies — policies are part of the shared configuration that Performance Replication does propagate to secondaries.
● Secrets engine configuration — secrets engines and their configuration are replicated so secondaries can serve equivalent functionality locally.
● Mount points — mount points are also part of the shared configuration replicated to performance secondaries.

Source: Replication support in Vault

Correct answer: It does not serve service read or write requests until it is elected and promoted to become the new primary
DR Replication maintains a near-complete, continuously updated copy of the primary’s state, including tokens and leases, purely so it can take over quickly if the primary cluster suffers a catastrophic failure. Under normal conditions the DR secondary does not service client read or write requests at all; it only becomes active once it is promoted to replace the primary.

Why the other options are incorrect:
● It load-balances service requests evenly between itself and the primary cluster — sharing live traffic across clusters is the role of Performance Replication secondaries, not a DR secondary.
● It serves only read requests locally while forwarding all writes to the primary — that pattern describes how a Performance Replication secondary generally behaves, not a DR secondary, which serves no client service traffic under normal operation.
● It serves all requests identically to the primary, since DR data is fully synchronized in real time — a DR secondary is a standby replica intended for failover, not an actively-serving cluster, even though its data closely tracks the primary.

Source: Replication support in Vault

Correct answer: With HCP Vault Dedicated, HashiCorp operates the underlying infrastructure and performs version upgrades, while a self-managed cluster’s operator is responsible for both
HCP Vault Dedicated is a hosted version of Vault Enterprise that HashiCorp operates on the customer’s behalf: HashiCorp handles infrastructure monitoring, storage operations and backups, and applies version upgrades, while the customer focuses on Vault configuration, auth methods, secrets engines, and application integration. In a self-managed deployment, the operator is responsible for all of that, including the underlying infrastructure and upgrade process.

Why the other options are incorrect:
● Self-managed clusters cannot use Integrated Storage; only HCP Vault Dedicated supports it — Integrated Storage (Raft) is available, and recommended, for self-managed deployments as well.
● HCP Vault Dedicated requires the customer to apply Vault version upgrades manually, the same as a self-managed cluster — HashiCorp performs upgrades for HCP Vault Dedicated clusters; this is one of the key operational burdens it removes from the customer.
● Only self-managed Vault supports high availability; HCP Vault Dedicated always runs as a single node — HCP Vault Dedicated clusters are built for high availability, not run as single nodes.

Source: What is HCP Vault Dedicated?

Correct answer: Vault Agent
Vault Agent is a client-side daemon that runs alongside an application. Its auto_auth block handles authenticating to Vault and renewing the resulting token automatically, and its template block can render secrets retrieved from Vault into a file on disk, so an unmodified legacy application can simply read that file instead of calling the Vault API itself.

Why the other options are incorrect:
● Vault Secrets Operator — synchronizes Vault secrets into native Kubernetes Secret objects for pods running in a Kubernetes cluster; it is not a general-purpose sidecar for arbitrary applications outside Kubernetes.
● The Vault UI — is a web interface intended for human operators to interact with Vault, not a background process that delivers secrets to applications.
● A Vault audit device — records requests and responses to Vault for compliance and troubleshooting; it does not authenticate on an application’s behalf or deliver secrets to it.

Source: Vault Agent

Correct answer: VaultStaticSecret
The Vault Secrets Operator (VSO) watches custom resources and syncs the secret data they describe into Kubernetes-native Secret objects, so pods can consume them without talking to Vault directly. A VaultStaticSecret resource synchronizes a single Vault static secret, from the KV v1 or KV v2 secrets engine, to a single Kubernetes Secret.

Why the other options are incorrect:
● VaultConnection — defines how VSO reaches a given Vault server instance (address and TLS settings), not which secret to sync.
● VaultAuth — configures the authentication method and credentials VSO uses to log in to Vault, not the secret synchronization itself.
● VaultDynamicSecret — is used for dynamic or rotated credentials from engines such as databases or cloud secrets engines, not for a static KV secret.

Source: Vault Secrets Operator — Vault as a secrets source