Free HCVA0-003 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

Comprehensive and Detailed in Depth

After authentication, Vault uses tokens for all subsequent calls. The HashiCorp Vault documentation

states: "After authenticating, a client is issued a service token which is associated with a policy. That

token is used to make all subsequent requests to Vault." Tokens serve as the primary security feature

for authorizing and authenticating requests.

The docs elaborate: "Tokens are the core method for authentication within Vault. Once

authenticated, the client uses this token to access secrets and perform operations according to the

attached policies." Other options like ldap, pgp, path, key shard, and listener are unrelated to this

role. Thus, F is correct.

Reference:

HashiCorp Vault Documentation - Authentication Concepts

Comprehensive and Detailed in Depth

A: Dev mode is faster to deploy; incorrect.

B: Production uses persistent storage vs. dev’s in-memory. Correct.

C: Auth methods work in both modes. Incorrect.

D: Production enables TLS; dev uses plaintext. Correct.

Overall Explanation from Vault Docs:

“Dev server mode stores data in memory… Production mode supports persistent storage and TLS

encryption.”

Reference: https://developer.hashicorp.com/vault/docs/concepts/dev-server

Comprehensive and Detailed in Depth

The Vault Secrets Operator (VSO) enhances secrets management in Kubernetes. The HashiCorp Vault

documentation lists its benefits: "The following features are supported by the Vault Secrets Operator:

Support for syncing from multiple secret sources.

Automatic secret drift and remediation.

Automatic secret rotation for Deployment, ReplicaSet, StatefulSet Kubernetes resource types."

The docs explain: "VSO watches for changes to its supported Custom Resource Definitions (CRDs) and

synchronizes secrets from Vault to Kubernetes Secrets, ensuring consistency (A). It detects and

corrects unauthorized changes (C) and rotates secrets for specified resource types (D)." Bi-directional

sync (B) is not supported—sync is one-way from Vault to Kubernetes. Thus, A, C, and D are correct.

Reference:

HashiCorp Vault Documentation - Vault Secrets Operator

Comprehensive and Detailed in Depth

To determine if a KV store is configured for versioning (i.e., KV v1 or v2), Steve needs detailed

information about the secrets engines. The HashiCorp Vault documentation states: "To list all

enabled secrets engines with detailed output, use the command vault secrets list -detailed. This will

provide additional information about each secrets engine, including the version of the KV secrets

engines." The -detailed flag reveals configuration details, such as the options field indicating

version=2 for KV v2, which supports versioning.

vault secrets list -all is not a valid command. vault kv get automation retrieves a specific secret, not

engine configuration. vault kv list lists keys in a path, not engine details. Thus, C is correct.

Reference:

HashiCorp Vault Documentation - Secrets Engines (Note: Specific command details are from CLI help

and tutorials)

Comprehensive and Detailed in Depth

After successful authentication, the CLI and UI interfaces in Vault automatically assume the token for

subsequent requests, simplifying user interaction. The HashiCorp Vault documentation states: "After

authenticating, the UI and CLI automatically assume the token for all subsequent requests. The API,

however, requires the user to extract the token from the server response after authenticating in

order to send with subsequent requests." This is facilitated by Vault’s token helper mechanism for CLI

and session management in the UI.

The documentation under "Token Helper" explains: "The Vault CLI uses a token helper to store the

token locally after login (e.g., vault login), and future commands automatically use this token without

requiring it to be specified each time." Similarly, the UI stores the token in the browser session post-

login. In contrast, the API requires explicit inclusion of the token in each request header (e.g., X-

Vault-Token), making manual token management necessary. Thus, A (CLI) and C (UI) are correct.

Reference:

HashiCorp Vault Documentation - Commands: Token Helper

Comprehensive and Detailed in Depth

The response wrapping feature in Vault functions by securing responses in a single-use token’s

cubbyhole. The HashiCorp Vault documentation states: "To help address this problem, Vault includes

a feature called response wrapping. When requested, Vault can take the response it would have sent

to an HTTP client and instead insert it into the cubbyhole of a single-use token, returning that single-

use token instead." This ensures the response is accessible only once by the intended recipient.

The docs further explain: "Logically speaking, the response is wrapped by the token, and retrieving it

requires an unwrap operation against this token. Functionally speaking, the token provides

authorization to use an encryption key from Vault’s keyring to decrypt the data." Options B, C, and D

misrepresent this process—no dedicated key encryption, no splitting into multiple tokens, and no

