VA-003 Practice Test 13 — 15 Questions

Question 1

A developer wants to encrypt a string "hello" using Vault's transit engine. What must they send in the API request?

Accepted Answer

The plaintext "hello" as a base64 encoded string. E is correct because Vault's transit engine requires plaintext to be base64-encoded before encryption. The API endpoint expects the plaintext as a base64-encoded string in the `plaintext` field of the request body. This ensures binary-safe transmission and consistent encoding across different systems.

Answer

The ciphertext of "hello"

Answer

Both the key name and the ciphertext

Answer

A reference to the key

Answer

The plaintext "hello" in raw bytes

Question 2

Which THREE are valid operations in the Vault transit secrets engine? (Choose three.)

Accepted Answer

rewrap. The Vault transit secrets engine is a cryptographic service that performs encryption/decryption operations on data in transit without storing the data itself, so option E (encrypt) is valid because it lets clients submit plaintext and receive ciphertext using a named encryption key, and option D (decrypt) is valid because it reverses that operation to recover plaintext from ciphertext. Option C (rewrap) is also valid: it decrypts ciphertext with an older key version and re-encrypts it with the latest key version in a single operation, which is useful for key rotation without exposing plaintext to the client. Options A (issue) and B (revoke) are not transit operations; issuing and revoking credentials are functions of secrets engines such as PKI (issue/revoke certificates) or the various dynamic secrets engines (e.g., database, AWS), not the transit engine, whose API endpoints are encrypt, decrypt, rewrap, datakey, hmac, sign, verify, and related key-management paths.

Answer

issue

Answer

revoke

Question 3

An application needs to read a secret using the Vault API after authenticating with an AppRole RoleID and SecretID. The application has already obtained a Vault token. Which API endpoint should be called to read a secret at 'secret/data/myapp' with the token?

Accepted Answer

GET /v1/secret/data/myapp. After authentication, the application already has a Vault token and needs to read a secret from the KV v2 secrets engine. The correct API endpoint for reading a secret from the KV v2 engine is GET /v1/secret/data/myapp, where 'secret' is the mount path and 'data' is the sub-path for KV v2 operations. The token is passed in the X-Vault-Token header, not in the URL.

Answer

GET /v1/secret/metadata/myapp

Answer

POST /v1/auth/approle/login

Answer

GET /v1/secret/myapp

Question 4

A development team wants to encrypt sensitive data before storing it in a database. They don't want to manage encryption keys themselves. Which secrets engine should they use?

Accepted Answer

Transit. The Transit secrets engine is designed to encrypt data in transit or at rest without exposing the encryption keys to the client. It performs cryptographic operations (encrypt/decrypt) on data sent to Vault, so the development team never manages or stores the keys themselves. This matches the requirement to avoid key management while encrypting sensitive data before database storage.

Answer

PKI

Answer

AWS

Answer

KV v2

Question 5

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.

Question 6

A Vault operator runs 'vault token lookup s.abc123' and sees that the token type is 'service', renewable is true, but the ttl is 30m and creation_ttl is 1h. The token has num_uses set to 0. What is the most likely explanation for the discrepancy between ttl and creation_ttl?

Accepted Answer

30 minutes have elapsed since the token was created. The token's current TTL (30m) is shorter than its creation_ttl (1h) because 30 minutes have already elapsed since the token was issued. The TTL dynamically decreases as time passes, while creation_ttl remains fixed at the original value set at token creation. This is normal behavior for a renewable service token with num_uses=0.

Answer

The token has renewable set to false

Answer

The token type is service, so it cannot be renewed

Answer

The token has been used and num_uses decremented

Question 7

A policy must allow a user to revoke their own token. Which endpoint and capability are required?

Accepted Answer

path "auth/token/revoke-self" { capabilities = ["update"] }. To allow a user to revoke their own token, the policy must grant the 'update' capability on the 'auth/token/revoke-self' endpoint. Vault's token revocation for self uses the update capability on that specific path, not write or the general revoke endpoint.

Answer

path "auth/token/revoke" { capabilities = ["update"] }

Answer

path "auth/token/revoke-self" { capabilities = ["write"] }

Answer

path "sys/leases/revoke" { capabilities = ["update"] }

Question 8

Refer to the exhibit. A user with this policy tries to write a new secret to "secret/data/production/db". What will happen?

Accepted Answer

The write fails because the policy only allows read on production.. The policy only grants 'read' capability on the 'secret/data/production/*' path, which allows reading secrets but not creating or updating them. Writing a new secret requires 'create' or 'update' capabilities (or 'write' which encompasses both). Since the policy lacks these capabilities, the write operation fails regardless of whether the secret already exists.

Answer

The write succeeds if the secret already exists.

Answer

The write succeeds because the path matches.

Answer

The write fails because the user does not have list capability.

Question 9

Which TWO authentication methods are designed for human users? (Choose two.)

Accepted Answer

