VA-003 Practice Test 2 — 30 Questions

Question 1

A financial services company uses HashiCorp Vault's transit engine to encrypt customer credit card numbers. The application sends each credit card number individually to Vault for encryption, and the response time is acceptable. However, during peak hours, the company needs to encrypt large batches of 10,000 credit card numbers. Users report that encrypting the entire batch takes several minutes, causing timeouts. The Vault cluster is healthy and not under high load. The security team wants to reduce the encryption time without changing the encryption algorithm or key strength. What should they do?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use the `batch_input` parameter to encrypt multiple plaintexts in one API call.. The `batch_input` parameter allows sending multiple plaintexts in a single API call to Vault's transit engine, significantly reducing the overhead of individual HTTP requests and TLS handshakes. This directly addresses the batch encryption timeout issue without changing the encryption algorithm or key strength, as the Vault cluster is healthy and not under load, indicating the bottleneck is network round-trips, not cryptographic computation.

Answer

Enable key derivation on the transit key to allow parallel encryption.

Answer

Enable convergent encryption to reuse ciphertexts.

Answer

Switch to an AES-256-GCM key for faster encryption.

Question 2

An administrator wants to mount the AWS secrets engine at 'aws' path using the API. Which request is correct?

Accepted Answer

POST /v1/sys/mounts/aws with body {"type":"aws"}. Mounting a secrets engine in Vault is performed via a POST request to the `/v1/sys/mounts/<path>` endpoint with a JSON body containing the `"type"` field set to the engine's type identifier. For the AWS secrets engine, the type is `"aws"`, and the path is specified in the URL as `aws`. The POST method is required for creating a new mount, while PUT is used for tuning an existing mount.

Answer

PUT /v1/sys/mounts/aws with body {"type":"aws"}

Answer

POST /v1/sys/auth/aws with body {"type":"aws"}

Answer

POST /v1/sys/mounts/aws with body {"type":"aws-secrets"}

Question 3

An application uses a periodic token with period=24h. The application renews every 12h. After 48h, the token is still valid. After 72h, the token is still valid. What is the maximum lifetime of this periodic token?

Accepted Answer

Unlimited (as long as it keeps renewing). A periodic token with a defined period (e.g., 24h) has no maximum lifetime; it remains valid indefinitely as long as it is renewed before the period expires. In this scenario, the token is renewed every 12h (well within the 24h period), so after 48h and 72h it is still valid because each renewal resets the token's lifetime, effectively giving it an unlimited lifespan. This behavior is inherent to periodic tokens in Vault, which are designed for long-lived sessions with regular re-authentication.

Answer

72h

Answer

48h

Answer

24h

Question 4

A platform team wants Kubernetes pods to authenticate to Vault by presenting their service account token, with Vault verifying the token's validity against the Kubernetes API and checking the pod's namespace and service account name. Which auth method should the team enable?

Accepted Answer

Kubernetes auth method. The Kubernetes auth method is purpose-built for this case: it validates the service account JWT through the Kubernetes TokenReview API and enforces role constraints such as namespace and service account name. Generic JWT auth cannot perform the Kubernetes-specific token review, and methods like AppRole or cert auth rely on entirely different credentials.

Answer

JWT auth method

Answer

AppRole auth method

Answer

Cert auth method

Question 5

A developer wants to store an API key for their application in Vault using the key-value secrets engine. They need to be able to retrieve the key and also roll back to a previous version if needed. Which secrets engine configuration should they use?

Accepted Answer

Enable the KV v2 secrets engine at a custom path. The KV v2 secrets engine supports versioning, allowing retrieval of previous versions and rollback capabilities. This directly meets the requirement to store an API key and revert to an older version if needed. KV v1 does not support versioning, while Transit and Database engines serve different purposes (encryption and dynamic credentials, respectively).

Answer

Enable the Transit secrets engine at a custom path

Answer

Enable the KV v1 secrets engine at a custom path

Answer

Enable the Database secrets engine at a custom path

Question 6

