VA-003 Practice Test 15 — 15 Questions

Question 1

A user attempts to read a secret at path 'secret/data/app' and receives a 403 Forbidden error. What is the most likely cause?

Accepted Answer

The token's policy does not grant read capability on that path. A 403 Forbidden error in Vault indicates that the token used for the request is valid and the path exists, but the token's attached policy does not grant the required 'read' capability on that specific path. This is a policy enforcement action by Vault's ACL system, which explicitly denies access when the policy lacks a matching 'read' rule for the path.

Answer

The secret engine is not mounted at 'secret/'

Answer

The secret key does not exist

Answer

The token has expired

Question 2

A security team wants to ensure that database credentials generated by Vault are never renewed and have a fixed lifespan of 30 minutes. They configure the role with default_ttl=30m and max_ttl=30m, and set renewable=false. However, they find that some users are able to renew the leases anyway. What could be the reason?

Accepted Answer

The renewable flag requires the role to be updated after existing leases are issued.. The `renewable=false` setting on a Vault role only affects newly issued leases; it does not retroactively apply to leases that were already issued before the role was updated. Since the security team configured the role after some users had already obtained credentials, those existing leases retain their original `renewable=true` property, allowing users to renew them despite the new role setting. Vault enforces the `renewable` flag at lease creation time, not dynamically during renewal requests.

Answer

The renewable flag is not respected when max_ttl equals default_ttl.

Answer

The renewable flag is only applicable to token auth methods, not secrets engines.

Answer

The lease's renewable property is controlled by the client token's renewable status.

Question 3

An administrator wants to audit token usage without exposing the actual token IDs to auditors. Which approach should they use?

Accepted Answer

Use token accessors in audit logs. Token accessors are non-sensitive, randomly generated identifiers that are mapped one-to-one with actual Vault tokens. By logging the accessor instead of the token ID, administrators can audit token usage (e.g., lookup, renewal, revocation) without exposing the token itself, which could be used to authenticate. This approach satisfies the requirement of auditing without compromising security.

Answer

Enable audit logging without any modifications

Answer

Use the token lookup API for each audit event

Answer

Use response wrapping to encapsulate tokens

Question 4

Match each Vault policy capability to its permission.

Accepted Answer

create: Allows creating data at the path.. The correct matches are: create allows creating data, read allows reading data, update allows updating data, and delete allows deleting data. Common confusions involve swapping create and read capabilities.

Answer

create: Allows reading data at the path.

Answer

read: Allows creating data at the path.

Question 5

An application needs to obtain short-lived, time-limited credentials to access an external database using username/password authentication. Which secrets engine should be used?

Accepted Answer

Database secrets engine. The Database secrets engine is designed specifically to generate short-lived, dynamic credentials for databases, including external databases accessed via username/password authentication. It creates unique, time-limited usernames and passwords on-the-fly, which are automatically revoked after a configurable TTL, meeting the requirement for temporary credentials.

Answer

KV v2 secrets engine

Answer

Consul secrets engine

Answer

Identity secrets engine

Question 6

A DevOps team wants to authenticate to Vault using short-lived tokens without storing a secret in their CI/CD pipeline. Which authentication method best meets this requirement?

Accepted Answer

JWT/OIDC. JWT/OIDC authentication allows a DevOps pipeline to exchange a signed JSON Web Token (JWT) from an external identity provider (e.g., GitHub Actions, GitLab CI) for a short-lived Vault token. This eliminates the need to store a long-lived secret in the CI/CD pipeline because the JWT is dynamically generated by the CI platform and validated by Vault using the OIDC provider's public keys. The resulting Vault token has a configurable TTL, typically minutes, aligning with the requirement for short-lived credentials.

Answer

AWS IAM

Answer

AppRole

Answer

Username & Password

Question 7

During an audit, it is discovered that a single AppRole role is used by hundreds of applications, and it is impossible to revoke access for a single compromised application without affecting others. What should be done to improve the security posture?

Accepted Answer

Create a unique AppRole role for each application. Creating a unique AppRole role for each application ensures that each application has its own set of credentials (RoleID and SecretID). This allows you to revoke access for a single compromised application by deleting or disabling its specific AppRole role, without impacting other applications. This directly addresses the core issue of shared credentials and provides granular access control.

Answer

Schedule periodic secret ID rotation

Answer

Reduce the token TTL to 1 minute

Answer

Add CIDR bindings to the AppRole role

Question 8

A company uses OIDC auth for human users. After the OIDC provider rotates its signing keys, some users report that they cannot authenticate. The Vault logs show that the OIDC response validation fails. What is the most likely cause?

Accepted Answer

Vault's OIDC cache has old JWKS keys. When an OIDC provider rotates its signing keys, Vault must fetch the new JWKS (JSON Web Key Set) to validate the token signature. Vault caches the JWKS for performance, and if the cache still holds the old keys, signature validation fails for tokens signed with the new key. This matches the symptom of OIDC response validation failing immediately after a key rotation.

Answer

