HashiCorp Certified: Vault Associate (003) HCVA0-003 Exam Practice Test

Answer : D

Comprehensive and Detailed in Depth

Batch tokens are designed for specific, transient use cases. The HashiCorp Vault documentation states: 'Batch tokens are lightweight and scalable and include just enough information to be used with Vault. They are generally used for ephemeral, high-performance workloads, such as encrypting data.' This makes them ideal for short-lived, high-volume, or 'ephemeral' tasks (D).

The docs contrast: 'Unlike service tokens, which are renewable and suited for long-lived processes, batch tokens have a fixed TTL and cannot be renewed.' Options like generating dynamic credentials (A) and daily batch jobs (C) align more with service tokens, while renewing tokens (B) isn't a batch token function. Thus, D is correct.

HashiCorp Vault Documentation - Batch Tokens

Answer : A

Comprehensive and Detailed in Depth

A: Correctly contrasts self-managed (user responsibility) with HCP Vault (HashiCorp-managed). Correct.

B: Both support replication; false. Incorrect.

C: HCP Vault doesn't require manual upgrades. Incorrect.

D: Reverses responsibilities; false. Incorrect.

Overall Explanation from Vault Docs:

''HCP Vault Dedicated is operated by HashiCorp... Self-managed Vault requires users to handle setup, maintenance, and scaling.''

Answer : B

Comprehensive and Detailed In-Depth

In HashiCorp Vault, when a user authenticates via multiple methods (e.g., LDAP, OIDC, userpass), each authentication method generates a distinct token with its own set of policies based on the configuration of that auth method. This can lead to inconsistent access levels depending on how the user logs in. To address this and ensure consistent policies across all authentication methods, Vault's Identity system can be utilized. Specifically, creating an entity and mapping aliases from each authentication method to that entity allows Vault to associate a single logical identity with the user, regardless of how they authenticate.

An entity in Vault represents a single identity (e.g., a user or application) and can have multiple aliases tied to different auth methods. Each alias links the authentication method's identifier (e.g., LDAP username, OIDC subject) to the entity. Policies can then be assigned directly to the entity, ensuring that all tokens generated for that entity---across any auth method---inherit the same set of policies. This eliminates the need for users to log out and back in to switch contexts, as their access remains consistent.

Option A (SSH secrets engine) is unrelated, as it manages SSH credentials, not policy consistency across auth methods. Option C (assigning the default policy) doesn't guarantee consistency, as the default policy might not include all required permissions and doesn't unify policies across methods. Option D (AppRole) is a machine-oriented auth method and doesn't solve the multi-method human user scenario. The correct approach, as per Vault's Identity documentation, is to leverage entities and aliases.

Vault Identity Documentation

Vault Entities and Aliases Tutorial

Answer : A, D, E

Comprehensive and Detailed in Depth

The command initializes Vault, splitting the master key into 3 shares (threshold 2) and encrypting each with PGP keys for Jane, John, and Student01. Let's analyze:

Option A: The admin never sees all the unseal keys and cannot unseal Vault by themselves

With -pgp-keys, Vault encrypts each share with a user's public PGP key. The admin (initializer) sees only encrypted outputs (e.g., Key 1: <encrypted>), not plaintext keys. Since 2 shares are needed and no single entity gets all, the admin can't unseal alone. Correct.

Vault Docs Insight: ''The initializer receives encrypted keys... never sees all plaintext keys, enhancing security.'' (Directly stated.)

Option B: All three users, Jane/John/Student01, will receive all unseal keys and can unseal Vault

Each user gets one encrypted share (e.g., Jane gets Key 1, John Key 2). No user receives all shares---only one, decryptable with their private key. Unsealing requires collaboration (2 of 3), so this is false. Incorrect.

Vault Docs Insight: ''Each PGP key encrypts one share... No single user gets all keys.'' (Distribution is per-user.)

Option C: The admin will receive the unseal keys and be able to unseal Vault themselves

Without PGP, the admin gets plaintext keys. With -pgp-keys, they get encrypted keys they can't decrypt (lacking private keys). Threshold=2 means collaboration is required. Incorrect.

Vault Docs Insight: ''Using PGP keys ensures the initializer cannot unseal alone...'' (Security feature.)

Option D: The keys will be returned encrypted

The -pgp-keys flag encrypts each share with the corresponding public key. Output shows encrypted blobs (e.g., base64-encoded PGP ciphertext), not plaintext. Correct.

Vault Docs Insight: ''Vault will generate the unseal keys and encrypt them using the given PGP keys...'' (Explicit behavior.)

Option E: Each individual can only decrypt their own unseal key using their private PGP key

Each share is encrypted with one user's public key (e.g., Jane's key encrypts Key 1). Only Jane's private key decrypts it. This ensures secure distribution. Correct.