A Vault operator wants to manage lease durations for secrets issued by a PKI secrets engine. Which two actions can they take to affect the lease duration of certificates?

Accepted Answer

Configure the 'ttl' parameter in the PKI role definition.. Option C is correct because the PKI role definition accepts a 'ttl' parameter that sets the default lease duration for certificates issued under that role, overriding the mount's default when specified. Option E is correct because setting 'default_lease_ttl' on the PKI secrets engine mount establishes the baseline lease duration for certificates issued by that mount when the role does not specify its own TTL. Options A and B are incorrect because 'default_lease_ttl' and 'max_lease_ttl' on an auth method govern the lifetime of the auth method's own tokens, not the leases of certificates issued by a PKI secrets engine. Option D is incorrect because 'lease_duration' is not a valid parameter in a PKI role definition; the correct parameter is 'ttl' (along with 'max_ttl').

Answer

Set the 'default_lease_ttl' on the auth method used to log in.

Answer

Set the 'max_lease_ttl' on the auth method used to log in.

Answer

Set the 'lease_duration' parameter in the PKI role definition.

Question 7

An admin wants to list all enabled authentication methods using the Vault API. Which curl command is correct?

Accepted Answer

curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auth. The Vault API endpoint to list all enabled authentication methods is a GET request to `/v1/sys/auth`. This endpoint returns a map of all enabled auth methods, and the command uses the correct HTTP method (GET) and the required `X-Vault-Token` header for authentication.

Answer

curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auths

Answer

curl -X POST -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/sys/auth

Answer

curl -H "X-Vault-Token: s.abc123" https://vault.example.com:8200/v1/auth

Question 8

A Vault cluster uses performance replication. A performance standby node is not responding to read requests. What is the most likely cause?

Accepted Answer

The performance standby node is sealed.. The performance standby node is sealed. In Vault, a sealed node cannot serve any requests, including read requests. Since the cluster uses performance replication, the standby node should be able to serve reads if it is unsealed. The fact that it is not responding indicates it is likely sealed. Other options are less likely: A is false because the cluster uses performance replication; B, a firewall blocking inbound traffic would cause no response but is less common; D, inability to connect for writes would affect write forwarding but reads should still work from local data.

Answer

Performance replication is not configured on this cluster.

Answer

The firewall is blocking inbound traffic to the standby node.

Answer

the performance standby node cannot connect to the primary for writes.

Question 9

A small startup wants to run Vault in a development environment with minimal operational overhead. They need to store secrets in memory only, without any persistence. Which storage backend should they choose?

Accepted Answer

In-memory storage backend. The in-memory storage backend stores all data in RAM with no persistence to disk, making it ideal for development environments where secrets must be lost on restart and operational overhead must be minimized. It requires no configuration, no external dependencies, and no data management, perfectly matching the requirement for minimal overhead and memory-only storage.

Answer

Integrated Storage (Raft) backend

Answer

Consul storage backend

Answer

File storage backend

Question 10

A Vault operator accidentally revoked a token that was used to lease many database credentials. What happens to the leases associated with that token?

Accepted Answer

All leases are immediately revoked.. In Vault, tokens are the root of identity and authorization for all associated leases. When a token is revoked, Vault immediately revokes all leases created using that token, including database credential leases, because the token's lifecycle governs the leases it has created. This ensures that no credentials remain valid after the token is revoked, maintaining security.

Answer

The leases become orphaned and will never be revoked.

Answer

Vault automatically renews the leases with a new token.

Answer

The leases continue until their natural expiration.

Question 11

A user receives 'permission denied' when running 'vault write secret/data/myapp value=123'. The user's token has a policy that includes 'path "secret/data/*" { capabilities = ["read", "list"] }'. What is the most likely cause?

Accepted Answer