persistent multi-use tokens occur. Thus, A is correct.

Reference:

HashiCorp Vault Documentation - Response Wrapping

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

Comprehensive and Detailed in Depth

Once a dynamic secret’s lease expires, it cannot be renewed or reused; a new secret must be

requested. The HashiCorp Vault documentation states: "A lease must be renewed before it has

expired. Once it has expired, it is permanently revoked and a new secret must be requested." This

means that after expiration, the secret is invalidated, and the application must obtain a new secret

with a new lease to regain access.

Trying an expired secret (A) is futile as it’s revoked. Performing a lease renewal (B) is impossible post-

expiration, as the docs note: "Renewal must occur before the lease expires." Extending the TTL (D)

isn’t an option for an expired lease. Thus, C is the correct action.

Reference:

HashiCorp Vault Documentation - Leases: Lease Renew and Revoke

Comprehensive and Detailed in Depth

HCP Vault Dedicated is a managed service, while self-hosted Vault (Community or Enterprise)

requires user management. Let’s evaluate:

A: Simple needs favor HCP Vault’s managed simplicity. Incorrect.

B: Offloading tasks aligns with HCP Vault, not self-hosted. Incorrect.

C: Managed scalability suits HCP Vault. Incorrect.

D: Compliance, custom integrations, and plugin development need full control, only possible with

self-hosted Vault. Correct.

Detailed Mechanics:

Self-hosted Vault allows custom plugins, FIPS 140-2 compliance, and specific network configs (e.g.,

air-gapped setups), unavailable in HCP Vault Dedicated due to its standardized, managed nature.

Overall Explanation from Vault Docs:

“Self-managed Vault supports custom requirements… HCP Vault Dedicated offloads operations but

limits control.”

Reference: https://developer.hashicorp.com/vault/tutorials/get-started/available-editions

Comprehensive and Detailed in Depth

The correct path for Vault backend functions, which include administrative actions, is /sys. The

HashiCorp Vault documentation confirms: "All backend system functions live in the /sys backend.

Policies should take /sys into account when users need to administer Vault configurations." This path

hosts endpoints for system-level operations like mounting secrets engines, managing policies, and

sealing/unsealing Vault.

Paths like /security, /admin, /vault, /system, and /backend are not standard for Vault’s system

backend. Only /sys provides the necessary administrative capabilities, making E the correct answer.

Reference:

HashiCorp Vault Documentation - System Backend

Comprehensive and Detailed in Depth

Token is enabled by default and cannot be disabled.

Userpass is explicitly enabled.

Total: 2 auth methods.

Overall Explanation from Vault Docs:

“Tokens are the default auth method… Additional methods like userpass increase the count.”

Reference: https://developer.hashicorp.com/vault/docs/concepts/tokens

Comprehensive and Detailed In-Depth

To ensure consistent access permissions for Sarah across multiple authentication methods (LDAP and

GitHub), the correct approach in Vault is to create an entity for Sarah and map both her LDAP and

GitHub identities as entity aliases to this single entity.

Entities and Aliases in Vault: Vault’s Identity secrets engine allows the creation of entities, which are

logical representations of users or machines. Each entity can have multiple aliases, where an alias

corresponds to an identity from a specific auth method. By mapping Sarah’s LDAP identity (e.g., her

LDAP username) and GitHub identity (e.g., her GitHub username) as aliases to a single entity, Vault

associates both identities with one set of policies. The documentation states: "Vault clients can be

mapped as entities and their corresponding accounts with authentication providers can be mapped

as aliases."

Why This Works: Assigning policies to the entity ensures that Sarah’s permissions remain consistent

regardless of whether she logs in via LDAP or GitHub. This centralizes policy management and

eliminates discrepancies.

Incorrect Options:

B. External Group Approach: Creating an external group and adding LDAP and GitHub providers as

members does not inherently synchronize permissions for a single user like Sarah. External groups

are better suited for mapping group memberships from external systems to Vault policies, not

individual identity unification.

C. Separate Policies: Managing separate policies per auth method is error-prone and inefficient.

Manual synchronization risks inconsistencies, undermining security and manageability.

D. Trust Relationship: Vault does not support configuring trust relationships between auth methods

like LDAP and GitHub to sync accounts. This is a misunderstanding of Vault’s architecture.

This entity-based approach leverages Vault’s identity system to unify Sarah’s access, simplifying

administration and ensuring consistency.

Reference: https://developer.hashicorp.com/vault/tutorials/auth-methods/identity

