514 questions total · 7pages · All types, answers revealed
Match each Vault term to its definition.
Drag a concept onto its matching description — or click a concept then click the description.
Encrypted state requiring unseal
Decrypt master key to access data
Encryption layer protecting storage
Key splitting for unseal
Superuser token with full access
Why these pairings
These are core Vault concepts.
A company uses Vault to store application configuration secrets for multiple teams. The Vault cluster is running in production and has the KV secrets engine enabled at the path 'secret/' using version 2. A DevOps engineer, using a Vault token with full admin access, creates a new secret at 'secret/data/team-a/app-config' using the CLI command 'vault kv put secret/team-a/app-config key=value'. The secret is intended for the CI/CD pipeline, which uses a token with a policy that grants 'read' capability on 'secret/data/*'. The pipeline is configured to read the secret by calling the Vault API at the path 'v1/secret/team-a/app-config'. The pipeline reports a 404 Not Found error. The pipeline engineer verifies that the token is valid and has the correct policy attached. All other secrets in the same path can be read successfully by the pipeline. What is the most likely cause of the 404 error?
KV v2 requires '/data/' in the path; the pipeline uses 'v1/secret/team-a/app-config' instead of 'v1/secret/data/team-a/app-config'.
Why this answer
The correct action is to update the pipeline to use the path 'v1/secret/data/team-a/app-config', because KV v2 requires the '/data/' prefix in the API path. Options A and B are incorrect because the engine is enabled and the policy covers the path. Option C is incorrect because the secret exists at the expected location; the issue is the API path used by the pipeline.
Which THREE statements about token accessors are true?
The lookup token accessor endpoint provides metadata using the accessor.
Why this answer
Token accessors are unique identifiers that can be used to look up token metadata and revoke tokens without the token ID. However, they cannot be used to renew tokens (requires token ID) and are not human-readable (they are UUIDs).
A DevOps team is using Vault tokens with short TTLs for CI/CD jobs. They notice that some jobs fail intermittently with 'permission denied' errors even though the token policy grants the required capabilities. The token is created with a TTL of 10 minutes and renewed automatically by the client library. What is the most likely cause of the failures?
If the token's lifetime exceeds max_ttl, renewal is denied and the token becomes invalid.
Why this answer
The correct answer is A because Vault tokens have both a TTL (time-to-live) and a max_ttl (maximum time-to-live). When a token is renewed, its TTL is reset to the original TTL (10 minutes) but only if the cumulative lifetime has not exceeded the max_ttl. If the max_ttl is reached, renewal fails, the token expires, and subsequent operations using that token return 'permission denied' errors, even though the policy itself grants the required capabilities.
Exam trap
HashiCorp often tests the distinction between TTL and max_ttl, trapping candidates who assume that automatic renewal indefinitely extends token validity without considering the hard upper limit imposed by max_ttl.
How to eliminate wrong answers
Option B is wrong because revoking the parent token would immediately invalidate all child tokens, causing consistent failures, not intermittent ones, and the scenario describes intermittent failures. Option C is wrong because the max_ttl is a hard upper bound and is never reset or extended by renewal; only the current TTL is reset. Option D is wrong because the client library is described as renewing automatically, and a 10-minute TTL is generally sufficient for CI/CD jobs; the issue is the cumulative lifetime exceeding max_ttl, not the renewal timing.
Which THREE of the following are true about using the Vault API with response wrapping? (Choose three.)
Single use is a key property.
Why this answer
Option B is correct because the Vault API's response wrapping feature is designed for one-time use: the wrapping token can be used only once to unwrap the response. After the client successfully calls the sys/wrapping/unwrap endpoint with the wrapping token, the token is immediately revoked, and the wrapped secret is deleted from the cubbyhole. This ensures that the secret is delivered securely and cannot be retrieved again with the same token.
Exam trap
HashiCorp often tests the misconception that the wrapping token is reusable or that the original token is needed to unwrap, when in fact the wrapping token is single-use and self-contained for unwrapping.
Refer to the exhibit. A Vault administrator ran the commands shown. What is the result?
The path is internal/aws and the role specifies iam_user with Admin policy.
Why this answer
Option D is correct because the command `vault secrets enable -path=internal/aws aws` enables the AWS secrets engine at the custom path `internal/aws`. The subsequent configuration with `lease` and `roles` sets up the engine to generate STS credentials (temporary security credentials) via the `sts` endpoint, not IAM users. However, the exhibit shows the role is configured with `credential_type=iam_user` and `policy_arn=arn:aws:iam::aws:policy/AdministratorAccess`, which means the engine will generate IAM users with full admin access, not STS credentials.
The path is custom, and the engine is enabled successfully.
Exam trap
HashiCorp often tests the distinction between `credential_type=iam_user` and `credential_type=sts` in the AWS secrets engine, where candidates mistakenly assume that the engine always generates STS credentials, but the role configuration explicitly determines the output type.
How to eliminate wrong answers
Option A is wrong because the engine is enabled at path `internal/aws`, not `aws/`, and while it generates IAM users with admin access, the path is custom, not the default `aws/`. Option B is wrong because the AWS secrets engine can be enabled at a custom path; the `-path` flag explicitly allows this, and the command succeeds. Option C is wrong because the role is configured with `credential_type=iam_user`, not `sts`, so the engine generates IAM users, not STS credentials.
A user tries to renew their own token using 'vault token renew -self' and gets 'Error renewing token: Error making API request'. The token is still valid. What could be the cause?
A is correct: non-renewable tokens cannot be renewed.
Why this answer
The error 'Error renewing token: Error making API request' when using 'vault token renew -self' on a still-valid token indicates the token is not renewable. In Vault, tokens have a renewable flag; if set to false, the token cannot have its TTL extended, even if it is still valid. The error message is generic but the core issue is the token's non-renewable property, not a policy denial or server connectivity problem.
Exam trap
HashiCorp often tests the distinction between token validity and renewability, trapping candidates who assume a valid token can always be renewed, when in fact the renewable flag is a separate attribute checked before any policy or TTL logic.
How to eliminate wrong answers
Option A is wrong because a token created with a period (explicit TTL) can still be renewable if the renewable flag is set to true; the period does not inherently prevent renewal. Option C is wrong because policy denial would result in a permission denied error (403), not a generic 'Error making API request' message; the token's own renewable flag is checked before policy. Option D is wrong because if the Vault server were unreachable, the error would typically be a connection timeout or refused, not a specific 'Error making API request' response from the server.
An admin needs to revoke all leases associated with a particular policy violation. Which two methods can be used? (Choose two.)
API equivalent to revoke by prefix.
Why this answer
Both `vault lease revoke -prefix <prefix>` and `vault write sys/leases/revoke-prefix <prefix>` will revoke all leases with the given prefix, which can target the mount or role involved in the policy violation. Option A revokes a specific lease only. Option B revokes a token and its leases, but not specifically by policy prefix.
Option E has an incorrect path.
A security administrator notices that a Vault client using AppRole authentication is generating a very large number of tokens, causing performance issues. The administrator finds that the same AppRole role is used by multiple applications. What should the administrator do to reduce the number of tokens while maintaining security?
This allows distinct secret IDs and token limits per application.
Why this answer
Option B is correct because creating separate AppRole roles for each application allows better control and reduces token blast radius. Option A is wrong because increasing secret_id_num_uses doesn't limit token count per use. Option C is wrong because decreasing token TTL might cause more frequent renewal but not reduce total token count necessarily.
Option D is wrong because periodically rotating secret IDs doesn't limit token generation.
A team is evaluating which secrets engines to use for different use cases. Which TWO statements about secrets engines are true?
KV v2 stores versions and metadata such as TTL.
Why this answer
Option C is correct because the KV v2 secrets engine stores multiple versions of a secret, supports metadata such as TTL and deletion time, and allows check-and-set operations for conflict detection. This makes it suitable for use cases requiring secret rotation and audit trails.
Exam trap
HashiCorp often tests the misconception that 'Transit' implies dynamic credential generation, when in fact Transit is strictly for cryptographic operations on data, not for database credential rotation.
A developer wants to store an API key for their application in Vault using the key-value secrets engine. They need to be able to retrieve the key and also roll back to a previous version if needed. Which secrets engine configuration should they use?
KV v2 supports versioning and rollback to previous versions.
Why this answer
The KV v2 secrets engine supports versioning, allowing retrieval of previous versions and rollback capabilities. This directly meets the requirement to store an API key and revert to an older version if needed. KV v1 does not support versioning, while Transit and Database engines serve different purposes (encryption and dynamic credentials, respectively).
Exam trap
HashiCorp often tests the distinction between KV v1 and KV v2, where candidates mistakenly assume all KV engines support versioning, or confuse the Transit engine's encryption capabilities with secret storage.
How to eliminate wrong answers
Option A is wrong because the Transit secrets engine is designed for encryption/decryption operations, not for storing secrets with versioning. Option C is wrong because KV v1 secrets engine does not support versioning or rollback; it only stores the latest value. Option D is wrong because the Database secrets engine generates dynamic database credentials, not for storing static API keys with version history.
This is the correct order: enable, generate root, create role, issue.
Why this answer
Option D is correct because the correct order to configure the Vault PKI secrets engine is: first enable the PKI secrets engine at a path, then generate a root CA certificate (which creates the CA's key pair and self-signed certificate), then create a role that defines certificate issuance parameters (such as allowed domains and TTL), and finally issue certificates using that role. This sequence ensures the CA exists before roles reference it, and roles exist before certificates are issued.
Exam trap
HashiCorp often tests the correct sequence of operations in Vault PKI setup, and the trap here is that candidates confuse the order of enabling the engine versus generating the CA, or they incorrectly assume an intermediate CA is always required for a private CA setup.
How to eliminate wrong answers
Option A is wrong because it places 'create a role' before 'generate root CA', but a role cannot be created without an existing CA (the role references the CA's key and certificate). Option B is wrong because it starts with 'generate root CA' before 'enable PKI', but the PKI secrets engine must be enabled first to have a mount point where the CA can be generated. Option C is wrong because it introduces an unnecessary 'generate intermediate CA' step; while intermediate CAs are used in multi-tier PKI, the question asks for a private CA setup, and generating an intermediate CA without first generating a root CA is invalid, and the question does not require an intermediate CA.
An administrator wants to view all currently enabled secrets engines and their mount paths. Which command provides this information?
vault secrets list or 'vault read sys/mounts' shows all mounted engines.
Why this answer
The correct command is `vault secrets list` (or its alias `vault secrets list -detailed`), which displays all enabled secrets engines along with their mount paths, accessor, type, and configuration. This is the standard CLI command for enumerating secrets engines in Vault, equivalent to reading the `sys/mounts` endpoint but with a user-friendly output format.
Exam trap
HashiCorp often tests the distinction between `list` and `read` on the `sys/mounts` path, where candidates mistakenly think `list` is valid, but Vault only supports `read` on that endpoint, and the recommended user-facing command is `vault secrets list`.
How to eliminate wrong answers
Option A is wrong because `vault list sys/mounts` is not a valid command; Vault's CLI uses `vault read sys/mounts` or `vault secrets list` to retrieve mount information, and `list` is not supported on that path. Option C is wrong because `vault secrets show` is not a valid Vault CLI command; the correct subcommand is `list`, not `show`.
Drag and drop the steps to initialize and unseal a Vault server for the first time into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
After starting the server, initialize it, distribute keys, unseal, then verify.
Which TWO components are required for Vault to start and function? (Choose two.)
Required for persisting Vault's encrypted data.
Why this answer
The storage backend is required because Vault must persist all data, including encrypted secrets, configuration, and audit logs, to a durable backend (e.g., Consul, Integrated Storage, or filesystem). Without a configured storage backend, Vault cannot initialize or start. The seal mechanism is required because Vault uses it to encrypt and decrypt the master key; the seal wraps the master key and must be unsealed before Vault can serve requests.
Exam trap
HashiCorp often tests the misconception that a listener is required for Vault to start, but the trap is that Vault can start and initialize without a listener configured, as the listener is only needed to accept API traffic, not for core startup.
Your company uses Vault to manage secrets for a fleet of microservices running on Kubernetes. Each microservice has a service account that authenticates to Vault using the Kubernetes auth method and receives a token with a policy granting access to its secrets. Recently, the team noticed that some tokens are being revoked prematurely, causing services to lose access to secrets. The tokens are created with a TTL of 24 hours and are set to be renewable. The Vault servers are configured with a default max_ttl of 24 hours. The tokens are renewed by the client libraries every 12 hours. Despite this, tokens are sometimes invalid before 24 hours. What should the team do to prevent this issue?
By increasing max_ttl, tokens can be renewed and remain valid for a longer period, preventing premature expiration.
Why this answer
Option D is correct because the tokens are being revoked prematurely due to the Vault server's default max_ttl of 24 hours. Even though the token TTL is 24 hours and the client renews every 12 hours, the max_ttl caps the total lifetime of the token, including renewals. By increasing the max_ttl on the token role to 48 hours, the token can be renewed beyond the initial 24-hour window, preventing premature invalidation.
Exam trap
HashiCorp often tests the distinction between TTL and max_ttl, and the trap here is that candidates assume renewing a token resets its entire lifetime, not realizing that max_ttl imposes a hard cap on total token duration.
How to eliminate wrong answers
Option A is wrong because setting num_uses to a high number controls the number of times a token can be used, not its lifetime; premature revocation here is a TTL issue, not a usage count issue. Option B is wrong because periodic tokens never expire only if they are continually renewed before their period ends, but they still respect max_ttl unless explicitly set to not expire, which is not the default behavior and would introduce security risks. Option C is wrong because decreasing the token TTL to 12 hours would cause the token to expire before the 12-hour renewal interval, leading to even more frequent loss of access; the renewal happens every 12 hours, so a 12-hour TTL would not allow a successful renewal before expiration.
Which THREE of the following best practices should be followed when using Vault's encryption as a service with the transit engine?
Provides isolation and limits blast radius.
Why this answer
Option B is correct because using a unique encryption key per application ensures cryptographic isolation: if one application's key is compromised, other applications' data remains secure. Vault's transit engine supports this by allowing you to create and manage multiple named keys, each with its own policy and rotation schedule, preventing cross-application data exposure.
Exam trap
HashiCorp often tests the misconception that key deletion is a safe cleanup practice, but in the transit engine, deletion is irreversible and can cause data loss, whereas disabling or archiving keys is the correct approach.
A company wants to use Vault to generate IAM users dynamically for each application, following the principle of least privilege. Which secrets engine configuration should they use?
This follows least privilege and generates IAM users dynamically.
Why this answer
Option A is correct because the AWS secrets engine can be configured with a dedicated IAM user that has limited permissions, and by using the 'iam_user' credential type, Vault dynamically creates a new IAM user for each application. This approach adheres to the principle of least privilege by ensuring each application gets a unique set of credentials scoped to its specific needs, without sharing or reusing static keys.
Exam trap
HashiCorp often tests the distinction between dynamic user creation ('iam_user') and temporary credential generation ('federation_token' or 'assumed_role'), where candidates mistakenly choose 'assumed_role' because it is commonly used for temporary access, but it does not create per-application IAM users for granular isolation.
How to eliminate wrong answers
Option B is wrong because using a root IAM user violates security best practices and the principle of least privilege, as root users have unrestricted access; the 'federation_token' credential type generates temporary tokens but still relies on a highly privileged root user. Option C is wrong because using a static access key with the 'iam_user' credential type defeats the purpose of dynamic credential generation, as it reuses the same key across applications, increasing the risk of exposure and violating least privilege. Option D is wrong because the 'assumed_role' credential type generates temporary credentials for an IAM role, which is suitable for cross-account access or role-based scenarios, but it does not create individual IAM users per application, making it less granular for per-application isolation.
A user 'john' logs in via the userpass method. The output shows a token with a duration of 768 hours. However, the userpass mount is configured with `token_ttl=24h`. What is the most likely reason for the longer token duration?
Userpass allows per-user TTL settings that override the mount default.
Why this answer
Option B is correct because the userpass mount allows per-user TTL overrides via the `token_ttl` parameter when creating or updating a user. Even though the mount has a default `token_ttl=24h`, if user 'john' was configured with a specific `token_ttl` of 768 hours, that per-user setting takes precedence over the mount-level default. This is a common way to grant specific users longer token lifetimes without changing the mount's default policy.
Exam trap
HashiCorp often tests the misconception that mount-level settings are absolute, when in fact per-user or per-role overrides can extend token lifetimes beyond the mount's default TTL.
How to eliminate wrong answers
Option A is wrong because the system backend's `max_ttl` sets an upper limit on token lifetimes, but it cannot extend a token beyond the mount's configured TTL; it only caps it. Option C is wrong because the mount `token_ttl` is applied regardless of whether the user specifies `token_policies`; the TTL and policies are independent parameters. Option D is wrong because a periodic token has no explicit TTL and instead relies on a `period` setting, and the output shows a specific duration (768 hours), not a periodic token behavior.
A CI/CD pipeline runs in a Kubernetes cluster and needs to authenticate to Vault to fetch secrets. The pipeline should not have to manage any long-lived credentials. Which authentication method is most suitable?
Uses the pod's service account token, no manual credential management.
Why this answer
The Kubernetes authentication method allows the CI/CD pipeline to authenticate to Vault using its Kubernetes service account token, which is automatically mounted into the pod. This eliminates the need for managing long-lived credentials because Vault verifies the token against the Kubernetes API server and issues a short-lived Vault token in return.
Exam trap
The trap here is that candidates may confuse 'token authentication' (a generic long-lived token) with 'Kubernetes authentication' (which uses a short-lived JWT from the pod's service account), leading them to incorrectly select option A.
How to eliminate wrong answers
Option A is wrong because token authentication requires the pipeline to manage a long-lived Vault token, which contradicts the requirement of not managing long-lived credentials. Option B is wrong because LDAP authentication requires the pipeline to have a username and password or a long-lived LDAP session, which again introduces long-lived credential management. Option C is wrong because AWS IAM authentication is designed for workloads running on AWS, not for a pipeline running inside a Kubernetes cluster, and it would require the pipeline to manage AWS IAM roles or keys.
A Vault administrator wants to ensure that all secrets are encrypted at rest and in transit. Which two configurations are necessary? (Choose two.)
TLS encrypts data in transit.
Why this answer
Options A and C are correct. A: TLS encrypts data in transit. C: The seal provides encryption at rest via envelope encryption.
B is wrong because Integrated Storage does not inherently encrypt data at rest; it relies on the seal. D is wrong because audit device encryption is optional and not required. E is wrong because such an environment variable does not exist.
A SaaS company uses AppRole authentication for their CI/CD pipeline. The pipeline runs on a Jenkins server. The pipeline generates a secret ID using the AppRole 'ci-role' and then logs in to Vault to read a database credential. Recently, the pipeline started failing intermittently with errors like 'secret ID is expired' or 'secret ID is used'. The pipeline generates a new secret ID every run. The team verified that the AppRole's secret_id_ttl is set to 0 (unlimited) and the secret_id_num_uses is set to 1. The pipeline runs multiple jobs concurrently, sometimes using the same AppRole. What is the most likely cause and solution?
Response wrapping creates a one-time use token independent of secret_id_num_uses.
Why this answer
Option C is correct because the intermittent failures ('secret ID is expired' or 'secret ID is used') occur when multiple concurrent pipeline jobs generate a new secret ID for the same AppRole 'ci-role' with secret_id_num_uses=1. Since each secret ID can only be used once, concurrent jobs may attempt to reuse an already-consumed secret ID or generate overlapping IDs. Response wrapping delivers a unique wrapped token to each job, ensuring that each job receives a fresh, single-use secret ID without race conditions, as the wrapping token is unwrapped only once per job.
Exam trap
HashiCorp often tests the misconception that increasing TTL or usage limits solves concurrency issues, but the real problem is the race condition inherent in generating and consuming single-use secret IDs concurrently, which response wrapping resolves by providing unique, atomic delivery.
How to eliminate wrong answers
Option A is wrong because setting secret_id_num_uses to 0 (unlimited) would allow any number of uses per secret ID, but it does not address the race condition where concurrent jobs generate and consume secret IDs simultaneously; the underlying issue is contention, not usage limits. Option B is wrong because creating separate AppRoles for each pipeline job would require significant administrative overhead and does not scale; the problem is not the number of roles but the concurrent use of a single role with single-use secret IDs. Option D is wrong because increasing secret_id_ttl to 24h does not resolve the 'secret ID is used' error; the error occurs because the secret ID is consumed by another job, not because it has expired, and the TTL is already unlimited (0).
A developer is troubleshooting an application that uses Vault's PostgreSQL secrets engine. The application successfully obtains a database credential from Vault, but after 30 minutes, the application starts receiving authentication errors from the database. The developer checks the Vault audit logs and sees that the lease for the credential was revoked. The lease was originally created with a TTL of 1 hour. The application is not renewing the lease. The developer wants to fix the issue so that the credential works for the full 1 hour. What should the developer do?
Renewing the lease extends its duration and prevents premature revocation.
Why this answer
Option B is correct because the application must actively renew the lease before it expires to maintain the database credential. Vault issues leases with a TTL, but the lease is not automatically extended; the client must call the renew endpoint using the lease ID. Since the application is not renewing, the lease is revoked at its TTL (1 hour) or earlier if the default lease duration is shorter, causing authentication errors after 30 minutes if the default lease TTL is 30 minutes.
Exam trap
The trap here is that candidates assume increasing the TTL or requesting a new credential will solve the problem, but Cisco tests the understanding that leases must be actively renewed by the client, not automatically extended by Vault.
How to eliminate wrong answers
Option A is wrong because revoking the lease and requesting a new credential with a longer TTL does not address the root cause—the application's failure to renew the lease; the credential will still expire if not renewed. Option C is wrong because calling sys/leases/renew is the correct API endpoint for renewal, but the developer needs to modify the application to call it periodically, not just use the lease ID from the response; the option implies a manual or one-time action, not a programmatic renewal loop. Option D is wrong because increasing the TTL of the database role to 2 hours only extends the maximum lease duration, but the application still does not renew the lease, so the credential will still be revoked after the TTL (now 2 hours) unless renewed; the issue is the lack of renewal, not the TTL length.
A Vault cluster has two nodes configured for HA. The active node becomes unresponsive, and the standby node takes over. However, clients cannot connect to the new active node. The firewall rules allow traffic on port 8200. What is the most likely issue?
TLS certificate mismatch causes connection failures.
Why this answer
Option A is correct because if the TLS certificate on the standby node does not match the hostname clients use, connections will fail. Option B is wrong because storage backend connectivity is not required for client listener. Option C is wrong because the unseal status is independent of TLS.
Option D is wrong because a tainted node would not affect client connections to the active node.
A DevOps engineer is designing a Vault architecture for a multi-cloud environment spanning AWS, GCP, and on-premises data centers. The requirement is to have low-latency read access to secrets across all regions, and the ability to handle a full regional outage without manual intervention. Which architecture best meets these requirements?
Non-voters can serve reads locally, and quorum can survive a regional outage.
Why this answer
Option D is correct because a single Vault cluster using Integrated Storage with voter and non-voter nodes can span multiple regions and clouds, providing low-latency reads via local non-voter nodes while maintaining a single Raft consensus group. This architecture handles a full regional outage without manual intervention because the Raft protocol automatically maintains quorum across voter nodes, and non-voter nodes can be promoted if needed, ensuring continuous read availability and automatic failover.
Exam trap
HashiCorp often tests the misconception that multiple clusters with DR replication are required for multi-region low-latency reads, but the trap is that DR replication requires manual promotion and does not provide automatic failover, whereas a single cluster with Integrated Storage and non-voter nodes can achieve both low-latency reads and automatic regional outage handling.
How to eliminate wrong answers
Option A is wrong because performance standby nodes do not participate in the Raft consensus or storage layer; they only forward write requests to the active node and cannot independently handle a full regional outage without the primary cluster. Option B is wrong because Disaster Recovery replication with Performance Replication requires manual promotion of a DR cluster to primary during an outage, violating the 'without manual intervention' requirement. Option C is wrong because even with an automated failover script, DR replication is designed for disaster recovery, not low-latency reads across regions, and the script introduces complexity and potential failure points that do not meet the requirement for automatic handling.
Match each Vault replication type to its behavior.
Drag a concept onto its matching description — or click a concept then click the description.
Disaster recovery, async replication
Scale read operations, active-standby
Replicate only mount-specific data
Replicate all data across clusters
Why these pairings
These are Vault Enterprise replication modes.
An admin wants to list all enabled authentication methods using the Vault API. Which curl command is correct?
Correct; GET to /v1/sys/auth returns all enabled auth methods.
Why this answer
Option B is correct because the Vault API endpoint to list all enabled authentication methods is a GET request to `/v1/sys/auth`. This endpoint returns a map of all enabled auth methods, and the command uses the correct HTTP method (GET) and the required `X-Vault-Token` header for authentication.
Exam trap
HashiCorp often tests the exact API endpoint path and HTTP method, so the trap here is confusing the `/v1/sys/auth` endpoint with the non-existent `/v1/sys/auths` or the incorrect `/v1/auth` path, or assuming a POST request is needed when a GET is correct.
How to eliminate wrong answers
Option A is wrong because `/v1/sys/auths` is not a valid Vault API endpoint; the correct path is `/v1/sys/auth` (without the trailing 's'). Option C is wrong because it uses `-X POST` instead of the required GET method; the `/v1/sys/auth` endpoint only supports GET and DELETE operations, not POST. Option D is wrong because `/v1/auth` is not a valid API path; the correct base path for listing auth methods is `/v1/sys/auth`.
A security team wants to ensure that database credentials generated by Vault are never renewed and have a fixed lifespan of 30 minutes. They configure the role with default_ttl=30m and max_ttl=30m, and set renewable=false. However, they find that some users are able to renew the leases anyway. What could be the reason?
Existing leases retain their original renewable setting; only new leases reflect the updated role.
Why this answer
When a role's configuration is changed, existing leases are not updated. Users who obtained leases before the renewable flag was set to false would still have leases with renewable=true. Option C correctly identifies that the role was likely updated after some leases were issued.
Option A is incorrect because the renewable flag is respected. Option B is incorrect; the lease's renewable property is independent of the token's. Option D is false; renewable applies to secret engine leases as well.
Which TWO statements are true about batch tokens?
They have a fixed lifetime and cannot be changed.
Why this answer
Batch tokens are light, not stored in Vault, and have no renewable or revocation capabilities. Option B is incorrect because batch tokens do not appear in lookup. Option D is incorrect because batch tokens cannot be renewed.
An operator runs vault lease list and sees many expired leases. Why are expired leases still listed?
Expired leases remain in storage until garbage collection runs.
Why this answer
Vault does not immediately remove expired leases; they are cleaned up by a periodic garbage collection process. Until then, they may appear in listing.
An application needs to obtain short-lived, time-limited credentials to access an external database using username/password authentication. Which secrets engine should be used?
Database engine generates dynamic database credentials with lease duration.
Why this answer
The Database secrets engine is designed specifically to generate short-lived, dynamic credentials for databases, including external databases accessed via username/password authentication. It creates unique, time-limited usernames and passwords on-the-fly, which are automatically revoked after a configurable TTL, meeting the requirement for temporary credentials.
Exam trap
HashiCorp often tests the distinction between static secret storage (KV) and dynamic secret generation (Database, AWS, etc.), so the trap here is assuming that any secrets engine can produce time-limited credentials, when only engines like Database, AWS, or PKI are designed for dynamic, lease-based credentials.
How to eliminate wrong answers
Option A is wrong because the KV v2 secrets engine stores static secrets (like fixed passwords or API keys) and does not generate dynamic, time-limited credentials; it simply retrieves stored values without any built-in expiration or rotation mechanism. Option C is wrong because the Consul secrets engine generates dynamic credentials for Consul services (e.g., ACL tokens) and is not designed for database username/password authentication. Option D is wrong because the Identity secrets engine manages entity and group identities within Vault, not external database credentials; it handles aliases and policies, not dynamic secret generation.
An organization is creating Vault policies to manage access to secrets across multiple application teams. According to HashiCorp best practices, which two approaches should be taken when designing policies? (Choose two.)
Templating reduces duplication and ties access to identity attributes.
Why this answer
Options B and D are correct. Path templating with entity metadata reduces policy duplication, and naming policies by application or team improves manageability. Option A is monolithic and insecure.
Option C violates least privilege. Option E is not a recommended practice; deny can be useful for exceptions.
An operator needs to create a periodic token with a period of 36 hours. Which command should they use?
C is correct: -period creates a periodic token.
Why this answer
Option A is correct because the `vault token create -period=36h` command creates a periodic token with a specified renewal period of 36 hours. Periodic tokens have no explicit TTL; their lifetime is tied to the renewal period, and they can be renewed indefinitely as long as the parent token is valid. This matches the requirement for a token that automatically extends its lifetime every 36 hours.
Exam trap
HashiCorp often tests the distinction between `-period` (for periodic tokens) and `-ttl` (for fixed-lifetime tokens), leading candidates to confuse the two and incorrectly choose `-ttl` when a renewable periodic token is required.
How to eliminate wrong answers
Option B is wrong because adding `-explicit-max-ttl=36h` imposes a hard upper limit on the token's lifetime, which contradicts the purpose of a periodic token that should be renewable indefinitely without a fixed maximum. Option C is wrong because `-ttl=36h` creates a non-periodic token with a fixed TTL of 36 hours, after which it expires and cannot be renewed beyond that time. Option D is wrong because `-explicit-max-ttl=36h` alone creates a token with a hard maximum lifetime but no periodic renewal behavior, so it does not meet the requirement for a periodic token.
A DevOps engineer is troubleshooting a script that uses the Vault CLI to authenticate and read a secret. The script works when run manually from a terminal, but fails when executed by a CI/CD pipeline. The engineer has verified that the same environment variables (VAULT_ADDR, VAULT_TOKEN) are set in both environments. Which two of the following are likely causes of the failure? (Choose two.)
Without correct VAULT_ADDR, the CLI cannot connect to Vault, causing failure.
Why this answer
Option B is correct because if VAULT_ADDR is not set correctly, the CLI cannot reach the server. Option D is correct because network restrictions can block API access. Option A is wrong because the same VAULT_TOKEN is set, so it's not expired/revoked.
Option C is wrong because CLI version differences rarely cause permission errors. Option E is wrong because a missing PATH would cause 'command not found', not CLI failure.
An administrator needs to issue tokens that are automatically renewable by the client (so they can stay alive as long as renewed) but must expire no later than 30 days. Which TWO token parameters should be configured on the token role?
Max_ttl enforces an absolute maximum lifetime.
Why this answer
Period allows automatic renewal by extending the token's TTL by the period value each renewal, while max_ttl caps the total lifetime. TTL is the initial lifetime, but with period set, the token's TTL is derived from period. Renewable must be true (default for periodic tokens), but it is not needed to set explicitly.
Num_uses is unrelated.
A Vault administrator creates a policy that grants 'read' and 'list' on 'secret/data/engineering/*' for a group. However, users in that group cannot read 'secret/data/engineering/project/db_password'. What is the most likely issue?
For KV v2, data is under 'secret/data/'; the policy path must match the data path.
Why this answer
In Vault KV v2, secrets are accessed via a path that includes 'data' between the mount point and the secret name (e.g., 'secret/data/engineering/project/db_password'). The policy grants 'read' and 'list' on 'secret/data/engineering/*', which correctly covers the 'data' prefix. However, the user cannot read the secret because KV v2 also requires the 'read' capability on the 'metadata' path for the same secret (e.g., 'secret/metadata/engineering/project/db_password') to resolve version metadata.
Without 'list' or 'read' on the metadata path, the read operation fails. The most likely issue is that the policy is missing the metadata path capability, but among the given options, A is correct because the policy path is incorrect—it should include both 'data' and 'metadata' paths for KV v2.
Exam trap
HashiCorp often tests the distinction between KV v1 and KV v2 path structures, specifically that KV v2 requires both 'data' and 'metadata' paths, and candidates mistakenly think granting 'read' on the data path alone is sufficient.
How to eliminate wrong answers
Option B is wrong because the question states the secret is at 'secret/data/engineering/project/db_password', which matches the mount path 'secret' used in the policy; there is no indication of a different mount. Option C is wrong because 'update' capability is for writing or modifying secrets, not for reading; the issue is about read access, not write. Option D is wrong because namespaces in Vault are isolated and policies must be explicitly assigned within a namespace; if users are in a different namespace, they would not inherit the policy at all, but the question implies the policy is applied to the group and the users are in that group, so namespace mismatch is not the most likely issue.
A DevOps team wants to authenticate to Vault using short-lived tokens without storing a secret in their CI/CD pipeline. Which authentication method best meets this requirement?
Correct: JWT/OIDC allows token exchange without storing static secrets.
Why this answer
JWT/OIDC authentication allows a DevOps pipeline to exchange a signed JSON Web Token (JWT) from an external identity provider (e.g., GitHub Actions, GitLab CI) for a short-lived Vault token. This eliminates the need to store a long-lived secret in the CI/CD pipeline because the JWT is dynamically generated by the CI platform and validated by Vault using the OIDC provider's public keys. The resulting Vault token has a configurable TTL, typically minutes, aligning with the requirement for short-lived credentials.
Exam trap
HashiCorp often tests the misconception that AppRole is the best choice for CI/CD because it is designed for machine authentication, but the trap is that AppRole still requires storing a role_id and secret_id, which are long-lived secrets unless using response wrapping, and the question explicitly prohibits storing any secret.
How to eliminate wrong answers
Option B (AWS IAM) is wrong because it requires the CI/CD pipeline to have access to AWS IAM credentials (access key and secret key) or an IAM role with a trust policy, which still involves storing a secret or assuming a role that may not be short-lived. Option C (AppRole) is wrong because it requires a secret_id and role_id to be stored in the pipeline; while secret_id can be wrapped or have a TTL, the role_id is typically static and must be securely stored, contradicting the 'without storing a secret' requirement. Option D (Username & Password) is wrong because it requires storing a static password in the pipeline, which is a long-lived secret and violates the short-lived token requirement.
Which TWO of the following are valid paths for reading and writing data in the KV v2 secrets engine? (Choose two.)
/data/ is the correct path for reading and writing secret data.
Why this answer
In the KV v2 secrets engine, data is accessed via the `data` and `metadata` paths. The `secret/data/myapp` path is the correct endpoint for reading and writing the actual secret data, as it triggers the versioned API. Option E, `secret/metadata/myapp`, is also valid for reading and writing metadata (such as deletion timestamps and version information) but not the secret values themselves.
Exam trap
HashiCorp often tests the distinction between KV v1 and KV v2 paths, trapping candidates who assume the base mount path (e.g., `secret/myapp`) works for both engines, when in KV v2 the `/data/` sub-path is mandatory for reading and writing secret data.
An operator notices that after a network partition, a Vault cluster with integrated storage (Raft) has a node that is unreachable and does not automatically rejoin. The cluster has 5 nodes with a minimum quorum of 3. What is a likely cause for the node not rejoining?
If 2 of 5 nodes are down, the remaining 3 constitute quorum; if more than 2 are down, quorum is lost.
Why this answer
In a Raft-based Vault cluster with 5 nodes and a quorum of 3, if a node becomes unreachable due to a network partition and does not automatically rejoin, the most likely cause is that additional nodes are also down or unreachable, causing the cluster to lose quorum. Without a majority of nodes (3 out of 5) able to communicate, the Raft consensus protocol cannot elect a leader or process log entries, so the isolated node cannot rejoin because the cluster itself is in a degraded state. The node not rejoining is a symptom of the broader quorum loss, not an isolated issue with that node.
Exam trap
HashiCorp often tests the misconception that a single node failure in a Raft cluster is automatically recoverable, but the trap here is that candidates overlook the quorum requirement and assume the node's own configuration or clock is at fault, rather than recognizing that the cluster may have lost majority due to multiple nodes being down.
How to eliminate wrong answers
Option A is wrong because a node's Raft index cannot be ahead of the leader's in a properly functioning Raft cluster; the leader always has the most up-to-date log index, and if a node were ahead, it would indicate a split-brain scenario or corruption, which is not typical after a partition. Option C is wrong because Raft does not rely on clock synchronization for timeouts; it uses election timeouts based on randomized timers, and clock skew is not a factor in Raft's consensus algorithm. Option D is wrong because manual removal and re-addition is a recovery step for a permanently failed node, not the likely cause of a node failing to rejoin after a partition; the cluster should automatically handle rejoin if quorum is restored.
An admin wants to revoke all leases associated with a specific AWS IAM user created by Vault. Which command should they use?
This revokes all leases starting with 'aws/creds/myrole', which covers all IAM users from that role.
Why this answer
The `vault lease revoke -prefix` command revokes all leases with a given prefix. The prefix for AWS IAM users created by a role is typically 'aws/creds/role-name'. Option C correctly uses the -prefix flag.
Option A revokes only that exact path if it were a lease ID. Option B has no -prefix. Option D has an incorrect syntax.
A compliance requirement states that encryption keys must be automatically rotated every 90 days. Which Vault feature can be used to enforce this?
The `auto_rotate_period` parameter on a transit key enables automatic rotation.
Why this answer
Option A is correct because the Vault Transit Secrets Engine supports an `auto_rotate` parameter that can be set on a key to enforce automatic rotation every 90 days. When enabled, Vault automatically rotates the encryption key at the specified interval without manual intervention, directly meeting the compliance requirement for automated 90-day rotation.
Exam trap
HashiCorp often tests the distinction between automatic rotation enforcement (`auto_rotate`) and manual or policy-based controls (`min_decryption_version`, periodic tokens), leading candidates to confuse decryption version management with rotation scheduling.
How to eliminate wrong answers
Option B is wrong because Vault does not have a built-in cron-like scheduler; rotation scheduling is handled internally by the Transit engine's `auto_rotate` or via external tools like cron jobs. Option C is wrong because `min_decryption_version` controls which key versions can decrypt data, not the rotation schedule; it is a decryption policy, not an enforcement mechanism for rotation timing. Option D is wrong because there is no 'key rotation schedule policy' in Vault; rotation is configured per key using parameters like `auto_rotate` or `rotation_period`, not through a separate policy object.
Option E is wrong because using a periodic token to call the rotate endpoint requires external scripting and does not enforce automatic rotation; it is a manual or semi-automated workaround, not a built-in enforcement feature.
Refer to the exhibit. A user with this policy tries to write a new secret to "secret/data/production/db". What will happen?
Only read is allowed on production paths, so write is denied.
Why this answer
Option B is correct. The policy for production only allows read, so write operations (create/update) are denied. The path does match the production glob, but capabilities do not permit write.
An administrator needs to enable authentication method for human users that integrates with an existing LDAP directory. The company wants to ensure that Vault can perform group-based policy assignment based on LDAP group membership. Which configuration step is mandatory to map LDAP groups to Vault policies?
This tells Vault which LDAP attribute holds group membership.
Why this answer
The 'groups' attribute mapping must be set to point to the LDAP attribute containing group membership. The 'users' attribute is for user mapping, 'upndomain' is for UPN suffix, 'certificate' is for TLS.
A security team wants to enforce that all tokens created by a specific AppRole can only be used to read secrets from the path 'secret/data/team-a/*'. They have configured the AppRole with token_policies that include that path. However, a developer uses the token created from this AppRole to create a child token with broader policies, granting access to 'secret/data/team-b/*'. The security team wants to prevent such privilege escalation. Which action should be taken to ensure that child tokens cannot have broader policies than the parent?
The parent token can set 'allowed_policies' to limit which policies child tokens can receive.
Why this answer
Option D is correct. By setting 'token_bound_cidrs' or more relevantly, the parent token can have 'allowed_policies' that restrict child token policies. However, the correct mechanism is to set 'token_policies' on the AppRole and also set 'token_bound_policies' or use 'token_explicit_max_ttl'? Actually the best practice is to set the AppRole's 'token_policies' and also restrict child token creation by setting 'token_no_default_policy'? Wait, the question asks about child token policies.
In Vault, when creating a child token, the parent's policies are inherited unless the parent has 'allowed_policies' set which limits the policies the child can have. If the parent does not set 'allowed_policies', the child can have any policies the creator has access to. To prevent this, set the parent's 'allowed_policies' to only include the desired policy.
Option A is wrong because root tokens are not needed. Option B is wrong because setting 'orphan=true' does not affect policies. Option C is wrong because revoking tokens does not prevent future escalation.
So the correct answer is to configure the parent token's 'allowed_policies' to restrict child token policies.
An administrator wants to allow human users to authenticate using their corporate Active Directory credentials. Which authentication method should they enable?
LDAP auth directly authenticates against AD.
Why this answer
LDAP (Lightweight Directory Access Protocol) authentication allows integration with corporate Active Directory by binding to the directory service using a user's credentials. This enables centralized authentication against existing AD user objects without duplicating accounts in the Vault system.
Exam trap
HashiCorp often tests the misconception that 'LDAP auth' is only for Unix/Linux systems, when in fact it is the standard protocol for integrating with Microsoft Active Directory for user authentication.
How to eliminate wrong answers
Option A is wrong because token auth is used for machine-to-machine authentication via pre-shared tokens, not for human users authenticating with corporate credentials. Option B is wrong because GitHub auth is an OAuth-based method for authenticating with GitHub identities, not for corporate Active Directory. Option C is wrong because userpass auth stores credentials locally in Vault's backend, requiring manual user management and not integrating with external directory services like Active Directory.
Which THREE are best practices when selecting authentication methods for different use cases?
AppRole is designed for machine authentication.
Why this answer
AppRole is designed for machine-to-machine authentication, making it ideal for automated CI/CD pipelines. It provides a secure way for applications to obtain a Vault token using a RoleID and SecretID, without requiring a human user. This avoids the security risks of long-lived tokens and allows for dynamic, short-lived credentials.
Exam trap
HashiCorp often tests the misconception that a single authentication method can be universally applied, or that a method designed for a specific platform (like Kubernetes auth) can be used in any environment, leading candidates to select overly broad or insecure options like B or D.
A root token creates token T1 with a TTL of 1 hour. T1 then creates token T2 with a TTL of 2 hours. After 30 minutes, T1 is revoked without using the 'cascade' option. What happens to T2?
Children of revoked tokens become orphans and remain functional.
Why this answer
Option C is correct because revoking a token does not automatically revoke its children unless the cascade flag is used. T2 becomes an orphan token but continues to function until its own TTL expires. Option A is wrong because cascade revocation was not used.
Option B is wrong because T2 is still active until its TTL. Option D is wrong because T2 does not inherit the parent's revocation.
A DevOps engineer is tasked with automating the rotation of a static secret stored in Vault's KV secrets engine (version 2). The secret is currently stored at path 'secret/data/app/config' with keys 'username' and 'password'. The engineer wants to update the 'password' key using the Vault CLI from a CI/CD pipeline. The pipeline uses a token with a policy that grants 'create', 'update', and 'read' capabilities on 'secret/data/app/*'. Which CLI command should the engineer use to update only the 'password' key, leaving other keys unchanged?
'vault kv patch' performs a partial update; only the specified key is changed.
Why this answer
Option C is correct because `vault kv patch` is specifically designed for KV v2 secrets engines to update individual keys without overwriting other keys. It performs a read-modify-write operation under the hood, sending a PATCH request to the API, which only modifies the specified fields. The policy grants 'create', 'update', and 'read' on 'secret/data/app/*', which aligns with the required capabilities for patching.
Exam trap
HashiCorp often tests the distinction between `vault kv put` (full overwrite) and `vault kv patch` (partial update) in KV v2, and candidates mistakenly assume `vault write` or `vault kv put` can selectively update keys, not realizing they replace the entire secret data.
How to eliminate wrong answers
Option A is wrong because `vault kv put` performs a full write, which would overwrite the entire secret at 'secret/data/app/config', deleting the 'username' key if not included. Option B is wrong because `vault update` is not a valid Vault CLI command; the correct verb for writing data is `vault write`. Option D is wrong because `vault write` on a KV v2 path sends a PUT request that replaces the entire secret data, similar to `vault kv put`, and would remove the 'username' key.
A company uses Vault's Kubernetes authentication method to provide secrets to pods. Pods in the 'production' namespace need to read secrets from the path 'secret/data/app/prod'. The administrator has created a Vault role that maps the service account to a policy with capabilities ['read', 'list'] on path 'secret/data/app/*'. However, pods report 'permission denied' when trying to read the secrets. The administrator verifies that the service account has the correct Vault role attached and that the Vault token is being used correctly. What is the most likely cause?
Correct: KV v1 does not use the 'data/' prefix. The policy is written for KV v2, so it does not match the actual path, resulting in permission denied.
Why this answer
Option B is the most likely cause. The mount being KV v1 means the actual secret path is 'secret/app/prod', not 'secret/data/app/prod'. The policy targeting 'secret/data/app/*' does not match, so the pods lack access.
The other options are less plausible given the verification steps.
An organization uses Vault's AWS secrets engine to generate temporary IAM credentials. The Vault administrator has set the default lease TTL on the AWS mount to 15 minutes. A developer creates a role with role TTL of 30 minutes and explicit max TTL of 1 hour. Which TWO statements are true regarding the lease behavior for credentials generated under this role?
The role TTL is used as the lease duration at creation time.
Why this answer
Option A is correct because when a role has an explicit role TTL (30 minutes), Vault uses that value as the initial lease duration for credentials generated under that role, overriding the default mount TTL. The default lease TTL of 15 minutes on the AWS mount only applies when no role TTL is specified.
Exam trap
HashiCorp often tests the distinction between initial lease duration (role TTL) and total allowable lifetime (explicit max TTL), and the trap here is assuming the default mount TTL or a minimum calculation governs the initial lease when a role TTL is explicitly configured.
During an audit, it is discovered that a single AppRole role is used by hundreds of applications, and it is impossible to revoke access for a single compromised application without affecting others. What should be done to improve the security posture?
Allows revoking a single application's access without affecting others.
Why this answer
Creating a unique AppRole role for each application ensures that each application has its own set of credentials (RoleID and SecretID). This allows you to revoke access for a single compromised application by deleting or disabling its specific AppRole role, without impacting other applications. This directly addresses the core issue of shared credentials and provides granular access control.
Exam trap
The trap here is that candidates often choose secret rotation (Option B) as a security best practice, but they fail to recognize that rotation does not solve the fundamental problem of shared credentials and lack of isolation between applications.
How to eliminate wrong answers
Option B is wrong because periodic secret ID rotation does not solve the problem of a single compromised application affecting others; all applications still share the same role, so rotating the secret ID would disrupt all applications simultaneously. Option C is wrong because reducing the token TTL to 1 minute only limits the lifespan of tokens, but it does not isolate applications; a compromised application could still continuously re-authenticate and access resources, and revoking its access would still require revoking the entire role. Option D is wrong because adding CIDR bindings restricts the source IP addresses that can authenticate, but if multiple applications share the same role and originate from different IPs, this could block legitimate traffic; more importantly, it does not allow selective revocation for a single compromised application.
Refer to the exhibit. An operator issues a certificate using this intermediate CA. The resulting certificate uses SHA1 signature algorithm. The operator wants SHA256. What should they do?
The intermediate must be recreated with the desired signature bits.
Why this answer
Option A is correct because the signature algorithm used by an intermediate CA is determined by the `signature_bits` parameter set when the intermediate CA's certificate is generated. To issue end-entity certificates with SHA256, the intermediate CA itself must be created with `signature_bits=256`. Simply changing a role or issuer after the intermediate exists does not retroactively alter the CA's signing key algorithm.
Exam trap
HashiCorp often tests the distinction between the CA's own signing algorithm (set at CA creation) and the role's signing algorithm (set per issuance), leading candidates to mistakenly think a role change can fix the CA's algorithm.
How to eliminate wrong answers
Option B is wrong because `vault write` on an existing intermediate CA cannot change its `signature_bits`; this parameter is immutable after issuance and only applies at generation time. Option C is wrong because using a different issuer_name that already has SHA256 would require a pre-existing intermediate CA configured with SHA256, which is not a direct action to fix the current intermediate — it avoids the root cause. Option D is wrong because a role's `signature_bits` only affects the signing algorithm for certificates issued by that role, but the intermediate CA's own certificate algorithm is fixed at creation; the role cannot override the CA's signing key algorithm.
A developer created a token and wants to ensure that the token can only be used to read secrets from the 'secret/data/production' path. Which policy attachment approach should be used?
Policies define access; attaching the policy grants the token those permissions.
Why this answer
Option C is correct because Vault uses policies to define fine-grained access control, and the only way to restrict a token to read secrets from a specific path is to create a policy with the appropriate capabilities (e.g., 'read' on 'secret/data/production') and attach that policy to the token at creation time. Tokens themselves do not inherently carry path restrictions; they inherit permissions solely from attached policies.
Exam trap
HashiCorp often tests the misconception that token metadata or token type can enforce access restrictions, when in fact only policies attached to the token define what paths and operations are allowed.
How to eliminate wrong answers
Option A is wrong because token metadata is used for audit and identity purposes, not for enforcing access control; Vault does not evaluate metadata to allow or deny API requests. Option B is wrong because a root token has unrestricted access to all paths and policies cannot restrict a root token—root tokens bypass all policy checks by design. Option D is wrong because the token type (service vs. batch) determines lifecycle and revocation behavior, not access permissions; a service token still requires an attached policy to define what it can read.
An organization uses Vault with the JWT/OIDC authentication method. After configuring the provider, users can authenticate, but the scopes requested do not include the email claim needed for policy mapping. What should the administrator do?
Adding the scope requests the email claim from the provider.
Why this answer
The email claim is not included in the JWT because the OIDC provider was not requested to issue it. In OIDC, claims are delivered only when the corresponding scope (e.g., 'email') is included in the authentication request. Adding the 'email' scope to the Vault OIDC auth method configuration ensures the provider returns the email claim, which can then be used for policy mapping.
Exam trap
HashiCorp often tests the distinction between configuring the auth method (Vault side) versus the provider side, and the trap here is that candidates mistakenly think they need to modify the external OIDC provider or create a claim mapping, when the fix is simply adding the missing scope to Vault's OIDC configuration.
How to eliminate wrong answers
Option A is wrong because adding a policy that uses the email claim does not cause the claim to appear in the token; the claim must first be requested via the correct scope. Option B is wrong because modifying the OIDC provider's configuration (the external identity provider) is not the correct action; the administrator must adjust Vault's OIDC auth method configuration to request the 'email' scope. Option C is wrong because custom claim mapping is used to rename or transform claims that are already present, not to request new claims that are missing due to an omitted scope.
A startup is deploying Vault for the first time. They want to use Integrated Storage for simplicity. They plan to run Vault on three small instances. During initial setup, they start the first node and initialize Vault, obtaining the unseal keys and root token. Then they start the second node and run `vault operator raft join http://<first_node>:8200`. The second node joins successfully. They then start the third node and attempt to join, but the join command fails with an error saying 'no leader'. What is the most likely cause?
The leader must be unsealed for joins to work.
Why this answer
The correct answer is A. In a Vault Integrated Storage (Raft) cluster, a newly joined node must be able to contact an unsealed leader to complete the join process. If the first node (the initial leader) is still sealed after initialization, it cannot participate in Raft consensus or respond to join requests.
The third node's join fails with 'no leader' because the sealed first node cannot act as a leader, and the second node, while joined, has not been unsealed and thus cannot become leader either. Unsealing the first node would restore its leadership and allow the third node to join.
Exam trap
HashiCorp often tests the misconception that initializing Vault automatically makes it ready to accept cluster joins, when in fact the node remains sealed and cannot act as a leader until unsealed.
How to eliminate wrong answers
Option B is wrong because the join command explicitly specifies the IP address of the first node, and the error 'no leader' indicates the issue is not a network connectivity or addressing problem but rather the absence of an unsealed leader. Option C is wrong because while a quorum of 2 nodes is needed for leader election, the core issue is that the first node is sealed; if it were unsealed, it would already be the leader and the third node could join. Option D is wrong because the second node does not need to be unsealed for the third node to join; the join process only requires an unsealed leader (the first node) to accept the new node, and the second node's sealed state does not prevent the third from joining.
A Vault administrator wants to minimize the impact of a single node failure in a three-node Raft cluster. Which TWO actions will help? (Choose two.)
Proactive detection and replacement reduce the window of vulnerability.
Why this answer
Configuring `retry_join` allows nodes to automatically rejoin the cluster after failure, and monitoring helps detect and replace failed nodes quickly. Load balancer and performance standby do not address node failure directly.
Which TWO of the following are valid methods to enable a secrets engine at a non-default path in Vault?
Correct: This is the same as A, shown for redundancy (but both are correct).
Why this answer
Option C is correct because the `vault secrets enable` command uses the `-path` flag to specify a custom mount path for a secrets engine, overriding the default path that matches the engine type. This is the standard CLI syntax for enabling a secrets engine at a non-default location, as documented by HashiCorp.
Exam trap
HashiCorp often tests the distinction between the correct `-path` flag and plausible but incorrect flags like `-custom-path` or `-mount-path`, exploiting candidates who memorize command syntax loosely without verifying the exact flag names.
A developer needs to generate a new certificate for an internal web service using the PKI secrets engine. A role named 'webserver' has been created. What is the correct command to issue the certificate?
This writes to the issue endpoint for the role 'webserver' with required parameters.
Why this answer
Option D is correct because the PKI secrets engine uses the path `pki/issue/<role_name>` to issue certificates. The `vault write` command sends a POST request to this endpoint with the required `common_name` parameter, which generates a new certificate signed by the CA associated with the 'webserver' role.
Exam trap
HashiCorp often tests the exact API path structure, where candidates mistakenly assume the role name is part of the path before 'issue' (e.g., `pki/role/issue`) or confuse the issue endpoint with the read endpoint for existing certificates.
How to eliminate wrong answers
Option A is wrong because `pki/webserver/issue` is not a valid endpoint; the correct path is `pki/issue/webserver`. Option B is wrong because `pki/webserver/cert` is not a valid endpoint for issuing certificates; it incorrectly appends 'cert' to the role name. Option C is wrong because `vault read pki/cert/webserver` retrieves an existing certificate by serial number or ID, not issue a new one, and 'webserver' is a role name, not a certificate identifier.
A Vault administrator is configuring AppRole authentication via the configuration file shown. After running `vault server -config=config.json`, they try to enable AppRole at a different path. What will happen?
Multiple AppRole mounts can exist at different paths.
Why this answer
Option C is correct because AppRole authentication can be enabled at any mount path, regardless of whether it is pre-configured in the Vault configuration file. The configuration file only defines the initial backend settings; it does not prevent the admin from enabling the same auth method at a different path using the `vault auth enable` command. Vault allows multiple mounts of the same auth method type at different paths, each with its own configuration.
Exam trap
The trap here is that candidates may think the configuration file's path setting locks the auth method to that specific path, preventing it from being enabled elsewhere, when in fact Vault allows multiple mounts of the same auth method type at different paths.
How to eliminate wrong answers
Option A is wrong because the backend defined in the config file will be enabled at the specified path when Vault starts; it is not disabled. Option B is wrong because the admin does not need to modify the config file to change the path; they can simply enable AppRole at another path via the CLI or API. Option D is wrong because Vault will not fail to start; the path in the config file is used for that specific mount, and enabling AppRole at a different path does not conflict with it.
A Vault administrator wants to allow a CI/CD pipeline to create short-lived tokens for deployment jobs. The pipeline itself authenticates with a periodic token. Which token type should the pipeline use to create tokens for jobs, considering the jobs need to be independent and not affected by the pipeline token's lifecycle?
Orphan tokens are not revoked when the parent expires.
Why this answer
Orphan tokens are the correct choice because they allow the CI/CD pipeline to create child tokens that are not tied to the parent token's lifecycle. When a periodic token creates an orphan token, the child token remains valid even if the parent token is revoked or expires, ensuring deployment jobs are independent and not affected by the pipeline token's lifecycle.
Exam trap
HashiCorp often tests the misconception that all child tokens are automatically orphaned or that periodic tokens can create independent child tokens, but the trap is that only explicitly orphaned tokens break the parent-child chain, while default token creation maintains a hierarchical dependency.
How to eliminate wrong answers
Option A is wrong because service tokens with explicit max TTL are still parent-child tokens; if the parent token is revoked, the child token is also revoked, so the jobs would be affected by the pipeline token's lifecycle. Option C is wrong because periodic tokens are used for long-lived, renewable tokens with a fixed lifetime, not for creating short-lived tokens for jobs; they also create parent-child relationships by default. Option D is wrong because batch tokens are lightweight, non-renewable tokens that cannot create child tokens at all, so they cannot be used to generate tokens for deployment jobs.
A developer wants to encrypt a password before storing it in a database. The encryption must be deterministic so that the same plaintext always produces the same ciphertext. Which encryption mode should be used in the transit secrets engine?
Convergent encryption derives the nonce from the plaintext and context, making output deterministic.
Why this answer
The transit secrets engine in Vault supports convergent encryption, which is a deterministic encryption mode where the same plaintext and context always produce the same ciphertext. This is achieved by using the plaintext itself as part of the encryption key derivation, ensuring repeatable output. The question specifically requires deterministic encryption, making convergent encryption the correct choice.
Exam trap
HashiCorp often tests the misconception that any AES-GCM mode is deterministic, but in practice, AES-GCM requires a unique nonce for each encryption, making it non-deterministic unless combined with convergent encryption or a fixed nonce (which would break security guarantees).
How to eliminate wrong answers
Option A is wrong because chacha20-poly1305 is an authenticated encryption algorithm, not a mode that provides deterministic output; it uses a nonce, so the same plaintext produces different ciphertexts each time. Option C is wrong because aes128-gcm96 is an AEAD algorithm that requires a unique nonce for each encryption, making it non-deterministic. Option D is wrong because aes-gcm is a generic algorithm that, without a fixed nonce, produces different ciphertexts for the same plaintext; Vault's transit engine does not support deterministic AES-GCM without convergent encryption.
Option E is wrong because padding is a data transformation technique, not an encryption mode, and does not provide deterministic encryption by itself.
Which of the following best describes a Vault lease?
This accurately describes a lease as a time-bound contract for secret usage.
Why this answer
A Vault lease is a time-bound agreement that governs the lifecycle of a secret, including its validity period, renewal, and revocation. When a secret is read from Vault, it is returned with a lease ID and a lease duration (TTL), after which the secret is automatically revoked unless renewed. This ensures that secrets are not valid indefinitely, reducing the risk of exposure.
Exam trap
HashiCorp often tests the distinction between the lease itself (the lifecycle management agreement) and the secret value, leading candidates to mistakenly choose Option D because they think the lease is the actual secret.
How to eliminate wrong answers
Option A is wrong because a Vault lease is not merely a permission to access a path; permissions are defined by policies attached to tokens or auth methods, not by leases. Option C is wrong because a lease is not a contract to use a secret for a certain duration; it is a technical mechanism that automatically manages the secret's lifecycle, including renewal and revocation, not a contractual agreement. Option D is wrong because the actual secret value is the data returned by Vault (e.g., a password or API key), while the lease is the metadata (lease ID, TTL, renewable flag) that controls that secret's lifecycle.
Match each Vault command to its function.
Drag a concept onto its matching description — or click a concept then click the description.
Write a secret
Read data at a path
Write data or invoke an endpoint
Delete a secret or path
List keys under a path
Why these pairings
These are basic Vault CLI commands.
A company uses Vault to manage secrets for multiple applications. A new security policy requires that all human users authenticate using LDAP and that all machine-to-machine authentication uses AppRole. An administrator has configured an LDAP auth method at 'ldap/' and an AppRole at 'approle/'. The administrator creates a role 'web-app' with a secret ID TTL of 30 days and a token TTL of 1 hour. After deploying the web application, the application successfully logs in using the AppRole role ID and secret ID, retrieves a token, and reads secrets. However, after 1 hour, the application begins receiving 'permission denied' errors when trying to read secrets. The application logs show that it is using the same token obtained during initial login. Which action should the administrator take to resolve this issue?
Token renewal extends the token's lifetime, preventing permission denied errors after TTL expiry.
Why this answer
Option D is correct because the application's token has a TTL of 1 hour, and once it expires, Vault will reject any further requests using that token. The application must renew the token before it expires by calling the 'auth/token/renew' endpoint, which extends the token's lifetime (up to the maximum TTL configured on the role). This is the standard pattern for long-running applications using short-lived tokens.
Exam trap
HashiCorp often tests the distinction between secret ID TTL and token TTL, leading candidates to confuse the two and incorrectly choose options that modify the secret ID or re-authenticate instead of renewing the token.
How to eliminate wrong answers
Option A is wrong because increasing the secret ID TTL does not affect the token's lifetime; the secret ID is only used during initial authentication to obtain a token, and the token's TTL is independent. Option B is wrong because setting the token TTL to 0 (unlimited) violates the security policy requiring short-lived tokens and is not a recommended practice; Vault's default maximum TTL also limits this. Option C is wrong because re-authenticating with the same secret ID after the token expires would work, but it is inefficient and unnecessary; the application should instead renew the existing token to avoid the overhead of re-authentication and to maintain a continuous session.
An administrator wants to mount the AWS secrets engine at 'aws' path using the API. Which request is correct?
A is correct: POST to mounts with type aws mounts the engine.
Why this answer
Option C is correct because mounting a secrets engine in Vault is performed via a POST request to the `/v1/sys/mounts/<path>` endpoint with a JSON body containing the `"type"` field set to the engine's type identifier. For the AWS secrets engine, the type is `"aws"`, and the path is specified in the URL as `aws`. The POST method is required for creating a new mount, while PUT is used for tuning an existing mount.
Exam trap
HashiCorp often tests the distinction between POST (create) and PUT (update/tune) for Vault API endpoints, and candidates confuse the mount path with auth method paths or use an incorrect type string like 'aws-secrets' instead of the official 'aws'.
How to eliminate wrong answers
Option A is wrong because it uses the PUT method, which is reserved for tuning an existing mount (e.g., updating configuration or adjusting default lease TTLs), not for creating a new mount; creating a mount requires POST. Option B is wrong because it targets the `/v1/sys/auth/aws` endpoint, which is used for enabling an auth method (like LDAP or AppRole), not for mounting a secrets engine; secrets engines are mounted under `/v1/sys/mounts/`. Option D is wrong because it specifies `"type":"aws-secrets"` in the body, but the correct type identifier for the AWS secrets engine is `"aws"`; `"aws-secrets"` is not a valid Vault engine type.
Drag and drop the steps to configure Vault's database secrets engine with PostgreSQL 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 engine, configure connection, create role, generate creds, revoke.
A company uses OIDC auth for human users. After the OIDC provider rotates its signing keys, some users report that they cannot authenticate. The Vault logs show that the OIDC response validation fails. What is the most likely cause?
Vault's cached JWKS may be outdated after key rotation.
Why this answer
When an OIDC provider rotates its signing keys, Vault must fetch the new JWKS (JSON Web Key Set) to validate the token signature. Vault caches the JWKS for performance, and if the cache still holds the old keys, signature validation fails for tokens signed with the new key. This matches the symptom of OIDC response validation failing immediately after a key rotation.
Exam trap
HashiCorp often tests the distinction between token expiration (which is a time-based claim validation) and key rotation (which is a cryptographic signature validation failure), leading candidates to incorrectly choose the expired token option when the real issue is stale cached keys.
How to eliminate wrong answers
Option A is wrong because the OIDC role configuration (e.g., allowed redirect URIs, bound claims) does not change when the provider rotates keys; a misconfigured role would cause consistent failures, not a sudden failure after key rotation. Option B is wrong because an expired token would produce a different error (e.g., 'token is expired' or 'token used before issued'), not a generic OIDC response validation failure, and the issue is tied to key rotation timing. Option C is wrong because if the OIDC provider were down, Vault would not be able to fetch the JWKS at all, leading to a connection timeout or discovery failure, not a signature validation failure on a response that was received.
A developer wants to ensure that their application automatically renews its secret leases before expiration. Which approach is recommended?
Vault Agent is designed for automatic lifecycle management of leases.
Why this answer
Vault Agent's template and renew capability is the recommended approach because it automatically manages the lifecycle of dynamic secrets, including renewing leases before they expire. Vault Agent runs as a sidecar or daemon and uses its built-in renewer to periodically extend the lease TTL, ensuring the application always has a valid secret without manual intervention or external scheduling.
Exam trap
HashiCorp often tests the distinction between renewing a token (which can use periodic tokens) versus renewing a secret lease (which requires Vault Agent or explicit lease renewal), causing candidates to mistakenly choose periodic tokens for secret lease renewal.
How to eliminate wrong answers
Option A is wrong because setting the lease TTL to infinite is not supported by Vault; leases always have a finite TTL defined by the secret engine's default or maximum, and infinite TTL would violate security best practices by never forcing rotation. Option B is wrong because using a cron job to call vault lease renew is brittle and not recommended; it introduces a single point of failure, lacks awareness of lease expiration timing, and does not handle Vault Agent's automatic renewal or template rendering. Option D is wrong because periodic tokens with auto-renewal are used for long-lived tokens, not for renewing secret leases; secret leases (e.g., database credentials, AWS IAM keys) require explicit lease renewal via the /sys/leases/renew endpoint, and periodic tokens do not automatically renew those leases.
Which TWO statements correctly describe Vault's storage backend and seal/unseal mechanism?
The unseal process decrypts the master key, which in turn decrypts the data in the storage backend.
Why this answer
Option A is correct because Vault's unseal process uses a threshold of unseal keys to decrypt the master key stored in the keyring. The master key then decrypts the storage backend's encryption key, allowing Vault to access the encrypted data. This ensures that the storage backend remains encrypted at rest and is only readable after a successful unseal operation.
Exam trap
HashiCorp often tests the misconception that Shamir's secret sharing splits the master key itself, when in reality it splits the unseal key used to decrypt the master key, and that the storage backend handles sealing/unsealing rather than just data persistence.
An application needs to encrypt credit card numbers. The encryption must be deterministic for indexing purposes but also support key rotation. Which approach should be used?
Convergent encryption allows deterministic output and supports key rotation via rewrapping.
Why this answer
Option D is correct because convergent encryption uses a deterministic key derived from the data itself (e.g., SHA-256 hash of the plaintext), which ensures the same credit card number always produces the same ciphertext for indexing. Key rotation is supported by re-encrypting the data encryption key (DEK) with a new key encryption key (KEK), without changing the underlying ciphertext, thus preserving determinism while rotating the wrapping key.
Exam trap
HashiCorp often tests the misconception that 'deterministic encryption' requires a single static key, leading candidates to choose standard encryption (E) or datakey encryption (C), while ignoring convergent encryption's ability to combine determinism with key rotation via key wrapping.
How to eliminate wrong answers
Option A is wrong because Vault's cubbyhole is a per-request temporary storage mechanism that does not provide deterministic encryption or key rotation capabilities. Option B is wrong because Vault's transformations engine (e.g., FPE or tokenization) is designed for format-preserving encryption or masking, not for deterministic encryption with key rotation; it typically uses a single key and does not natively support rotating the key without re-processing all data. Option C is wrong because datakey encryption generates a unique random data key per encryption operation, producing non-deterministic ciphertexts that cannot be used for deterministic indexing.
Option E is wrong because standard encryption (e.g., AES-GCM) with a static key is non-deterministic due to random IVs, and re-encrypting all data on rotation is operationally expensive and defeats the purpose of efficient key rotation.
A DevOps team is deploying Vault in a Kubernetes cluster. They want to ensure that when a pod starts, it can obtain a short-lived Vault token without human intervention. Which Vault architecture component should they use?
Automatically authenticates and injects tokens into pods.
Why this answer
Option C is correct because the Vault Agent sidecar runs alongside the application container in the same pod, automatically authenticating to Vault and retrieving a short-lived token. This eliminates the need for human intervention by handling the authentication lifecycle (e.g., using Kubernetes auth method) and renewing or re-authenticating as needed, ensuring the application always has a valid token.
Exam trap
HashiCorp often tests the misconception that a storage backend or audit device can provide authentication tokens, when in fact they serve entirely different roles in Vault's architecture.
How to eliminate wrong answers
Option A is wrong because an Audit Device logs all requests and responses to Vault for security monitoring, but it does not provide tokens or handle authentication for pods. Option B is wrong because the Storage Backend (e.g., Consul) is used for persisting Vault's encrypted data and cluster state, not for issuing tokens to applications. Option D is wrong because the Vault CLI with a token helper is an interactive tool requiring a human to authenticate and manage tokens, which does not meet the requirement for automated, non-interactive token retrieval at pod startup.
A Vault administrator wants to allow users to authenticate using their corporate Active Directory credentials. Which authentication method should they enable?
LDAP can connect to Active Directory.
Why this answer
LDAP (Lightweight Directory Access Protocol) is the correct choice because it enables Vault to authenticate users against an external corporate Active Directory (AD) server. Vault's LDAP auth method binds to the AD directory using a service account, then validates user credentials via a simple bind operation, allowing seamless integration with existing corporate identity infrastructure.
Exam trap
HashiCorp often tests the misconception that any external identity provider (like Okta) is the default choice for AD integration, but the question specifically asks for the authentication method that directly uses corporate Active Directory credentials, which is LDAP.
How to eliminate wrong answers
Option A is wrong because Okta is a third-party identity provider (IdP) that uses OIDC/SAML, not a direct authentication method for Active Directory; it would require additional configuration and is not the native AD integration method. Option B is wrong because AppRole is a machine-to-machine authentication method that uses role IDs and secret IDs, designed for applications and automation, not for human users with corporate credentials. Option C is wrong because Userpass is a built-in Vault auth method that stores usernames and passwords locally within Vault's internal storage, not against an external corporate Active Directory.
A team wants to retrieve a dynamic database credential from Vault. Which CLI command should be used?
A is correct: write to the creds path generates new dynamic credentials.
Why this answer
Option C is correct because Vault uses the `vault write` command to generate dynamic credentials from a database secrets engine. The `database/creds/readonly` path triggers the generation of a new credential (username/password) for the configured role, and the response includes the lease ID, username, and password. Unlike static secrets, dynamic credentials are created on demand and require a write operation to the role path.
Exam trap
HashiCorp often tests the misconception that `vault read` is used for all secret retrieval, but dynamic secrets require a `vault write` because the operation creates a new credential rather than reading an existing one.
How to eliminate wrong answers
Option A is wrong because `vault list` is used to enumerate paths or keys under a given path, not to generate credentials; it would return a list of role names, not a credential. Option B is wrong because `vault generate` is not a valid Vault CLI command; the correct verb for generating dynamic secrets is `vault write`. Option D is wrong because `vault read` retrieves static secrets or configuration data, but for dynamic database credentials, a write operation is required to trigger credential creation and return the lease.
A security team is configuring Vault's seal mechanism. They want to ensure that in the event of a data center outage, the Vault cluster can be unsealed without human intervention, but still require approval from multiple administrators to rekey the master key. Which seal type should they use?
Auto-unseal with KMS allows automatic unseal and MFA for rekey.
Why this answer
Option B is correct because auto-unseal using a cloud KMS allows Vault to unseal automatically after a restart, and the KMS key can be configured to require MFA for cryptographic operations, effectively requiring multiple approvals for rekeying. Option A is wrong because Shamir seals require manual unseal. Option C is wrong because Transit seal requires a running Vault to unseal Vault.
Option D is wrong because HSM with quorum still requires manual intervention to unseal.
An organization uses Vault with a database secrets engine. They have a role that issues credentials with a lease TTL of 30 minutes. After some time, they notice that the database is full of stale users. What is the most likely cause?
Without tidy, expired leases may not have their underlying secrets revoked.
Why this answer
Vault does not automatically revoke the actual database user when a lease expires; it relies on the tidy operation to clean up stale leases and revoke the underlying credentials. If tidy is not run or configured, expired leases can leave behind database users. Option B is correct.
Option A: high max_ttl would lengthen lifespan but still eventually expire. Option C: rotation statement affects password changes, not revocation. Option D: network issues could cause revocation failures, but tidy would still help clean up.
Practice VA-003 by domain
Target a specific domain to shore up weak areas.