VA-003 Hard Questions — 25 Difficult Questions

Question 1

A user with this policy wants to delete secrets under the 'team/' path. Which additional capability must be added?

Accepted Answer

delete. The user's policy grants 'create' and 'update' capabilities on 'team/*', but not 'delete'. In Vault's ACL policy system, each operation (create, read, update, delete, list, sudo) must be explicitly allowed. Since 'delete' is missing, the user cannot delete secrets under 'team/'. Adding the 'delete' capability to the policy is required.

Answer

sudo

Answer

list

Answer

patch

Question 2

A user 'john' logs in via the userpass method. The output shows a token with a duration of 768 hours. However, the userpass mount is configured with `token_ttl=24h`. What is the most likely reason for the longer token duration?

Accepted Answer

The user has a custom `ttl` set in the userpass configuration for user 'john'.. The userpass mount allows per-user TTL overrides via the `token_ttl` parameter when creating or updating a user. Even though the mount has a default `token_ttl=24h`, if user 'john' was configured with a specific `token_ttl` of 768 hours, that per-user setting takes precedence over the mount-level default. This is a common way to grant specific users longer token lifetimes without changing the mount's default policy.

Answer

The system backend is configured with a max_ttl that overrides the mount setting.

Answer

The mount token_ttl is only applied if the user does not specify a `token_policies` parameter.

Answer

The token was issued with a periodic token and ignores the TTL.

Question 3

An organization uses Vault with the JWT/OIDC authentication method. After configuring the provider, users can authenticate, but the scopes requested do not include the email claim needed for policy mapping. What should the administrator do?

Accepted Answer

Add the 'email' scope to the OIDC auth method config. The email claim is not included in the JWT because the OIDC provider was not requested to issue it. In OIDC, claims are delivered only when the corresponding scope (e.g., 'email') is included in the authentication request. Adding the 'email' scope to the Vault OIDC auth method configuration ensures the provider returns the email claim, which can then be used for policy mapping.

Answer

Add a policy that uses the email claim

Answer

Modify the OIDC provider's configuration in Vault

Answer

Create a custom claim mapping in the OIDC auth method

Question 4

A company uses AWS IAM auth for EC2 instances. An instance with an IAM role 'app-role' successfully logs in, but another instance with the same IAM role receives a permission denied error when trying to authenticate. The Vault server and AWS account are healthy. What is the most likely cause?

Accepted Answer

The second instance does not have the IAM role attached to its instance profile. The second instance likely does not have the IAM role 'app-role' attached to its instance profile. For Vault's AWS IAM auth method, the EC2 instance must have the IAM role attached to its instance profile at launch time; the Vault server uses the instance's credentials (via the instance metadata service) to verify the role. If the role is not attached, the instance cannot present valid credentials for authentication, resulting in a permission denied error even though the Vault server and AWS account are healthy.

Answer

The Vault server's AWS credentials are expired

Answer

The Vault role for AWS auth is configured with a wrong bound IAM role ARN

Answer

The IAM role's trust policy does not allow Vault to assume the role

Question 5

A company is migrating from on-premises to cloud and needs to authenticate applications using short-lived credentials. They have a mix of workloads: some on AWS EC2, some on Kubernetes, and some in their own datacenter. Which Vault authentication method provides a unified solution that works across all these environments without requiring a shared secret?

Accepted Answer

JWT/OIDC authentication. JWT/OIDC authentication is the correct choice because it provides a unified, standards-based method for verifying identity across AWS EC2, Kubernetes, and on-premises environments without requiring a shared secret. By leveraging OpenID Connect (OIDC) identity tokens issued by trusted providers (e.g., AWS IAM Identity Center, Kubernetes service account token, or an on-premises IdP), Vault can validate the token's signature and claims to authenticate workloads. This eliminates the need for pre-shared secrets or per-environment-specific integrations, making it ideal for heterogeneous deployments.

Answer

AWS IAM authentication

Answer

Kubernetes authentication

Answer

AppRole authentication

Question 6

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 (POST /v1/auth/token/create), the valid parameters include num_uses (A), which sets the maximum number of times the token can be used before it is revoked; ttl (B), which specifies the token's time-to-live as a duration string such as "1h"; and policies (C), which is a list of policies to attach to the token. These three are all accepted fields in the token creation request body and directly control the token's usage limit, lifetime, and authorization scope. In contrast, accessor (D) is a read-only identifier generated by Vault and returned in the token lookup response, not a parameter that can be supplied at creation time. Likewise, max_ttl (E) is not a settable parameter on token creation; the token's maximum lifetime is governed by the system or mount max_ttl, not by a request field.

Answer

accessor

Answer

max_ttl

Question 7

An organization uses the transit engine with key rotation. They want to ensure that data encrypted with an older key version can be decrypted by Vault, but only if the key has not been deleted. Which of the following must be true?

Accepted Answer

The key must not have been archived. In Vault's transit engine, key rotation creates new key versions while preserving older ones. The ability to decrypt data encrypted with an older key version depends on whether that version is still available in the key's version history. Archiving a key removes all versions from the active key ring, making decryption of data encrypted with any version of that key impossible. Therefore, the key must not have been archived to allow decryption of data encrypted with an older key version, provided the key itself has not been deleted.

Answer

The key's `min_decryption_version` must be set to 1

Answer

The key must have the `allow_plaintext_backup` setting enabled

Answer

The key must have a `deletion_allowed` set to false

Answer

The key's `latest_version` must be greater than 0

Question 8

A finance company runs a microservices architecture on Kubernetes. Each microservice has its own service account and uses Kubernetes auth to authenticate to Vault and read secrets. Recently, a new microservice 'payment' was deployed in the 'prod' namespace with service account 'payment-sa'. The team created a Vault role with bound_service_account_names=['payment-sa'] and bound_service_account_namespaces=['prod']. The microservice can authenticate and obtains a token, but when it tries to read the secret at path 'secret/data/payments/db', it gets a permissions error. Other microservices in the same namespace with similar roles work fine. The Vault policy for the role includes read access to 'secret/data/payments/*'. What is the most likely issue and correct action?

Accepted Answer

Update the Vault role to include the policy 'payments-read' in the token_policies parameter.. The Vault role is configured with `token_policies` that grant read access to `secret/data/payments/*`, but the role itself does not include that policy in its `token_policies` parameter. When the microservice authenticates via Kubernetes auth, the token issued by Vault only carries policies explicitly attached to the role. Without the policy being listed in `token_policies`, the token lacks the necessary permissions to read the secret, even though the policy exists. Updating the role to include the policy in `token_policies` resolves the permissions error.

Answer

Increase the TTL of the Vault token to give more time for the secret read.

Answer

Add the microservice's service account to the bound_service_account_names of an existing role that works.

Answer

Change the authentication method to AppRole for the payment microservice.

Question 9

A DevOps engineer configures the AWS secrets engine to assume a specific IAM role for generating dynamic credentials. The engine is enabled and the root configuration is set. Which parameter is essential in the role configuration to allow assuming the IAM role?

Accepted Answer

arn. The `arn` parameter is essential in the role configuration for the AWS secrets engine because it specifies the Amazon Resource Name (ARN) of the IAM role that Vault will assume to generate dynamic credentials. Without this parameter, Vault cannot identify which IAM role to assume via AWS STS AssumeRole API, making dynamic credential generation impossible.

Answer

role_type

Answer

credential_type

Answer

inline_policy

Question 10

An application's token is failing to renew, and the logs show 'token not renewable'. The token was created with a TTL of 24h and no explicit max TTL. What is the most likely cause?

Accepted Answer

The token was created with the renewable flag set to false. The error 'token not renewable' occurs when a token is created with the `renewable` flag explicitly set to `false`. Even though the token has a TTL of 24h and no explicit max TTL, the absence of the renewable flag means the token cannot be renewed at all. Vault tokens are renewable by default, but if the application or operator sets `renewable=false` during creation, the token will expire after its TTL and cannot be extended.

Answer

The token has been renewed too many times, exceeding its TTL

Answer

The token accessor is invalid

Answer

The token's max TTL has been reached

Question 11

A DevOps team uses Vault's transit engine to encrypt secrets in CI/CD pipelines. They report that encryption operations are failing with 'permission denied' errors. The team has a policy granting 'create' and 'update' capabilities on the transit key path. What is the most likely missing capability?

Accepted Answer

The 'encrypt' capability is missing.. The Vault transit engine uses distinct capabilities for key management versus data operations. 'Create' and 'update' allow managing the key itself (e.g., creating or rotating the key), but encryption of data requires the 'encrypt' capability on the transit key path. Without 'encrypt', the API call to encrypt data fails with a 'permission denied' error, even if the key exists and is properly configured.

Answer

The 'read' capability is missing.

Answer

The 'delete' capability is missing.

Answer

The 'list' capability is missing.

Question 12

A security team must automate periodic credential rotation for a database. The rotation script should run on a server that cannot have the Vault binary installed but can make HTTP requests. Which approach should they use?

Accepted Answer

Use the Vault API with proper authentication.. The server can make HTTP requests, allowing it to interact with Vault's RESTful API directly without installing the Vault binary. The Vault API supports token-based authentication (e.g., using X-Vault-Token header) and can be used to programmatically rotate database credentials by calling the appropriate endpoint (e.g., POST /v1/database/rotate-root/:name). This approach satisfies the constraint of no binary installation while enabling secure, automated credential rotation.

Answer

Use the Vault CLI with curl to wrap commands.

Answer

Install Vault binary on the server and use CLI.

Answer

Use Vault Agent to handle rotation.

Question 13

During a security assessment, a penetration tester discovers that Vault's seal configuration uses a single master key stored in a file on the server. The attacker gains root access to the server and retrieves the unseal key. What is the best mitigation to prevent this scenario?

Accepted Answer

Use a cloud auto-unseal mechanism such as AWS KMS. Cloud auto-unseal mechanisms like AWS KMS decouple the unseal key from the Vault server itself. Instead of storing the master key on the local filesystem, Vault uses a cloud-based key management service (KMS) to wrap and unwrap the master key. Even if an attacker gains root access to the server, they cannot retrieve the unseal key because it is never stored locally; Vault must call the KMS API (with appropriate IAM credentials) to unseal, and those credentials can be further protected with instance profiles or roles.

Answer

Restrict network access to the Vault server with a firewall

Answer

Use Shamir's secret sharing to split the key across multiple files

Answer

Encrypt the unseal key file with a strong password

Question 14

An administrator wants to ensure that a token created by a user cannot be used after 24 hours, even if the user tries to renew it. What should the administrator do?

Accepted Answer

Set explicit max TTL on the token to 24h. Setting an explicit max TTL on the token to 24h ensures that the token's lifetime cannot be extended beyond 24 hours, even if the user attempts to renew it. In Vault, the `explicit_max_ttl` parameter overrides any renewal requests, enforcing a hard upper limit on the token's validity. This directly addresses the requirement that the token cannot be used after 24 hours, regardless of renewal attempts.

Answer

Use a periodic token with a period of 24h

Answer

Create an orphan token with a TTL of 24h

Answer

Use a batch token

Question 15

An administrator configures AppRole with a RoleID and SecretID. They want to ensure that each SecretID can be used only once. Which configuration should they use?

Accepted Answer

Set secret_id_num_uses=1 in the role.. Setting `secret_id_num_uses=1` in the AppRole role configuration ensures that each SecretID can be used only once to obtain a token. Once the SecretID is used for login, it is automatically revoked and cannot be reused. This directly satisfies the requirement of single-use SecretIDs.

Answer

Set token_num_uses=1 in the role.

Answer

Set bound_cidr_list to a specific IP.

Answer

Set secret_id_ttl=1s in the role.

Question 16

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 17

Refer to the exhibit. A Vault policy is defined as shown. A user presents a token with this policy. Which operation will be permitted?

Accepted Answer

Create secret/data/engineering/config. The policy grants `create` and `update` capabilities on `secret/data/engineering/*`, which allows creating secrets under that path. Option C is correct because the `create` capability permits writing a new secret at `secret/data/engineering/config`, as the path matches the glob pattern and the operation is a write (POST/PUT).

Answer

List secret/data/finance

Answer

Delete secret/data/finance/budget

Answer

Read secret/data/finance

Question 18

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 19

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 20

An administrator runs the commands shown in the exhibit. Later, they run 'vault kv delete kv-v2/secret' and then 'vault kv undelete -versions=1 kv-v2/secret' to recover the secret. Which command must the administrator run to verify that the secret is now readable?

Accepted Answer

vault kv get kv-v2/secret. 'vault kv get' is the standard command to read and display the latest version of a secret from a KV v2 secrets engine. After running 'vault kv undelete -versions=1', version 1 is restored from a deleted state, and 'vault kv get kv-v2/secret' will retrieve and show that version's data, confirming it is readable.

Answer

vault kv list kv-v2/secret

Answer

vault read kv-v2/data/secret

Answer

vault kv metadata get kv-v2/secret