Comprehensive and Detailed in Depth

The statement is False. Setting the minimum decryption version does not remove older key versions.

The HashiCorp Vault documentation states: "Key versions that are earlier than a key’s specified

min_decryption_version get archived, and the rest of the key versions belong to the working set. In

an emergency, the min_decryption_version can be moved back to allow for legitimate decryption."

Older versions remain available for decryption if needed.

The docs add: "Archiving a key version does not delete it; it simply marks it as outside the active

working set, but Vault retains it for potential use." Thus, older versions are not removed, making B

correct.

Reference:

HashiCorp Vault Documentation - Transit Secrets Engine: Working Set Management

Comprehensive and Detailed in Depth

A: Incorrect. Transit doesn’t store ciphertext; it returns it to the client.

B: Correct. The Transit engine performs encryption/decryption without persisting data.

Overall Explanation from Vault Docs:

“The Vault Transit secrets engine does NOT store any data… Ciphertext is returned to the caller.”

Reference: https://developer.hashicorp.com/vault/docs/secrets/transit

Not all storage backends support high availability mode for Vault. Only the storage backends that

support locking can enable Vault to run in a multi-server mode where one server is active and the

others are standby. Some examples of storage backends that support high availability mode are

Consul, Integrated Storage, and ZooKeeper. Some examples of storage backends that do not support

high availability mode are Filesystem, MySQL, and PostgreSQL. Reference:

https://developer.hashicorp.com/vault/docs/concepts/ha1,

https://developer.hashicorp.com/vault/docs/configuration/storage2

Comprehensive and Detailed In-Depth

The policy’s path syntax determines access:

B. False: "This policy will NOT permit access to secrets stored under secrets/cloud/apps/jenkins." The

wildcard * applies to paths after jenkins/, e.g., secrets/cloud/apps/jenkins/config, but not the exact

path secrets/cloud/apps/jenkins. "Notice that in the policy, the wildcard (*) is AFTER the path

jenkins, and not AT the jenkins path."

Incorrect Option:

A. True: Incorrect; the policy requires an additional segment to match.

To permit secrets/cloud/apps/jenkins, the policy should be path "secrets/cloud/apps/jenkins" {} or

include a broader wildcard like secrets/cloud/apps/*.

Reference: https://developer.hashicorp.com/vault/docs/concepts/policies

Comprehensive and Detailed In-Depth

False. Vault supports multiple auth methods, not just platform-specific ones. The Vault

documentation states:

"Just because you are using a certain platform does not mean you need to use the related auth

method. Vault offers a variety of auth methods that can be used based on the organization’s needs

and existing infrastructure, allowing for flexibility and customization in authentication processes."

— Vault Auth Concepts

B: Correct. Options like AppRole, LDAP, or JWT can be used on GCP:

"GCP auth MIGHT be the best option, but it’s not the ONLY option that you can use."

— Vault Auth Concepts

A: Incorrect; Vault isn’t limited to GCP auth on GCP.

Reference:

Vault Auth Concepts

The statement is true. When an auth method is disabled, all users authenticated via that method

lose access. This is because the tokens issued by the auth method are automatically revoked when

the auth method is disabled. This prevents the users from performing any operation in Vault using

the revoked tokens. To regain access, the users have to authenticate again using a different auth

method that is enabled and has the appropriate policies attached. Reference: Auth Methods | Vault |

HashiCorp Developer, auth disable - Command | Vault | HashiCorp Developer

Comprehensive and Detailed In-Depth

AppRole’s flexibility allows human use:

A. True: "Although AppRole is primarily designed for machine-to-machine authentication, it can also

be used by humans to authenticate to Vault if needed." It uses a role_id and secret_id, which, while

less convenient for humans, are technically usable. "Yeah, absolutely. Although it’s not super friendly

for us humans to remember the values, you could use it if you wanted to."

Incorrect Option:

B. False: Incorrect; it’s not restricted to machines only.

This adaptability broadens AppRole’s applicability.

Reference: https://developer.hashicorp.com/vault/docs/auth/approle

Comprehensive and Detailed In-Depth

Dynamic secrets are managed actively:

A. True: "Once the lease for a dynamic secret has expired, Vault automatically revokes the credentials

on the backend platform for which they were created." This cleanup reduces technical debt.

Incorrect Option:

B. False: Incorrect; revocation is automatic.

"When a lease expires, Vault does indeed revoke the credentials on the platform."

Reference: https://developer.hashicorp.com/vault/docs/concepts/lease