VA-003 Practice Test 28 — 15 Questions

Question 1

A user's token was revoked by an administrator, but the user can still read secrets from a KV v1 secrets engine. What is the most likely reason?

Accepted Answer

The secrets were from a KV v1 engine that does not use leases. KV v1 secrets engines do not issue leases for read operations, so token revocation does not affect access to previously read secrets. The token itself was revoked, but the user's ability to read secrets from KV v1 persists because the engine does not enforce lease-based expiration or revocation checks on stored data.

Answer

The token had sudo capabilities on the path

Answer

The token was a root token and cannot be revoked

Answer

The token was an orphan token and therefore immune to revocation

Question 2

A user tries to renew their own token using 'vault token renew -self' and gets 'Error renewing token: Error making API request'. The token is still valid. What could be the cause?

Accepted Answer

The token is not renewable.. The error 'Error renewing token: Error making API request' when using 'vault token renew -self' on a still-valid token indicates the token is not renewable. In Vault, tokens have a renewable flag; if set to false, the token cannot have its TTL extended, even if it is still valid. The error message is generic but the core issue is the token's non-renewable property, not a policy denial or server connectivity problem.

Answer

The token was created with a period.

Answer

The token's policy denies renewal.

Answer

The Vault server is unreachable.

Question 3

Which three of the following are valid capabilities in a Vault policy path statement? (Select three.)

Accepted Answer

list. In Vault policy path statements, capabilities define the allowed operations on secrets. The 'list' capability is valid and allows listing keys at a given path, which is essential for enumerating secrets without reading their values. This is a core capability in Vault's policy system, distinct from 'read' or 'write'.

Answer

encrypt

Answer

patch

Question 4

An admin needs to revoke all leases associated with a particular policy violation. Which two methods can be used? (Choose two.)

Accepted Answer

vault write sys/leases/revoke-prefix . `vault write sys/leases/revoke-prefix ` revokes all leases sharing a given prefix, which is the standard method for bulk revocation based on a policy violation path. Option E is correct because `vault lease revoke -prefix ` achieves the same result by revoking all leases under a specified mount path, effectively targeting the same scope. Both commands allow an admin to revoke multiple leases associated with a particular policy violation without needing individual lease IDs.

Answer

vault sys/leases/revoke-force <prefix>

Answer

vault token revoke -mode=orphan <token>

Answer

vault lease revoke <lease_id>

Question 5

A token with this policy attempts to read the secret at path 'secret/data/engineering/special'. Will the read succeed?

Accepted Answer

