VA-003 Compare authentication methods Practice Test 4 — 15 Questions

Question 1

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 2

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

Question 3

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. Option A is correct because 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 4

A security engineer needs to choose an authentication method for a set of microservices running in a Kubernetes cluster that require short-lived secrets. The method should leverage the pod's identity. Which method is best?

Accepted Answer

Kubernetes auth. Kubernetes auth is the best choice because it allows a pod to authenticate to Vault using its own service account token, which is automatically mounted and short-lived. This method directly leverages the pod's identity without requiring manual secret distribution, making it ideal for microservices in a Kubernetes cluster that need ephemeral credentials.

Answer

AppRole auth

Answer

Token auth

Answer

LDAP auth

Question 5

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 6

A company uses Kubernetes auth. A pod in namespace 'prod' with service account 'my-sa' can authenticate and read secrets. After upgrading the Kubernetes cluster, the same pod fails to authenticate with error 'JWT token issuer is not valid'. What is the most likely cause?

Accepted Answer

The issuer in the Vault configuration does not match the new cluster issuer. The error 'JWT token issuer is not valid' indicates that the Kubernetes cluster's issuer URL (typically found in the service account token's `iss` claim) has changed after the upgrade. Vault's Kubernetes auth method must be configured with the correct `kubernetes_ca_cert`, `kubernetes_host`, and crucially the `issuer` parameter. If the cluster's new issuer (e.g., `https://kubernetes.default.svc.cluster.local` or a custom OIDC issuer) does not match the one stored in Vault's configuration, Vault will reject the JWT during validation, causing authentication to fail.

Answer

The service account was deleted

Answer

The Vault role's bound_service_account_names is incorrect

Answer

The Vault server's Kubernetes API address changed

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

Which TWO statements correctly describe differences between AppRole and Kubernetes authentication methods?

Accepted Answer

Kubernetes auth authenticates using a service account JWT token, whereas AppRole uses a RoleID and SecretID.. Option D is correct because Kubernetes authentication works by having Vault validate a Kubernetes service account JWT token against the Kubernetes TokenReview API, while AppRole authentication requires a RoleID (which identifies the role) and a SecretID (which acts as a credential). The SecretID can be a generated value or a wrapped response, but the JWT token in Kubernetes auth is the sole credential presented to Vault.

Answer

AppRole requires a secret ID, while Kubernetes auth does not require any secret.

Answer

Kubernetes auth can only be used within the same cluster as Vault, while AppRole can be used remotely.

Answer

Both support response wrapping for secure delivery of credentials.

Question 9

Which THREE are best practices when selecting authentication methods for different use cases?

Accepted Answer

Use AppRole for automated CI/CD pipelines.. AppRole is designed for machine-to-machine authentication, making it ideal for automated CI/CD pipelines. It provides a secure way for applications to obtain a Vault token using a RoleID and SecretID, without requiring a human user. This avoids the security risks of long-lived tokens and allows for dynamic, short-lived credentials.

Answer

Use token auth as the sole method for all users and machines.

Answer

Use Kubernetes auth for pods in any environment.

Question 10

Which THREE authentication methods are built into Vault (no plugin required)?

Accepted Answer

OIDC. OIDC (OpenID Connect) is built into Vault as an identity provider and authentication method without requiring any external plugin. It allows clients to authenticate via OIDC providers like Okta or Azure AD, leveraging JWT tokens for identity verification. Vault's built-in OIDC support is configured through the `vault auth enable oidc` command and does not depend on any separate plugin binary.

Answer

SAML

Answer

RADIUS

Question 11

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 12

A SaaS company uses AppRole authentication for their CI/CD pipeline. The pipeline runs on a Jenkins server. The pipeline generates a secret ID using the AppRole 'ci-role' and then logs in to Vault to read a database credential. Recently, the pipeline started failing intermittently with errors like 'secret ID is expired' or 'secret ID is used'. The pipeline generates a new secret ID every run. The team verified that the AppRole's secret_id_ttl is set to 0 (unlimited) and the secret_id_num_uses is set to 1. The pipeline runs multiple jobs concurrently, sometimes using the same AppRole. What is the most likely cause and solution?

Accepted Answer

Use response wrapping for the secret ID delivery to ensure each job gets a unique wrapped token.. Option C is correct because the intermittent failures ('secret ID is expired' or 'secret ID is used') occur when multiple concurrent pipeline jobs generate a new secret ID for the same AppRole 'ci-role' with secret_id_num_uses=1. Since each secret ID can only be used once, concurrent jobs may attempt to reuse an already-consumed secret ID or generate overlapping IDs. Response wrapping delivers a unique wrapped token to each job, ensuring that each job receives a fresh, single-use secret ID without race conditions, as the wrapping token is unwrapped only once per job.