The OIDC role is misconfigured

Answer

The client's OIDC token is expired

Answer

The OIDC provider is down

Question 9

Drag and drop the steps to set up Vault's Kubernetes auth method into the correct order.

Accepted Answer

Enable the Kubernetes auth method, then configure it with the Kubernetes host and CA cert, then create a role that binds a service account, then deploy a pod using that service account, then verify login using the Vault token.. The correct sequence for setting up Vault's Kubernetes auth method is: enable the auth method, configure it with the Kubernetes API server details, create a role that binds to a service account, deploy a pod using that service account, and finally verify login. This order ensures that each prerequisite is fulfilled before the subsequent step can function correctly.

Answer

Configure the Kubernetes auth method with host and CA cert, then enable it, then create a role, then deploy a pod, then verify login.

Answer

Enable the Kubernetes auth method, then create a role, then configure the auth method, then deploy a pod, then verify login.

Answer

Enable the Kubernetes auth method, then configure it, then deploy a pod, then create a role, then verify login.

Question 10

An application uses a Vault token with a policy that grants read access to secrets. The security team wants to ensure that if the application is compromised, the token cannot be used after a certain time even if the attacker has the token. What is the best approach?

Accepted Answer

Set a short TTL on the token and do not allow renewal. Setting a short TTL on the token and disallowing renewal ensures that the token automatically expires after a fixed, short duration. Even if an attacker compromises the token, they cannot extend its lifetime, limiting the window of exposure. This directly meets the security requirement of preventing token use beyond a certain time without relying on external revocation mechanisms.

Answer

Use a revocation script that runs periodically

Answer

Set explicit max TTL on the token

Answer

Use a periodic token with a long period

Question 11

Refer to the exhibit. A user deletes the current version of 'secret/myapp' using 'vault kv delete secret/myapp'. What happens to the version?

Accepted Answer

It is deleted and can be undeleted if not destroyed. With default delete_version_after=0s and max_versions=0, deleting a version marks it as deleted but does not destroy it. The version can be undeleted. The cas_required setting affects write operations, not delete. Permanent destruction requires a separate 'destroy' command or automatic cleanup if delete_version_after is set.

Answer

It is destroyed because cas_required is true

Answer

It is permanently deleted immediately

Answer

It is marked as deleted but can be undeleted because cas_required is true

Question 12

A Vault administrator wants to configure a role for dynamic secrets with a default TTL of 1 hour and a max TTL of 4 hours. They also want to allow renewal but only up to the max TTL. Which configuration achieves this?

Accepted Answer

default_ttl=1h, max_ttl=4h, renewable=true. It sets the default TTL to 1 hour, the maximum TTL to 4 hours, and enables renewal (renewable=true). In Vault, dynamic secret leases can be renewed up to the max_ttl, so with this configuration the initial lease is 1 hour, and each renewal extends the lease until the total lifetime reaches 4 hours, after which no further renewals are allowed.

Answer

default_ttl=1h, max_ttl=4h, renewable=false

Answer

default_ttl=4h, max_ttl=1h, renewable=true

Answer

default_ttl=1h, max_ttl=4h, renewable=true, ttl=1h

Question 13

A team is adopting Vault and wants to organize secrets by application and environment (e.g., production, staging). What is the best practice for secrets engine path naming?

Accepted Answer

Use hierarchical paths like 'app/env/secret'. Hierarchical paths like 'app/env/secret' are the best practice because they allow Vault's ACL policies to apply fine-grained access control at each level of the path. This structure maps directly to the organization's application and environment boundaries, enabling least-privilege access without complex policy rules. It also simplifies secret rotation and auditing by keeping related secrets logically grouped.

Answer

Use a single path like 'secrets/' for simplicity

Answer

Use the same path for all applications but separate with prefixes like 'app1-'

Answer

Use random UUIDs to avoid guessing

Question 14

An organization uses the Transit secrets engine to encrypt sensitive files. They want to rotate the encryption key regularly without re-encrypting all existing files. Which feature allows this?

Accepted Answer

Key versioning. The Transit secrets engine in Vault supports key versioning, which allows you to rotate the encryption key by creating a new version while keeping older versions available for decryption of existing ciphertext. This means you can regularly rotate the key without needing to re-encrypt all previously encrypted files, as each ciphertext is tagged with the key version used to encrypt it.

Answer

Key derivation

Answer

Key ttl

Answer

Convergent encryption

Question 15

An administrator wants to retrieve the value of a secret stored at the path 'kv/secret/mykey' using the Vault CLI. Which command should they use?

Accepted Answer

vault read kv/secret/mykey. The correct command to retrieve a secret from Vault's KV secrets engine is `vault read`. This command is used to read data and metadata from a specified path. Option D is correct because `vault read kv/secret/mykey` will retrieve the value stored at that path, assuming the KV engine is mounted at `kv/`.

Answer

vault get kv/secret/mykey

Answer

vault retrieve kv/secret/mykey

Answer

vault show kv/secret/mykey