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 #111
Before the following command can be run to encrypt data, what (three) commands must be run to enable and configure the transit secrets engine in Vault? (Select three) text
CollapseWrapCopy
$ vault write transit/encrypt/vendor
plaintext="aGFzaGljb3JwIGNlcnRpZmllZA=="
- A . base64 <<< "hashicorp certified"
- B . vault write transit/encrypt/vendor
- C . vault secrets list
- D . vault secrets enable transit
- E . vault write -f transit/keys/vendor
Correct Answer: A, D, E
A, D, E
Explanation:
Comprehensive and Detailed in Depth
To encrypt data using the Transit secrets engine, it must be enabled and configured. The HashiCorp Vault documentation states: "Enable the Transit secrets engine at the default path of ‘transit’ using the command vault secrets enable transit. Create an encryption key called ‘vendor’ using the command vault write -f transit/keys/vendor. Encode the string using base-64 encoding by using the command base64 <<< ‘hashicorp certified’." These steps are prerequisites for the given vault write transit/encrypt/vendor command:
A (base64 <<< "hashicorp certified"): The docs note, "All plaintext data must be base64-encoded. The reason for this requirement is that Vault does not require that the plaintext is ‘text’. It could be a binary file such as a PDF or image. The easiest safe transport mechanism for this data as part of a JSON payload is to base64-encode it." The provided plaintext aGFzaGljb3JwIGNlcnRpZmllZA== is the base64 encoding of "hashicorp certified."
D (vault secrets enable transit): "Before you can use the transit secrets engine, it must be enabled with vault secrets enable transit at the default path ‘transit/’."
E (vault write -f transit/keys/vendor): "An encryption key must be created before encryption can occur. Use vault write -f transit/keys/vendor to generate a key named ‘vendor’."
B is the target command, not a prerequisite. C (vault secrets list) lists engines but doesn’t configure
Transit. Thus, A, D, and E are correct.
Reference: HashiCorp Vault Documentation – Transit Secrets Engine
A, D, E
Explanation:
Comprehensive and Detailed in Depth
To encrypt data using the Transit secrets engine, it must be enabled and configured. The HashiCorp Vault documentation states: "Enable the Transit secrets engine at the default path of ‘transit’ using the command vault secrets enable transit. Create an encryption key called ‘vendor’ using the command vault write -f transit/keys/vendor. Encode the string using base-64 encoding by using the command base64 <<< ‘hashicorp certified’." These steps are prerequisites for the given vault write transit/encrypt/vendor command:
A (base64 <<< "hashicorp certified"): The docs note, "All plaintext data must be base64-encoded. The reason for this requirement is that Vault does not require that the plaintext is ‘text’. It could be a binary file such as a PDF or image. The easiest safe transport mechanism for this data as part of a JSON payload is to base64-encode it." The provided plaintext aGFzaGljb3JwIGNlcnRpZmllZA== is the base64 encoding of "hashicorp certified."
D (vault secrets enable transit): "Before you can use the transit secrets engine, it must be enabled with vault secrets enable transit at the default path ‘transit/’."
E (vault write -f transit/keys/vendor): "An encryption key must be created before encryption can occur. Use vault write -f transit/keys/vendor to generate a key named ‘vendor’."
B is the target command, not a prerequisite. C (vault secrets list) lists engines but doesn’t configure
Transit. Thus, A, D, and E are correct.
Reference: HashiCorp Vault Documentation – Transit Secrets Engine
Question #112
From the options below, select the benefits of using a batch token over a service token (select four).
- A . Often used for ephemeral, high-performance workloads
- B . Can be a root token
- C . Can be used on performance replication clusters (if orphan)
- D . Has accessors
- E . Lightweight and scalable
- F . No storage cost for token creation
Correct Answer: A, C, E, F
A, C, E, F
Explanation:
Comprehensive and Detailed in Depth
Batch tokens are lightweight alternatives to service tokens, with trade-offs. Let’s analyze:
A: Designed for short-lived, high-performance tasks. Correct.
B: Cannot be root tokens; root status is service-token-specific. Incorrect.
C: Orphan batch tokens work in replication. Correct.
D: No accessors; unique to service tokens. Incorrect.
E: Minimal overhead makes them scalable. Correct.
F: No disk storage reduces cost. Correct.
Overall Explanation from Vault Docs:
“Batch tokens are encrypted blobs… lightweight, scalable, no storage cost, ideal for ephemeral workloads.”
Reference: https://developer.hashicorp.com/vault/tutorials/tokens/batch-tokens
A, C, E, F
Explanation:
Comprehensive and Detailed in Depth
Batch tokens are lightweight alternatives to service tokens, with trade-offs. Let’s analyze:
A: Designed for short-lived, high-performance tasks. Correct.
B: Cannot be root tokens; root status is service-token-specific. Incorrect.
C: Orphan batch tokens work in replication. Correct.
D: No accessors; unique to service tokens. Incorrect.
E: Minimal overhead makes them scalable. Correct.
F: No disk storage reduces cost. Correct.
Overall Explanation from Vault Docs:
“Batch tokens are encrypted blobs… lightweight, scalable, no storage cost, ideal for ephemeral workloads.”
Reference: https://developer.hashicorp.com/vault/tutorials/tokens/batch-tokens
Question #113
After creating a dynamic credential on a database, the DBA accidentally deletes the credentials on the database itself. When attempting to remove the lease, Vault returns an error stating that the credential cannot be found.
What command can be run to make Vault remove the secret?
- A . vault lease revoke -force -prefix <lease_path>
- B . vault lease -renew
- C . vault lease revoke -enforce
- D . vault revoke -apply
Correct Answer: A
A
Explanation:
Comprehensive and Detailed in Depth
When a dynamic credential is deleted externally, Vault may fail to revoke the lease due to the missing backend secret. The HashiCorp Vault documentation states: "The -force flag is meant for recovery situations where the secret in the target platform was manually removed." The command vault lease revoke -force -prefix <lease_path> allows Vault to forcibly revoke all leases under the specified prefix, bypassing the error.
The docs elaborate: "Using -force with -prefix will revoke all leases that match the given prefix, even if the underlying secrets cannot be found or revoked on the target system. This is useful for cleaning up Vault’s lease table when external changes disrupt normal revocation." Here, <lease_path> would be the path like database/creds/role/. B (vault lease -renew) renews leases, not removes them. C (-enforce) is not a valid flag. D (vault revoke -apply) is incorrect syntax. Thus, A is correct.
Reference: HashiCorp Vault Documentation – Lease Revoke Command: Force
A
Explanation:
Comprehensive and Detailed in Depth
When a dynamic credential is deleted externally, Vault may fail to revoke the lease due to the missing backend secret. The HashiCorp Vault documentation states: "The -force flag is meant for recovery situations where the secret in the target platform was manually removed." The command vault lease revoke -force -prefix <lease_path> allows Vault to forcibly revoke all leases under the specified prefix, bypassing the error.
The docs elaborate: "Using -force with -prefix will revoke all leases that match the given prefix, even if the underlying secrets cannot be found or revoked on the target system. This is useful for cleaning up Vault’s lease table when external changes disrupt normal revocation." Here, <lease_path> would be the path like database/creds/role/. B (vault lease -renew) renews leases, not removes them. C (-enforce) is not a valid flag. D (vault revoke -apply) is incorrect syntax. Thus, A is correct.
Reference: HashiCorp Vault Documentation – Lease Revoke Command: Force
Question #114
You need to decrypt customer data to provide it to an application.
When you run the decryption command, you get the output below.
Why does the response not directly reveal the cleartext data? $ vault write transit/decrypt/phone_number ciphertext="vault:v1:tgx2vsxtlQRfyLSKvem…" Key Value
— —–
plaintext aGFzaGljb3JwIGNlcnRpZmllZDogdmF1bHQgYXNzb2NpYXRl
- A . The user does not have permission to view the cleartext data
- B . The output is base64 encoded
- C . The output is actually a response wrapped token that needs to be unwrapped
- D . The original data must have been encrypted
Correct Answer: B
B
Explanation:
Comprehensive and Detailed In-Depth
The Vault Transit secrets engine returns decrypted data in base64-encoded format:
B. The output is base64 encoded: "All plaintext data must be base64-encoded before being
encrypted by Vault. As a result, decrypted data is always base64 encoded." Users must decode it
(e.g., using base64 -d) to see cleartext.
Incorrect Options:
B
Explanation:
Comprehensive and Detailed In-Depth
The Vault Transit secrets engine returns decrypted data in base64-encoded format:
B. The output is base64 encoded: "All plaintext data must be base64-encoded before being
encrypted by Vault. As a result, decrypted data is always base64 encoded." Users must decode it
(e.g., using base64 -d) to see cleartext.
Incorrect Options:
Question #115
The Vault Agent provides which of the following benefits? (Select three)
- A . Token renewal
- B . Authentication to Vault
- C . Client-side caching of responses
- D . Automatically creates secrets in the desired storage backend
Correct Answer: A, B, C
A, B, C
Explanation:
Comprehensive and Detailed in Depth
The Vault Agent is a client daemon designed to simplify integration with Vault by providing several key benefits. According to the HashiCorp Vault documentation, these include:
Token Renewal: "Vault Agent automatically renews tokens issued by Vault," ensuring continuous access without manual intervention.
Authentication to Vault: "Vault Agent provides authentication to Vault," allowing applications to authenticate using their identity without managing tokens directly.
Client-side caching of responses: "Vault Agent offers client-side caching of responses," improving performance by reducing server requests.
However, automatically creating secrets in the desired storage backend is not a function of Vault Agent. Secret creation is handled by Vault’s secrets engines, not the agent, which focuses on authentication, token management, and caching. Thus, A, B, and C are the correct benefits.
Reference: HashiCorp Vault Documentation – Vault Agent
A, B, C
Explanation:
Comprehensive and Detailed in Depth
The Vault Agent is a client daemon designed to simplify integration with Vault by providing several key benefits. According to the HashiCorp Vault documentation, these include:
Token Renewal: "Vault Agent automatically renews tokens issued by Vault," ensuring continuous access without manual intervention.
Authentication to Vault: "Vault Agent provides authentication to Vault," allowing applications to authenticate using their identity without managing tokens directly.
Client-side caching of responses: "Vault Agent offers client-side caching of responses," improving performance by reducing server requests.
However, automatically creating secrets in the desired storage backend is not a function of Vault Agent. Secret creation is handled by Vault’s secrets engines, not the agent, which focuses on authentication, token management, and caching. Thus, A, B, and C are the correct benefits.
Reference: HashiCorp Vault Documentation – Vault Agent
Question #116
You have multiple Vault clusters in your environment, one for test and one for production. You have the CLI installed on your local machine and need to target the production cluster to make configuration changes.
What environment variable can you set to target the production cluster?
- A . VAULT_REDIRECT_ADDR
- B . VAULT_CLUSTER_ADDR
- C . VAULT_ADDR
- D . VAULT_CAPATH
Correct Answer: C
C
Explanation:
Comprehensive and Detailed In-Depth
The VAULT_ADDR variable specifies the target Vault server.
The Vault documentation states: "VAULT_ADDR is the environment variable that is used to specify the address of the Vault server expressed as a URL and port, for example: https://vault.bryankrausen.com:8200/. You can easily modify the value of the environment variable whenever you want to target a different Vault node/cluster."
― Vault Environment Variables
C: Correct. Sets the production cluster address:
"Setting the VAULT_ADDR environment variable allows you to specify the address of the Vault server you want to target."
― Vault Environment Variables
A, B, D: Incorrect; unrelated to CLI targeting.
Reference: Vault Environment Variables
C
Explanation:
Comprehensive and Detailed In-Depth
The VAULT_ADDR variable specifies the target Vault server.
The Vault documentation states: "VAULT_ADDR is the environment variable that is used to specify the address of the Vault server expressed as a URL and port, for example: https://vault.bryankrausen.com:8200/. You can easily modify the value of the environment variable whenever you want to target a different Vault node/cluster."
― Vault Environment Variables
C: Correct. Sets the production cluster address:
"Setting the VAULT_ADDR environment variable allows you to specify the address of the Vault server you want to target."
― Vault Environment Variables
A, B, D: Incorrect; unrelated to CLI targeting.
Reference: Vault Environment Variables
Question #117
Which of the following auth methods are intended for machine-to-machine authentication, and not necessarily human (operator) authentication? (Select four)
- A . Okta
- B . Tokens
- C . TLS Certificates
- D . Cloud-based Auth methods (AWS, Azure, GCP)
- E . LDAP
- F . AppRole
Correct Answer: B, C, D, F
B, C, D, F
Explanation:
Comprehensive and Detailed In-Depth
Machine-oriented methods:
B, C, D, F: "Machine-oriented: AppRole, TLS, tokens, platform-specific methods (cloud, k8s)."
Incorrect Options:
A, E: "Operator-oriented: LDAP, Okta."
Reference: https://developer.hashicorp.com/vault/tutorials/get-started/why-use-vault#human-and-machine-authentication
B, C, D, F
Explanation:
Comprehensive and Detailed In-Depth
Machine-oriented methods:
B, C, D, F: "Machine-oriented: AppRole, TLS, tokens, platform-specific methods (cloud, k8s)."
Incorrect Options:
A, E: "Operator-oriented: LDAP, Okta."
Reference: https://developer.hashicorp.com/vault/tutorials/get-started/why-use-vault#human-and-machine-authentication
Question #118
As a best practice, the root token should be stored in which of the following ways?
- A . Should be revoked and never stored after initial setup
- B . Should be stored in configuration automation tooling
- C . Should be stored in another password safe
- D . Should be stored in Vault
Correct Answer: A
A
Explanation:
The root token is the initial token created when initializing Vault. It has unlimited privileges and can perform any operation in Vault. As a best practice, the root token should be revoked and never stored after initial setup. This is because the root token is a single point of failure and a potential security risk if it is compromised or leaked. Instead of using the root token, Vault operators should create other tokens with appropriate policies and roles that allow them to perform their tasks. If a new root token is needed in an emergency, the vault operator generate-root command can be used to create one on-the-fly with the consent of a quorum of unseal key holders.
Reference: Tokens | Vault | HashiCorp Developer, Generate root tokens using unseal keys | Vault | HashiCorp Developer
A
Explanation:
The root token is the initial token created when initializing Vault. It has unlimited privileges and can perform any operation in Vault. As a best practice, the root token should be revoked and never stored after initial setup. This is because the root token is a single point of failure and a potential security risk if it is compromised or leaked. Instead of using the root token, Vault operators should create other tokens with appropriate policies and roles that allow them to perform their tasks. If a new root token is needed in an emergency, the vault operator generate-root command can be used to create one on-the-fly with the consent of a quorum of unseal key holders.
Reference: Tokens | Vault | HashiCorp Developer, Generate root tokens using unseal keys | Vault | HashiCorp Developer
Question #119
To give a role the ability to display or output all of the end points under the /secrets/apps/* end point it would need to have which capability set?
- A . update
- B . read
- C . sudo
- D . list
- E . None of the above
Correct Answer: C
C
Explanation:
To give a role the ability to display or output all of the end points under the /secrets/apps/* end point, it would need to have the list capability set. The list capability allows a role to perform any operation on any path in Vault, including reading, writing, deleting, and listing. The list capability is required for roles that need to access sensitive data or perform administrative tasks in Vault. The other capabilities are not relevant for this scenario, as they only allow specific operations on specific paths or secrets engines.
Reference: Policies | Vault | HashiCorp Developer, token capabilities – Command | Vault | HashiCorp Developer
C
Explanation:
To give a role the ability to display or output all of the end points under the /secrets/apps/* end point, it would need to have the list capability set. The list capability allows a role to perform any operation on any path in Vault, including reading, writing, deleting, and listing. The list capability is required for roles that need to access sensitive data or perform administrative tasks in Vault. The other capabilities are not relevant for this scenario, as they only allow specific operations on specific paths or secrets engines.
Reference: Policies | Vault | HashiCorp Developer, token capabilities – Command | Vault | HashiCorp Developer
Question #120
You are using Vault CLI and enable the database secrets engine on the default path of database/. However, the DevOps team wants to enable another database secrets engine for testing but receives an error stating the path is already in use.
How can you enable a second database secrets engine using the CLI?
- A . vault secrets enable database database2/
- B . vault secrets enable -force database
- C . vault secrets enable -path=database2 database
- D . vault secrets enable database2/
Correct Answer: C
C
Explanation:
Comprehensive and Detailed In-Depth
Vault mounts secrets engines at unique paths, and only one engine can occupy a given path (e.g., database/). To enable a second database secrets engine, you must specify a different path using the – path flag: vault secrets enable -path=database2 database mounts a new instance at database2/. The type (database) defines the engine, and -path customizes its location, avoiding conflicts.
A: Incorrect syntax; lacks -path and misplaces database2/.
B: -force doesn’t create a new path; it overwrites an existing engine, which isn’t the goal.
D: Omits -path and engine type, making it invalid.
The secrets engine tutorial confirms -path is required for multiple instances of the same engine type.
Reference: Secrets Engines Tutorial Secrets Enable Command
C
Explanation:
Comprehensive and Detailed In-Depth
Vault mounts secrets engines at unique paths, and only one engine can occupy a given path (e.g., database/). To enable a second database secrets engine, you must specify a different path using the – path flag: vault secrets enable -path=database2 database mounts a new instance at database2/. The type (database) defines the engine, and -path customizes its location, avoiding conflicts.
A: Incorrect syntax; lacks -path and misplaces database2/.
B: -force doesn’t create a new path; it overwrites an existing engine, which isn’t the goal.
D: Omits -path and engine type, making it invalid.
The secrets engine tutorial confirms -path is required for multiple instances of the same engine type.
Reference: Secrets Engines Tutorial Secrets Enable Command