HashiCorp HCVA0-003 Practice Exams
Last updated on Oct 22,2026- Exam Code: HCVA0-003
- Exam Name: HashiCorp Certified: Vault Associate (003)Exam
- Certification Provider: HashiCorp
- Latest update: Oct 22,2026
Question #51
What command is used to extend the TTL of a token, if permitted?
- A . vault token revoke <token-id>
- B . vault capabilities <token-id>
- C . vault token lookup <token-id>
- D . vault token renew <token-id>
Correct Answer: D
D
Explanation:
Comprehensive and Detailed in Depth
To extend a token’s TTL, the vault token renew command is used. The HashiCorp Vault documentation states: "In order to renew a token, a user can issue a vault token renew command to extend the TTL. The token can also be renewed using the API." It adds: "The vault token renew command extends the Time To Live (TTL) of a token if the policy associated with the token permits renewal."
The docs detail: "Tokens have a TTL that determines their validity period. If renewable, the renew
command can be used before expiration to extend this duration, subject to any max TTL limits." A
(revoke) invalidates tokens. B (capabilities) shows permissions, not TTL. C (lookup) displays token
info, not extends it. Thus, D is correct.
Reference: HashiCorp Vault Documentation – Token Renew Command
D
Explanation:
Comprehensive and Detailed in Depth
To extend a token’s TTL, the vault token renew command is used. The HashiCorp Vault documentation states: "In order to renew a token, a user can issue a vault token renew command to extend the TTL. The token can also be renewed using the API." It adds: "The vault token renew command extends the Time To Live (TTL) of a token if the policy associated with the token permits renewal."
The docs detail: "Tokens have a TTL that determines their validity period. If renewable, the renew
command can be used before expiration to extend this duration, subject to any max TTL limits." A
(revoke) invalidates tokens. B (capabilities) shows permissions, not TTL. C (lookup) displays token
info, not extends it. Thus, D is correct.
Reference: HashiCorp Vault Documentation – Token Renew Command
Question #52
Your organization uses a CI/CD pipeline to deploy its applications on Azure. During testing, you
generate new credentials to validate Vault can create new credentials.
The result of this command is below:
text
CollapseWrapCopy
$ vault read azure/creds/bryan-krausen
Key Value
— —–
lease_id azure/creds/bryan-krausen/9eed0373-ca92-99b6-b914-779b7bb0e1d9
lease_duration 60m
lease_renewable true
client_id 532bf678-ee4e-6be1-116b-4e4221e445dd client_secret be60395b-4e6b-2b7e-a4b3-c449a5c00973
What commands can be used to revoke this secret after you have finished testing? (Select three)
- A . vault lease revoke azure/
- B . vault lease revoke -prefix azure/
- C . vault lease revoke azure/creds/bryan-krausen/9eed0373-ca92-99b6-b914-779b7bb0e1d9
- D . vault lease revoke azure/creds/bryan-krausen
- E . vault lease revoke -prefix azure/creds/bryan-krausen
Correct Answer: B, C, E
B, C, E
Explanation:
Comprehensive and Detailed In-Depth
Dynamic credentials are tracked by leases, revocable via vault lease revoke.
The Vault documentation states:
"The vault lease revoke command is used to revoke a lease/secret created by a Vault secrets engine. Each lease that is created is tracked using a unique lease ID, which can be used to renew or revoke a lease.
You can revoke an individual lease using the command vault lease revoke <lease_id>
You can also revoke ALL leases from a secrets engine using the -prefix flag, such as vault lease revoke -prefix azure/
You can also revoke leases created from a specific role by using the -prefix flag but specifying the path all the way to the role like this: vault lease revoke -prefix azure/creds/<role_name>"
― Vault Commands: lease revoke
B: Correct. vault lease revoke -prefix azure/ revokes all leases under azure/.
C: Correct. vault lease revoke azure/creds/bryan-krausen/9eed0373-ca92-99b6-b914-779b7bb0e1d9 targets the specific lease ID.
E: Correct. vault lease revoke -prefix azure/creds/bryan-krausen revokes all leases for that role.
A: Incorrect; lacks the -prefix flag, making it invalid syntax.
D: Incorrect; lacks the -prefix flag and isn’t a full lease ID.
Reference: Vault Commands: lease revoke
B, C, E
Explanation:
Comprehensive and Detailed In-Depth
Dynamic credentials are tracked by leases, revocable via vault lease revoke.
The Vault documentation states:
"The vault lease revoke command is used to revoke a lease/secret created by a Vault secrets engine. Each lease that is created is tracked using a unique lease ID, which can be used to renew or revoke a lease.
You can revoke an individual lease using the command vault lease revoke <lease_id>
You can also revoke ALL leases from a secrets engine using the -prefix flag, such as vault lease revoke -prefix azure/
You can also revoke leases created from a specific role by using the -prefix flag but specifying the path all the way to the role like this: vault lease revoke -prefix azure/creds/<role_name>"
― Vault Commands: lease revoke
B: Correct. vault lease revoke -prefix azure/ revokes all leases under azure/.
C: Correct. vault lease revoke azure/creds/bryan-krausen/9eed0373-ca92-99b6-b914-779b7bb0e1d9 targets the specific lease ID.
E: Correct. vault lease revoke -prefix azure/creds/bryan-krausen revokes all leases for that role.
A: Incorrect; lacks the -prefix flag, making it invalid syntax.
D: Incorrect; lacks the -prefix flag and isn’t a full lease ID.
Reference: Vault Commands: lease revoke
Question #53
An organization would like to use a scheduler to track & revoke access granted to a job (by Vault) at completion.
What auth-associated Vault object should be tracked to enable this behavior?
- A . Token accessor
- B . Token ID
- C . Lease ID
- D . Authentication method
Correct Answer: C
C
Explanation:
A lease ID is a unique identifier that is assigned by Vault to every dynamic secret and service type authentication token. A lease ID contains information such as the secret path, the secret version, the secret type, etc. A lease ID can be used to track and revoke access granted to a job by Vault at completion, as it allows the scheduler to perform the following operations:
Lookup the lease information by using the vault lease lookup command or the sys/leases/lookup API endpoint. This will return the metadata of the lease, such as the expire time, the issue time, the renewable status, and the TTL.
Renew the lease if needed by using the vault lease renew command or the sys/leases/renew API endpoint. This will extend the validity of the secret or the token for a specified increment, or reset the TTL to the original value if no increment is given.
Revoke the lease when the job is completed by using the vault lease revoke command or the sys/leases/revoke API endpoint. This will invalidate the secret or the token immediately and prevent any further renewals. For example, with the AWS secrets engine, the access keys will be deleted from AWS the moment a lease is revoked.
A lease ID is different from a token ID or a token accessor. A token ID is the actual value of the token that is used to authenticate to Vault and perform requests. A token ID should be treated as a secret and protected from unauthorized access. A token accessor is a secondary identifier of the token that is used for token management without revealing the token ID. A token accessor can be used to lookup, renew, or revoke a token, but not to authenticate to Vault or access secrets. A token ID or a token accessor can be used to revoke the token itself, but not the leases associated with the token. To revoke the leases, a lease ID is required.
An authentication method is a way to verify the identity of a user or a machine and issue a token with appropriate policies and metadata. An authentication method is not an object that can be tracked or revoked, but a configuration that can be enabled, disabled, tuned, or customized by using the vault auth commands or the sys/auth API endpoints.
Reference: (https://developer.hashicorp.com/vault/docs/commands/lease/lookup), (https://developer.hashicorp.com/vault/docs/commands/lease/renew), (https://developer.hashicorp.com/vault/docs/commands/lease/revoke), (https://developer.hashicorp.com/vault/docs/concepts/tokens#token-accessors), (https://developer.hashicorp.com/vault/docs/concepts/auth)
C
Explanation:
A lease ID is a unique identifier that is assigned by Vault to every dynamic secret and service type authentication token. A lease ID contains information such as the secret path, the secret version, the secret type, etc. A lease ID can be used to track and revoke access granted to a job by Vault at completion, as it allows the scheduler to perform the following operations:
Lookup the lease information by using the vault lease lookup command or the sys/leases/lookup API endpoint. This will return the metadata of the lease, such as the expire time, the issue time, the renewable status, and the TTL.
Renew the lease if needed by using the vault lease renew command or the sys/leases/renew API endpoint. This will extend the validity of the secret or the token for a specified increment, or reset the TTL to the original value if no increment is given.
Revoke the lease when the job is completed by using the vault lease revoke command or the sys/leases/revoke API endpoint. This will invalidate the secret or the token immediately and prevent any further renewals. For example, with the AWS secrets engine, the access keys will be deleted from AWS the moment a lease is revoked.
A lease ID is different from a token ID or a token accessor. A token ID is the actual value of the token that is used to authenticate to Vault and perform requests. A token ID should be treated as a secret and protected from unauthorized access. A token accessor is a secondary identifier of the token that is used for token management without revealing the token ID. A token accessor can be used to lookup, renew, or revoke a token, but not to authenticate to Vault or access secrets. A token ID or a token accessor can be used to revoke the token itself, but not the leases associated with the token. To revoke the leases, a lease ID is required.
An authentication method is a way to verify the identity of a user or a machine and issue a token with appropriate policies and metadata. An authentication method is not an object that can be tracked or revoked, but a configuration that can be enabled, disabled, tuned, or customized by using the vault auth commands or the sys/auth API endpoints.
Reference: (https://developer.hashicorp.com/vault/docs/commands/lease/lookup), (https://developer.hashicorp.com/vault/docs/commands/lease/renew), (https://developer.hashicorp.com/vault/docs/commands/lease/revoke), (https://developer.hashicorp.com/vault/docs/concepts/tokens#token-accessors), (https://developer.hashicorp.com/vault/docs/concepts/auth)
Question #54
Why are short-lived, dynamic secrets in Vault more secure than long-lived, static credentials?
- A . They provide better performance by caching credentials for longer durations
- B . They are created on-demand and expire after a short period, minimizing the risk of credential leakage
- C . They eliminate the need for authentication, allowing seamless access to Vault-managed systems
- D . They automatically rotate on a set schedule, reducing the need for manual intervention
Correct Answer: B
B
Explanation:
Comprehensive and Detailed In-Depth
Short-lived, dynamic secrets in Vault enhance security by being generated on-demand and expiring after a short, configurable time-to-live (TTL). This reduces the window of opportunity for credential leakage or misuse. Unlike long-lived, static credentials, which persist indefinitely and increase exposure risk if compromised, dynamic secrets are ephemeral―once they expire, they’re automatically revoked by Vault, rendering them useless to attackers. For example, a database credential might last 5 minutes, limiting its attack surface compared to a static password stored indefinitely.
Option A (performance via caching) is unrelated to security and inaccurate, as dynamic secrets aren’t cached longer.
Option C (eliminating authentication) is false; authentication is still required to obtain dynamic secrets.
Option D (automatic rotation) applies to some dynamic secrets (e.g., database roles), but the core security benefit is their short lifespan, not just rotation. Vault’s documentation on dynamic secrets emphasizes their ephemerality as the key security advantage.
Reference: Dynamic Secrets Tutorial
Dynamic Secrets Concepts
B
Explanation:
Comprehensive and Detailed In-Depth
Short-lived, dynamic secrets in Vault enhance security by being generated on-demand and expiring after a short, configurable time-to-live (TTL). This reduces the window of opportunity for credential leakage or misuse. Unlike long-lived, static credentials, which persist indefinitely and increase exposure risk if compromised, dynamic secrets are ephemeral―once they expire, they’re automatically revoked by Vault, rendering them useless to attackers. For example, a database credential might last 5 minutes, limiting its attack surface compared to a static password stored indefinitely.
Option A (performance via caching) is unrelated to security and inaccurate, as dynamic secrets aren’t cached longer.
Option C (eliminating authentication) is false; authentication is still required to obtain dynamic secrets.
Option D (automatic rotation) applies to some dynamic secrets (e.g., database roles), but the core security benefit is their short lifespan, not just rotation. Vault’s documentation on dynamic secrets emphasizes their ephemerality as the key security advantage.
Reference: Dynamic Secrets Tutorial
Dynamic Secrets Concepts
Question #55
True or False? After initializing Vault or restarting the Vault service, each individual node in the cluster needs to be unsealed.
- A . True
- B . False
Correct Answer: A
A
Explanation:
Comprehensive and Detailed in Depth
The statement is True. In a Vault cluster, each node must be individually unsealed after initialization or a restart unless auto-unseal is configured. The HashiCorp Vault documentation states: "Since the encryption key is stored in memory, Vault nodes do not share or replicate the encryption key to other nodes. Therefore, each node needs to individually unseal itself upon Vault initialization or anytime the Vault service is restarted on that node." This is due to Vault’s design, where the master key (root key) is held in memory and lost on restart, requiring the unseal process to reconstruct it.
The documentation elaborates: "When a Vault server is started, it starts in a sealed state. In this state, Vault is configured to know where and how to access the physical storage, but doesn’t know how to decrypt any of it. Unsealing is the process of obtaining the plaintext root key necessary to read the decryption key to decrypt the data." Without auto-unseal, this process is manual for each node, making A (True) correct in the default scenario.
Reference: HashiCorp Vault Documentation – Seal and Unseal: Unsealing
HashiCorp Vault Documentation – Vault Concepts: Seal
A
Explanation:
Comprehensive and Detailed in Depth
The statement is True. In a Vault cluster, each node must be individually unsealed after initialization or a restart unless auto-unseal is configured. The HashiCorp Vault documentation states: "Since the encryption key is stored in memory, Vault nodes do not share or replicate the encryption key to other nodes. Therefore, each node needs to individually unseal itself upon Vault initialization or anytime the Vault service is restarted on that node." This is due to Vault’s design, where the master key (root key) is held in memory and lost on restart, requiring the unseal process to reconstruct it.
The documentation elaborates: "When a Vault server is started, it starts in a sealed state. In this state, Vault is configured to know where and how to access the physical storage, but doesn’t know how to decrypt any of it. Unsealing is the process of obtaining the plaintext root key necessary to read the decryption key to decrypt the data." Without auto-unseal, this process is manual for each node, making A (True) correct in the default scenario.
Reference: HashiCorp Vault Documentation – Seal and Unseal: Unsealing
HashiCorp Vault Documentation – Vault Concepts: Seal
Question #56
You have enabled the Transit secrets engine on your Vault cluster to provide an "encryption as a service" service as your team develops new applications.
What is a prime use case for the Transit secrets engine?
- A . Encrypting data before being written to an Amazon S3 bucket
- B . Storing the encrypted data in Vault for easy retrieval
- C . Generating dynamic SSH credentials for access to local systems
- D . Creating X.509 certificates for a new fleet of containers
Correct Answer: A
A
Explanation:
Comprehensive and Detailed In-Depth
The Transit secrets engine provides encryption as a service. The Vault documentation states: "The Transit secrets engine is used to encrypt data in transit. It does NOT store the data locally. It simply encrypts the data and returns the ciphertext to the requester. A prime use case is encrypting data before being written to an external storage service like Amazon S3."
― Vault Secrets: Transit
A: Correct. Encrypting data for S3 is a key use case:
"Encrypting data before being written to an Amazon S3 bucket ensures that sensitive data is protected both in transit and at rest."
― Transit Tutorial
B: Incorrect; Transit doesn’t store data long-term.
C: SSH credentials are handled by the SSH engine.
D: X.509 certificates are managed by the PKI engine.
Reference: Vault Secrets: Transit Transit Tutorial
A
Explanation:
Comprehensive and Detailed In-Depth
The Transit secrets engine provides encryption as a service. The Vault documentation states: "The Transit secrets engine is used to encrypt data in transit. It does NOT store the data locally. It simply encrypts the data and returns the ciphertext to the requester. A prime use case is encrypting data before being written to an external storage service like Amazon S3."
― Vault Secrets: Transit
A: Correct. Encrypting data for S3 is a key use case:
"Encrypting data before being written to an Amazon S3 bucket ensures that sensitive data is protected both in transit and at rest."
― Transit Tutorial
B: Incorrect; Transit doesn’t store data long-term.
C: SSH credentials are handled by the SSH engine.
D: X.509 certificates are managed by the PKI engine.
Reference: Vault Secrets: Transit Transit Tutorial
Question #57
An application requires a specific key/value pair to be updated in order to process a batch job. The value should be either "true" or "false." However, when developers have been updating the value, sometimes they mistype the value or capitalize the value, causing the batch job not to run.
What feature of a Vault policy can be used to restrict entry to the required values?
- A . Add a deny statement for all possible misspellings of the value
- B . Add an allowed_parameters value to the policy
- C . Change the policy to include the list capability
- D . Use a * wildcard at the end of the policy
Correct Answer: B
B
Explanation:
Comprehensive and Detailed in Depth
To restrict the values of a key/value pair to only "true" or "false" and prevent mistyping or capitalization errors, the allowed_parameters feature in a Vault policy is the most effective solution.
The HashiCorp Vault documentation explains that allowed_parameters can be used to "permit a list of keys and values that are permitted on the given path." By specifying allowed_parameters with the exact values "true" and "false," the policy ensures that only these values are accepted, rejecting any deviations (e.g., "True," "TRUE," or "flase"). This provides fine-grained control and eliminates the risk of human error impacting the batch job.
Adding a deny statement for all possible misspellings is impractical and error-prone, as it requires
anticipating every potential mistake, which is neither scalable nor efficient. The list capability allows
listing and reading values but does not restrict what can be written, failing to address the problem of
enforcing specific values. Using a wildcard (*) at the end of the policy permits unrestricted values,
which directly contradicts the need to limit entries to "true" or "false." Thus, allowed_parameters is
the precise tool for this use case.
Reference: HashiCorp Vault Documentation – Policies: Fine-Grained Control
B
Explanation:
Comprehensive and Detailed in Depth
To restrict the values of a key/value pair to only "true" or "false" and prevent mistyping or capitalization errors, the allowed_parameters feature in a Vault policy is the most effective solution.
The HashiCorp Vault documentation explains that allowed_parameters can be used to "permit a list of keys and values that are permitted on the given path." By specifying allowed_parameters with the exact values "true" and "false," the policy ensures that only these values are accepted, rejecting any deviations (e.g., "True," "TRUE," or "flase"). This provides fine-grained control and eliminates the risk of human error impacting the batch job.
Adding a deny statement for all possible misspellings is impractical and error-prone, as it requires
anticipating every potential mistake, which is neither scalable nor efficient. The list capability allows
listing and reading values but does not restrict what can be written, failing to address the problem of
enforcing specific values. Using a wildcard (*) at the end of the policy permits unrestricted values,
which directly contradicts the need to limit entries to "true" or "false." Thus, allowed_parameters is
the precise tool for this use case.
Reference: HashiCorp Vault Documentation – Policies: Fine-Grained Control
Question #58
You are enabling a secrets engine in Vault using the CLI.
What subcommands are available when using the vault secrets command? (Select five)
- A . update
- B . migrate
- C . tune
- D . enable
- E . move
- F . disable
- G . list
Correct Answer: C, D, E, F, G
C, D, E, F, G
Explanation:
Comprehensive and Detailed In-Depth
The vault secrets command supports:
C. tune: "Tune a secrets engine configuration."
D. enable: "Enable a secrets engine."
E. move: "Move a secrets engine to a new path."
F. disable: "Disable a secrets engine."
G. list: "List enabled secrets engines."
Incorrect Options:
C, D, E, F, G
Explanation:
Comprehensive and Detailed In-Depth
The vault secrets command supports:
C. tune: "Tune a secrets engine configuration."
D. enable: "Enable a secrets engine."
E. move: "Move a secrets engine to a new path."
F. disable: "Disable a secrets engine."
G. list: "List enabled secrets engines."
Incorrect Options:
Question #59
You have a legacy application that requires secrets from Vault that must be written to a local configuration file. However, you cannot refactor the application to communicate directly with Vault.
What solution should you implement to satisfy the requirements?
- A . Run the Vault Agent and use the templating feature
- B . Use the Vault Proxy with Auto-Auth to authenticate with Vault
- C . Use the Vault Proxy to act as a proxy for the Vault API
- D . Use the Vault Agent and cache the newly created tokens and leases
Correct Answer: A
A
Explanation:
Comprehensive and Detailed in Depth
For a legacy application that cannot communicate directly with Vault but needs secrets in a local configuration file, the Vault Agent with templating feature is the best solution. The HashiCorp Vault documentation notes: "Vault Agent can obtain secrets and provide them to applications," and its templating feature "generates dynamic credentials based on predefined templates" and writes them to files. This allows secrets to be automatically fetched and rendered into a configuration file, meeting the requirement without refactoring.
Vault Proxy with Auto-Auth simplifies authentication but doesn’t inherently write secrets to files. Vault Proxy as an API proxy secures API access but doesn’t address file writing. Vault Agent with caching improves performance but doesn’t solve the file output need. Thus, A is correct.
Reference: HashiCorp Vault Documentation – Vault Agent and Proxy
A
Explanation:
Comprehensive and Detailed in Depth
For a legacy application that cannot communicate directly with Vault but needs secrets in a local configuration file, the Vault Agent with templating feature is the best solution. The HashiCorp Vault documentation notes: "Vault Agent can obtain secrets and provide them to applications," and its templating feature "generates dynamic credentials based on predefined templates" and writes them to files. This allows secrets to be automatically fetched and rendered into a configuration file, meeting the requirement without refactoring.
Vault Proxy with Auto-Auth simplifies authentication but doesn’t inherently write secrets to files. Vault Proxy as an API proxy secures API access but doesn’t address file writing. Vault Agent with caching improves performance but doesn’t solve the file output need. Thus, A is correct.
Reference: HashiCorp Vault Documentation – Vault Agent and Proxy
Question #60
Which of the following statements best describes the difference between static and dynamic credentials in a secrets management system?
- A . They are functionally identical―the only difference is what secrets engine creates them.
- B . Static credentials only apply to specific use cases, while dynamic credentials can be used everywhere.
- C . Static credentials often remain persistent for long periods of time, while dynamic are short-lived and auto-rotated.
- D . Static credentials are ephemeral and rotated frequently, while dynamic credentials remain unchanged indefinitely.
Correct Answer: C
C
Explanation:
Comprehensive and Detailed in Depth
The key difference between static and dynamic credentials lies in their lifecycle and management. The HashiCorp Vault documentation explains: "Static credentials are typically assigned and remain valid for long stretches, requiring manual rotation. By contrast, dynamic credentials are issued on-demand, designed to be short-lived, and automatically rotated or revoked when they expire." This reduces exposure risk and simplifies management, making C the correct statement: "Static credentials often remain persistent for long periods of time, while dynamic are short-lived and auto-rotated."
Option A is incorrect as static and dynamic credentials differ in function, not just origin.
Option B misstates their applicability―static credentials aren’t limited to specific use cases, and dynamic
credentials have specific purposes.
Option D reverses the definitions entirely. Thus, C aligns with
Vault’s design.
Reference: HashiCorp Vault Documentation – Static and Dynamic Secrets
C
Explanation:
Comprehensive and Detailed in Depth
The key difference between static and dynamic credentials lies in their lifecycle and management. The HashiCorp Vault documentation explains: "Static credentials are typically assigned and remain valid for long stretches, requiring manual rotation. By contrast, dynamic credentials are issued on-demand, designed to be short-lived, and automatically rotated or revoked when they expire." This reduces exposure risk and simplifies management, making C the correct statement: "Static credentials often remain persistent for long periods of time, while dynamic are short-lived and auto-rotated."
Option A is incorrect as static and dynamic credentials differ in function, not just origin.
Option B misstates their applicability―static credentials aren’t limited to specific use cases, and dynamic
credentials have specific purposes.
Option D reverses the definitions entirely. Thus, C aligns with
Vault’s design.
Reference: HashiCorp Vault Documentation – Static and Dynamic Secrets