Vault Docs Insight: ''Only the owner of the corresponding private key can decrypt the value...'' (PGP security.)

Detailed Mechanics:

Command: vault operator init -key-shares=3 -key-threshold=2 -pgp-keys='jane.pgp,john.pgp,student01.pgp'. Vault generates 3 shares via Shamir's Secret Sharing, encrypts each (Key 1 with jane.pgp, etc.), and outputs encrypted strings. Unsealing requires 2 decrypted shares combined via vault operator unseal. PGP ensures the admin can't access plaintext, enforcing split knowledge.

Real-World Example:

Output: Key 1: <encrypted-jane>, Key 2: <encrypted-john>, Key 3: <encrypted-student01>. Jane decrypts Key 1 with gpg -d, John decrypts Key 2. They submit via UI or CLI to unseal.

Overall Explanation from Vault Docs: ''Vault can optionally be initialized using PGP keys. In this mode, Vault will generate the unseal keys and immediately encrypt them using the given users' public PGP keys. Only the owner of the corresponding private key is able to decrypt the value... The initializer never sees all plaintext keys and cannot unseal Vault alone.'' This enhances security by distributing trust. Reference: https://developer.hashicorp.com/vault/docs/commands/operator/init#pgp-keys

''Vault can optionally be initialized using PGP keys. In this mode, Vault will generate the unseal keys and immediately encrypt them using the given users' public PGP keys. Only the owner of the corresponding private key is able to decrypt the value... The initializer never sees all plaintext keys and cannot unseal Vault alone.'' This enhances security by distributing trust.

Overall Explanation from Vault Docs: ''Vault can optionally be initialized using PGP keys. In this mode, Vault will generate the unseal keys and immediately encrypt them using the given users' public PGP keys. Only the owner of the corresponding private key is able to decrypt the value... The initializer never sees all plaintext keys and cannot unseal Vault alone.'' This enhances security by distributing trust. Reference: https://developer.hashicorp.com/vault/docs/commands/operator/init#pgp-keys

Answer : D

Comprehensive and Detailed in Depth

The data.json file in this API request contains the data to be encrypted by the Transit secrets engine. The HashiCorp Vault documentation states: 'When executing any call to the Vault API, data can be sent using an external file as shown above. In this case, the contents of the file would be cleartext customer data that needs to be encrypted by the transit secrets engine.' Specifically, for the /transit/encrypt/ endpoint, it explains: 'The API expects a JSON payload with a plaintext field containing the base64-encoded data to encrypt.'

The documentation elaborates under 'Encrypt Data': 'The request body must include the plaintext parameter, which is the base64-encoded version of the data you want to encrypt. For example: {'plaintext': 'base64-encoded-data'}.' Here, D (Cleartext customer data to be encrypted) fits this requirement---customer data in cleartext, base64-encoded, sent for encryption. A (Transit config) is managed in Vault, not sent. B (Ciphertext) is the output, not input. C (Encryption key) is stored in Vault, not provided by the client. Thus, D is correct.

HashiCorp Vault Documentation - Transit API: Encrypt Data

Answer : C, F

Comprehensive and Detailed in Depth

Vault policies use specific characters for wildcards and path segments. The HashiCorp Vault documentation states: 'The plus sign (+) can be used to denote a path segment and can be used in the middle of a path. The splat (*) can be used as a wildcard but can only be used at the very end of a path.' These are the only characters designated for such purposes in policy syntax.

The docs add: 'For example, secret/data/* matches all paths under secret/data/, while secret/+/foo matches a single segment like secret/bar/foo.' &, @, $, and # have no special meaning in Vault policies. Thus, C (*) and F (+) are correct.

HashiCorp Vault Documentation - Policies: Policy Syntax

Answer : C

When looking at Vault token details, the policies key helps you find the paths the token is able to access. Policies are a declarative way to grant or forbid access to certain paths and operations in Vault. Policies are written in HCL or JSON and are attached to tokens by name. Policies are deny by default, so an empty policy grants no permission in the system. A token can have one or more policies associated with it, and the effective policy is the union of all the individual policies. You can view the token details by using the vault token lookup command or the auth/token/lookup API endpoint. The output will show the policies key with a list of policy names that are attached to the token. You can also view the contents of a policy by using the vault policy read command or the sys/policy API endpoint. The output will show the rules key with the HCL or JSON representation of the policy.The rules will specify the paths and the capabilities (such as create, read, update, delete, list, etc.) that the policy allows or denies.Reference: https://developer.hashicorp.com/vault/docs/concepts/policies4, https://developer.hashicorp.com/vault/docs/commands/token/lookup5, https://developer.hashicorp.com/vault/api-docs/auth/token#lookup-a-token6, https://developer.hashicorp.com/vault/docs/commands/policy/read7, https://developer.hashicorp.com/vault/api-docs/system/policy8