The path requires create or update capability.. The user's policy grants only 'read' and 'list' capabilities on the path 'secret/data/*'. The 'vault write' command requires either 'create' or 'update' capability (or both) on the path. Since the policy lacks these capabilities, Vault returns a 'permission denied' error, even though the token is valid and the secret engine is mounted.

Answer

The user is not authenticated.

Answer

The secret engine is not mounted.

Answer

The token is expired.

Question 12

The CLI command returns a 403 error. What is the most likely cause?

Accepted Answer

The token does not have a policy allowing read on 'database/creds/readonly'. A 403 Forbidden error from Vault indicates that the request was authenticated (the token is valid) but the token's policies do not grant permission for the requested action. Since the command attempts to read from 'database/creds/readonly', the most likely cause is that the token lacks a policy allowing read access on that path. This is a standard authorization failure, not an authentication or configuration issue.

Answer

The role 'readonly' does not exist

Answer

The database secrets engine is not mounted at 'database/'

Answer

The field 'value' does not exist in the secret

Question 13

A security team wants to ensure that tokens can be revoked immediately if a compromised token is detected, even if the token ID is unknown. Which token feature should they use?

Accepted Answer

Token accessors. Token accessors allow revocation of a token without knowing the token ID. They are specifically designed for this purpose.

Answer

Periodic tokens

Answer

Batch tokens

Answer

Orphan tokens

Question 14

Refer to the exhibit. What operation was performed on the secret "mysecret"?

Accepted Answer

Read. The exhibit shows a Vault CLI command that retrieves the value of a secret at the path 'secret/mysecret'. The 'vault read' command is used to read data from Vault's key-value store, returning the stored value. Since the command 'vault read secret/mysecret' is executed, the operation performed is a Read, making option B correct.

Answer

Write

Answer

Delete

Answer

List

Question 15

A team is migrating from a monolithic application to microservices. Each microservice needs to authenticate to Vault using its own AppRole. The security team wants to enforce that each AppRole can only read secrets from its own dedicated path (e.g., service-a can only read from 'services/service-a/*', service-b from 'services/service-b/*'). They have created the AppRoles and policies. However, during testing, they notice that service-a can read secrets from service-b's path. The administrator checks the policy for service-a and sees it has a 'capabilities' list on 'services/service-a/*' and also 'services/service-b/*' by mistake. They correct the policy, but the issue persists. What is the most likely reason that service-a still has access?

Accepted Answer

The token was issued before the policy was corrected and still carries the old policy version; it must be replaced or renewed to get the updated permissions. Vault tokens are immutable once issued; they carry a snapshot of the policies at the time of creation. Correcting the policy on the Vault server does not retroactively update existing tokens. Service-a's token was issued before the policy fix and still contains the old policy that granted access to 'services/service-b/*'. The token must be replaced (revoked and re-issued) or renewed to pick up the updated policy permissions.

Answer

The policy still contains an error that grants access to the wrong path

Answer

The policy update has not been applied to the Vault cluster yet

Answer

The service-a token has a second policy attached that grants access to service-b

Question 16

An administrator creates a service token with a TTL of 1 hour and a max TTL of 24 hours. The token is renewed once after 55 minutes. What happens to the token after 24 hours from creation?

Accepted Answer

The token expires and cannot be renewed. The token's TTL was set to 1 hour with a max TTL of 24 hours. After the first renewal at 55 minutes, the token's TTL resets to 1 hour, but the max TTL remains 24 hours from creation. Once 24 hours have passed from creation, the token reaches its max TTL and expires permanently; it cannot be renewed because the max TTL is a hard upper limit enforced by Vault's token lifecycle logic.

Answer

The token is revoked by the system

Answer

The token's TTL is automatically extended by 1 hour

Answer

The token becomes an orphan token

Question 17

A user wants to view information about their current token, including its policies and TTL. Which TWO CLI commands can be used?

Accepted Answer

vault read auth/token/lookup-self. Option A, `vault read auth/token/lookup-self`, is correct because it reads the `auth/token/lookup-self` endpoint, which returns details about the token used to make the request, including its policies, TTL, and other metadata. Option E, `vault token lookup`, is correct because it queries the same token lookup functionality through the CLI and, when run without a token argument, displays information about the current token such as policies and TTL. Option B, `vault token list`, is incorrect because it lists accessor values of tokens rather than showing details of the current token. Option C, `vault write auth/token/lookup`, is incorrect because the lookup endpoint is read-oriented and requires a token parameter; writing to it without a token does not return current-token information. Option D, `vault token info`, is incorrect because it is not a valid Vault CLI command.

Answer

vault token list

Answer

vault write auth/token/lookup

Answer

vault token info

Question 18

An organization has two Vault clusters in different geographic regions and wants to replicate secrets from the primary cluster to the secondary cluster for disaster recovery. Which Vault replication feature should they use?

Accepted Answer

Disaster Recovery (DR) replication. Disaster Recovery (DR) replication is the correct Vault feature for replicating secrets from a primary cluster to a secondary cluster in a different geographic region for disaster recovery. DR replication copies all data, including secrets, policies, and tokens, in a one-way direction from primary to secondary, ensuring the secondary cluster can be promoted if the primary fails. This is distinct from performance replication, which is designed for load distribution and allows writes on both sides.

Answer

Cluster replication

Answer

Active Directory replication

Answer

Performance replication

Question 19

A financial services company runs a microservices application on Kubernetes. Each service needs to authenticate to Vault using Kubernetes auth and then read secrets from a shared KV v2 engine mounted at 'shared-kv'. The security team requires that Service-A can only read secrets under 'shared-kv/team-alpha/*' and Service-B can only read secrets under 'shared-kv/team-beta/*'. The Vault administrator has already configured the Kubernetes auth method and created roles for each service with bound service account names. However, both services are currently able to read all paths under 'shared-kv/'. The administrator wants to enforce the least privilege access. Which course of action should the administrator take?

Accepted Answer

Review and update the policy attached to the Kubernetes auth roles to restrict capabilities to the specific paths, e.g., 'path "shared-kv/data/team-alpha/*" { capabilities = ["read"] }'.. The issue is that the policy attached to the Kubernetes auth roles grants read access to the entire 'shared-kv/*' path. By updating the policy to restrict capabilities to specific paths like 'shared-kv/data/team-alpha/*' and 'shared-kv/data/team-beta/*', the administrator enforces least privilege. The 'data' prefix is required for KV v2 engines to access secret data, and the wildcard ensures only the respective team's secrets are readable.

Answer

Configure the Kubernetes auth role to use 'token_policies' with a restrictive policy and ensure the bound service account names are correct.

Answer

Create a new secrets engine for each team and mount them at 'team-alpha' and 'team-beta', then assign each service to its respective engine.

Answer

Add a 'path_deny' capability in the policy for the disallowed paths.

Question 20

A company uses Vault transit to encrypt secrets. They want to periodically rotate the encryption key to comply with compliance requirements. Which TWO actions should be taken? (Choose two.)

Accepted Answer

Rewrap all existing ciphertext with the new key version.. Option E is correct because Vault's transit secrets engine supports key rotation via the `rotate` endpoint (e.g., `vault write -f transit/keys//rotate`), which creates a new key version while retaining older versions for decrypting existing ciphertext. Option C is correct because after rotation, existing ciphertext still references older key versions, so `rewrap` (e.g., `vault write transit/rewrap/ ciphertext=<...>`) re-encrypts the data under the latest key version without exposing the plaintext, satisfying periodic rotation compliance. Option A is wrong because immediately setting `min_decryption_version` to the newest version would make ciphertext encrypted with older versions undecryptable, breaking access to existing data. Option B is wrong because exporting the key defeats the purpose of Vault transit (keys never leave Vault) and manual re-encryption is unnecessary since `rewrap` handles it. Option D is wrong because deleting old key versions would render existing ciphertext undecryptable and is not required for rotation.

Answer

Update the min_decryption_version to the newest version immediately.

Answer

Export the key and re-encrypt all data manually.

Answer

Delete old key versions after rotation.