VA-003 Practice Test 29 — 15 Questions

Question 1

A company runs Vault in a single cluster with three nodes using the Raft storage backend. The nodes are behind a load balancer that distributes traffic to all nodes. The operations team notices that occasionally, write operations (e.g., writing a secret or creating a policy) fail with a '502 Bad Gateway' error, while read operations succeed. The Vault audit logs show no errors. The load balancer health checks are configured to check the /v1/sys/health endpoint with a 200 response expected. The Vault nodes are all unsealed and the cluster is healthy. Which of the following is the most likely cause of the intermittent write failures?

Accepted Answer

The load balancer is sending write requests to standby nodes, which cannot handle writes.. In a Vault cluster with Raft storage, only the elected leader node can handle write operations (e.g., writing secrets, creating policies). Standby nodes serve read requests and forward writes to the leader. If the load balancer distributes traffic to all nodes without considering leadership, write requests sent to a standby node will fail with a 502 Bad Gateway error because the standby cannot process the write locally and the load balancer may not properly handle the forwarded response or timeout.

Answer

The Raft storage backend does not support write operations.

Answer

The load balancer is not configured to use the /v1/sys/leader endpoint for routing.

Answer

One of the Vault nodes is sealed, causing write requests to fail.

Question 2

A DevOps team is managing secrets for a microservices application using Vault. They have created a policy named 'app-policy' that grants read access to secrets under the path 'secret/data/app/*'. The policy is assigned to an AppRole role. When a service authenticates with the role ID and secret ID, it receives a token but is unable to read secrets from 'secret/data/app/db-creds'. The token's identity metadata shows the policies associated with the token include 'default' and 'app-policy'. The Vault server logs show no errors. The service can successfully read other secrets from the same path, like 'secret/data/app/config'. What is the most likely cause of the issue?

Accepted Answer

The secret 'secret/data/app/db-creds' does not exist in Vault.. Option A is correct because the most likely cause is that the secret 'secret/data/app/db-creds' does not exist in Vault. The token has the 'app-policy' policy attached, which grants read access to 'secret/data/app/*', and the service can successfully read other secrets under that path (e.g., 'secret/data/app/config'). The absence of Vault server errors indicates that the policy is correctly evaluated and the path is valid, but a read on a non-existent secret returns a 404 (or a permission-denied-like response) without logging an error. The token's metadata confirms the policy is present, ruling out policy assignment issues.

Answer

The token does not have the 'app-policy' policy attached due to a misconfiguration in the role.

Answer

There is an explicit deny rule in the policy that denies access to 'db-creds'.

Answer

The token is periodic and does not have the correct capabilities for the path.

Question 3