Yes, because the first path grants read on all secrets under 'secret/data/engineering/'. The first path grants read on secret/data/engineering/*, which includes 'special'. The second path grants create/update on a different path (without 'data' prefix) and does not deny read. Vault merges capabilities, so read is allowed. Option B is wrong because ACL merging does not cause one statement to override another unless there is an explicit deny. Option C is wrong because the token already has a policy covering that path. Option D is wrong because the second path does not grant read but also does not deny it.

Answer

No, because the token needs an additional policy to read from that specific path

Answer

Yes, because the second path implicitly allows read

Answer

No, because the second path is more specific and only allows create/update

Question 6

Refer to the exhibit. A token has this policy. Which action can the token perform?

Accepted Answer

Read a secret at "secret/data/engineering/db-pass". The token's policy grants 'read' capability on 'secret/data/engineering/*' via the 'data' path. Since 'secret/data/engineering/db-pass' falls under that wildcard, the token can read it. The policy does not allow 'update', 'list', or 'delete' actions on the specified paths.

Answer

Update a secret at "secret/data/engineering/config"

Answer

List secrets at "secret/data/finance/"

Answer

Delete a secret at "secret/data/finance/budget"

Question 7

A company needs to issue short-lived TLS certificates for internal microservices. They want to set up a private CA using Vault. Which steps are required to configure the PKI secrets engine?

Accepted Answer

Enable PKI, generate root CA, create a role, issue certificates. The correct order to configure the Vault PKI secrets engine is: first enable the PKI secrets engine at a path, then generate a root CA certificate (which creates the CA's key pair and self-signed certificate), then create a role that defines certificate issuance parameters (such as allowed domains and TTL), and finally issue certificates using that role. This sequence ensures the CA exists before roles reference it, and roles exist before certificates are issued.

Answer

Enable PKI, create a role, generate root CA, issue certificates

Answer

Generate root CA, enable PKI, create a role, issue certificates

Answer

Enable PKI, generate intermediate CA, generate root CA, issue certificates

Question 8

Which TWO of the following are valid methods to authenticate to Vault using the CLI without using a token? (Choose two.)

Accepted Answer

vault login -method=userpass username=joe password=pass. The `vault login -method=userpass` command authenticates to Vault using the userpass auth method via the CLI, which does not require a pre-existing token. Instead, it directly exchanges the provided username and password for a client token from the Vault server. This is a standard tokenless authentication flow for the userpass method.

Answer

vault auth -method=ldap username=joe password=pass

Answer

vault write auth/userpass/login/joe password=pass

Answer

vault token create -policy=default

Question 9

A Vault cluster uses Consul for HA. After a brief network partition, a standby node loses contact with the active node. What does the standby node do after a timeout?

Accepted Answer

It seals itself.. In a Vault cluster using Consul for high availability, only the active node serves requests. When a standby node loses contact with the active node due to a network partition, it cannot verify the active node's health or its own leadership status. After a configurable timeout (default 10 seconds), the standby node seals itself to prevent serving stale or inconsistent data, ensuring data integrity and security.

Answer

It becomes the active node.

Answer

It continues to serve requests.

Answer

It replicates data from the storage backend.

Question 10

A large enterprise uses Vault with multiple namespaces for different business units. The security team has implemented a policy that requires all tokens to be created with a bounded set of allowed policies defined in a token role. The token role allows policies 'app-dev', 'app-staging', and 'app-prod' for the development namespace. The token role has token_type set to 'service'. A developer attempts to create a token using this role but specifies an additional policy 'admin' in the creation request. The Vault administrator expects this request to fail because 'admin' is not in the allowed policies list. However, the token is created successfully with only the allowed policies applied. Why did the request succeed?

Accepted Answer

The developer added the 'admin' policy directly to the token role before creating the token.. In Vault, token roles enforce a strict policy: the policies requested during token creation must be a subset of the allowed policies (or match allowed_policies_glob). If a requested policy like 'admin' is not in the allowed list, the request should fail. The only way the developer's request could succeed is if the 'admin' policy was added to the token role's allowed policies before the request was made. Option D correctly identifies this: the developer added the 'admin' policy directly to the token role, making it allowed. Options A and C contradict Vault's known behavior, and option B's glob pattern 'app-*' does not match 'admin'.

Answer

The token role's 'token_type' was set to 'batch', which ignores policy restrictions.

Answer

The token role had 'allowed_policies_glob' set to 'app-*', which matched 'admin' as well.

Answer

Vault ignores the 'allowed_policies' list when the token creation request includes policies, as long as one of the requested policies is in the allowed list.

Question 11

Which THREE of the following are valid parameters when creating a token via the API?

Accepted Answer

num_uses. When creating a token via the Vault API, valid parameters include `num_uses` to set the number of times the token can be used, `ttl` to set the time-to-live, and `policies` to attach policies. `max_ttl` is not a direct input parameter; it is a property that may be inherited from the role or mount configuration. `accessor` is a read-only field returned in the response, not an input parameter.

Answer

accessor

Answer

max_ttl

Question 12

Your company uses Vault to manage secrets for a fleet of microservices running on Kubernetes. Each microservice has a service account that authenticates to Vault using the Kubernetes auth method and receives a token with a policy granting access to its secrets. Recently, the team noticed that some tokens are being revoked prematurely, causing services to lose access to secrets. The tokens are created with a TTL of 24 hours and are set to be renewable. The Vault servers are configured with a default max_ttl of 24 hours. The tokens are renewed by the client libraries every 12 hours. Despite this, tokens are sometimes invalid before 24 hours. What should the team do to prevent this issue?

Accepted Answer

Increase the max_ttl on the token role to 48 hours to allow renewal beyond 24 hours.. The tokens are being revoked prematurely due to the Vault server's default max_ttl of 24 hours. Even though the token TTL is 24 hours and the client renews every 12 hours, the max_ttl caps the total lifetime of the token, including renewals. By increasing the max_ttl on the token role to 48 hours, the token can be renewed beyond the initial 24-hour window, preventing premature invalidation.

Answer

Set the token's num_uses to a high number to prevent premature revocation.

Answer

Change the tokens to periodic tokens so they never expire.

Answer

Decrease the token TTL to 12 hours so that renewal happens before the max_ttl is reached.

Question 13

Which TWO statements correctly describe Vault's encryption as a service using the Transit secrets engine?

Accepted Answer

Data is encrypted and decrypted on the server side without the client having direct access to the encryption key.. The Transit secrets engine in Vault performs encryption and decryption on the server side, meaning the client sends plaintext to Vault and receives ciphertext back without ever having direct access to the underlying encryption key. This is the core of encryption as a service: the key remains securely stored within Vault's barrier, and the client only interacts with the key via API calls, never seeing the key material itself.

Answer

Ciphertext is stored within Vault for later retrieval.

Answer

Encryption always produces a unique ciphertext even with the same plaintext and key.

Answer

Key rotation is not supported; the key version is fixed.

Question 14

Which THREE of the following best practices should be followed when using Vault's encryption as a service with the transit engine?

Accepted Answer

Use a unique encryption key per application. Using a unique encryption key per application ensures cryptographic isolation: if one application's key is compromised, other applications' data remains secure. Vault's transit engine supports this by allowing you to create and manage multiple named keys, each with its own policy and rotation schedule, preventing cross-application data exposure.

Answer

Allow deletion of keys to clean up unused keys

Answer

Store the key name in the application code for easy access

Question 15

What happens when a lease reaches its TTL?

Accepted Answer

The lease is marked as expired and can no longer be renewed.. When a lease reaches its Time-To-Live (TTL), it becomes expired and cannot be renewed. Vault does not automatically delete the lease from storage at the moment of TTL expiry; rather, the lease is marked as expired and is eventually garbage-collected. This cleanup is separate from revocation of the underlying secret, which must be performed explicitly or via a different mechanism.

Answer

The lease is automatically renewed.

Answer

The secret is automatically revoked.

Answer

The lease is deleted from storage.