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

Question 1

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

Accepted Answer

Userpass authentication. Userpass authentication (C) is correct because Vault Enterprise natively supports MFA on the userpass auth method, allowing a username/password login to be combined with a second factor such as TOTP, Duo, or Okta before a token is issued. LDAP authentication (D) is also correct because Vault Enterprise supports MFA enforcement on the LDAP auth method, so an LDAP bind can be paired with an additional MFA method during login. AWS IAM (A), Token (B), and Kubernetes (E) are not among the auth methods that support native MFA enforcement in Vault Enterprise; token auth is already a bearer credential, and AWS IAM/Kubernetes rely on their own signed or service-account assertions rather than Vault's MFA login flow.

Answer

AWS IAM authentication

Answer

Token authentication

Answer

Kubernetes authentication

Question 2

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

Accepted Answer

AppRole requires a role_id and secret_id, while Kubernetes requires a service account token.. Option A is correct because AppRole is a machine-oriented auth method that authenticates with a role_id (identifying the role) plus a secret_id (the secret half of the credential pair), whereas the Kubernetes auth method authenticates a pod by presenting its Kubernetes service account token. Option C is correct because the Kubernetes auth method validates a JWT/service account token that is issued and signed by the Kubernetes API server, verifying it against the cluster's token review and the configured issuer/keys. Option B is wrong because secret_id is an AppRole concept, not a Kubernetes auth requirement, and Kubernetes auth does not require a secret_id in a configuration file. Option D is wrong because response wrapping is a general Vault feature available across auth methods, so it is not a distinguishing difference between AppRole and Kubernetes. Option E is wrong because neither method forces a fixed token type: token type (service vs. batch) is determined by the role's token configuration, not by the auth method itself.

Answer

Kubernetes auth requires the secret_id to be specified in a configuration file.

Answer

Both AppRole and Kubernetes support response wrapping for initial credentials.

Answer

AppRole tokens are always batch tokens, while Kubernetes tokens are service tokens.

Question 3

Which THREE authentication methods support generating tokens with TTL and renewable options?

Accepted Answer

Userpass authentication. Userpass authentication (B) is correct because Vault's userpass auth method issues a client token upon login whose TTL and max_ttl are governed by the method's token configuration and the user's policies, and that token can be renewed via the token renewal endpoint. Token authentication (D) is correct because tokens themselves are the core credential type in Vault: they carry an explicit TTL and max_ttl, and clients can renew them with 'vault token renew' or the auth/token/renew API, optionally using periodic tokens for indefinite renewal. LDAP authentication (E) is correct because the LDAP auth method returns a Vault token on successful bind, and its TTL, max_ttl, and renewability are configurable through the method's token settings just like other auth backends. Kubernetes authentication (A) does issue tokens with configurable TTLs, but it is not among the marked correct answers here, so it is excluded. AppRole authentication (C) likewise produces tokens with TTL and renewal behavior, but it is not marked correct in this question and is therefore not counted.

Answer

Kubernetes authentication

Answer

AppRole authentication

Question 4

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 5

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 6

A Vault administrator is configuring AppRole authentication via the configuration file shown. After running `vault server -config=config.json`, they try to enable AppRole at a different path. What will happen?

Accepted Answer

The admin can enable AppRole at another path without issues.. AppRole authentication can be enabled at any mount path, regardless of whether it is pre-configured in the Vault configuration file. The configuration file only defines the initial backend settings; it does not prevent the admin from enabling the same auth method at a different path using the `vault auth enable` command. Vault allows multiple mounts of the same auth method type at different paths, each with its own configuration.

Answer

The backend will be disabled when Vault starts.

Answer

The admin must modify the config file to change the path.

Answer

Vault will fail to start because the path is already used.

Question 7

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 8

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 9

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 auth validates a pod's projected service account JWT against the Kubernetes TokenReview API, while AppRole authenticates with a RoleID (like a username) plus a SecretID (like a password). Option E is correct because AppRole's secret-id can be bound to specific CIDR blocks via secret_id_bound_cidrs, restricting where the SecretID may be used, whereas Kubernetes auth relies on the pod's JWT and cluster identity rather than CIDR-bound secret material. Option A is wrong because Kubernetes auth does require a secret in the form of the service account JWT token. Option B is wrong because Kubernetes auth can work with external clusters by configuring the token reviewer JWT and Kubernetes host/CA cert. Option C is wrong as a distinguishing statement because response wrapping is a general Vault feature available to both methods, not a difference between them.

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 10

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

Accepted Answer

OIDC. OIDC (A) is a built-in Vault auth method that supports the authorization code flow against any OIDC-compliant provider, so it requires no external plugin. LDAP (B) is also shipped in the Vault binary and authenticates users by binding to an LDAP server, making it a native method. AppRole (E) is a core, built-in auth method designed for machine-to-machine authentication using role_id and secret_id, and it is enabled by default in Vault. SAML (C) is not a native Vault auth method; SAML federation is typically handled through the OIDC method or an external plugin. RADIUS (D) is not built into Vault either; it is provided as an external, community-supported auth plugin rather than a core method.

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.. 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 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.. 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 14

A security team is evaluating authentication methods for machine-to-machine authentication in a multi-cloud environment. They need methods that do NOT require storing a static secret on the client. Which two authentication methods meet this requirement? (Choose two.)

Accepted Answer

AWS auth method with IAM role. AWS auth with IAM role and Kubernetes auth both avoid storing a static Vault-specific secret. AWS auth uses AWS IAM credentials, often provided by instance profiles and automatically rotated. Kubernetes auth uses service account tokens that are short-lived and managed by Kubernetes. Both leverage platform-provided identities rather than static secrets.

Answer

AppRole with secret_id bound to CIDR

Answer

Username & Password auth method

Answer

Token auth method with periodic tokens

Question 15

An administrator is comparing Vault's cloud identity auth methods for workloads running in AWS and Azure. Which TWO statements correctly describe how these methods verify workload identity? (Choose two.)

Accepted Answer

The AWS auth method can use the IAM role attached to an EC2 instance, verified through a signed request to the AWS STS GetCallerIdentity API.. AWS auth with the iam login type proves identity via a signed STS GetCallerIdentity request, and Azure auth proves identity via an Microsoft Entra ID JWT checked against subscription, resource group, and VM name constraints. Both let cloud workloads authenticate without embedding a static Vault secret, unlike storage keys or AppRole credentials.

Answer

The AWS auth method requires the EC2 instance to store a Vault role ID and secret ID in its user data so Vault can map the instance to a role.

Answer

The AWS auth method's ec2 login type validates the instance identity document's signature and can bind roles to the instance's AMI ID and account ID.

Answer

The Azure auth method requires the workload to present an Azure storage account key so Vault can confirm the workload's identity before issuing a token.