Answer

Set secret_id_num_uses to 0 to allow unlimited uses.

Answer

Create separate AppRoles for each pipeline job.

Answer

Increase secret_id_ttl to a high value like 24h.

Question 13

A small company uses Vault with LDAP authentication for their employees. They configured the LDAP auth method pointing to their on-premises Active Directory. Several users report that they can log in to the Vault UI, but they cannot see any secrets in the paths they expect. The administrator verified that the users are in the correct AD groups. The Vault policies are defined and assigned to groups via the LDAP auth method's group mapping. However, the users still have no permissions. What is the most likely root cause and the correct fix?

Accepted Answer

The group mapping in Vault does not match the AD group names (case or syntax).. The most likely root cause is that the group mapping in Vault does not match the AD group names due to case sensitivity or syntax differences. Vault's LDAP auth method performs exact string matching when mapping LDAP groups to Vault policies; if the group names in the Vault configuration (e.g., 'Domain Admins') differ from the actual AD group names (e.g., 'Domain Admins' with a trailing space or different case), the mapping fails, resulting in no policy assignment and thus no permissions.

Answer

The LDAP bind credentials are incorrect.

Answer

The LDAP auth method is not enabled.

Answer

The Vault token's TTL is too short.

Question 14

A large e-commerce company uses Vault to manage secrets for their AWS EC2 instances. They use AWS IAM auth. The Vault role is configured with bound_iam_role_arn to match the IAM role 'ec2-app-role'. Most instances work fine. However, a new instance launched with the same IAM role fails to authenticate. The instance can reach Vault (network is fine) and the AWS credentials are valid. The Vault server logs show: 'error validating login: unable to get instance identity document'. The new instance is in a different AWS region (us-west-2) while most others are in us-east-1. Vault is deployed in us-east-1. What is the most likely cause and solution?

Accepted Answer

Vault's AWS auth method must be configured with the correct region for instance identity validation.. Option D is correct because the AWS auth method in Vault validates the instance identity document, which includes the region where the instance is launched. By default, Vault's AWS auth method uses the region configured in its sts_endpoint or the Vault server's own region (us-east-1). When a new instance in us-west-2 presents its identity document signed with a us-west-2 region-specific key, Vault fails to validate it because it is checking against the wrong region's signing key. Configuring the auth method with the correct region (or a wildcard) allows Vault to validate identity documents from multiple regions.

Answer

The IAM role does not exist in us-west-2.

Answer

The new instance needs to be associated with an instance profile.

Answer

Create a new Vault role for the us-west-2 region.

Question 15

A company runs its containerized workloads on multiple Kubernetes clusters and also maintains a number of legacy virtual machines running critical applications. The Vault cluster is deployed outside Kubernetes and is used to manage secrets for both environments. The DevOps team has configured the Kubernetes auth method for pods in the Kubernetes clusters, but they are experiencing authentication failures for pods in one specific namespace. Meanwhile, legacy VMs cannot authenticate at all because they are not part of any Kubernetes cluster. The Vault administrator needs to enable authentication for all workloads while minimizing changes to existing applications. The administrator has received the following requirements: containerized pods should authenticate without manual token distribution, legacy VMs should use a method that supports machine-oriented authentication with short-lived tokens, and all authentication should be auditable. Which course of action should the administrator take?

Accepted Answer

Keep the Kubernetes auth method for pods (fixing the namespace-specific issue) and enable AppRole authentication for the legacy VMs, using response wrapping or trusted entities for SecretID delivery.. Option D is correct because it preserves the existing Kubernetes auth method for pods (after fixing the namespace-specific issue) and introduces AppRole for legacy VMs, which provides machine-oriented authentication with short-lived tokens via SecretIDs. This approach minimizes changes to existing applications, meets the requirement for auditable authentication (both methods log to Vault audit devices), and avoids manual token distribution by using response wrapping or trusted entities for secure SecretID delivery.

Answer

Configure the LDAP auth method for both pods and legacy VMs, creating service accounts in Active Directory for each application.

Answer

Configure the Kubernetes auth method on all clusters and also install a Vault sidecar on the legacy VMs to make them appear as pods.

Answer

Use AppRole as the sole authentication method for all workloads, generating secret IDs for each pod and VM.