VA-003 Practice Test 9 — 10 Questions

Question 1

Drag and drop the steps to configure Vault's audit logging to a file into the correct order.

Accepted Answer

Enable audit device, then perform operations to generate log entries, then verify the audit log.. The correct sequence for configuring Vault's audit logging to a file is: first enable the audit device (e.g., 'vault audit enable file file_path=...'), then perform operations (e.g., read/write secrets) to generate audit log entries, and finally verify the log file to confirm entries are being recorded. Common mistakes include enabling after generating logs, verifying too early, or skipping the generation step.

Answer

Perform operations to generate log entries, then enable audit device, then verify the audit log.

Answer

Verify audit log, then enable audit device, then perform operations to generate log entries.

Answer

Enable audit device, then verify the audit log, then perform operations to generate log entries.

Question 2

Which TWO authentication methods support multi-factor authentication (MFA) natively within Vault Enterprise?

Accepted Answer

Userpass authentication. Userpass authentication in Vault Enterprise supports MFA natively because it can be configured with a second factor such as TOTP, Duo, or Okta directly within the auth method's configuration. This allows the userpass method to enforce both a password and an additional authentication factor without requiring an external identity provider or custom wrapper.

Answer

AWS IAM authentication

Answer

Token authentication

Answer

Kubernetes authentication

Question 3

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 4

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 5

A multi-national company uses Vault's AWS secrets engine to manage access to multiple AWS accounts. They have a central Vault cluster and need to generate IAM users in account A that assume a role in account B for cross-account access. The team has configured the AWS secrets engine with the root credentials of account A. They created a role on the engine that should generate STS credentials for the cross-account role. However, when they try to generate credentials, Vault returns an error: 'AccessDenied: User: arn:aws:iam:::user/vault-user is not authorized to perform: STS:AssumeRole on resource: arn:aws:iam:::role/CrossAccountRole'. What additional configuration is required?

Accepted Answer

Attach an IAM policy to the Vault user in account A that allows sts:AssumeRole on the cross-account role ARN.. The error indicates that the Vault user in account A lacks the IAM permission to call sts:AssumeRole on the cross-account role in account B. Even though the AWS secrets engine is configured with root credentials of account A, the engine uses those credentials to make API calls on behalf of the Vault user. Therefore, you must attach an IAM policy to the Vault user in account A that explicitly allows sts:AssumeRole on the target role ARN in account B. This is a prerequisite for cross-account access via STS.

Answer

Create a new role in the AWS secrets engine that uses the cross-account role ARN directly.

Answer

Change the AWS secrets engine mount path to avoid conflicts.

Answer

Set up AWS federation with SAML to allow cross-account access.

Question 6

A DevOps team wants to authenticate a CI/CD pipeline running on a Jenkins server outside Kubernetes. The pipeline needs to obtain short-lived tokens to read secrets. Which authentication method should be used?

Accepted Answer

AppRole auth. AppRole auth is designed for machine-to-machine authentication, allowing Jenkins (outside Kubernetes) to obtain short-lived tokens by providing a RoleID and SecretID. This method supports automated workflows without human intervention, making it ideal for CI/CD pipelines that need to read secrets from Vault.

Answer

LDAP auth

Answer

Kubernetes auth

Answer

GitHub auth

Question 7

An administrator wants to allow human users to authenticate using their corporate Active Directory credentials. Which authentication method should they enable?

Accepted Answer

LDAP auth. LDAP (Lightweight Directory Access Protocol) authentication allows integration with corporate Active Directory by binding to the directory service using a user's credentials. This enables centralized authentication against existing AD user objects without duplicating accounts in the Vault system.

Answer

Token auth

Answer

GitHub auth

Answer

Userpass auth

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

What is the purpose of the `storage` stanza in a Vault server configuration file?

Accepted Answer

Defines where Vault stores encrypted data.. The `storage` stanza in a Vault server configuration file defines the backend where Vault stores all encrypted data, including secrets, tokens, and metadata. This backend can be a file system, Consul, Raft, or other supported storage backends, and it is the persistent layer that holds the encrypted data after it has been processed by the seal mechanism. Without a properly configured `storage` stanza, Vault cannot persist any data and will fail to start.

Answer

Defines the encryption algorithm for secrets.

Answer

Defines the seal mechanism.

Answer

Defines the listener address.

Question 10

A security auditor requires that all encryption keys used to protect customer data must be periodically rotated according to company policy. The company uses Vault's Transit secrets engine. What is the recommended approach to rotate the encryption key?

Accepted Answer

Use the `vault write -f transit/keys/my-key/rotate` command to rotate the key. The Vault Transit secrets engine provides a dedicated `rotate` endpoint that creates a new encryption key version while keeping the previous version available for decryption of existing ciphertext. This allows the key to be rotated without re-encrypting all data, and the new key version is automatically used for future encryption operations. The `-f` flag forces the rotation without requiring interactive confirmation.

Answer

Use Vault's key rotation endpoint to rewrap the key

Answer

Delete the existing key and create a new one with the same name

Answer

Generate a new key with a different name and update the application configuration