A DevOps engineer is tasked with automating the rotation of a static secret stored in Vault's KV secrets engine (version 2). The secret is currently stored at path 'secret/data/app/config' with keys 'username' and 'password'. The engineer wants to update the 'password' key using the Vault CLI from a CI/CD pipeline. The pipeline uses a token with a policy that grants 'create', 'update', and 'read' capabilities on 'secret/data/app/*'. Which CLI command should the engineer use to update only the 'password' key, leaving other keys unchanged?

Accepted Answer

vault kv patch secret/data/app/config password=newpass. Option C is correct because `vault kv patch` is specifically designed for KV v2 secrets engines to update individual keys without overwriting other keys. It performs a read-modify-write operation under the hood, sending a PATCH request to the API, which only modifies the specified fields. The policy grants 'create', 'update', and 'read' on 'secret/data/app/*', which aligns with the required capabilities for patching.

Answer

vault kv put secret/data/app/config password=newpass

Answer

vault update secret/data/app/config password=newpass

Answer

vault write secret/data/app/config password=newpass

Question 4

A security team wants to allow applications to authenticate to Vault without storing any secrets in configuration files. The applications run on AWS EC2 instances with an IAM role attached. Which Vault authentication method leverages the EC2 instance metadata to obtain credentials?

Accepted Answer

AWS IAM authentication. AWS IAM authentication (option D) is correct because it allows applications running on EC2 instances with an attached IAM role to authenticate to Vault without storing any secrets. The Vault client uses the EC2 instance metadata service (IMDS) to retrieve the instance identity document and its signature, which are then presented to Vault. Vault verifies these credentials against the AWS API, confirming the instance's identity and IAM role, thereby enabling secure, secretless authentication.

Answer

GCP IAM authentication

Answer

Userpass authentication

Answer

AppRole authentication

Question 5

An organization uses Vault with LDAP authentication. Users report they are unable to log in, and the administrator sees errors like 'LDAP bind failed: invalid credentials' in the Vault logs. The LDAP server is reachable. What is the most likely cause?

Accepted Answer

The binddn or bindpass configured in Vault is incorrect. The error 'LDAP bind failed: invalid credentials' specifically indicates that the authentication attempt to the LDAP server using the configured binddn and bindpass failed. Since the LDAP server is reachable, the most direct cause is that the bind credentials stored in Vault's LDAP configuration do not match what the LDAP server expects. This is a configuration mismatch, not a connectivity or TLS issue.

Answer

Vault is not configured to use SSL/TLS for LDAP

Answer

The LDAP server does not allow anonymous binds

Answer

The LDAP server certificate is not trusted by Vault

Question 6

A DevOps team wants to automate authentication to Vault for Jenkins jobs running on AWS EC2 instances. Which authentication method is most appropriate and secure for this use case without storing long-lived credentials?

Accepted Answer

AWS IAM auth. AWS IAM auth is the most appropriate and secure method because it allows Jenkins jobs running on EC2 instances to authenticate to Vault using the instance's AWS IAM role without storing any long-lived credentials. The EC2 instance obtains temporary AWS credentials via the instance metadata service (IMDS), and Vault validates these against AWS STS to issue a short-lived Vault token. This eliminates the need to manage static secrets or tokens in Jenkins job configurations.

Answer

GitHub personal access token

Answer

AppRole

Answer

Username & password (userpass)

Question 7

A development team wants to authenticate to Vault using a method that does not require storing secrets in source code and supports automatic rotation of credentials. Which authentication method best meets these requirements?

Accepted Answer

AWS IAM authentication. AWS IAM authentication allows Vault to authenticate using AWS IAM credentials (access key/secret key or instance metadata) without storing any secrets in source code. It supports automatic credential rotation by leveraging AWS IAM roles and STS to generate temporary credentials, which Vault can validate via the AWS API. This eliminates the need for long-lived secrets in code and enables seamless rotation.

Answer

Token authentication

Answer

LDAP authentication

Answer

Userpass authentication

Question 8

A company has a Vault cluster and wants to allow applications running in Kubernetes pods to authenticate without storing static secrets. Which Vault authentication method is specifically designed for Kubernetes?

Accepted Answer

Kubernetes. The Kubernetes auth method is specifically designed for Kubernetes workloads. It allows pods to authenticate to Vault using their Kubernetes service account token, which Vault validates against the Kubernetes API server. This eliminates the need to store static secrets in the cluster.

Answer

AWS IAM

Answer

JWT/OIDC

Answer

AppRole

Question 9

An organization uses AppRole with secret_id generation via the Vault API. Security policy requires that each secret_id can be used only once and must expire after 1 hour. Which configuration option should be set on the AppRole role to enforce this?

Accepted Answer

secret_id_num_uses=1, secret_id_ttl=1h. Option B is correct because the security policy requires both single-use (secret_id_num_uses=1) and a 1-hour expiration (secret_id_ttl=1h). In Vault's AppRole authentication, secret_id_num_uses controls how many times a secret_id can be used, and secret_id_ttl sets the time-to-live. Setting both ensures the secret_id is invalidated after one use or after one hour, whichever comes first, meeting the policy exactly.

Answer

secret_id_num_uses=1

Answer

secret_id_ttl=1h

Answer

secret_id_num_uses=1, secret_id_ttl=60m

Question 10

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 11

A CI/CD pipeline runs in a Kubernetes cluster and needs to authenticate to Vault to fetch secrets. The pipeline should not have to manage any long-lived credentials. Which authentication method is most suitable?

Accepted Answer

Kubernetes authentication. The Kubernetes authentication method allows the CI/CD pipeline to authenticate to Vault using its Kubernetes service account token, which is automatically mounted into the pod. This eliminates the need for managing long-lived credentials because Vault verifies the token against the Kubernetes API server and issues a short-lived Vault token in return.

Answer

Token authentication

Answer

LDAP authentication

Answer

AWS IAM authentication

Question 12

Which authentication method in Vault uses a shared secret (Role ID) and a dynamic secret (Secret ID) to authenticate machines or applications?

Accepted Answer

AppRole. AppRole is the correct authentication method because it is specifically designed for machine-to-machine or application-to-application authentication in Vault. It uses a static Role ID (like a username) combined with a dynamically generated Secret ID (like a password) that can be created, revoked, or have a time-to-live, providing a secure and flexible way for non-human entities to obtain a Vault token.

Answer

LDAP

Answer

Username & password (userpass)

Answer

Okta

Question 13

A Vault administrator runs `vault auth list` and sees the output above. The administrator wants to disable the default token authentication method to improve security. Which command should they run?

Accepted Answer

vault auth disable token/. The `vault auth list` output shows that the default token authentication method is enabled at the `token/` path. To disable it, the administrator must run `vault auth disable token/`, which removes the token auth method entirely. This improves security by preventing unauthenticated users from using the default token login endpoint, forcing the use of other configured auth methods like LDAP or AppRole.

Answer

vault auth disable userpass/

Answer

vault auth disable ldap/

Answer

vault auth disable approle/

Question 14

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'.. Option B is correct because 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 15

An organization previously used userpass auth and is migrating to LDAP auth. After enabling LDAP and configuring the bind user, users can authenticate but their policies do not apply. What is the most likely cause?

Accepted Answer

LDAP groups are not mapped to Vault policies. When users can authenticate but policies do not apply, it indicates that authentication itself is working (LDAP bind succeeded), but Vault has no way to associate the authenticated user with the correct policies. In Vault, LDAP authentication relies on group membership mapping: the LDAP server returns the user's groups, and Vault must have those groups mapped to Vault policies via `vault write auth/ldap/groups/ policies=`. Without this mapping, the user authenticates but receives no policies, resulting in an empty token with no permissions.

Answer

The bind credentials are incorrect

Answer

The userpass auth method is still enabled

Answer

The LDAP server is unreachable