OIDC. OIDC (Option D) is correct because it is an authentication method built for human users, allowing them to authenticate through an external OpenID Connect identity provider (e.g., Okta, Microsoft Entra ID, Google) using browser-based SSO flows rather than static secrets. Userpass (Option E) is also correct because it is Vault's native username-and-password method intended for interactive human logins, where credentials are stored as password hashes and can be rotated by the user. By contrast, AWS (Option A) is a machine-oriented method that authenticates workloads using AWS IAM credentials or instance metadata, not people. Kubernetes (Option B) is likewise designed for pods and service accounts to authenticate via Kubernetes ServiceAccount tokens, not human users. AppRole (Option C) is a machine-to-machine method that issues RoleID and SecretID credentials for automated applications, so it is not intended for human authentication.

Answer

AWS

Answer

Kubernetes

Answer

AppRole

Question 10

A developer wants to encrypt a password before storing it in a database. The encryption must be deterministic so that the same plaintext always produces the same ciphertext. Which encryption mode should be used in the transit secrets engine?

Accepted Answer

convergent-encryption. The transit secrets engine in Vault supports convergent encryption, which is a deterministic encryption mode where the same plaintext and context always produce the same ciphertext. This is achieved by using the plaintext itself as part of the encryption key derivation, ensuring repeatable output. The question specifically requires deterministic encryption, making convergent encryption the correct choice.

Answer

chacha20-poly1305

Answer

aes128-gcm96

Answer

aes-gcm

Answer

padding

Question 11

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. Option A is correct because `vault login -method=userpass username=joe password=pass` invokes the userpass auth method's login endpoint and returns a Vault token, allowing CLI authentication without supplying an existing token. Option B is correct because `vault login -method=ldap username=joe password=pass` performs the same token-issuing login flow against the LDAP auth method, which is a valid non-token authentication path. Option C is not valid because `vault auth` is used to enable, disable, and tune auth methods, not to log in and obtain a token. Option D is not the documented CLI login workflow; while it resembles a raw API write to the userpass login path, the CLI's supported non-token login mechanism is `vault login -method=...`. Option E is incorrect because `vault token create` requires an existing token with sufficient permissions and creates a new token rather than authenticating without one.

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 12

Refer to the exhibit. A user with this policy attempts to read the secret at path "secret/data/team-a/admin". What will happen?

Accepted Answer

The read is denied because the deny policy takes precedence.. The deny policy takes precedence over any allow policy in Vault, regardless of the path specificity. Even though the first path grants read access to 'secret/data/team-a/*', the second path explicitly denies all capabilities (including read) on 'secret/data/team-a/admin', which is a more specific path. Vault's policy evaluation uses a deny-overrides model, so the deny action blocks the read operation.

Answer

The read fails because the path does not exist.

Answer

The read succeeds because the first path grants read.

Answer

The read succeeds because deny only applies to write operations.

Question 13

A token with a policy that explicitly denies 'read' on 'secret/engineering/private' is issued. The same token also has another policy that grants 'read' on 'secret/engineering/*'. What is the result when the token tries to read 'secret/engineering/private'?

Accepted Answer

The read fails because the explicit deny on the specific path takes precedence. D is correct because Vault's policy evaluation uses a deny-overrides model: any explicit deny on a specific path takes precedence over any allow, even if the allow is more permissive or from a wildcard. The explicit deny on 'secret/engineering/private' blocks the read, regardless of the broader grant on 'secret/engineering/*'.

Answer

The read succeeds because the grant from the wildcard policy is more permissive

Answer

The read fails because the policies conflict and Vault defaults to deny

Answer

The read succeeds because the token has a separate policy that grants read

Question 14

An administrator enables the database secrets engine for PostgreSQL. After configuring the connection, running `vault write database/config/someconfig` yields error: 'x509: certificate signed by unknown authority'. What is the most likely cause?

Accepted Answer

The PostgreSQL server's TLS certificate is not trusted by Vault's CA bundle. The error 'x509: certificate signed by unknown authority' indicates that Vault, when connecting to the PostgreSQL database, received a TLS certificate from the server that was not signed by any Certificate Authority (CA) present in Vault's trusted CA bundle. Vault uses its system's CA pool or a custom CA bundle configured in the connection string to verify the database server's certificate. If the PostgreSQL server uses a self-signed certificate or one issued by an internal CA not trusted by Vault, this error occurs. Option B correctly identifies that the PostgreSQL server's TLS certificate is not trusted by Vault's CA bundle.

Answer

The connection string is incorrect

Answer

The database engine is not enabled

Answer

The Vault server's TLS certificate is self-signed

Question 15

A team has set up automatic key rotation on a transit key. After rotation, encrypted data that was encrypted with the previous key version can no longer be decrypted. What is the most likely cause?

Accepted Answer

The key's min_decryption_version is set too high. The `min_decryption_version` setting on a transit key in Vault's transit secrets engine controls the minimum key version that can be used to decrypt ciphertext. If this value is set too high (e.g., to the current version), older key versions are effectively disabled for decryption, causing any data encrypted with a previous key version to become undecryptable. This is a common misconfiguration when automating key rotation without properly managing version policies in Vault.

Answer

The key was deleted

Answer

The key's min_encryption_version is set too high

Answer

The team used the 'rewrap' operation incorrectly

Answer

The key is not exportable