HashiCorp hcva0-003 practice test
HashiCorp Certified: Vault Associate (003) Exam
Question 1
Select the policies below that permit you to create a new entry of environment=prod at the path
/secrets/apps/my_secret (select three).
- A. path "secrets/+/my_secret" { capabilities = ["create"] allowed_parameters = { "*" = [] } }
- B. path "secrets/apps/my_secret" { capabilities = ["update"] }
- C. path "secrets/apps/my_secret" { capabilities = ["create"] allowed_parameters = { "environment" = [] } }
- D. path "secrets/apps/*" { capabilities = ["create"] allowed_parameters = { "environment" = ["dev", "test", "qa", "prod"] } }
Answer:
A, C, D
Explanation:
Comprehensive and Detailed in Depth
This question requires identifying Vault policies that allow creating a new entry with
environment=prod at the specific path /secrets/apps/my_secret. Vault policies define permissions
using paths, capabilities, and parameter constraints. Let’s evaluate each option:
Option A: path "secrets/+/my_secret" { capabilities = ["create"] allowed_parameters = { "*" = [] } }
The + wildcard matches any single segment in the path, so this policy applies to
/secrets/apps/my_secret. The create capability permits creating new entries at this path. The
allowed_parameters = { "*" = [] } means any parameter (including environment) can be set to any
value. This satisfies the requirement to create an entry with environment=prod. Thus, this policy is
correct.
Option B: path "secrets/apps/my_secret" { capabilities = ["update"] }
This policy targets the exact path /secrets/apps/my_secret but only grants the update capability.
According to Vault’s documentation, update allows modifying existing entries, not creating new
ones. Since the question specifies creating a new entry, this policy does not meet the requirement
and is incorrect.
Option C: path "secrets/apps/my_secret" { capabilities = ["create"] allowed_parameters = {
"environment" = [] } }
This policy explicitly matches /secrets/apps/my_secret and grants the create capability, which allows
new entries to be written. The allowed_parameters = { "environment" = [] } specifies that the
environment parameter can take any value (an empty list means no restriction on values). This
permits setting environment=prod, making this policy correct.
Option D: path "secrets/apps/*" { capabilities = ["create"] allowed_parameters = { "environment" =
["dev", "test", "qa", "prod"] } }
The * wildcard matches any path under secrets/apps/, including /secrets/apps/my_secret. The create
capability allows new entries, and the allowed_parameters restricts environment to dev, test, qa, or
prod. Since prod is an allowed value, this policy permits creating an entry with environment=prod
and is correct.
Overall Explanation from Vault Docs:
Vault policies control access via paths and capabilities (create, read, update, delete, list). The create
capability is required to write new data. Parameter constraints (allowed_parameters) further restrict
what key-value pairs can be written. An empty list ([]) allows any value, while a populated list
restricts values to those specified. A deny takes precedence over any allow, but no deny is present
here.
Reference:
https://developer.hashicorp.com/vault/docs/concepts/policies#parameter-constraints
Question 2
Below is a list of parent and child tokens and their associated TTL. Which token(s) will be revoked
first?
├
A.
───hvs.y4fUERqCtUV0xsQjWLJar5qX - TTL: 4 hours
├
B.
───hvs.FNiIFU14RUxxUYAl4ErLfPVR - TTL: 6 hours
├
C.
───hvs.Jw9LMpu7oCQgxiKbjfyzyg75 - TTL: 4 hours (child of B)
├
D.
───hvs.3IrlhEvcerEGbae11YQf9FvI - TTL: 3 hours
├
E.
───hvs.hOpweMVFvqfvoVnNgvZq8jLS - TTL: 5 hours (child of D)
Answer:
D
Explanation:
Comprehensive and Detailed in Depth
Vault tokens have a Time-To-Live (TTL) that determines their expiration time, after which they are
revoked. Parent-child relationships mean that revoking a parent token also revokes its children,
regardless of their TTLs. Let’s analyze:
A: TTL 4 hours - Expires after 4 hours, no children listed.
B: TTL 6 hours - Expires after 6 hours, parent to C.
C: TTL 4 hours (child of B) - Expires after 4 hours or if B is revoked earlier.
D: TTL 3 hours - Expires after 3 hours, parent to E.
E: TTL 5 hours (child of D) - Expires after 5 hours or if D is revoked earlier.
Analysis:
Shortest TTL is D (3 hours), so it expires first unless a parent above it (none listed) is revoked sooner.
E (5 hours) is a child of D. If D is revoked at 3 hours, E is also revoked, despite its longer TTL.
A and C (4 hours) expire after D.
B (6 hours) expires last among parents.
The question asks which token(s) are revoked first based on TTL alone, not manual revocation. D has
the shortest TTL (3 hours) and will be revoked first. E’s revocation depends on D, but the question
focuses on initial expiration. Thus, only D is revoked first based on its TTL.
Overall Explanation from Vault Docs:
Tokens form a hierarchy where child tokens inherit revocation from their parents. “When a parent
token is revoked, all of its child tokens—and all of their leases—are revoked as well.” TTL dictates
automatic expiration unless overridden by manual revocation or parent revocation. Here, D’s 3-hour
TTL is the shortest, making it the first to expire naturally.
Reference:
https://developer.hashicorp.com/vault/docs/concepts/tokens#token-hierarchies-and-
orphan-tokens
Question 3
Your company's security policies require that all encryption keys must be rotated at least once per
year. After using the Transit secrets engine for a year, the Vault admin issues the proper command to
rotate the key named ecommerce that was used to encrypt your dat
a. What command can be used to easily re-encrypt the original data with the new version of the key?
- A. vault write -f transit/keys/ecommerce/rotate <old data>
- B. vault write -f transit/keys/ecommerce/update <old data>
- C. vault write transit/encrypt/ecommerce v1:v2 <old data>
- D. vault write transit/rewrap/ecommerce ciphertext=<old data>
Answer:
D
Explanation:
Comprehensive and Detailed in Depth
The Transit secrets engine in Vault manages encryption keys and supports key rotation. After rotating
the ecommerce key, existing ciphertext (encrypted with the old key version) must be re-encrypted
(rewrapped) with the new key version without exposing plaintext. Let’s evaluate:
A: vault write -f transit/keys/ecommerce/rotate <old data>
This command rotates the key, creating a new version, but does not re-encrypt existing data. It’s for
key management, not data rewrapping. Incorrect.
B: vault write -f transit/keys/ecommerce/update <old data>
There’s no update endpoint in Transit for re-encrypting data. This is invalid and incorrect.
C: vault write transit/encrypt/ecommerce v1:v2 <old data>
The transit/encrypt endpoint encrypts new plaintext, not existing ciphertext. The v1:v2 syntax is
invalid. Incorrect.
D: vault write transit/rewrap/ecommerce ciphertext=<old data>
The transit/rewrap endpoint takes existing ciphertext, decrypts it with the old key version, and re-
encrypts it with the latest key version (post-rotation). This is the correct command. For example, if
<old data> is vault:v1:cZNHVx+..., the output might be vault:v2:kChHZ9w4....
Overall Explanation from Vault Docs:
“Vault’s Transit secrets engine supports key rotation… The rewrap endpoint allows ciphertext
encrypted with an older key version to be re-encrypted with the latest key version without exposing
the plaintext.” This operation is secure and efficient, using the keyring internally.
Reference:
https://developer.hashicorp.com/vault/tutorials/encryption-as-a-service/eaas-transit-
rewrap
Question 4
From the unseal options listed below, select the options you can use if you're deploying Vault on-
premises (select four).
- A. Certificates
- B. Transit
- C. AWS KMS
- D. HSM PKCS11
- E. Key shards
Answer:
B, C, D, E
Explanation:
Comprehensive and Detailed in Depth
Vault requires unsealing to access encrypted data, and on-premises deployments support various
unseal mechanisms. Let’s assess:
A: Certificates
Certificates secure communication (e.g., TLS), not unsealing. Vault’s seal/unseal process uses
cryptographic keys, not certificates. Incorrect.
B: Transit
The Transit secrets engine can auto-unseal Vault by managing encryption keys internally. Ideal for on-
premises setups avoiding external services. Correct.
C: AWS KMS
AWS KMS can auto-unseal Vault if the on-premises cluster has internet access to AWS APIs. Common
in hybrid setups. Correct.
D: HSM PKCS11
Hardware Security Modules (HSM) with PKCS11 support secure key storage and auto-unsealing on-
premises. Correct.
E: Key shards
Shamir’s Secret Sharing splits the master key into shards, the default manual unseal method for all
Vault clusters. Correct.
Overall Explanation from Vault Docs:
“Vault supports multiple seal types… Key shards (Shamir) is the default… Auto-unseal options like
Transit, AWS KMS, and HSM (PKCS11) are viable for on-premises if configured with access to required
services.” Certificates are not an unseal mechanism.
Reference:
https://developer.hashicorp.com/vault/docs/configuration/seal
Question 5
How does the Vault Secrets Operator (VSO) assist in integrating Kubernetes-based workloads with
Vault?
- A. By enabling a local API endpoint to allow the workload to make requests directly from the VSO
- B. By using client-side caching for KVv1 and KVv2 secrets engines
- C. By injecting a Vault Agent directly into the pod requesting secrets from Vault
- D. By watching for changes to its supported set of Custom Resource Definitions (CRD)
Answer:
D
Explanation:
Comprehensive and Detailed in Depth
The Vault Secrets Operator (VSO) integrates Kubernetes workloads with Vault by syncing secrets.
Let’s evaluate:
A: VSO doesn’t create a local API endpoint for direct requests; it syncs secrets to Kubernetes Secrets.
Incorrect.
B: Client-side caching is a Vault Agent feature, not VSO’s primary function. VSO can use caching, but
it’s not the main integration method. Incorrect.
C: VSO doesn’t inject Vault Agents; that’s a separate Vault Agent Sidecar approach. Incorrect.
D: VSO watches Custom Resource Definitions (CRDs) to sync Vault secrets to Kubernetes Secrets
dynamically. This is its core mechanism. Correct.
Overall Explanation from Vault Docs:
“VSO operates by watching for changes to its supported set of CRDs… It synchronizes secrets from
Vault to Kubernetes Secrets, ensuring applications access them natively.”
Reference:
https://developer.hashicorp.com/vault/docs/platform/k8s/vso
Question 6
By default, what TCP port does Vault replication use?
- A. tcp/8200
- B. tcp/8300
- C. tcp/8201
- D. tcp/8301
Answer:
C
Explanation:
Comprehensive and Detailed in Depth
Vault replication ensures data consistency across clusters, using a specific port:
A: 8200 - Default HTTP API port, not replication.
B: 8300 - Raft protocol port, not replication.
C: 8201 - Default replication port. Correct.
D: 8301 - Serf protocol port, not replication.
Overall Explanation from Vault Docs:
“Replication occurs on TCP port 8201 by default… distinct from the API (8200) and Raft (8300) ports.”
Reference:
https://developer.hashicorp.com/vault/tutorials/day-one-raft/raft-reference-
architecture#network-connectivity
Question 7
What is the proper command to enable the AWS secrets engine at the default path?
- A. vault enable aws secrets engine
- B. vault secrets enable aws
- C. vault secrets aws enable
- D. vault enable secrets aws
Answer:
B
Explanation:
Comprehensive and Detailed in Depth
Enabling a secrets engine in Vault follows a specific syntax:
A: Incorrect syntax; jumbled order.
B: Correct: vault secrets enable <type> enables the AWS engine at aws/. Correct.
C: Incorrect word order.
D: Incorrect syntax.
Overall Explanation from Vault Docs:
“The command vault secrets enable <type> enables a secrets engine at its default path (e.g., aws/ for
AWS).”
Reference:
https://developer.hashicorp.com/vault/docs/commands/secrets
Question 8
In regards to the Transit secrets engine, which of the following is true given the following command
and output (select three):
$ vault write encryption/encrypt/creditcard plaintext=$(base64 <<< "1234 5678 9101 1121")
Key: ciphertext Value:
vault:v3:cZNHVx+sxdMErXRSuDa1q/pz49fXTn1PScKfhf+PIZPvy8xKfkytpwKcbC0fF2U=
- A. The Transit secrets engine is mounted at the encryption path
- B. The name of the keyring used to encrypt the data is creditcard
- C. There are at least three data keys associated with this keyring
- D. The data was written to the encryption path, which is provided by default when enabling the Transit secrets engine
Answer:
A, B, C
Explanation:
Comprehensive and Detailed in Depth
A: The command uses encryption/encrypt/creditcard, indicating the Transit engine is mounted at
encryption/. Correct.
B: The endpoint creditcard specifies the key name used for encryption. Correct.
C: The output vault:v3: shows key version 3, implying at least three versions (v1, v2, v3) after
rotations. Correct.
D: The default path for Transit is transit/, not encryption/. This is a custom mount, not default.
Incorrect.
Overall Explanation from Vault Docs:
“The Transit engine encrypts data at a specified key name… Key versions (e.g., v3) indicate rotations.”
Reference:
https://developer.hashicorp.com/vault/docs/secrets/transit
Question 9
Which of the following statements are true regarding Vault seal and unseal (select three)?
- A. By default, Vault uses the Shamir Sharing algorithm to create unseal keys during the initialization process
- B. When using Vault Auto Unseal feature, Vault returns unseal keys to the user when it is initialized
- C. Vault can use a third-party KMS solution to automatically unseal during a service restart
- D. Vault supports high availability for the Auto Unseal feature, allowing you to point to multiple keys
Answer:
A, C, D
Explanation:
Comprehensive and Detailed in Depth
A: Vault uses Shamir’s Secret Sharing by default for unseal keys. Correct.
B: Auto Unseal uses KMS or similar; it returns recovery keys, not unseal keys. Incorrect.
C: Third-party KMS (e.g., AWS KMS) can auto-unseal Vault. Correct.
D: Auto Unseal supports HA with multiple keys for redundancy. Correct.
Overall Explanation from Vault Docs:
“Vault uses Shamir’s algorithm by default… Auto Unseal with KMS supports HA and does not return
unseal keys but recovery keys.”
Reference:
https://developer.hashicorp.com/vault/docs/concepts/seal#seal-unseal
Question 10
If Bobby is currently assigned the following policy, what additional policy can be added to ensure
Bobby cannot access the data stored at secret/apps/confidential but still read all other secrets?
path "secret/apps/*" { capabilities = ["create", "read", "update", "delete", "list"] }
- A. path "secret/apps/confidential" { capabilities = ["deny"] }
- B. path "secret/*" { capabilities = ["read", "deny"] }
- C. path "secret/apps/*" { capabilities = ["deny"] }
- D. path "secret/apps/confidential/*" { capabilities = ["deny"] }
Answer:
A
Explanation:
Comprehensive and Detailed in Depth
A: Denies all access to secret/apps/confidential, overriding the original policy’s permissions. Correct.
B: Applies to all secret/*, overly restrictive and unclear with mixed capabilities. Incorrect.
C: Denies all secret/apps/*, blocking more than required. Incorrect.
D: Denies subpaths under confidential, not the path itself. Incorrect.
Overall Explanation from Vault Docs:
“A deny capability takes precedence over any allow… Use it to restrict specific paths.”
Reference:
https://developer.hashicorp.com/vault/docs/concepts/policies#capabilities
Question 11
Tommy has written an AWS Lambda function that will perform certain tasks for the organization
when data has been uploaded to an S3 bucket. Security policies for the organization do not allow
Tommy to hardcode any type of credential within the Lambda code or environment variables.
However, Tommy needs to retrieve a credential from Vault to write data to an on-premises database.
What auth method should Tommy use in Vault to meet the requirements while not violating security
policies?
- A. AWS
- B. Userpass
- C. Token
- D. AppRole
Answer:
A
Explanation:
Comprehensive and Detailed in Depth
A: AWS auth uses IAM roles, avoiding hardcoded credentials. Correct for Lambda.
B: Userpass requires username/password, violating policy. Incorrect.
C: Token requires a pre-generated token, often hardcoded. Incorrect.
D: AppRole needs RoleID/SecretID, typically hardcoded. Incorrect.
Overall Explanation from Vault Docs:
“The AWS auth method provides an automated mechanism to retrieve a Vault token for IAM
principals… no manual credential provisioning required.”
Reference:
https://developer.hashicorp.com/vault/docs/auth/aws#aws-auth-method
Question 12
What command would have created the token displayed below?
$ vault token lookup hvs.nNeZ2I64ALCxuO7dqQEJGPrO
Key: policies Value: [default dev], num_uses: 5, ttl: 767h59m49s
Key
Value
---
-----
accessor
mfvaVMFgOcXHIeqlRasroSOn
creation_time
1604610457
creation_ttl
768h
display_name
token
entity_id
n/a
expire_time
2024-12-07T16:07:37.7540672-05:00
explicit_max_ttl 0s
id
hvs.nNeZ2I64ALCxuO7dqQEJGPrO
issue_time
2024-11-05T16:07:37.7540672-05:00
meta
<nil>
num_uses
orphan
false
path
auth/token/create
policies
[default dev]
renewable
true
ttl
767h59m49s
type
service
- A. vault token create -policy=dev -use-limit=5
- B. vault token create -policy=dev -ttl=768h
- C. vault token create -policy=dev -policy=default -ttl=768h
- D. vault token create -policy=dev
Answer:
A
Explanation:
Comprehensive and Detailed in Depth
A: Matches dev policy and num_uses=5. TTL is system default (768h). Correct.
B: Missing num_uses. Incorrect.
C: Adds default policy explicitly, not needed as it’s implicit. Incorrect.
D: Missing num_uses. Incorrect.
Overall Explanation from Vault Docs:
“vault token create with -policy and -use-limit sets specific attributes… default policy is included
implicitly.”
Reference:
https://developer.hashicorp.com/vault/docs/commands/token/create#command-options
Question 13
You’ve set up multiple Vault clusters, one on-premises intended to be the primary cluster, and the
second cluster in AWS, which was deployed for performance replication. After enabling replication,
developers complain that all the data they’ve stored in the AWS Vault cluster is missing. What
happened?
- A. There is a certificate mismatch after replication was enabled since Vault replication generates its own TLS certificates to ensure nodes are trusted entities
- B. All of the data on the secondary cluster was deleted after replication was enabled
- C. The data was automatically copied to the primary cluster after replication was enabled since all writes are always forwarded to the primary cluster
- D. The data was moved to a recovery path after replication was enabled. Use the vault secrets move command to move the data back to its intended location
Answer:
B
Explanation:
Comprehensive and Detailed in Depth
A: Certificate issues don’t delete data. Incorrect.
B: Performance replication wipes the secondary’s data to sync with the primary. Correct.
C: Data isn’t copied to the primary; replication is one-way. Incorrect.
D: No recovery path exists; data is wiped. Incorrect.
Overall Explanation from Vault Docs:
“When replication is enabled, all of the secondary’s existing storage will be wiped… This is
irrevocable.”
Reference:
https://developer.hashicorp.com/vault/tutorials/enterprise/performance-replication
Question 14
Based on the screenshot below, how many auth methods have been enabled on this Vault instance?
- A. 1
- B. 2
- C. 4
- D. 3
Answer:
B
Explanation:
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
Question 15
Given the following policy, which command below would not result in a permission denied error
(select two)?
path "secret/*" { capabilities = ["create", "update"] allowed_parameters = { "student" = ["steve",
"frank", "jamie", "susan", "gerry", "damien"] } }
path "secret/apps/*" { capabilities = ["read"] }
path "secret/apps/results" { capabilities = ["deny"] }
- A. vault kv put secret/apps/results student03=practice
- B. vault kv put secret/apps/app01 student=bryan
- C. vault kv put secret/common/results student=frank
- D. vault kv get secret/apps/api_key
Answer:
C, D
Explanation:
Comprehensive and Detailed in Depth
A: Denied by secret/apps/results deny policy. Incorrect.
B: secret/apps/app01 only allows read, not create. Incorrect.
C: secret/common/results allows create with student=frank (allowed value). Correct.
D: secret/apps/api_key allows read. Correct.
Overall Explanation from Vault Docs:
“deny overrides any allow… allowed_parameters restricts values.”
Reference:
https://developer.hashicorp.com/vault/docs/concepts/policies#parameter-constraints