VA-003 Practice Test 2 — 25 Questions

Question 1

Drag and drop the steps to configure Vault's audit logging to a file into the correct order.

Accepted Answer

Enable audit device, then perform operations to generate log entries, then verify the audit log.. The correct sequence for configuring Vault's audit logging to a file is: first enable the audit device (e.g., 'vault audit enable file file_path=...'), then perform operations (e.g., read/write secrets) to generate audit log entries, and finally verify the log file to confirm entries are being recorded. Common mistakes include enabling after generating logs, verifying too early, or skipping the generation step.

Answer

Perform operations to generate log entries, then enable audit device, then verify the audit log.

Answer

Verify audit log, then enable audit device, then perform operations to generate log entries.

Answer

Enable audit device, then verify the audit log, then perform operations to generate log entries.

Question 2

An administrator wants to write a secret 'myapp' with value 'password=pass123' to the KV v2 secret engine mounted at 'secret/'. Which command should they use?

Accepted Answer

vault kv put secret/myapp password=pass123. `vault kv put` is the proper command to write or update a secret in the KV v2 secrets engine. The KV v2 engine requires the `put` subcommand to create or overwrite a secret at the specified path, and the syntax `vault kv put secret/myapp password=pass123` correctly writes the key-value pair to the path `secret/myapp` under the mounted engine at `secret/`.

Answer

vault kv write secret/myapp password=pass123

Answer

vault kv create secret/myapp password=pass123

Answer

vault write secret/myapp password=pass123

Question 3

An admin creates a token with TTL=48h and explicit_max_ttl=120h. The token is renewed every 24h. After 10 days, will the token still be valid?

Accepted Answer

No, because the total lifetime cannot exceed the explicit_max_ttl of 120h.. The token's total lifetime is capped by the `explicit_max_ttl` of 120 hours (5 days). Even though the token is renewed every 24 hours, the cumulative time since creation cannot exceed the explicit maximum TTL. After 10 days (240 hours), the token will have long surpassed the 120-hour limit and will be invalid.

Answer

Yes, because TTL refreshes to 48h on each renewal.

Answer

Yes, if renewed before TTL expires, it can persist indefinitely.

Answer

No, because tokens cannot be renewed more than 5 times.

Question 4

Refer to the exhibit. A user has a token with a policy that grants 'read' on 'secret/*'. The user attempts to read the secret at 'secret/data/app' using `vault kv get secret/data/app` but receives a '404 Not Found' error. The user can successfully list the engine at 'secret/' with `vault secrets list`. What is the most likely cause of the 404 error?

Accepted Answer

The secrets engine is KV v1, but the user is using the KV v2 path format with '/data/'.. The KV v2 secrets engine requires the path format `secret/data/` for reading secret data, while KV v1 uses `secret/` directly. The user is using `vault kv get secret/data/app`, which is the correct command for KV v2, but the error indicates the engine is actually KV v1. Since KV v1 does not have a `/data/` prefix, the path `secret/data/app` does not exist, resulting in a 404 Not Found error. The successful `vault secrets list` confirms the engine is enabled at `secret/`, ruling out option D.

Answer

The user's policy does not cover the sub-path 'secret/data/app'.

Answer

The secret path is mistyped; it should be 'secret/application'.

Answer

The secret engine at 'secret/' is not enabled.

Question 5

A developer needs to manually revoke a token but only knows its accessor. Which Vault API endpoint can be used to revoke the token using only the accessor?

Accepted Answer

auth/token/revoke-accessor. The `auth/token/revoke-accessor` endpoint is specifically designed to revoke a token when only its accessor is known. The accessor is a non-sensitive identifier that Vault uses to perform token operations without exposing the actual token ID, making this endpoint the appropriate choice for revocation by accessor.

Answer

auth/token/accessors

Answer

auth/token/renew-accessor

Answer

auth/token/revoke

Question 6

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?

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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