514 questions total · 7pages · All types, answers revealed
Where can you view a list of all active tokens in Vault?
Both commands list token accessors, which represent active tokens.
Why this answer
Both `vault token list` and `vault list auth/token/accessors` list token accessors, which represent active tokens.
A company stores static secrets in Vault and requires that all data is encrypted at rest in the storage backend. Which Vault feature provides this encryption?
The barrier encrypts all data at rest.
Why this answer
C is correct because Vault's storage encryption is handled by the security barrier, which automatically encrypts all data written to the storage backend using a 256-bit AES-GCM encryption key. This ensures that data is encrypted at rest regardless of the storage backend's own capabilities, meeting the requirement without relying on backend-specific features.
Exam trap
HashiCorp often tests the misconception that storage backend encryption (e.g., Consul's built-in encryption) is required or sufficient, when in fact Vault's barrier provides mandatory encryption at rest that is independent of the backend.
How to eliminate wrong answers
Option A is wrong because the storage backend itself does not need to be configured to encrypt data; Vault's barrier handles encryption transparently, and the backend only stores the encrypted ciphertext. Option B is wrong because the transit secrets engine is used for encrypting application data in transit or at rest outside Vault, not for encrypting Vault's own stored secrets. Option D is wrong because relying on the storage backend's built-in encryption (e.g., Consul's encryption) is optional and not required by Vault; Vault's barrier provides its own encryption layer independent of the backend.
An application is failing to decrypt data using the transit secrets engine. The ciphertext was generated with key 'my-key' version 3, but the engine currently shows key version 5. What is the most likely cause of the failure?
If min_decryption_version is higher than the ciphertext's key version, decryption is denied.
Why this answer
The transit secrets engine allows configuring a minimum decryption version (`min_decryption_version`) for each key. If this value is set to 4, the engine will refuse to decrypt any ciphertext generated with key version 3, even if version 3 still exists in the key ring. This is the most direct and likely cause of the failure, as the ciphertext was created with version 3 but the engine now enforces a higher minimum version.
Exam trap
HashiCorp often tests the misconception that key rotation automatically invalidates older ciphertext, but the actual mechanism is the `min_decryption_version` setting, which explicitly controls which versions are allowed for decryption.
How to eliminate wrong answers
Option B is wrong because the ciphertext was explicitly generated with key 'my-key', and the failure is tied to version mismatch, not a different key name. Option C is wrong because key rotation does not automatically re-encrypt existing ciphertext; the transit engine never re-encrypts data automatically, and decryption with older versions is allowed unless `min_decryption_version` blocks it. Option D is wrong because the encryption algorithm is set at key creation time and does not change with version bumps; the algorithm remains consistent across versions of the same key.
An administrator wants to use Vault's authentication method that allows users to log in with their corporate credentials via a federated identity system. The credentials are stored in an external identity provider (IdP) and Vault should not store any passwords. Which authentication method should be configured?
Uses external IdP for authentication, no password stored in Vault.
Why this answer
OIDC authentication delegates authentication to an external IdP, Vault never sees the password. LDAP stores hashed passwords at rest, userpass stores hashed passwords, and token is Vault-native.
A periodic token is created with a TTL of 30 days. After 60 days, the token is still in use but suddenly stops working. What is the most likely reason?
Periodic tokens can be revoked at any time; the most likely cause after 60 days is revocation.
Why this answer
Periodic tokens have an explicit_max_ttl default of 0 (unlimited) but if the token role has a max_ttl set, it will enforce that. However, the common reason is that the token was revoked. Option A is wrong because periodic tokens do not have a default max TTL.
Option B is wrong because explicit_max_ttl is typically 0 for periodic tokens unless set. Option D is wrong because there is no default max TTL for periodic tokens.
An organization uses the AWS secrets engine to generate IAM users dynamically. They notice that the generated IAM user is not immediately available for use in AWS. What is the most likely reason?
AWS IAM has eventual consistency, causing a short delay.
Why this answer
Option D is correct because AWS IAM is an eventually consistent system. When Vault uses the AWS secrets engine to create an IAM user via the CreateUser API call, the user is not immediately available across all AWS services due to propagation delays. This eventual consistency means the generated IAM user may take a few seconds to be fully usable, which is a known behavior of AWS IAM.
Exam trap
The trap here is that candidates may confuse eventual consistency with a Vault-side failure or misconfiguration, such as a short TTL or a write failure, rather than recognizing it as an inherent property of AWS IAM.
How to eliminate wrong answers
Option A is wrong because a Vault write operation failure due to network latency would result in an error response from Vault, not a delayed availability of the IAM user; the user would simply not be created. Option B is wrong because the TTL on the role controls how long the generated credentials are valid, not the time it takes for the IAM user to become available after creation. Option C is wrong because Vault does not wait for AWS secret key rotation before returning the user; the AWS secrets engine creates the IAM user and returns credentials immediately, with propagation delay being an AWS-side behavior.
Drag and drop the steps to configure Vault's AWS secrets engine to generate IAM credentials into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Enable, configure root, create role, generate creds, rotate root.
A large e-commerce company uses Vault to manage database credentials for microservices. They have a Vault cluster of 5 nodes using Integrated Storage (Raft). To increase capacity, they add a sixth node to the cluster. Shortly after, they notice intermittent 'no leader' errors in the Vault logs, and some clients experience failures when reading secrets. The cluster was functioning correctly before the addition. What is the most likely cause and the recommended action?
Raft performs best with an odd number of nodes to avoid split-brain. With 6 nodes, quorum is 4, and a partition could lead to no leader.
Why this answer
Option A is correct. Adding a sixth node creates an even-numbered cluster, which increases the risk of split-brain and leader election issues. The recommended action is to revert to an odd number (5 or 7).
Other options are less likely given the symptoms.
A company wants to grant developers the ability to read and write secrets under the path 'secret/dev/*', but only they should be able to delete their own secrets. Which policy design best meets this requirement?
Correctly grants full access to the dev path, but delete is only allowed on the user's own sub-path using entity name.
Why this answer
Option D is correct because it grants full CRUDL access to 'secret/dev/*' for reading and writing, but then restricts delete to only the path 'secret/dev/{{identity.entity.name}}/*', which uses the entity's name to ensure developers can only delete secrets under their own sub-path. This leverages Vault's identity entity name templating to enforce per-developer delete scoping.
Exam trap
HashiCorp often tests the distinction between wildcard '*' (matches any number of segments) and '+' (matches exactly one segment), and the use of identity template variables to scope permissions per entity, which candidates may overlook by choosing a broad delete permission.
How to eliminate wrong answers
Option A is wrong because it grants delete on the entire 'secret/dev/*' path, allowing any developer to delete any secret, violating the requirement that only they should delete their own. Option B is wrong because it only allows read and list, not create, update, or delete, so developers cannot write secrets at all. Option C is wrong because the path pattern 'secret/dev/+/{{identity.entity.name}}' uses a wildcard '+' for a single segment, but the requirement is for secrets under 'secret/dev/*'; also, it grants delete on that specific path but does not allow creating or updating secrets under other sub-paths, and the '+' does not match multi-segment paths.
When running Vault in development mode, which storage backend is used by default?
Dev mode uses an in-memory backend by default.
Why this answer
When Vault is started in development mode using `vault server -dev`, it defaults to an in-memory storage backend. This is explicitly designed for local testing and development, as all data is stored in memory and lost when the process terminates. The in-memory backend requires no configuration and is automatically selected when no `-dev` flag overrides are provided.
Exam trap
HashiCorp often tests the distinction between development mode defaults and production mode defaults, trapping candidates who assume that Raft integrated storage (the production default) is also the development default, or who confuse the file system backend path with a default setting.
How to eliminate wrong answers
Option A is wrong because Raft integrated storage is the default for Vault in production mode (when no storage backend is explicitly configured), but not for development mode; development mode always uses the in-memory backend. Option B is wrong because the file system backend at /var/lib/vault is a common production storage backend but is never the default in development mode; it must be explicitly configured in the Vault configuration file. Option D is wrong because Consul backend is an external storage backend that requires a separate Consul cluster and is never the default in any Vault mode; it must be explicitly specified.
A Vault administrator needs to create a policy for a developer who must read and list secrets from the path 'secret/data/engineering/' and create new secrets under 'secret/data/engineering/projects/'. Which two policy statements should the administrator include? (Choose two.)
Correct: Grants create capability on the projects subpath, fulfilling the create requirement with minimal permissions.
Why this answer
The correct statements are A and D. Statement A grants read and list on all secrets under engineering/. Statement D grants create on the projects/ subpath.
Other options either have incorrect paths (B, E) or grant unnecessary capabilities (C).
A cloud-native application uses Vault's Kubernetes auth method to inject tokens into pods. Each pod receives a Vault token with a TTL of 1 hour, renewable. The application is designed to renew tokens before they expire. However, after a recent update, some pods are failing to authenticate with Vault, reporting 'token not found' errors. The operations team checks the Vault audit logs and sees that tokens associated with these pods are being revoked immediately after creation. The pods have not performed any revocation. What is the most likely cause?
Correct: Vault automatically revokes tokens when the underlying identity (service account) is removed or the JWT becomes invalid.
Why this answer
The Kubernetes auth method in Vault can be configured with 'kubernetes_ca_cert' and 'token_reviewer_jwt' for validation. If the service account token used by the pod is invalid or expired, Vault will revoke the derived Vault token. Additionally, if the pod's service account is deleted or permissions change, Vault will revoke tokens.
Option B is correct because if the Kubernetes service account token is invalid or the service account is deleted, Vault revokes associated tokens. Option A is incorrect because the auth method's JWT validation does not cause token revocation of derived tokens. Option C is incorrect because renewing the token does not cause revocation.
Option D is incorrect because the Vault token is not tied to a batch token creation.
Match each Vault storage backend to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Highly available, key-value store
Integrated storage with consensus
Local filesystem storage
AWS object storage
AWS NoSQL database
Why these pairings
These are common Vault storage backends.
A DevOps engineer needs to create a token that can only read secrets under the path 'secret/engineering'. What is the recommended approach?
A custom policy with minimal privileges follows the principle of least privilege.
Why this answer
Option D is correct because creating a policy with the read capability on the specific path and issuing a token with that policy is the best practice. Option A is wrong because using a root token grants full access. Option B is wrong because the default policy allows extensive access.
Option C is wrong because simply setting a TTL does not restrict access.
A user runs 'vault write secret/mydata value=hello' and gets a warning about missing metadata. They intended to store a simple key-value pair. What is the most likely issue?
B is correct: KV v2 expects path like secret/data/mydata.
Why this answer
The warning about missing metadata indicates the path is under a KV v2 secret engine, which requires the `data/` prefix before the path (e.g., `vault write secret/data/mydata value=hello`). KV v2 stores metadata and versioned data separately, so writing directly to `secret/mydata` triggers a warning because it expects the `data/` subpath. This is the most likely issue given the user's intent to store a simple key-value pair.
Exam trap
HashiCorp often tests the distinction between KV v1 and KV v2 path requirements, trapping candidates who assume all key-value engines use the same flat path structure without the `data/` prefix.
How to eliminate wrong answers
Option A is wrong because KV v2 accepts plain string values like `value=hello`; JSON encoding is optional and not required for simple key-value pairs. Option B is wrong because the warning specifically mentions missing metadata, not a permission error; if the token lacked write capability, the command would return a 403 Forbidden error, not a warning. Option D is wrong because if the secret engine were not enabled, the command would fail with an error like 'no secret engine mounted at secret/', not a warning about metadata.
A company is using Vault's PKI secrets engine to issue certificates for internal services. They have set up a root CA and an intermediate CA. The intermediate CA's certificate expires soon, and they need to renew it. They generate a new intermediate CSR and have it signed by the root CA. After importing the new intermediate certificate, the team notices that certificates issued by the old intermediate are still valid but new certificate requests fail with 'no valid intermediate CA found'. What step did the team likely miss?
After signing the CSR, the signed certificate must be written back to the intermediate mount via set-signed endpoint.
Why this answer
In Vault's PKI secrets engine, after the root CA signs a new intermediate certificate, the signed certificate must be explicitly set as the issuing CA for the intermediate's mount. This is done by writing the signed certificate to the `pki/intermediate/set-signed` endpoint. Without this step, the intermediate mount still references the old (expiring) certificate, causing new certificate requests to fail with 'no valid intermediate CA found' because Vault cannot locate a valid issuing certificate for signing operations.
Exam trap
HashiCorp often tests the specific API workflow of Vault's PKI secrets engine, where candidates confuse the CSR generation and signing process with the final step of importing the signed certificate via `set-signed`, assuming that simply having the signed certificate in the mount path is sufficient.
How to eliminate wrong answers
Option B is wrong because updating CRL distribution points is a configuration detail for certificate revocation, not a prerequisite for the intermediate to be recognized as a valid issuing CA; the immediate failure is due to the missing set-signed step, not CRL endpoints. Option C is wrong because changing the root CA's key algorithm would require re-signing the entire chain and is unrelated to the described renewal process; the question states they generated a new CSR and had it signed by the root CA, implying no algorithm change. Option D is wrong because revoking the old intermediate CA is not required before importing the new one; Vault can have multiple intermediate certificates in the same mount, and the old one remains valid until its expiration — the issue is that the new certificate was not set as the active issuing CA.
A developer wants to authenticate to Vault using a username and password without any external identity provider. Which authentication method should be enabled?
Userpass allows local username/password authentication.
Why this answer
The userpass authentication method is designed for Vault to authenticate users directly with a username and password, without relying on any external identity provider. It stores the credentials within Vault's own backend, making it the correct choice for a standalone authentication scenario where no external system like LDAP or an OIDC provider is involved.
Exam trap
HashiCorp often tests the distinction between authentication methods that require external dependencies versus those that are self-contained; the trap here is that candidates may confuse token authentication (which is a result, not a method) with a credential-based login, or assume LDAP is the only option for username/password authentication.
How to eliminate wrong answers
Option B (Token authentication) is wrong because tokens are the result of a successful authentication, not a method for authenticating with a username and password; tokens are issued after authentication and are used for subsequent requests. Option C (LDAP authentication) is wrong because it requires an external LDAP directory service (e.g., OpenLDAP or Active Directory) to validate credentials, which contradicts the requirement of no external identity provider. Option D (AppRole authentication) is wrong because it is designed for machine-to-machine authentication using a RoleID and SecretID, not for human users providing a username and password.
A company needs to automatically generate short-lived database credentials for developers. Which secrets engine should they use?
Database engine creates dynamic credentials.
Why this answer
The Database secrets engine is specifically designed to generate short-lived, dynamic database credentials on demand. It connects to a database and creates unique user accounts with configurable time-to-live (TTL) values, which are automatically revoked when the lease expires. This directly meets the requirement for automatically generating temporary database credentials for developers.
Exam trap
HashiCorp often tests the distinction between secrets engines that generate dynamic credentials (like Database, AWS) versus those that only store static secrets (like KV v2), leading candidates to mistakenly choose KV v2 because it is the most commonly used engine for general secret storage.
How to eliminate wrong answers
Option A is wrong because KV v2 is a static key-value store that does not generate dynamic credentials; it stores secrets as-is and does not support automatic credential rotation or TTL-based expiration. Option B is wrong because the AWS secrets engine generates dynamic credentials for AWS services (e.g., IAM users, STS tokens), not for databases. Option C is wrong because Cubbyhole is a per-token private storage space that is tied to the lifetime of the token itself and cannot be used to generate or manage database credentials for other users.
A DevOps team uses Vault to manage secrets for a microservices application. The application authenticates to Vault using AppRole, and each service obtains a periodic token with a TTL of 24 hours and a period of 1 hour. The tokens are used to read secrets from a path. Recently, the team noticed that some services are unable to read secrets after a few hours, with error messages indicating that the token is not authorized or has expired. Upon investigation, the team finds that the tokens are being renewed properly but still fail after some time. What is the most likely cause of this issue?
Correct: Periodic tokens have a max TTL that caps total lifetime; if max TTL is less than the period, the token will expire and cannot be renewed.
Why this answer
The issue is that periodic tokens have a maximum TTL that cannot be exceeded. While the period allows the token to be renewed before it expires, the overall lifetime is capped by the max TTL. In this scenario, the token's max TTL is likely set to a value shorter than 24 hours (e.g., default 32 days, but could be overridden).
However, the specific symptom suggests that after a few hours, tokens expire and cannot be renewed because they have reached their max TTL. Option B directly addresses the max TTL. Option A is incorrect because the error is about authorization/expiration, not resource limits.
Option C is incorrect because tokens are renewable by design with the period. Option D is incorrect because the auth method does not cause such expiration errors.
A company has a Vault cluster and wants to allow applications running in Kubernetes pods to authenticate without storing static secrets. Which Vault authentication method is specifically designed for Kubernetes?
Kubernetes auth uses the pod's service account token.
Why this answer
The Kubernetes auth method is specifically designed for Kubernetes workloads. It allows pods to authenticate to Vault using their Kubernetes service account token, which Vault validates against the Kubernetes API server. This eliminates the need to store static secrets in the cluster.
Exam trap
HashiCorp often tests the distinction between 'designed for Kubernetes' (Kubernetes auth) and 'can be used with Kubernetes' (JWT/OIDC or AppRole), leading candidates to pick a generic method that works but is not purpose-built.
How to eliminate wrong answers
Option A is wrong because AWS IAM is an authentication method for AWS EC2 instances or Lambda functions, not for Kubernetes pods. Option C is wrong because JWT/OIDC is a generic method for any OIDC-compliant identity provider, not specifically designed for Kubernetes; it requires manual JWT management and does not leverage Kubernetes service account tokens natively. Option D is wrong because AppRole uses a secret ID and role ID, which are static credentials that must be stored somewhere, defeating the purpose of avoiding static secrets in Kubernetes.
A team wants to store static secrets like database passwords and rotate them periodically. Which secrets engine should they enable?
KV v2 supports versioning and can store static secrets with rotation capabilities.
Why this answer
The KV v2 secrets engine is designed for static secrets like database passwords, offering versioning, configurable deletion, and periodic rotation via lease management or external automation. It stores secrets as key-value pairs with metadata, making it ideal for static credentials that need controlled lifecycle management.
Exam trap
HashiCorp often tests the distinction between secrets engines that generate dynamic secrets (like AWS or PKI) versus those that store static secrets (like KV v2), leading candidates to confuse 'rotation' with 'dynamic generation' and pick a dynamic engine instead.
How to eliminate wrong answers
Option A is wrong because the AWS secrets engine is specifically for dynamically generating AWS IAM credentials or accessing AWS Secrets Manager, not for storing static secrets locally in Vault. Option B is wrong because the PKI secrets engine generates and manages X.509 certificates, not static passwords or secrets. Option C is wrong because the Transit secrets engine performs encryption/decryption operations on data in transit without storing secrets; it is a cryptographic function, not a storage backend.
A token with this policy attempts to read the secret at path 'secret/data/engineering/special'. Will the read succeed?
The wildcard includes 'special'.
Why this answer
Option A is correct because the first path grants read on secret/data/engineering/*, which includes 'special'. The second path grants create/update on a different path (without 'data' prefix) and does not deny read. Vault merges capabilities, so read is allowed.
Option B is wrong because ACL merging does not cause one statement to override another unless there is an explicit deny. Option C is wrong because the token already has a policy covering that path. Option D is wrong because the second path does not grant read but also does not deny it.
A token is created with policies 'default' and 'web-app'. Later, a parent token's policy is updated to add 'logging'. The child token's policies are not updated. What will happen when the child token is used?
Token policies are set at creation and do not change.
Why this answer
Token policies are snapshotted at creation time; they do not inherit changes from parent tokens. Therefore, the child token still has only 'default' and 'web-app'. Option A is wrong because parent token changes do not propagate.
Option C is wrong because Vault does not automatically refresh policy. Option D is wrong because the token is not invalidated.
An organization uses the transit engine with key rotation. They want to ensure that data encrypted with an older key version can be decrypted by Vault, but only if the key has not been deleted. Which of the following must be true?
Archived key versions are removed from the decryption set and cannot be used.
Why this answer
In Vault's transit engine, key rotation creates new key versions while preserving older ones. The ability to decrypt data encrypted with an older key version depends on whether that version is still available in the key's version history. Archiving a key removes all versions from the active key ring, making decryption of data encrypted with any version of that key impossible.
Therefore, the key must not have been archived to allow decryption of data encrypted with an older key version, provided the key itself has not been deleted.
Exam trap
HashiCorp often tests the distinction between key deletion and key archiving, where candidates mistakenly assume that as long as a key is not deleted, older versions remain decryptable, overlooking that archiving also removes access to all versions.
How to eliminate wrong answers
Option A is wrong because `min_decryption_version` controls the minimum version allowed for decryption, not the ability to decrypt older versions; setting it to 1 would allow decryption of all versions, but it does not address the condition that the key must not be deleted. Option B is wrong because `allow_plaintext_backup` permits exporting the key in plaintext for backup purposes, but it has no effect on the ability to decrypt data with older key versions. Option C is wrong because `deletion_allowed` controls whether the key can be deleted entirely, but even if deletion is not allowed, the key could still be archived, which would prevent decryption of older versions.
Option D is wrong because `latest_version` being greater than 0 simply indicates that at least one version exists; it does not guarantee that older versions are available for decryption if the key has been archived.
An organization is implementing Vault policies for the first time. They want to ensure that policies are easy to manage and follow the principle of least privilege. Which approach should they take when creating policies?
This enables granular, least-privilege access based on application needs.
Why this answer
Option D is correct because creating separate policies per application and using group aliases to attach them allows granular control and follows least privilege. Option A is monolithic and insecure. Option B gives too much power.
Option C is backwards; tokens inherit policies, not the other way.
A Vault administrator needs to allow users to authenticate using their existing corporate Active Directory credentials. The administrator has configured the LDAP authentication method but users cannot log in. The Vault logs show 'LDAP bind successful' but then 'user not found in group' error. What is the most likely issue?
Group membership check fails after bind.
Why this answer
The error 'LDAP bind successful' confirms that the Vault server can connect and authenticate to the LDAP server using the bind credentials. The subsequent 'user not found in group' error indicates that while the user exists and can bind, the group membership lookup fails. This is most commonly caused by an incorrect `groupfilter` or `groupattr` configuration, which defines how Vault queries the LDAP directory to map users to groups for authorization.
Exam trap
HashiCorp often tests the distinction between authentication (bind) and authorization (group lookup) — candidates mistakenly focus on the bind success and assume the issue is with user attributes or server connectivity, when the real problem lies in the group membership configuration.
How to eliminate wrong answers
Option A is wrong because an incorrect LDAP server hostname would cause a connection failure, not a successful bind. Option B is wrong because the `userattr` configuration controls how the user's DN is derived during login; a successful bind implies this is correct. Option D is wrong because anonymous queries are not required for group lookup; Vault uses the bind credentials (or a configured service account) to perform the group search, so anonymous access is irrelevant.
A DevOps engineer runs `vault token lookup s.abc123` and receives a permission denied error. The engineer has a valid token with the default policy attached. What is the most likely cause?
The default policy only allows self token lookup, not other tokens.
Why this answer
The default policy in Vault is intentionally restrictive and does not include the `token/lookup` capability for tokens other than the caller's own token. Since the engineer is attempting to look up a specific token ID (`s.abc123`) rather than their own token, the default policy denies this action. The permission denied error is expected because the default policy only allows basic operations like reading system capabilities and managing the caller's own token, not inspecting other tokens.
Exam trap
HashiCorp often tests the misconception that the default policy grants broad token management capabilities, when in reality it only allows self-service operations and denies any cross-token inspection unless explicitly permitted via a custom policy with sudo capabilities.
How to eliminate wrong answers
Option A is wrong because the default policy does include the `token/lookup` capability for the caller's own token (via the `self` path), but the engineer is trying to look up a different token, which requires a policy that explicitly grants `token/lookup` on the specific token ID or a broader path. Option B is wrong because if the token were expired or revoked, the `vault token lookup` command would return an error like 'token not found' or 'bad token', not a permission denied error; permission denied indicates the token is valid but lacks authorization. Option C is wrong because the engineer used a token ID (starting with `s.`), not a token accessor (which starts with `a.`); using an accessor would also require specific policy permissions and would not cause a permission denied error in this context.
Which THREE statements are true about Vault's encryption as a service using the transit engine?
Old versions are kept for decryption.
Why this answer
Option B is correct because Vault's transit engine supports key rotation while maintaining the ability to decrypt data encrypted with previous key versions. When a key is rotated, Vault creates a new version of the key, but the old version is retained for decryption purposes. This allows clients to decrypt ciphertext that was encrypted with an earlier key version, ensuring data remains accessible after rotation.
Exam trap
HashiCorp often tests the misconception that key rotation invalidates previous ciphertext, but Vault's transit engine retains old key versions specifically to allow decryption of data encrypted before rotation.
A team needs to issue unique tokens to each of 100 microservices, each with its own policy, and ensure that revoking one token does not affect others. Which token feature should they use?
Token roles enable creation of tokens with specific policies, providing isolation.
Why this answer
Token roles allow creating tokens with specific policies and settings. Each microservice can have its own token role with a distinct policy, ensuring isolation.
A company has deployed Vault with an LDAP auth method and has created entity aliases for all users. The company uses KV v2 secrets engine mounted at 'secret/'. Each team's secrets are stored under a path like 'secret/data/team_<team_name>/'. They have multiple teams (engineering, marketing, sales). Currently, an administrator manually creates a separate policy for each team, e.g., path "secret/data/team_engineering/*" { capabilities = ["read", "list"] }. This is becoming cumbersome as new teams are added. The administrator wants to create a single policy that dynamically grants read access to the secrets path corresponding to the user's team, which is stored in the entity's metadata as 'team'. The LDAP auth method is configured to sync group memberships and map to entity aliases, and the entity metadata is correctly populated. Which approach should the administrator take?
This uses entity metadata to dynamically match the correct team path.
Why this answer
Option B is correct because Vault's policy templating allows using {{identity.entity.metadata.team}} to dynamically insert the team name from the entity's metadata into the path. This creates a single policy that works for all teams without manual updates. Option A gives too broad access.
Option C is not a valid policy mechanism. Option D is insecure and not scalable.
A company uses Kubernetes auth. A pod in namespace 'prod' with service account 'my-sa' can authenticate and read secrets. After upgrading the Kubernetes cluster, the same pod fails to authenticate with error 'JWT token issuer is not valid'. What is the most likely cause?
Vault's configuration must match the cluster's issuer, which may change on upgrade.
Why this answer
The error 'JWT token issuer is not valid' indicates that the Kubernetes cluster's issuer URL (typically found in the service account token's `iss` claim) has changed after the upgrade. Vault's Kubernetes auth method must be configured with the correct `kubernetes_ca_cert`, `kubernetes_host`, and crucially the `issuer` parameter. If the cluster's new issuer (e.g., `https://kubernetes.default.svc.cluster.local` or a custom OIDC issuer) does not match the one stored in Vault's configuration, Vault will reject the JWT during validation, causing authentication to fail.
Exam trap
HashiCorp often tests the distinction between authentication failures (issuer mismatch, token validation) and authorization failures (role bindings, service account names), so candidates mistakenly choose Option B when the error message explicitly points to the JWT issuer.
How to eliminate wrong answers
Option A is wrong because deleting the service account would cause a different error (e.g., 'service account not found' or 'token not found'), not a JWT issuer validation error. Option B is wrong because `bound_service_account_names` controls authorization (which service accounts are allowed to use a role), not the JWT issuer validation; an incorrect role binding would result in a permission denied error, not an issuer error. Option C is wrong because if the Vault server's Kubernetes API address changed, the error would be a connection or TLS error (e.g., 'dial tcp: lookup' or 'x509: certificate is valid for'), not a JWT issuer validation error.
A security team must automate periodic credential rotation for a database. The rotation script should run on a server that cannot have the Vault binary installed but can make HTTP requests. Which approach should they use?
C is correct: the API can be called via HTTP without the vault binary.
Why this answer
Option C is correct because the server can make HTTP requests, allowing it to interact with Vault's RESTful API directly without installing the Vault binary. The Vault API supports token-based authentication (e.g., using X-Vault-Token header) and can be used to programmatically rotate database credentials by calling the appropriate endpoint (e.g., POST /v1/database/rotate-root/:name). This approach satisfies the constraint of no binary installation while enabling secure, automated credential rotation.
Exam trap
HashiCorp often tests the distinction between using the Vault API directly versus relying on the Vault CLI or Agent, trapping candidates who assume that automation always requires the Vault binary or that Vault Agent is a lightweight alternative that doesn't need installation.
How to eliminate wrong answers
Option A is wrong because the Vault CLI is a binary that must be installed on the server, which violates the constraint that the server cannot have the Vault binary installed; wrapping CLI commands with curl does not eliminate the need for the binary. Option B is wrong because it explicitly requires installing the Vault binary on the server, which is prohibited by the scenario. Option D is wrong because Vault Agent is a separate binary that must be installed and configured on the server; it is not a solution for a server that cannot have the Vault binary installed.
A company uses both userpass and AppRole authentication methods. They notice that tokens issued via AppRole are not properly revoked when the corresponding secret_id is deleted. Which concept explains this behavior?
The secret_id is used only during login; once the token is issued, it is separate.
Why this answer
When a token is issued via AppRole, the token is created after a successful login using a secret_id. The token itself is independent of the secret_id; deleting the secret_id does not affect the token's lifecycle. Token revocation must be performed explicitly on the token, not by removing the secret_id.
Exam trap
The trap here is that candidates mistakenly believe that deleting the authentication credential (secret_id) will cascade to revoke the token, when in fact tokens and their authentication credentials are independent after login.
How to eliminate wrong answers
Option A is wrong because the secret_id TTL controls the validity of the secret_id itself, not the token's lifetime; even if the secret_id expires, the token remains valid until its own TTL or explicit revocation. Option B is wrong because AppRole does support entity aliases when used with identity entities, but the core issue is that tokens are decoupled from the secret_id after login, not the presence or absence of entity aliases. Option C is wrong because periodic tokens can be revoked just like any other token; the periodic nature only affects renewal behavior, not revocability.
A Vault cluster configured with auto-unseal using AWS KMS is deployed across two availability zones. After a network partition, the standby node remains sealed while the active node is unsealed and serving requests. What is the most likely reason the standby cannot unseal?
Auto-unseal requires network access to the seal provider.
Why this answer
In a Vault cluster with auto-unseal via AWS KMS, each node must independently communicate with AWS KMS to unseal itself. A network partition that isolates the standby node from AWS KMS prevents it from reaching the KMS endpoint, so it cannot decrypt its unseal key and remains sealed. The active node is unaffected because it is already unsealed and serving requests from the other side of the partition.
Exam trap
The trap here is that candidates may confuse the cluster replication traffic (which uses the cluster address) with the auto-unseal traffic (which uses outbound HTTPS to AWS KMS), leading them to incorrectly select Option C.
How to eliminate wrong answers
Option A is wrong because the standby node would use the same AWS region configuration as the active node (typically set in Vault's configuration file or environment variables), and a network partition does not change the region setting; a misconfigured region would cause persistent unseal failures regardless of partition. Option B is wrong because KMS API quotas are per-account per-region and are not consumed by a single node; even if quota were exhausted, it would affect both nodes equally, not selectively leave the standby sealed. Option C is wrong because the cluster address is used for Raft or integrated storage replication between nodes, not for the auto-unseal process; a misconfigured cluster address would affect replication health but not the standby's ability to contact AWS KMS.
A multinational corporation uses Vault Enterprise with the transit engine to encrypt sensitive financial data across multiple cloud regions. Each region has its own Vault cluster, and they use performance replication to synchronize transit keys. Recently, the team in the Asia-Pacific region reports that encryption operations are slower than in other regions. They also notice that some decryption requests for data encrypted with a key that was rotated in the primary region are failing with 'key version not found' errors. The transit key is named 'fin-key' and has been rotated three times. The Asia-Pacific cluster is up-to-date with replication according to the replication status dashboard. Which action should the operations team take to resolve the decryption failures?
Policy might be missing decrypt on older versions.
Why this answer
The decryption failures are caused by missing key versions in the Asia-Pacific cluster's transit engine. Even though performance replication synchronizes transit keys, older key versions may not be replicated if the transit engine's key version caching or policy does not explicitly grant access to them. Verifying that the policy includes 'decrypt' capability on the key path for older key versions ensures that the cluster can serve decryption requests for data encrypted with rotated keys.
Exam trap
HashiCorp often tests the misconception that replication automatically grants all capabilities, but the trap here is that policy must explicitly allow access to older key versions, and candidates may incorrectly focus on replication health or manual key copying instead.
How to eliminate wrong answers
Option B is wrong because increasing the performance standby count improves read scalability and failover speed, but does not resolve missing key versions or policy restrictions. Option C is wrong because manually copying key material violates Vault's security model and replication design; performance replication automatically synchronizes transit keys, and manual intervention is neither supported nor necessary. Option D is wrong because re-encrypting all data with the current version is a costly workaround that does not address the root cause—the policy or replication issue preventing access to older key versions.
Which THREE API endpoints are valid for managing policies in Vault?
GET retrieves the named policy.
Why this answer
The GET, DELETE, and POST endpoints are valid for managing policies in Vault. GET retrieves a policy, DELETE removes it, and POST creates or updates a policy. These correspond to the standard CRUD operations supported by Vault's sys/policy API.
Exam trap
HashiCorp often tests the misconception that PUT is the standard HTTP method for creating/updating resources in Vault, but Vault specifically uses POST for policy management, making PUT an invalid choice.
A DevOps team is using Vault's database secrets engine to generate dynamic credentials for a PostgreSQL database. They notice that the lease duration is set to 24 hours, but security policy requires that credentials expire after 1 hour. What should the team do to enforce the 1-hour expiration without changing the default lease TTL for all secrets?
The role-level ttl overrides the default lease TTL.
Why this answer
Option C is correct because the database secrets engine allows role-level TTL configuration that overrides the default lease duration for credentials generated from that role. By setting the role's `ttl` to 1h, the team enforces a 1-hour expiration for credentials created under that specific role without affecting the default lease TTL for all secrets or other roles. This directly meets the security policy requirement while maintaining flexibility for other secrets.
Exam trap
The trap here is that candidates often confuse mount-level TTL settings with role-level TTL settings, assuming that changing the mount's `max_lease_ttl` is the only way to enforce expiration, when in fact role-level configuration provides granular control without affecting other secrets.
How to eliminate wrong answers
Option A is wrong because setting the mount's `max_lease_ttl` to 1h would enforce a hard upper limit on all secrets generated from that mount, including other roles or engines, which violates the requirement to not change the default lease TTL for all secrets. Option B is wrong because relying on each developer to set the TTL when requesting credentials is error-prone and does not enforce the policy centrally; developers might forget or intentionally set a longer TTL, leading to non-compliance. Option D is wrong because periodic tokens are used for long-lived tokens that automatically renew, not for database credentials; they do not control the TTL of dynamic credentials generated by the database secrets engine.
An admin creates a token with TTL=48h and explicit_max_ttl=120h. The token is renewed every 24h. After 10 days, will the token still be valid?
Explicit_max_ttl caps the total lifetime regardless of renewals.
Why this answer
The token's total lifetime cannot exceed the explicit_max_ttl of 120h (5 days). After 10 days, it would have exceeded this limit and become invalid.
Refer to the exhibit. Based on the output from 'vault status', which statement is true?
Total Shares is 5, Threshold is 3.
Why this answer
The 'vault status' output shows 'Sealed: false', 'Key Shares: 5', and 'Key Threshold: 3'. This indicates that Vault is unsealed and uses a Shamir seal configuration with 5 key shares, requiring any 3 of them to unseal. Option B correctly states this unseal configuration.
Exam trap
HashiCorp often tests the distinction between 'storage backend' and 'seal type' — candidates confuse the Consul storage backend with auto-unseal, but auto-unseal requires a separate seal provider like AWS KMS, not Consul.
How to eliminate wrong answers
Option A is wrong because the output shows 'Storage Type: consul', not 'file', so the storage backend is Consul, not a file backend. Option C is wrong because the output shows 'Seal Type: shamir', not 'auto-unseal' or 'Consul as seal provider'; auto-unseal would show a seal type like 'awskms' or 'gcpckms'. Option D is wrong because the output shows 'HA Enabled: true', indicating Vault is configured for high availability.
Which THREE of the following are valid parameters when creating a token via the API?
TTL can be set at creation.
Why this answer
Valid parameters include 'policies', 'ttl', 'max_ttl', 'renewable', 'period', 'explicit_max_ttl', 'id', 'role', 'meta', etc. 'Accessor' is not a creation parameter; it is returned after creation. 'Num_uses' is a valid parameter to limit the number of uses.
A development team wants to authenticate to Vault using a method that does not require storing secrets in source code and supports automatic rotation of credentials. Which authentication method best meets these requirements?
AWS IAM auth uses instance metadata service to obtain a signed identity, no secrets stored in code.
Why this answer
AWS IAM authentication allows Vault to authenticate using AWS IAM credentials (access key/secret key or instance metadata) without storing any secrets in source code. It supports automatic credential rotation by leveraging AWS IAM roles and STS to generate temporary credentials, which Vault can validate via the AWS API. This eliminates the need for long-lived secrets in code and enables seamless rotation.
Exam trap
HashiCorp often tests the misconception that token authentication is stateless and secret-free, but the trap here is that tokens themselves are secrets that must be stored and rotated manually, whereas AWS IAM authentication leverages cloud-native identity federation to eliminate stored secrets entirely.
How to eliminate wrong answers
Option A is wrong because token authentication requires a Vault token to be stored somewhere (e.g., in a file or environment variable), which means a secret is still present in source code or configuration, and tokens do not automatically rotate unless explicitly managed. Option B is wrong because LDAP authentication requires storing LDAP credentials (username/password) in source code or configuration, and those credentials are long-lived with no built-in automatic rotation mechanism. Option D is wrong because userpass authentication requires storing a username and password in source code or configuration, and those credentials are static unless manually rotated, which defeats the requirement of no stored secrets and automatic rotation.
An application uses a Vault token with a policy that grants read access to secrets. The security team wants to ensure that if the application is compromised, the token cannot be used after a certain time even if the attacker has the token. What is the best approach?
A short TTL ensures the token expires quickly.
Why this answer
Option D is correct because setting a short TTL on the token and disallowing renewal ensures that the token automatically expires after a fixed, short duration. Even if an attacker compromises the token, they cannot extend its lifetime, limiting the window of exposure. This directly meets the security requirement of preventing token use beyond a certain time without relying on external revocation mechanisms.
Exam trap
HashiCorp often tests the distinction between TTL and renewal behavior; the trap here is that candidates confuse 'max TTL' (which still allows renewal) with 'short TTL + no renewal' (which enforces absolute expiry), leading them to incorrectly select Option B.
How to eliminate wrong answers
Option A is wrong because a revocation script that runs periodically introduces a window of vulnerability between revocation checks; the token remains valid until the script executes, and the script itself adds operational complexity and potential failure points. Option B is wrong because setting an explicit max TTL on the token does not prevent the token from being renewed up to that max TTL; if renewal is allowed, an attacker could keep the token alive for the entire max TTL duration, which may be longer than desired. Option C is wrong because a periodic token with a long period is designed for long-lived, renewable access; it can be renewed indefinitely as long as the parent policy allows, which contradicts the requirement to limit token lifetime after compromise.
A finance company runs a microservices architecture on Kubernetes. Each microservice has its own service account and uses Kubernetes auth to authenticate to Vault and read secrets. Recently, a new microservice 'payment' was deployed in the 'prod' namespace with service account 'payment-sa'. The team created a Vault role with bound_service_account_names=['payment-sa'] and bound_service_account_namespaces=['prod']. The microservice can authenticate and obtains a token, but when it tries to read the secret at path 'secret/data/payments/db', it gets a permissions error. Other microservices in the same namespace with similar roles work fine. The Vault policy for the role includes read access to 'secret/data/payments/*'. What is the most likely issue and correct action?
The role must specify which policies to attach.
Why this answer
The Vault role is configured with `token_policies` that grant read access to `secret/data/payments/*`, but the role itself does not include that policy in its `token_policies` parameter. When the microservice authenticates via Kubernetes auth, the token issued by Vault only carries policies explicitly attached to the role. Without the policy being listed in `token_policies`, the token lacks the necessary permissions to read the secret, even though the policy exists.
Updating the role to include the policy in `token_policies` resolves the permissions error.
Exam trap
HashiCorp often tests the distinction between creating a policy and attaching it to a role; the trap here is assuming that simply having a policy with the correct path is sufficient, when in fact the policy must be explicitly referenced in the role's `token_policies` parameter.
How to eliminate wrong answers
Option B is wrong because increasing the TTL does not affect permissions; it only extends the token's validity period, which is irrelevant to a permissions error. Option C is wrong because adding the service account to an existing role that works would grant the same policies as that role, but those policies may not include read access to `secret/data/payments/*`, and it would bypass the intended role isolation. Option D is wrong because changing to AppRole is unnecessary; the Kubernetes auth method is already functioning for authentication, and the issue is purely a policy attachment problem, not an authentication method flaw.
A security architect is designing a secrets management solution with Vault. Which THREE secrets engines are most appropriate for dynamically generating credentials for external systems?
PKI dynamically issues X.509 certificates.
Why this answer
The PKI secrets engine is correct because it dynamically generates X.509 certificates for TLS/mTLS authentication, enabling short-lived credentials that reduce the risk of key compromise. This aligns with the requirement for dynamically generating credentials for external systems, as certificates can be issued on-demand with configurable TTLs and revocation support.
Exam trap
HashiCorp often tests the distinction between secrets engines that generate dynamic credentials (PKI, AWS, Database) versus those that store or process static data (KV v2, Transit), leading candidates to incorrectly select KV v2 for its familiarity or Transit for its security focus.
Which TWO authentication methods support multi-factor authentication (MFA) natively within Vault Enterprise?
Userpass can be configured with MFA by adding an MFA method.
Why this answer
Userpass authentication in Vault Enterprise supports MFA natively because it can be configured with a second factor such as TOTP, Duo, or Okta directly within the auth method's configuration. This allows the userpass method to enforce both a password and an additional authentication factor without requiring an external identity provider or custom wrapper.
Exam trap
HashiCorp often tests the distinction between 'native MFA support' (where the auth method itself can be configured with MFA without external plugins) versus 'MFA can be added externally' (which is possible for all auth methods via login MFA enforcement, but not native to the method).
A multi-national company uses Vault's AWS secrets engine to manage access to multiple AWS accounts. They have a central Vault cluster and need to generate IAM users in account A that assume a role in account B for cross-account access. The team has configured the AWS secrets engine with the root credentials of account A. They created a role on the engine that should generate STS credentials for the cross-account role. However, when they try to generate credentials, Vault returns an error: 'AccessDenied: User: arn:aws:iam::<accountA>:user/vault-user is not authorized to perform: STS:AssumeRole on resource: arn:aws:iam::<accountB>:role/CrossAccountRole'. What additional configuration is required?
The Vault user needs explicit permission to assume the target role.
Why this answer
The error indicates that the Vault user in account A lacks the IAM permission to call sts:AssumeRole on the cross-account role in account B. Even though the AWS secrets engine is configured with root credentials of account A, the engine uses those credentials to make API calls on behalf of the Vault user. Therefore, you must attach an IAM policy to the Vault user in account A that explicitly allows sts:AssumeRole on the target role ARN in account B.
This is a prerequisite for cross-account access via STS.
Exam trap
HashiCorp often tests the misconception that configuring the AWS secrets engine role with the cross-account role ARN is sufficient, when in fact the underlying IAM permissions for the Vault user must also be explicitly granted.
How to eliminate wrong answers
Option A is wrong because creating a new role in the AWS secrets engine that uses the cross-account role ARN directly does not grant the Vault user the required sts:AssumeRole permission; the engine role definition alone cannot bypass IAM authorization. Option B is wrong because changing the mount path only affects the API endpoint path in Vault and has no impact on AWS IAM permissions or cross-account trust. Option C is wrong because SAML federation is an alternative identity federation method, but it is not required here; the existing AWS secrets engine with root credentials can perform cross-account access once the proper IAM policy is attached to the Vault user.
Drag and drop the steps to create and use a periodic service token in Vault into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
First create the role, then generate a token with a TTL, use it, and renew periodically.
Refer to the exhibit. A developer issues a Vault CLI command to write a secret to path 'secret/data/team/billing'. What will be the outcome?
Vault evaluates the most specific path first; the second rule matches exactly and only allows read, so the write is denied.
Why this answer
Option B is correct because Vault uses most-specific-path matching; the second rule applies to the exact path and only allows read, overriding the wildcard rule. The write is denied.
An organization wants to use Vault to generate AWS IAM users with specific managed policies attached. They have configured the AWS secrets engine with the appropriate IAM credentials. What step is required to ensure each generated user gets the correct policies?
The role defines the policies to attach to generated IAM users.
Why this answer
Option D is correct because the AWS secrets engine in Vault uses roles to define the exact permissions and policies for generated IAM users. By configuring a role that specifies the managed policies, Vault ensures that each dynamically generated IAM user is created with those policies attached, meeting the organization's requirement.
Exam trap
The trap here is that candidates may confuse the purpose of the AWS secrets engine role with other Vault features like mount paths or encryption engines, assuming policy attachment is handled automatically or through unrelated configurations.
How to eliminate wrong answers
Option A is wrong because enabling the AWS secrets engine at a custom path does not affect policy assignment; it only changes the mount point for API access. Option B is wrong because setting a high TTL on the AWS secrets engine mount controls credential lease duration, not the policies attached to generated users. Option C is wrong because the transit secrets engine is used for encryption of data in transit or at rest, not for defining IAM policies; it is unrelated to AWS IAM user generation.
Refer to the exhibit. A Vault administrator starts a Vault server and receives this error. What is the most likely cause?
Vault requires a storage stanza to define the backend for persisting data.
Why this answer
The error indicates that Vault cannot find a configured storage backend. The storage stanza is mandatory in Vault's configuration file because it defines where Vault persists its data (e.g., Consul, Raft, file). Without it, the server fails to start because it has no backend to store secrets and state.
Exam trap
HashiCorp often tests the mandatory nature of the storage stanza, tricking candidates into thinking a listener or seal misconfiguration is the cause when the real issue is the absence of a storage backend definition.
How to eliminate wrong answers
Option A is wrong because a corrupt binary would typically produce a different error (e.g., checksum mismatch or segmentation fault), not a missing storage backend message. Option B is wrong because an incorrect listener address would cause a bind or connection error, not a missing storage stanza error. Option C is wrong because a misconfigured seal stanza (e.g., wrong transit path or key) would produce a seal initialization error, not a missing storage backend error.
An administrator needs to revoke a token but wants to keep all child tokens that were created using this token as the parent. Which revocation operation should be used?
Orphan revocation removes the token from the hierarchy but preserves children.
Why this answer
Orphan revocation removes the token from the parent-child tree but does not revoke its children. Option A is wrong because immediate revocation revokes the token and all its children. Option B is wrong because sudo revocation is not a standard Vault operation.
Option D is wrong because self revocation revokes the token making the request, not specifying orphan behavior.
Refer to the exhibit. An admin wants to ensure this token can be used for 60 hours total. Which action should be taken?
A new token with appropriate max TTL is required.
Why this answer
The token's explicit max TTL is 48h, meaning it cannot last longer than 48h. To achieve 60h, a new token must be created with explicit_max_ttl set to at least 60h. The existing token cannot be modified.
Refer to the exhibit. A user with this policy attempts to read the secret at path "secret/data/team-a/admin". What will happen?
Deny always takes precedence over other capabilities.
Why this answer
Option B is correct. In Vault, a deny statement takes precedence over any other capabilities. Even though the wildcard grants read, the explicit deny on the specific path blocks access.
A DevOps team wants to authenticate a CI/CD pipeline running on a Jenkins server outside Kubernetes. The pipeline needs to obtain short-lived tokens to read secrets. Which authentication method should be used?
AppRole is ideal for non-human clients like CI/CD pipelines.
Why this answer
AppRole auth is designed for machine-to-machine authentication, allowing Jenkins (outside Kubernetes) to obtain short-lived tokens by providing a RoleID and SecretID. This method supports automated workflows without human intervention, making it ideal for CI/CD pipelines that need to read secrets from Vault.
Exam trap
HashiCorp often tests the distinction between authentication methods designed for humans (LDAP, GitHub) versus those for machines (AppRole), and the trap here is assuming Kubernetes auth can be used from outside the cluster because it is commonly associated with CI/CD pipelines.
How to eliminate wrong answers
Option B (LDAP auth) is wrong because it requires a human username/password and is intended for user authentication, not for automated pipelines. Option C (Kubernetes auth) is wrong because it relies on a Kubernetes service account token and is only valid for pods running inside a Kubernetes cluster, not for an external Jenkins server. Option D (GitHub auth) is wrong because it is designed for authenticating users via GitHub OAuth, not for machine-to-machine token generation in a CI/CD pipeline.
You are a Vault administrator for a large organization. Your team uses a centralized Vault cluster with multiple auth methods enabled, including userpass, LDAP, and approle. Recently, a developer reported that they are unable to authenticate using their userpass credentials, receiving the error 'permission denied'. The developer confirms the username and password are correct. Other developers using userpass can authenticate successfully. The Vault audit logs show that the authentication request for this developer is reaching Vault but failing with 'invalid password'. You have verified that the password is correct by resetting it via the Vault CLI. The developer's userpass entry exists and is not disabled. Which of the following is the most likely cause and correct course of action?
Correct; account lockout is a common cause of authentication failures after repeated failed attempts.
Why this answer
Option D is correct because Vault's userpass auth method supports account locking after a configurable number of failed login attempts (default is 0, meaning no lockout, but if set to a positive integer via `max_attempts`, the account becomes locked). The audit log shows 'invalid password' despite the password being verified as correct, and other users can authenticate, which points to a lockout rather than a password or user entry issue. The admin can unlock the account using `vault write auth/userpass/users/<username>/unlock` to restore access.
Exam trap
HashiCorp often tests the misconception that 'invalid password' always means the password is wrong, when in fact it can also indicate an account lockout, especially when the user confirms the password is correct and other users authenticate successfully.
How to eliminate wrong answers
Option A is wrong because the developer's user entry is confirmed to exist and not disabled; Vault userpass does not have an 'enable' endpoint—the correct command to enable a user would be `vault write auth/userpass/users/<username>/enable` does not exist; disabling is done via `vault write auth/userpass/users/<username>/disable` and re-enabling is not a standard operation. Option B is wrong because userpass passwords do not have an expiration mechanism by default; password expiry is not a feature of the userpass auth method unless custom TTL policies are applied, but the error 'invalid password' would not occur from expiry alone. Option C is wrong because password hash corruption is extremely unlikely in Vault's backend storage (which uses encrypted storage and integrity checks); deleting and recreating the user entry would be an unnecessary destructive action when the issue is lockout.
A security team wants to ensure that all Vault policies for applications follow the principle of least privilege. They have a policy 'app-kv' that grants read access to secrets under 'secret/data/app/*'. An auditor finds that a developer can also read secrets under 'secret/data/team/*'. The policy currently uses a path-based glob. Which change should the team make to restrict access to only the app path?
Using a concrete path with trailing slash (or no glob) restricts to that specific path prefix only.
Why this answer
Option D is correct because removing the glob and using an exact path 'secret/data/app/' restricts access to only that specific path. In Vault, a trailing slash without a glob matches exactly that path and its immediate children when used with the appropriate capabilities, enforcing least privilege without granting unintended access to other paths like 'secret/data/team/*'.
Exam trap
HashiCorp often tests the misconception that Vault supports a 'deny' capability or that you can override a wildcard with a deny policy, when in reality Vault policies are additive and only allow capabilities, not deny them.
How to eliminate wrong answers
Option A is wrong because the '+' glob in Vault matches only a single path segment, not a wildcard for multiple segments, and 'list' capability does not grant read access to secrets. Option B is wrong because Vault does not support a 'deny' capability; access control is based on allowed capabilities, and adding a deny is not a valid construct. Option C is wrong because Vault does not have a 'deny' capability; policies are additive, and you cannot explicitly deny access to a path; instead, you must avoid granting access to unintended paths.
A developer requests a credential from this role. Which statement about the resulting lease is true?
The default_ttl sets the initial TTL, and renewable=false prevents renewal.
Why this answer
The role has default_ttl=1h and renewable=false, so the lease will have an initial TTL of 1 hour and cannot be renewed. The max_ttl of 24h is irrelevant because renewal is disabled. Option C is correct.
Which Vault component is responsible for encrypting data before storing it in the storage backend?
Encrypts all data before storage.
Why this answer
The Barrier (also known as the Security Barrier) is the Vault component responsible for encrypting all data before it is written to the storage backend. It wraps every entry with encryption using the master key, ensuring that data at rest is never stored in plaintext. This is a core architectural layer that provides a cryptographic boundary between Vault's internal operations and the underlying storage.
Exam trap
HashiCorp often tests the misconception that the Storage Backend handles encryption, but the trap here is that candidates confuse the storage layer's persistence role with the Barrier's cryptographic role, leading them to pick Option A.
How to eliminate wrong answers
Option A is wrong because the Storage Backend is a passive, durable storage layer (e.g., Consul, file system, S3) that only persists encrypted data; it has no encryption capabilities and never sees plaintext. Option B is wrong because an Audit Device logs requests and responses for auditing purposes but does not perform encryption of stored data; it operates at the logging layer, not the storage layer. Option D is wrong because a Secrets Engine generates, manages, and returns secrets (e.g., KV, AWS, database credentials) but does not encrypt data before storage; it relies on the Barrier to encrypt its output before writing to the storage backend.
Which TWO are benefits of using Vault's encryption as a service?
Core benefit of encryption as a service.
Why this answer
Option B is correct because Vault's encryption as a service allows applications to offload encryption and decryption operations to Vault via its API, without the application ever handling or storing encryption keys. This reduces the risk of key exposure and simplifies compliance with security policies.
Exam trap
HashiCorp often tests the misconception that encryption as a service is for encrypting cloud storage at rest, when in fact it is for application-level data encryption without key management exposure.
Which of the following commands would force a lease to expire immediately?
This writes to the revoke-lease endpoint, which immediately revokes the lease.
Why this answer
Option D is correct because the endpoint `sys/leases/revoke-lease` immediately revokes the lease, forcing it to expire right away. This is the proper API path to force an immediate lease expiration, as opposed to a gradual or deferred revocation.
Exam trap
HashiCorp often tests the distinction between standard revocation (`vault lease revoke`) and immediate forced expiration (`sys/leases/revoke-lease`), expecting candidates to know the exact API path for immediate lease termination.
How to eliminate wrong answers
Option A is wrong because `vault lease renew -increment=0` attempts to renew a lease with zero increment, which is not a valid operation and does not force expiration; it may even extend the lease if the increment is ignored. Option B is wrong because `vault lease revoke` performs a standard revocation that may not be immediate if the lease has a grace period or if the secret engine defers revocation; it does not guarantee instant expiration. Option C is wrong because `vault lease expire` is not a valid Vault CLI command; there is no such subcommand in the Vault CLI.
Given the output from 'vault operator raft list-peers', which node(s) will become unavailable if node1 (leader) experiences a network partition away from all other nodes?
Node1 is partitioned, but node2 and node3 (voters) can form quorum (2 out of 3) and elect a new leader.
Why this answer
Option A is correct because only node1 is unavailable; the remaining nodes (node2, node3, node4, node5) can still communicate and form quorum (3 voters out of 4, but node4 and node5 are non-voters; only voters count for quorum). Node2 and node3 are voters (2), less than majority of 5 voters? Wait initial voters: node1, node2, node3 are voters (3). If node1 is partitioned, node2 and node3 remain (2 voters out of 3, < majority? Actually quorum requires >50% of voters.
With 3 voters, quorum is 2. So node2 and node3 can still form quorum (2 is majority of 3) and elect a new leader. So only node1 becomes unavailable.
Option B is wrong because node2 and node3 can still agree. Option C is wrong because non-voters don't affect quorum. Option D is wrong.
A data analytics company needs to encrypt streaming data (e.g., clickstream events) before sending to a cloud data lake. Each event is about 1KB. They use Vault Transit to encrypt each event individually. The encryption rate is too slow for the volume (100,000 events/second). The team considers options to improve performance. Which approach is most effective for reducing the number of API calls to Vault while maintaining security?
Envelope encryption reduces Vault calls to one per DEK rotation, enabling high throughput with minimal API overhead.
Why this answer
Option B is correct because it implements an envelope encryption pattern: a local Data Encryption Key (DEK) encrypts each event locally, avoiding an API call per event, while the DEK itself is encrypted by Vault's Transit engine (Key Encryption Key, KEK). This reduces the number of Vault API calls from 100,000 per second to a single call per DEK rotation, drastically improving throughput without exposing the DEK in plaintext.
Exam trap
HashiCorp often tests the misconception that Vault's Transit engine can batch multiple data items in a single API call, but Transit only supports single-item encrypt/decrypt operations per request, making envelope encryption the only viable solution for high-throughput streaming data.
How to eliminate wrong answers
Option A is wrong because switching to Database or PKI secrets engines does not provide encryption-as-a-service; they generate credentials or certificates, not encrypt data, and would not reduce API calls for encryption. Option C is wrong because scaling Vault nodes and load balancing only distributes the same per-event API call load, not reducing the number of calls; the bottleneck is the per-event encryption request, not node capacity. Option D is wrong because Vault's Transit engine does not support batch encryption in a single API call; each event still requires a separate encrypt operation, so batching is not a feature of Transit and would not reduce API calls.
Which Vault API path is used to encrypt data with the transit engine?
This is the standard endpoint for transit encryption.
Why this answer
Option C is correct because the Vault transit engine uses the exact path `/v1/transit/encrypt/{keyname}` to encrypt plaintext data. The `{keyname}` parameter specifies the named encryption key stored in the transit engine, and the API endpoint expects a POST request with the plaintext base64-encoded in the request body. This path aligns with Vault's RESTful design where the action (`encrypt`) is a sub-path under the transit mount, and the key name is a required path parameter.
Exam trap
HashiCorp often tests the exact API path syntax, and the trap here is that candidates confuse the action verb 'encrypt' with the noun 'encryption' or use abbreviations, leading them to pick options like D or E that sound correct but use the wrong word.
How to eliminate wrong answers
Option A is wrong because `/v1/transit/enc/` uses an incomplete and non-standard abbreviation ('enc' instead of 'encrypt'), which does not match Vault's documented API. Option B is wrong because `/v1/transit/encrypt/` omits the required key name parameter; Vault's transit encrypt endpoint requires the key name as part of the path, not as a query parameter or request body field. Option D is wrong because `/v1/transit/encryption/` uses the full word 'encryption' instead of the correct action verb 'encrypt', and also lacks the key name.
Option E is wrong because while it includes the key name, it uses 'encryption' instead of 'encrypt'; Vault's API is case-sensitive and uses the exact verb 'encrypt' for this operation.
A DevOps team is using Vault tokens for authentication in CI/CD pipelines. They notice that tokens are often expired before the pipeline completes, causing failures. Which Vault feature should they use to address this without manual intervention?
Periodic tokens can be renewed before expiration as long as they are within max TTL.
Why this answer
Periodic tokens are designed for long-running processes like CI/CD pipelines. They have no maximum TTL and can be renewed indefinitely as long as the renewal occurs before the current token's TTL expires. By using a periodic token with a short period and enabling automatic renewal in the pipeline, the token stays valid without manual intervention, solving the expiration issue.
Exam trap
HashiCorp often tests the misconception that increasing TTL or using orphan tokens solves indefinite expiration, but the key is that periodic tokens are the only token type designed for renewable, long-lived use without a hard upper limit.
How to eliminate wrong answers
Option A is wrong because batch tokens are stateless and cannot be renewed; they have a fixed TTL and are unsuitable for long-running pipelines. Option C is wrong because orphan tokens are detached from their parent but still have a finite TTL and must be renewed; they do not inherently prevent expiration. Option D is wrong because increasing the default TTL on the token auth method only extends the initial validity but does not allow indefinite renewal; the token will still eventually expire, and manual intervention would be needed to re-authenticate.
Based on the exhibit, what is the maximum total lifespan of this lease?
The max_ttl indicates the maximum total lifespan.
Why this answer
The max_ttl field shows 1h, which is the maximum total time the lease can exist from its issue time, including all renewals. The current ttl of 30m is the remaining time if not renewed, but the lease can be renewed up to the max_ttl of 1 hour. Option B is correct.
A company deploys Vault in a single data center with 3 nodes using Integrated Storage. The application team reports that secret reads are slow, with median latency of 200ms. The Vault cluster is under moderate load of 100 requests per second. The administrator checks the server metrics and sees that the Raft commit latency is low, but the HTTP request handling time is high. The Vault nodes are running on virtual machines with 4 vCPUs and 8GB RAM each. The administrator suspects that the bottleneck is due to resource contention. What should the administrator do to reduce read latency without compromising availability?
Performance standbys reduce read latency by bypassing Raft.
Why this answer
Adding performance standby nodes is the correct solution because they are specifically designed to handle read requests without participating in the Raft consensus protocol. Since the bottleneck is high HTTP request handling time (not Raft commit latency), performance standbys offload read traffic from the active cluster nodes, reducing latency without affecting write availability or requiring changes to the existing cluster topology.
Exam trap
HashiCorp often tests the distinction between scaling reads with performance standbys versus scaling the cluster with additional Raft nodes, where candidates mistakenly assume adding more cluster nodes will improve read performance without considering the consensus overhead.
How to eliminate wrong answers
Option B is wrong because increasing CPU and memory addresses resource contention, but the metrics show low Raft commit latency and high HTTP request handling time, indicating the bottleneck is at the application layer (request handling), not compute resources; scaling vertically may not resolve the issue and could be less cost-effective. Option C is wrong because switching to a Consul storage backend introduces additional complexity and dependency on Consul servers, and the current issue is not related to storage backend performance (Raft commit latency is low); this would not directly reduce HTTP request handling time. Option D is wrong because adding more Vault nodes to the cluster increases the number of Raft participants, which can actually increase write latency and complexity, and does not specifically address read latency since all nodes in a Raft cluster can handle reads but still share the same consensus overhead; performance standbys are a more targeted solution for read scaling.
An administrator runs the commands shown in the exhibit. Later, they run 'vault kv delete kv-v2/secret' and then 'vault kv undelete -versions=1 kv-v2/secret' to recover the secret. Which command must the administrator run to verify that the secret is now readable?
After undelete, the secret is readable; this command retrieves the data.
Why this answer
Option C is correct because 'vault kv get' is the standard command to read and display the latest version of a secret from a KV v2 secrets engine. After running 'vault kv undelete -versions=1', version 1 is restored from a deleted state, and 'vault kv get kv-v2/secret' will retrieve and show that version's data, confirming it is readable.
Exam trap
HashiCorp often tests the distinction between 'vault kv get' (reads secret data) and 'vault kv metadata get' (reads metadata only), leading candidates to choose the metadata command when they need to verify data readability.
How to eliminate wrong answers
Option A is wrong because 'vault kv list' lists the secret paths under a given path, not the data of a specific secret; it would show 'secret' as a key but not its values. Option B is wrong because 'vault read kv-v2/data/secret' is the correct raw API path for reading a KV v2 secret, but the question asks for the command to verify readability, and the standard CLI command is 'vault kv get', not 'vault read' (though 'vault read' would also work technically, it is not the intended answer in the context of the 'kv' subcommand). Option D is wrong because 'vault kv metadata get' retrieves metadata (like version info, deletion time, created time) but does not return the secret's actual data, so it cannot verify that the secret is readable.
Which TWO of the following are valid token states?
A revoked token is invalid.
Why this answer
Option D is correct because 'Revoked' is a standard token state defined in the OAuth 2.0 framework (RFC 7009) and implemented in Vault's token lifecycle. When a token is explicitly revoked via the `/sys/leases/revoke` endpoint or through a lease revocation, it transitions to the revoked state and can no longer be used for authentication or authorization.
Exam trap
HashiCorp often tests the distinction between token lifecycle states and token properties (like orphan status) to confuse candidates who may think 'orphan' or 'suspended' are official states, when in fact only 'Active' and 'Revoked' are the primary valid token states in Vault.
Which TWO of the following are valid methods to authenticate to Vault using the CLI?
Valid; userpass authentication via CLI.
Why this answer
Option B is correct because `vault login -method=userpass username=jdoe` is the valid CLI command to authenticate using the userpass auth method, which prompts for the password interactively. Option E is correct because `vault login -method=ldap username=jdoe` is the valid CLI command to authenticate using the LDAP auth method, also prompting for the password. Both commands follow the standard `vault login -method=<type>` syntax required by the Vault CLI.
Exam trap
HashiCorp often tests the distinction between the deprecated `vault auth` and the current `vault login` command, as well as the correct environment variable (`VAULT_TOKEN` vs. `VAULT_AUTH`), to catch candidates who rely on outdated documentation or assume generic naming conventions.
Refer to the exhibit. A user has a token that has the 'default' policy attached. What actions can the user perform on 'secret/data/team'?
Correct; default policy typically allows read and list on many paths.
Why this answer
The 'default' policy in Vault provides broad read and list capabilities across most paths, including 'secret/data/team'. It does not grant create, update, or delete permissions, which require explicit policy rules. Therefore, the user can only read and list secrets at that path.
Exam trap
HashiCorp often tests the misconception that the 'default' policy grants no permissions, when in fact it provides read and list access to most secret engines, leading candidates to incorrectly choose 'No actions' or 'Read only'.
How to eliminate wrong answers
Option A is wrong because the 'default' policy does grant read and list access, so the user is not restricted to no actions. Option B is wrong because the 'default' policy also allows list operations, not just read. Option C is wrong because create, update, and delete require explicit policy capabilities (e.g., 'create', 'update', 'delete') which are not included in the 'default' policy.
A company runs multiple microservices in a Kubernetes cluster. Each microservice authenticates to Vault using a service token created via the token auth method. The tokens are created with a default TTL of 72h, a max TTL of 168h, and renewable set to true. The services are configured to renew their tokens when the remaining TTL drops below 24h. Recently, some tokens have been expiring prematurely, causing service outages. Upon investigation, you find that the expired tokens were created with a role that includes explicit_max_ttl = 72h. The services see the TTL decreasing normally, but then it jumps to zero even though the services attempted renewal. What is the most likely cause and correct action?
Removing explicit_max_ttl allows tokens to be renewed up to the max TTL of 168h.
Why this answer
The explicit_max_ttl of 72h overrides the creation_ttl and max_ttl. Even though renewable is true, the token cannot be renewed beyond its explicit_max_ttl. The correct action is to remove or set explicit_max_ttl to 0 in the role configuration.
Increasing the default TTL (option A) does not help because explicit_max_ttl is lower. Setting max_ttl to 72h (option C) would not change behavior. Renewing earlier (option D) still cannot bypass the hard limit.
Refer to the exhibit. A DevOps engineer runs `vault read -format=json transit/keys/mykey` and receives the output shown. A microservice attempts to decrypt data that was encrypted with version 1 of the key. Will the decryption succeed?
Correct interpretation of min_decryption_version.
Why this answer
Option B is correct because the `min_decryption_version` parameter in Vault's transit secrets engine specifies the lowest key version that can be used for decryption. In the exhibit, `min_decryption_version` is set to 1, meaning any version from 1 upward is allowed. Since the data was encrypted with version 1, decryption will succeed.
This parameter does not block decryption with version 1; it only prevents decryption with versions lower than the specified value.
Exam trap
The trap here is that candidates often misinterpret `min_decryption_version` as a minimum version that is required (i.e., only versions above that number are allowed), when in fact it means the minimum version that is still permitted — so version 1 is allowed if the value is 1.
How to eliminate wrong answers
Option A is wrong because `min_decryption_version` does affect decryption — it explicitly controls which key versions are permitted for decryption operations. Option C is wrong because a `min_decryption_version` of 1 allows decryption with version 1 and higher, not only version 2 and higher. Option D is wrong because setting `min_decryption_version` to 1 does not block decryption with version 1; it actually permits it.
A developer wants to authenticate to Vault using LDAP credentials. Which CLI command should they use?
C is correct: vault login with -method=ldap prompts for password and authenticates.
Why this answer
Option A is correct because `vault login -method=ldap username=john` is the standard Vault CLI command to authenticate using LDAP credentials. This command triggers the LDAP auth method, prompting the user for their password (or accepting it via `-password` flag) and returning a Vault token upon successful authentication against the configured LDAP server.
Exam trap
The trap here is that candidates confuse the raw API endpoint (`vault write auth/ldap/login`) with the correct CLI login command (`vault login -method=ldap`), or mistake enabling the auth method for performing authentication.
How to eliminate wrong answers
Option B is wrong because `vault token create -policy=ldap` creates a new token with a specified policy, but it does not perform LDAP authentication; it requires an existing valid token and is used for token management, not for logging in with LDAP credentials. Option C is wrong because `vault write auth/ldap/login username=john` is an API-style command that would require the password to be passed in the request body (e.g., via `-password` flag or stdin), but the question specifies using the CLI, and the standard CLI command for login is `vault login -method=ldap`, not a raw write operation. Option D is wrong because `vault auth enable ldap` enables the LDAP auth method at a path (default `auth/ldap`), but it does not perform authentication; it is an administrative operation to configure the backend, not a login command.
A large enterprise runs Vault in a production environment with multiple secrets engines, including databases, AWS, and PKI. Recently, the operations team noticed that the number of active leases has grown significantly, causing performance degradation in Vault. The team suspects that many leases are orphaned or expired but not cleaned up. They run the vault lease tidy command regularly, but the issue persists. The vault audit logs show no errors during revocation. However, the team observes that the database credentials are being revoked correctly, but the PKI certificates are not being revoked when their leases expire. Additionally, some AWS IAM user leases seem to persist beyond their max TTL. What is the most likely cause of this issue?
Lease expiration does not automatically revoke certificates or IAM users; explicit revocation is needed.
Why this answer
For some secrets engines like PKI and AWS, lease expiration does not automatically revoke the underlying secret (certificate or IAM user). The revocation must be explicitly triggered by a revoke operation or by the backend's cleanup routines. The tidy operation only cleans up lease metadata, not the actual secrets.
Therefore, even if leases expire, the certificates and IAM users remain. Option B correctly identifies this. Option A is false because tidy is effective for metadata but does not trigger revocation for all backends.
Option C is possible but not the root cause if max_ttl is correctly set. Option D is unlikely given that database revocations work correctly.
Refer to the exhibit. What does min_decryption_version = 1 indicate?
Decryption requests must use a key version >= min_decryption_version.
Why this answer
In Vault Enterprise, the `min_decryption_version` parameter on a transit key specifies the lowest key version that is allowed to decrypt existing ciphertext. Setting `min_decryption_version = 1` means that any key version from 1 up to the current version can be used for decryption; version 1 is the minimum allowed. This ensures backward compatibility while allowing newer versions to be used for encryption.
Exam trap
HashiCorp often tests the distinction between `min_encryption_version` and `min_decryption_version`; the trap here is confusing which parameter controls encryption versus decryption, leading candidates to incorrectly assume `min_decryption_version` restricts encryption or forces rewrapping.
How to eliminate wrong answers
Option A is wrong because `min_decryption_version = 1` does not restrict decryption to only version 1; it allows version 1 and any higher version to decrypt. Option B is wrong because it implies a minimum encryption version, but `min_decryption_version` controls decryption, not encryption; data encrypted with version 1 can be decrypted by version 1 or higher, but the statement is reversed and imprecise. Option D is wrong because `min_decryption_version` does not force rewrapping of ciphertext; rewrapping is a separate operation (e.g., `rewrap` API) and is not automatically triggered by this setting.
Option E is wrong because version 1 keys are explicitly allowed for decryption when `min_decryption_version = 1`; setting it to 1 means version 1 is the lowest permitted, not forbidden.
Practice VA-003 by domain
Target a specific domain to shore up weak areas.