Knowledge + Practice

CCNA Compare authentication methods Questions

49 questions · Compare authentication methods · All types, answers revealed

Practice these questions Domain overview All questions

1

MCQmedium

A platform team manages a fleet of on-premises Linux servers that are not joined to any cloud provider or Active Directory domain. They want each server to authenticate to Vault automatically at boot without embedding a long-lived token in a configuration file. The team already maintains an internal PKI that issues X.509 certificates to every server. Which authentication method should they enable to meet these requirements with the least new infrastructure?

A.Enable the aws auth method and bind each server to an IAM role so it can call STS GetCallerIdentity during login.

B.Enable the approle auth method and distribute a role_id and secret_id to each server's configuration file.

C.Enable the cert auth method and configure a trusted CA certificate so each server presents its PKI-issued certificate during login.

D.Enable the ldap auth method and point it at the internal directory where each server has a service account.

AnswerC

The cert auth method validates the client certificate presented during the TLS handshake against a CA certificate configured on the mount. Because the internal PKI already issues certificates to every server, the team reuses existing infrastructure rather than deploying new credential stores or cloud integrations. This satisfies the requirement of automatic, token-free authentication at boot.

Why this answer

Certificate authentication leverages the PKI certificates the servers already possess, so no new credential distribution channel is needed. During the TLS handshake the server presents its certificate, and Vault validates it against the trusted CA configured on the cert mount. This yields automatic, secret-free login for on-premises hosts that have no cloud identity.

Exam trap

The trap here is assuming that any machine-to-machine method works everywhere, when cloud identity methods like aws auth only function for workloads that actually have a cloud-issued identity.

Practice this question →

2

MCQhard

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?

A.JWT auth method

B.AppRole auth method

C.Cert auth method

D.Kubernetes auth method

AnswerD

The Kubernetes auth method accepts a service account JWT, calls the Kubernetes TokenReview API to validate it, and then checks the bound namespace and service account against the role configuration. This exactly matches the requirement to verify tokens against the Kubernetes API and enforce namespace and service account constraints.

Why this answer

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.

Exam trap

The trap here is confusing Kubernetes auth with generic JWT auth, since both involve a token, but only Kubernetes auth performs TokenReview and namespace/service account binding.

Practice this question →

3

MCQeasy

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?

A.GCP IAM authentication

B.Userpass authentication

C.AppRole authentication

D.AWS IAM authentication

AnswerD

AWS IAM authentication has Vault verify the instance's signed PKCS#7 metadata document against AWS, issuing a token without stored secrets. This satisfies the constraint that applications on EC2 with an attached IAM role authenticate using instance metadata rather than configuration-file credentials.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between authentication methods that require pre-shared secrets (like AppRole) versus those that leverage cloud instance metadata (like AWS IAM), leading candidates to mistakenly choose AppRole because it is commonly associated with machine authentication.

How to eliminate wrong answers

Option A is wrong because GCP IAM authentication is designed for Google Cloud Platform instances, not AWS EC2, and relies on GCP instance metadata and service accounts. Option B is wrong because Userpass authentication requires a username and password to be provided at login, which would still need to be stored or transmitted as a secret, contradicting the requirement to avoid storing secrets. Option C is wrong because AppRole authentication requires a RoleID and a SecretID; while the RoleID can be supplied via configuration, the SecretID must be securely delivered (e.g., via a trusted orchestrator), and it does not leverage EC2 instance metadata for credential retrieval.

Practice this question →

4

Multi-Selecteasy

Which TWO authentication methods are designed for human users? (Choose two.)

Select 2 answers

A.AWS

B.Kubernetes

C.AppRole

D.OIDC

E.Userpass

AnswersD, E

OIDC authenticates human users through an external identity provider's browser-based login flow, issuing tokens tied to a person's identity. This satisfies the stem's requirement for human-oriented methods, unlike machine-oriented approaches such as AppRole or AWS IAM auth.

Why this answer

OIDC (Option D) is correct because it is an authentication method built for human users, allowing them to authenticate through an external OpenID Connect identity provider (e.g., Okta, Azure AD, Google) using browser-based SSO flows rather than static secrets. Userpass (Option E) is also correct because it is Vault's native username-and-password method intended for interactive human logins, where credentials are stored as password hashes and can be rotated by the user. By contrast, AWS (Option A) is a machine-oriented method that authenticates workloads using AWS IAM credentials or instance metadata, not people.

Kubernetes (Option B) is likewise designed for pods and service accounts to authenticate via Kubernetes ServiceAccount tokens, not human users. AppRole (Option C) is a machine-to-machine method that issues RoleID and SecretID credentials for automated applications, so it is not intended for human authentication.

Exam trap

HashiCorp often tests the distinction between authentication methods designed for human users versus machine/application identities, and the trap here is that candidates may confuse 'AppRole' (a machine auth method) with a human-oriented method due to its name suggesting a role for a person.

Practice this question →

5

MCQeasy

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?

A.GitHub personal access token

B.AWS IAM auth

C.AppRole

D.Username & password (userpass)

AnswerB

AWS IAM auth lets each EC2 instance present its instance profile credentials to Vault, which verifies them against AWS STS and returns a short-lived Vault token. No long-lived secrets are stored on the Jenkins hosts, satisfying the constraint.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that AppRole is the best choice for automated workloads, but the trap here is that AppRole still requires storing a secret ID, whereas AWS IAM auth eliminates all long-lived credentials by leveraging the EC2 instance's IAM role and temporary AWS credentials.

How to eliminate wrong answers

Option A is wrong because a GitHub personal access token is a long-lived static credential that must be stored securely, violates the requirement of not storing long-lived credentials, and is not designed for AWS EC2 instance authentication to Vault. Option C is wrong because AppRole requires a secret ID and role ID to be provisioned and stored, which are long-lived credentials that must be managed securely, and does not leverage the EC2 instance's IAM role for automatic credential rotation. Option D is wrong because username & password (userpass) authentication requires storing static credentials in Jenkins, which are long-lived and pose a security risk, and does not integrate with AWS IAM roles or instance metadata.

Practice this question →

6

MCQeasy

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?

A.AppRole auth

B.Token auth

C.LDAP auth

D.Kubernetes auth

AnswerD

Kubernetes auth lets workloads exchange their pod-bound service account token for short-lived Vault tokens, so no static secret is stored. This directly satisfies the stem's requirement to leverage the pod's identity and issue short-lived secrets, unlike AppRole or token methods that rely on pre-shared credentials.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that AppRole is suitable for Kubernetes workloads because it is 'machine-oriented,' but they ignore that AppRole does not leverage the pod's native identity and requires out-of-band secret distribution.

How to eliminate wrong answers

Option A is wrong because AppRole auth requires a pre-shared RoleID and a generated SecretID, which are not inherently short-lived or tied to a pod's identity, and managing these for many microservices adds operational overhead. Option B is wrong because Token auth relies on static, long-lived tokens that must be manually distributed and rotated, contradicting the requirement for short-lived secrets and pod identity. Option C is wrong because LDAP auth is designed for user or machine authentication against an LDAP directory, not for Kubernetes pod identities, and it does not integrate with the pod's service account token.

Practice this question →

7

MCQeasy

Refer to the exhibit. Which authentication method is currently enabled for production applications?

A.Token

B.LDAP

C.AppRole

D.Userpass

AnswerC

AppRole is a machine-oriented auth method where the enabled roles on the production mount determine access. Its presence as the configured method for production applications satisfies the exhibit's requirement to identify the currently enabled authentication method.

Why this answer

The exhibit shows that the production applications are configured with the 'AppRole' authentication method, which is indicated by the presence of a RoleID and SecretID in the application configuration. AppRole is a machine-oriented authentication method in HashiCorp Vault that allows applications to authenticate using a pair of credentials (RoleID and SecretID), making it suitable for automated, non-human workflows. The other methods listed (Token, LDAP, Userpass) are either human-centric or not configured for these applications.

Exam trap

HashiCorp often tests the distinction between human-centric authentication methods (LDAP, Userpass) and machine-centric methods (AppRole, Token), and the trap here is that candidates mistakenly choose Token because it is simpler, overlooking that AppRole is specifically designed for production applications requiring dynamic, role-based credentials.

How to eliminate wrong answers

Option A is wrong because Token authentication uses a single static token, which is less secure and not designed for dynamic application workloads where credentials should be rotated or have limited lifetimes. Option B is wrong because LDAP authentication is used for human users authenticating against an external directory service (e.g., Active Directory), not for machine-to-machine authentication in production applications. Option D is wrong because Userpass authentication requires a username and password, which is intended for interactive human logins and not suitable for automated application authentication without additional secret management.

Practice this question →

8

MCQmedium

A Vault operator needs to let an on-premises LDAP directory's groups map directly to Vault policies, but the directory does not implement any OIDC or SAML endpoints. Which auth method should the operator enable to authenticate users against that directory?

A.GitHub auth method

B.SAML auth method

C.LDAP auth method

D.OIDC auth method

AnswerC

The LDAP auth method binds directly to an LDAP server over the LDAP protocol, allowing users to authenticate with their directory credentials and groups to be mapped to Vault policies. It does not require OIDC or SAML endpoints, so it fits a directory that only exposes standard LDAP bind operations.

Why this answer

The LDAP auth method is designed to authenticate against an LDAP directory using standard bind operations and can map directory groups to Vault policies. Because the directory lacks OIDC or SAML capabilities, methods built on those protocols cannot be used, and a cloud-specific method like GitHub auth is unrelated to the on-premises directory.

Exam trap

The trap here is assuming any federated identity method can consume an LDAP directory, when only the LDAP auth method speaks the LDAP protocol directly.

Practice this question →

9

MCQhard

A company uses Vault for secrets management. They want to authenticate using GitHub tokens, but only for users who are members of a specific GitHub team. What must be configured?

A.Vault validates the token's scope.

B.Users must generate a personal access token with repo scope.

C.The GitHub token must include the team scope.

D.Map the GitHub team to a Vault policy in the auth method configuration.

AnswerD

Mapping the GitHub team to a Vault policy in the auth method configuration satisfies the team-membership constraint: Vault's GitHub auth method reads the user's team memberships from the GitHub API and assigns the mapped policy, so only members of that specific team receive the token's permissions.

Why this answer

Vault's GitHub auth method requires mapping GitHub teams to Vault policies. When a user authenticates with a GitHub personal access token, Vault checks the token's associated teams against the configured team-to-policy mappings. Only users belonging to a mapped team receive the corresponding Vault policy, enabling access control based on team membership.

Exam trap

HashiCorp often tests the misconception that Vault validates token scopes or that GitHub tokens have a 'team' scope, when in reality Vault relies on GitHub API team membership lookups and the token must have the appropriate OAuth scope (read:org) to retrieve that information.

How to eliminate wrong answers

Option A is wrong because Vault does not validate the token's scope; it validates the token's associated teams via the GitHub API, not the scope claim. Option B is wrong because while a personal access token is required, the 'repo' scope is not mandatory for authentication; any token with access to the user's team membership information (typically requiring 'read:org' scope) suffices. Option C is wrong because GitHub tokens do not include a 'team' scope; team membership is determined by the token's ability to read organization data, not by a dedicated scope.

Practice this question →

10

MCQmedium

A startup uses Vault to manage secrets for their web application. They currently have a single admin user who authenticates with a root token. They want to allow two developers to authenticate with their own credentials and restrict them to read-only access to a specific path 'secret/data/webapp'. They decide to use the Userpass auth method. The admin creates a user 'dev1' with password 'password123' and assigns a policy 'webapp-readonly' that grants read capability on 'secret/data/webapp'. However, when dev1 tries to log in, Vault returns a permission denied error. The admin checks the token and sees no policies attached. What is the most likely issue?

A.The policy 'webapp-readonly' does not exist.

B.The admin did not assign any policies to the user.

C.The user 'dev1' does not exist.

D.The password is incorrect.

AnswerB

The Userpass auth method requires policies to be attached to the user account itself, not merely created as a standalone policy. Creating 'webapp-readonly' does not bind it to 'dev1'; the admin must associate that policy with the user via the userpass endpoint. Without this association, the issued token carries no policies, producing the permission denied error.

Why this answer

The most likely issue is that the admin created the user 'dev1' but did not assign any policies to that user. In Vault's Userpass auth method, simply creating a user does not attach any policies; the admin must explicitly specify the policies when creating or updating the user. Without a policy attached, the token issued upon login has no capabilities, resulting in a permission denied error even if the policy 'webapp-readonly' exists.

Exam trap

HashiCorp often tests the nuance that creating a user in Vault does not automatically assign any policies; candidates mistakenly assume that simply creating a user and a policy with the same name is sufficient, but the policy must be explicitly linked to the user.

How to eliminate wrong answers

Option A is wrong because if the policy 'webapp-readonly' did not exist, Vault would still allow the user to log in (the token would be issued) but would deny access to the path; however, the error occurs at login time and the token has no policies attached, indicating the policy exists but was not assigned. Option C is wrong because the admin successfully created the user 'dev1', and if the user did not exist, Vault would return a 'user not found' error, not a permission denied error. Option D is wrong because an incorrect password would cause an authentication failure (invalid credentials), not a permission denied error after login; the token would not be issued at all.

Practice this question →

11

MCQmedium

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?

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

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

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

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

AnswerD

This approach uses the most suitable auth method for each environment: Kubernetes auth for pods (short-lived, no manual tokens) and AppRole for VMs (machine-oriented, auditable). The failing namespace issue can be resolved by verifying service account and token reviewer configurations.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between authentication methods designed for human users (LDAP) versus machine workloads (AppRole, Kubernetes), and the trap here is assuming that a single method can be universally applied without considering the operational overhead of SecretID distribution or the namespace-specific configuration nuances of Kubernetes auth.

How to eliminate wrong answers

Option A is wrong because LDAP auth method is designed for user authentication against an LDAP directory, not for machine-oriented authentication; it would require creating and managing service accounts in Active Directory for each application, which is not minimal change and does not natively support short-lived tokens for machines. Option B is wrong because installing a Vault sidecar on legacy VMs to make them appear as pods is impractical and violates the requirement to minimize changes; the sidecar would require significant reconfiguration and does not solve the authentication issue for non-Kubernetes workloads. Option C is wrong because using AppRole as the sole authentication method for all workloads would require generating and distributing SecretIDs for every pod, which contradicts the requirement for containerized pods to authenticate without manual token distribution; Kubernetes auth method is more appropriate for pods as it leverages service account tokens automatically.

Practice this question →

12

MCQmedium

A company's CI system runs outside any cloud provider and must authenticate to Vault without embedding a long-lived secret in its build scripts. The security team wants the CI job to prove its identity using a credential that Vault validates against the CI platform itself. Which auth method best fits this requirement?

A.Token auth method

B.Cert auth method

C.JWT/OIDC auth method

D.Userpass auth method

AnswerC

JWT/OIDC auth lets the CI platform issue a signed JWT that Vault validates against the platform's JWKS or public key. The job presents this short-lived token instead of a static secret, and Vault checks claims such as audience and subject, satisfying the requirement without embedding long-lived credentials.

Why this answer

JWT/OIDC auth is the right fit because the CI platform can mint a short-lived signed JWT that Vault validates against the platform's keys, proving the job's identity without a stored static secret. Userpass and token auth both require long-lived credentials, and cert auth relies on a stored client certificate rather than a platform-issued token.

Exam trap

The trap here is assuming any non-password method avoids static secrets, when cert auth still requires a long-lived private key stored with the CI job.

Practice this question →

13

MCQhard

A security architect is designing authentication for an internal tool that must verify a user's hardware-backed token on a smart card before granting access to secrets. The tool already has a PKI issuing client certificates to each user, and the architect wants Vault to validate the client certificate chain during login. Which auth method should be used, and what is the key configuration requirement?

A.Username & Password auth, with the smart card PIN used as the Vault password and the certificate serial as the username.

B.JWT auth, with the smart card's certificate serial number embedded as a claim in a JWT signed by the internal PKI.

C.Cert auth, with the trusted CA certificate uploaded so Vault can validate the presented client certificate against that CA.

D.TLS certificate auth, with the certificate's private key imported into Vault so Vault can re-sign the client's requests.

AnswerC

The Cert auth method authenticates clients by validating a TLS client certificate against one or more trusted CA certificates configured on the mount. Uploading the issuing CA lets Vault verify the chain presented during the TLS handshake, and the role's allowed_common_names or required_extensions map the verified identity to policies, matching the smart-card-backed certificate requirement.

Why this answer

Cert auth is purpose-built to authenticate clients from their TLS client certificates by validating the chain against a trusted CA configured on the mount. The architect must upload the issuing CA certificate and define role bindings such as allowed_common_names so the verified certificate maps to Vault policies, which aligns with the smart-card PKI already in place.

Exam trap

The trap here is believing Vault needs the client's private key to validate a certificate, when Cert auth only validates the presented chain against a trusted CA.

Practice this question →

14

MCQhard

A consulting firm deploys Vault to multiple tenants. Each tenant uses the OIDC auth method with its own identity provider, but the security team observes that users from one tenant occasionally receive policies intended for another tenant. The OIDC mounts were configured separately, and each uses a distinct default_role. Which configuration issue most likely explains the cross-tenant policy assignment?

A.The user_claim and groups_claim settings on each role resolve to values that collide across tenants, and Vault maps them to the same external group aliases.

B.Each OIDC mount uses the same bound_issuer value, so tokens from either provider are treated as originating from a single issuer.

C.The OIDC discovery URL for one tenant was entered with a trailing slash, causing claim parsing to fall back to defaults.

D.The OIDC role's bound_audiences value includes an audience shared by both identity providers.

AnswerA

When OIDC roles map group claims to external groups, Vault creates group aliases on the identity backend. If two tenants produce the same claim value, the alias collides and the group's policies are applied to users from both tenants. Distinct mounts and default roles do not prevent this, because the identity group alias is global to the namespace rather than scoped to the auth mount.

Why this answer

Identity group aliases created from OIDC group claims are stored on the identity backend and are not isolated per auth mount. When claim values coincide across tenants, Vault treats them as the same external group and attaches that group's policies to all matching users. Auditing the user_claim and groups_claim values, and namespacing alias names, resolves the collision.

Exam trap

The trap here is assuming that separate OIDC mounts provide complete tenant isolation, when identity group aliases derived from claims are actually shared across mounts within the same namespace.

Practice this question →

15

MCQmedium

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?

A.The bind credentials are incorrect

B.The userpass auth method is still enabled

C.LDAP groups are not mapped to Vault policies

D.The LDAP server is unreachable

AnswerC

LDAP authentication resolves group membership from directory attributes, and Vault applies policies only when those groups are mapped via the groups parameter. Without that mapping, users authenticate successfully but receive only the default policy, so their intended policies never apply.

Why this answer

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/<group_name> policies=<policy_name>`. Without this mapping, the user authenticates but receives no policies, resulting in an empty token with no permissions.

Exam trap

The trap here is that candidates assume successful authentication automatically grants permissions, but in Vault, authentication and authorization are decoupled — LDAP only verifies identity, and group-to-policy mapping is a separate configuration step that is easy to overlook.

How to eliminate wrong answers

Option A is wrong because incorrect bind credentials would prevent authentication entirely, not allow successful authentication without policies. Option B is wrong because having the userpass auth method still enabled does not interfere with LDAP authentication or policy application; multiple auth methods can coexist, and the user is authenticating via LDAP. Option D is wrong because if the LDAP server were unreachable, authentication would fail with a connection error, not succeed without policies.

Practice this question →

16

MCQmedium

An administrator wants to use Vault's authentication method that allows users to log in with their corporate credentials via a federated identity system. The credentials are stored in an external identity provider (IdP) and Vault should not store any passwords. Which authentication method should be configured?

A.LDAP authentication

B.OIDC authentication

C.Userpass authentication

D.Token authentication

AnswerB

OIDC authentication delegates login to an external identity provider via federated tokens, so Vault never stores or verifies passwords itself. This satisfies the stem's requirement that credentials reside in the IdP and Vault hold no passwords.

Why this answer

OIDC (OpenID Connect) authentication is the correct choice because it enables federated identity, allowing users to log in with corporate credentials managed by an external IdP (e.g., Azure AD, Okta) without Vault storing any passwords. Vault acts as a relying party, delegating authentication to the IdP and receiving identity tokens, which aligns with the requirement for a passwordless, federated approach.

Exam trap

In HashiCorp Vault, the key distinction is between LDAP (direct authentication against an LDAP directory, where Vault validates credentials) and OIDC (federated authentication where an external IdP handles credential validation). Candidates often confuse LDAP with true federation, but LDAP still requires Vault to verify passwords, whereas OIDC delegates authentication entirely to the IdP.

How to eliminate wrong answers

Option A is wrong because LDAP authentication requires Vault to directly bind to an LDAP directory server and, while it does not store passwords, it does not support federated identity via an external IdP; it relies on direct directory lookups. Option C is wrong because Userpass authentication stores password hashes locally in Vault's backend, contradicting the requirement that Vault should not store any passwords. Option D is wrong because Token authentication is a core Vault mechanism for session management, not an authentication method that integrates with an external IdP or federated identity system.

Practice this question →

17

MCQmedium

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?

A.AWS IAM

B.Kubernetes

C.JWT/OIDC

D.AppRole

AnswerB

The Kubernetes auth method validates a pod's service account JWT against the Kubernetes API, then returns a Vault token, so pods authenticate without any static secret stored in the container. This directly satisfies the stem's requirement for secretless pod authentication.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between 'designed for Kubernetes' (Kubernetes auth) and 'can be used with Kubernetes' (JWT/OIDC or AppRole), leading candidates to pick a generic method that works but is not purpose-built.

How to eliminate wrong answers

Option A is wrong because AWS IAM is an authentication method for AWS EC2 instances or Lambda functions, not for Kubernetes pods. Option C is wrong because JWT/OIDC is a generic method for any OIDC-compliant identity provider, not specifically designed for Kubernetes; it requires manual JWT management and does not leverage Kubernetes service account tokens natively. Option D is wrong because AppRole uses a secret ID and role ID, which are static credentials that must be stored somewhere, defeating the purpose of avoiding static secrets in Kubernetes.

Practice this question →

18

MCQmedium

A Vault administrator needs to allow users to authenticate using their existing corporate Active Directory credentials. The administrator has configured the LDAP authentication method but users cannot log in. The Vault logs show 'LDAP bind successful' but then 'user not found in group' error. What is the most likely issue?

A.The LDAP server hostname is incorrect

B.The userattr configuration is incorrect

C.The groupfilter or groupattr configuration is incorrect

D.The LDAP server does not allow anonymous queries

AnswerC

A successful LDAP bind followed by 'user not found in group' means credentials validated but group membership resolution failed. Vault's groupfilter and groupattr settings control how groups are queried and mapped, so incorrect values there prevent the user matching any group.

Why this answer

The error 'LDAP bind successful' confirms that the Vault server can connect and authenticate to the LDAP server using the bind credentials. The subsequent 'user not found in group' error indicates that while the user exists and can bind, the group membership lookup fails. This is most commonly caused by an incorrect `groupfilter` or `groupattr` configuration, which defines how Vault queries the LDAP directory to map users to groups for authorization.

Exam trap

HashiCorp often tests the distinction between authentication (bind) and authorization (group lookup) — candidates mistakenly focus on the bind success and assume the issue is with user attributes or server connectivity, when the real problem lies in the group membership configuration.

How to eliminate wrong answers

Option A is wrong because an incorrect LDAP server hostname would cause a connection failure, not a successful bind. Option B is wrong because the `userattr` configuration controls how the user's DN is derived during login; a successful bind implies this is correct. Option D is wrong because anonymous queries are not required for group lookup; Vault uses the bind credentials (or a configured service account) to perform the group search, so anonymous access is irrelevant.

Practice this question →

19

MCQhard

A company uses both userpass and AppRole authentication methods. They notice that tokens issued via AppRole are not properly revoked when the corresponding secret_id is deleted. Which concept explains this behavior?

A.The secret_id TTL was not set, causing the token to outlive the secret_id.

B.AppRole does not support entity aliases, so revoking the secret_id does not affect the token.

C.The token was created with a periodic token and cannot be revoked.

D.Tokens are independent of secret_id after login; deleting secret_id does not revoke the token.

AnswerD

A SecretID is only a login credential; once exchanged for a token, that token has its own lifecycle and lease. Deleting the SecretID prevents future logins but does not revoke already-issued tokens, which require explicit revocation.

Why this answer

When a token is issued via AppRole, the token is created after a successful login using a secret_id. The token itself is independent of the secret_id; deleting the secret_id does not affect the token's lifecycle. Token revocation must be performed explicitly on the token, not by removing the secret_id.

Exam trap

The trap here is that candidates mistakenly believe that deleting the authentication credential (secret_id) will cascade to revoke the token, when in fact tokens and their authentication credentials are independent after login.

How to eliminate wrong answers

Option A is wrong because the secret_id TTL controls the validity of the secret_id itself, not the token's lifetime; even if the secret_id expires, the token remains valid until its own TTL or explicit revocation. Option B is wrong because AppRole does support entity aliases when used with identity entities, but the core issue is that tokens are decoupled from the secret_id after login, not the presence or absence of entity aliases. Option C is wrong because periodic tokens can be revoked just like any other token; the periodic nature only affects renewal behavior, not revocability.

Practice this question →

20

MCQmedium

A platform team runs Vault in an on-premises data center. Their legacy monitoring appliance cannot present a TLS client certificate and has no cloud identity provider, but it does have a dedicated filesystem path where it can read a small configuration file written at deployment time. The team wants the appliance to authenticate on a schedule with credentials that can be issued per appliance, scoped by policy, and revoked without affecting other appliances. Which authentication method best fits this requirement?

A.JWT/OIDC

B.TLS Certificates

C.Username & Password

D.AppRole

AnswerD

AppRole is designed for machine-to-machine authentication where the client holds a RoleID and a SecretID, both of which can be delivered through a file on the appliance. Each appliance can receive its own AppRole role, bound to a policy, and revocation of that role or its SecretIDs invalidates only that appliance's access without disturbing other clients.

Why this answer

AppRole is the machine-oriented authentication method that issues each client a RoleID and a SecretID, both of which can be delivered through a file on the appliance. Roles are bound to policies, and SecretIDs can be revoked individually, allowing the platform team to isolate and revoke a single appliance without impacting others. The other methods require capabilities the appliance does not have.

Exam trap

The trap here is assuming that any method which can read credentials from a file is equivalent, when only AppRole is purpose-built for non-interactive machine identities with per-client RoleID and SecretID issuance.

Practice this question →

21

MCQeasy

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?

A.AppRole auth

B.LDAP auth

C.Kubernetes auth

D.GitHub auth

AnswerA

AppRole issues short-lived tokens using a RoleID and SecretID delivered to the Jenkins pipeline, with no dependency on Kubernetes service accounts or cloud instance metadata. This suits an external CI/CD server needing temporary credentials to read secrets.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between authentication methods designed for humans (LDAP, GitHub) versus those for machines (AppRole), and the trap here is assuming Kubernetes auth can be used from outside the cluster because it is commonly associated with CI/CD pipelines.

How to eliminate wrong answers

Option B (LDAP auth) is wrong because it requires a human username/password and is intended for user authentication, not for automated pipelines. Option C (Kubernetes auth) is wrong because it relies on a Kubernetes service account token and is only valid for pods running inside a Kubernetes cluster, not for an external Jenkins server. Option D (GitHub auth) is wrong because it is designed for authenticating users via GitHub OAuth, not for machine-to-machine token generation in a CI/CD pipeline.

Practice this question →

22

MCQhard

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?

A.The binddn or bindpass configured in Vault is incorrect

B.Vault is not configured to use SSL/TLS for LDAP

C.The LDAP server does not allow anonymous binds

D.The LDAP server certificate is not trusted by Vault

AnswerA

Vault performs an LDAP simple bind using the configured binddn and bindpass before searching for the user. If those service-account credentials are wrong or expired, the bind fails with 'invalid credentials' even though the LDAP server itself is reachable.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between authentication failures (invalid credentials) and connectivity/TLS errors, so candidates mistakenly choose TLS or certificate issues when the error message clearly points to credential mismatch.

How to eliminate wrong answers

Option B is wrong because the error message does not mention SSL/TLS; a TLS misconfiguration would typically produce a 'connection refused' or 'TLS handshake failed' error, not 'invalid credentials'. Option C is wrong because anonymous binds are irrelevant here; Vault uses a configured binddn/bindpass for the initial bind, not anonymous authentication. Option D is wrong because an untrusted certificate would cause a TLS verification error, not a bind failure with 'invalid credentials'.

Practice this question →

23

MCQmedium

A platform team operates Vault in a hybrid cloud. They want a single authentication method that lets employees use their existing cloud provider identity (e.g., AWS IAM role, Azure managed identity) to log in without distributing Vault-specific credentials. Which authentication method should they enable?

A.GitHub auth method

B.Username & Password auth method

C.Cloud auth method (e.g., AWS, Azure, GCP)

D.Cloud Foundry auth method

AnswerC

Cloud auth methods (AWS, Azure, GCP) allow users and machines to authenticate using their existing cloud provider identity. For AWS, Vault verifies the IAM principal via signed STS requests; for Azure, it validates managed identity tokens. This matches the requirement to use existing cloud identity without distributing Vault-specific credentials.

Why this answer

Cloud auth methods (AWS, Azure, GCP) enable authentication using existing cloud provider identities. For AWS, Vault uses the IAM principal's signed request to verify identity; for Azure, it validates managed identity tokens. This eliminates the need to distribute Vault-specific credentials and aligns with the hybrid cloud requirement.

Exam trap

The trap here is confusing Cloud Foundry auth (for PaaS apps) with cloud provider auth methods that leverage AWS IAM or Azure managed identity for user and machine login.

Practice this question →

24

MCQmedium

A platform team runs Vault in a hybrid cloud and wants to let engineers log in with their existing corporate identities held in Okta, without creating separate Vault usernames or passwords. The Okta tenant supports OpenID Connect and exposes a discovery document. Which authentication method should they enable to meet this requirement with the least administrative overhead?

A.Enable the Username & Password auth method and synchronize Okta user records into Vault on a schedule.

B.Enable the GitHub auth method and map Okta users by their GitHub organization membership.

C.Enable the LDAP auth method and bind Vault to the Okta LDAP interface using a service account.

D.Enable the OIDC auth method and configure it with the Okta discovery URL and a client ID/secret registered in Okta.

AnswerD

OIDC is designed exactly for federated identity: Vault acts as a relying party, redirects the user to Okta, validates the returned ID token, and maps claims to Vault policies via an OIDC role. Because Okta publishes a discovery document, Vault can auto-discover endpoints, minimizing manual configuration and avoiding separate Vault credentials.

Why this answer

Federated login against an OIDC-capable identity provider is served by Vault's OIDC auth method, which consumes the provider's discovery document and validates ID tokens. The other methods either require a static bind credential, depend on an unrelated identity source, or duplicate credentials inside Vault, none of which satisfies least-overhead federation with Okta.

Exam trap

The trap here is assuming any external-directory method provides federation, when LDAP auth still needs a stored bind password while OIDC delegates authentication entirely to the provider.

Practice this question →

25

MCQhard

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?

A.Set token_num_uses=1 in the role.

B.Set bound_cidr_list to a specific IP.

C.Set secret_id_ttl=1s in the role.

D.Set secret_id_num_uses=1 in the role.

AnswerD

Setting secret_id_num_uses=1 makes each SecretID valid for a single authentication attempt, so a captured SecretID cannot be replayed. This directly satisfies the stem's constraint that each SecretID be usable only once, unlike TTL settings which limit time rather than use count.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between `secret_id_num_uses` (controls SecretID reuse) and `token_num_uses` (controls token reuse), leading candidates to confuse the two and incorrectly select Option A.

How to eliminate wrong answers

Option A is wrong because `token_num_uses=1` limits the number of times the resulting token can be used, not the SecretID itself; the SecretID could still be reused to generate multiple tokens. Option B is wrong because `bound_cidr_list` restricts the source IP addresses allowed to use the SecretID, but does not enforce single-use behavior. Option C is wrong because `secret_id_ttl=1s` sets a time-to-live of 1 second for the SecretID, which may expire quickly but does not guarantee single-use; a SecretID could still be used multiple times within that second.

Practice this question →

26

MCQmedium

An administrator is configuring Vault to allow employees to log in using their existing corporate credentials managed by an external identity provider that supports OIDC. The administrator wants to avoid creating local Vault users. Which authentication method should be used?

A.Okta auth method

B.OIDC auth method

C.LDAP auth method

D.Username & Password auth method

AnswerB

OIDC auth method allows users to authenticate via an external OIDC identity provider. It supports authorization code flow and JWT validation, enabling single sign-on without local Vault users. This matches the requirement to use existing corporate credentials managed by an OIDC provider and avoids creating local users.

Why this answer

OIDC auth method enables authentication via an external OIDC identity provider, allowing employees to use corporate credentials without local Vault users. It supports standard OIDC flows and JWT validation, making it the right choice for integrating with an OIDC-capable IdP.

Exam trap

The trap here is choosing a vendor-specific method like Okta when the scenario only specifies OIDC compliance, not a particular vendor.

Practice this question →

27

MCQeasy

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?

A.The group mapping in Vault does not match the AD group names (case or syntax).

B.The LDAP bind credentials are incorrect.

C.The LDAP auth method is not enabled.

D.The Vault token's TTL is too short.

AnswerA

LDAP group mapping matches the group name string exactly, including case and whitespace, so a mismatch means no policies attach despite correct AD membership. Aligning the Vault group mapping with the exact AD group name restores permissions.

Why this answer

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.

Exam trap

HashiCorp often tests the nuance that LDAP authentication can succeed while authorization fails due to group mapping mismatches, leading candidates to incorrectly suspect authentication or token issues instead of policy mapping.

How to eliminate wrong answers

Option B is wrong because incorrect LDAP bind credentials would prevent the LDAP auth method from authenticating users at all, but the users can log in successfully, so the bind credentials are valid. Option C is wrong because if the LDAP auth method were not enabled, users would not be able to log in to the Vault UI at all, but they can log in. Option D is wrong because a short Vault token TTL would cause tokens to expire quickly, not prevent users from seeing secrets immediately after login; the issue is about missing permissions, not token lifetime.

Practice this question →

28

MCQmedium

A company has multiple AWS accounts and wants to allow EC2 instances to authenticate to Vault without storing any secrets on the instances. Which authentication method should they use?

A.OIDC

B.AWS

C.TLS Certificates

D.AppRole

AnswerB

The AWS auth method uses the EC2 instance identity document and AWS IAM role credentials, obtained from the instance metadata service, to prove identity to Vault. No static secret is ever stored on the instance, satisfying the no-secrets-on-instances constraint across multiple accounts.

Why this answer

(AWS) is correct because the AWS authentication method in Vault allows EC2 instances to authenticate using their AWS instance identity documents and PKCS#7 signatures, without requiring any long-lived secrets to be stored on the instances. Vault verifies the instance's identity by calling the AWS EC2 API to validate the document and signature, then binds the instance to a Vault role. This eliminates the need to store tokens or credentials on the instance, meeting the requirement of secretless authentication.

Exam trap

HashiCorp often tests the misconception that OIDC or TLS certificates are the 'most secure' or 'standard' methods for secretless authentication, but the trap here is that the question specifically requires no secrets stored on the instance, which only the AWS auth method achieves by using dynamic, ephemeral instance metadata instead of static credentials.

How to eliminate wrong answers

Option A (OIDC) is wrong because OIDC relies on an external identity provider (e.g., Okta, Azure AD) to issue ID tokens, which would still require the EC2 instance to either store a client secret or perform a complex token exchange, and it does not natively leverage AWS instance metadata for secretless authentication. Option C (TLS Certificates) is wrong because while TLS certificates can authenticate instances, they require the certificates and private keys to be stored on the EC2 instances, violating the 'no secrets stored on instances' requirement. Option D (AppRole) is wrong because AppRole requires a RoleID and a SecretID to be provided by the client; the SecretID is a secret that must be stored or delivered to the instance, which contradicts the requirement of not storing any secrets on the instances.

Practice this question →

29

Drag & Dropmedium

Drag and drop the steps to set up Vault's Kubernetes auth method into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence for setting up Vault's Kubernetes auth method is: enable the auth method, configure it with the Kubernetes API server details, create a role that binds to a service account, deploy a pod using that service account, and finally verify login. This order ensures that each prerequisite is fulfilled before the subsequent step can function correctly.

Practice this question →

30

MCQeasy

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?

A.Token authentication

B.LDAP authentication

C.AWS IAM authentication

D.Kubernetes authentication

AnswerD

Kubernetes authentication validates the pod's projected service account JWT against the cluster's TokenReview API, issuing a Vault token bound to that service account. No long-lived credentials are stored, satisfying the pipeline's requirement to avoid managing static secrets.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse 'token authentication' (a generic long-lived token) with 'Kubernetes authentication' (which uses a short-lived JWT from the pod's service account), leading them to incorrectly select option A.

How to eliminate wrong answers

Option A is wrong because token authentication requires the pipeline to manage a long-lived Vault token, which contradicts the requirement of not managing long-lived credentials. Option B is wrong because LDAP authentication requires the pipeline to have a username and password or a long-lived LDAP session, which again introduces long-lived credential management. Option C is wrong because AWS IAM authentication is designed for workloads running on AWS, not for a pipeline running inside a Kubernetes cluster, and it would require the pipeline to manage AWS IAM roles or keys.

Practice this question →

31

Matchingmedium

Match each Vault replication type to its behavior.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Disaster recovery, async replication

Scale read operations, active-standby

Replicate only mount-specific data

Replicate all data across clusters

Why these pairings

Performance Replication replicates mounts/policies (not secrets) for read scaling; DR Replication replicates everything for failover. Common confusions include swapping the two or inventing non-existent types like Snapshot or Local Replication.

Practice this question →

32

MCQeasy

A small development team wants engineers to log in to Vault with a username and password stored directly in Vault, without integrating any external directory or identity provider. Which authentication method should the administrator enable to satisfy this requirement?

A.github

B.ldap

C.userpass

D.okta

AnswerC

The userpass auth method stores usernames and password hashes inside Vault itself, so it works without any external directory or identity provider. Administrators create users with vault write auth/userpass/users/<name> password=... and assign policies per user. This matches the team's desire for a self-contained credential store with minimal integration effort.

Why this answer

Userpass is the built-in method that keeps usernames and password hashes inside Vault's storage backend, requiring no external directory or identity service. Administrators manage users and their policies directly through the auth mount, which fits a small team that wants simple, self-contained authentication with minimal setup.

Exam trap

The trap here is treating any username-and-password method as equivalent, when ldap and okta both depend on external systems while userpass stores credentials internally.

Practice this question →

33

MCQeasy

A DevOps team wants to authenticate to Vault using short-lived tokens without storing a secret in their CI/CD pipeline. Which authentication method best meets this requirement?

A.JWT/OIDC

B.AWS IAM

C.AppRole

D.Username & Password

AnswerA

JWT/OIDC auth has the CI/CD pipeline present its platform-issued identity token, which Vault validates against the provider's signing keys. The resulting Vault token is short-lived, so no static secret is stored in the pipeline, meeting the requirement.

Why this answer

JWT/OIDC authentication allows a DevOps pipeline to exchange a signed JSON Web Token (JWT) from an external identity provider (e.g., GitHub Actions, GitLab CI) for a short-lived Vault token. This eliminates the need to store a long-lived secret in the CI/CD pipeline because the JWT is dynamically generated by the CI platform and validated by Vault using the OIDC provider's public keys. The resulting Vault token has a configurable TTL, typically minutes, aligning with the requirement for short-lived credentials.

Exam trap

HashiCorp often tests the misconception that AppRole is the best choice for CI/CD because it is designed for machine authentication, but the trap is that AppRole still requires storing a role_id and secret_id, which are long-lived secrets unless using response wrapping, and the question explicitly prohibits storing any secret.

How to eliminate wrong answers

Option B (AWS IAM) is wrong because it requires the CI/CD pipeline to have access to AWS IAM credentials (access key and secret key) or an IAM role with a trust policy, which still involves storing a secret or assuming a role that may not be short-lived. Option C (AppRole) is wrong because it requires a secret_id and role_id to be stored in the pipeline; while secret_id can be wrapped or have a TTL, the role_id is typically static and must be securely stored, contradicting the 'without storing a secret' requirement. Option D (Username & Password) is wrong because it requires storing a static password in the pipeline, which is a long-lived secret and violates the short-lived token requirement.

Practice this question →

34

MCQeasy

A developer wants to log in to Vault from a terminal by supplying a username and password that Vault stores and manages internally, without relying on any external identity system. Which auth method should be enabled?

A.Token auth method

B.OIDC auth method

C.Userpass auth method

D.LDAP auth method

AnswerC

The Userpass auth method stores usernames and password hashes inside Vault itself, allowing users to log in with credentials Vault manages. It requires no external identity provider, which matches the developer's need for a self-contained username and password login from the CLI.

Why this answer

Userpass keeps user records and password hashes within Vault, so it delivers exactly the self-contained username and password login described. LDAP and OIDC both depend on external systems, and token auth only consumes a pre-existing token rather than authenticating a user with credentials.

Exam trap

The trap here is overlooking that Userpass stores credentials inside Vault, while LDAP looks similar at login time but always delegates validation to an external directory.

Practice this question →

35

MCQeasy

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

A.Token auth

B.GitHub auth

C.Userpass auth

D.LDAP auth

AnswerD

LDAP auth lets Microsoft Entra ID validate credentials directly against on-premises Active Directory domain controllers, so users sign in with their existing corporate AD accounts without separate cloud passwords. This satisfies the stem's requirement for authenticating human users via corporate Active Directory credentials, unlike token-based or federated methods.

Why this answer

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.

Exam trap

HashiCorp often tests the misconception that 'LDAP auth' is only for Unix/Linux systems, when in fact it is the standard protocol for integrating with Microsoft Active Directory for user authentication.

How to eliminate wrong answers

Option A is wrong because token auth is used for machine-to-machine authentication via pre-shared tokens, not for human users authenticating with corporate credentials. Option B is wrong because GitHub auth is an OAuth-based method for authenticating with GitHub identities, not for corporate Active Directory. Option C is wrong because userpass auth stores credentials locally in Vault's backend, requiring manual user management and not integrating with external directory services like Active Directory.

Practice this question →

36

Multi-Selecthard

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

Select 3 answers

A.Use AppRole for automated CI/CD pipelines.

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

C.Use AWS IAM auth for EC2 instances running in AWS.

D.Use Kubernetes auth for pods in any environment.

E.Use LDAP auth for human users with Active Directory.

AnswersA, C, E

AppRole assignments suit automated CI/CD pipelines because they grant application permissions without interactive sign-in, satisfying the non-interactive workload constraint. Unlike delegated scopes, which require a signed-in user context, app roles let the pipeline authenticate as itself via client credentials, avoiding stored user passwords or MFA prompts.

Why this answer

Option A is correct because AppRole is purpose-built for machine-to-machine authentication: it issues a RoleID and SecretID that a CI/CD pipeline can deliver programmatically, and its response-wrapping and secret-ID lifecycle controls make it the recommended method for automated, non-interactive workloads. Option C is correct because AWS IAM auth lets an EC2 instance present its instance profile credentials to Vault, which verifies the AWS-signed request via STS, so no static Vault credentials need to be stored on the instance. Option E is correct because LDAP auth binds directly to a directory such as Active Directory, allowing human users to authenticate with their existing AD credentials and inherit group-based policies, which is the standard approach for enterprise human access.

Option B is not a best practice because making token auth the sole method for everyone ignores stronger, purpose-specific methods and forces manual token distribution and lifecycle management, increasing leakage risk. Option D is not a best practice as stated because Kubernetes auth is only appropriate for pods running in a Kubernetes cluster that Vault is configured to trust; using it 'in any environment' is impossible where no Kubernetes service account token or Vault Kubernetes auth role exists.

Exam trap

HashiCorp often tests the misconception that a single authentication method can be universally applied, or that a method designed for a specific platform (like Kubernetes auth) can be used in any environment, leading candidates to select overly broad or insecure options like B or D.

Practice this question →

37

MCQeasy

A developer needs to authenticate to Vault from a CI/CD pipeline running on an on-premises server. The pipeline cannot use cloud provider identities or Kubernetes. The security team wants to avoid embedding long-lived Vault tokens in the pipeline scripts. Which authentication method is most appropriate?

A.AppRole auth method

B.Username & Password auth method

C.GitHub auth method

D.OIDC auth method

AnswerA

AppRole is designed for machine-to-machine authentication and is ideal for CI/CD pipelines. It uses a role_id and secret_id, which can be delivered securely and have short TTLs. This avoids embedding long-lived tokens. The pipeline can retrieve a secret_id dynamically (e.g., from a trusted orchestrator) and authenticate to get a short-lived Vault token.

Why this answer

AppRole is purpose-built for machine-to-machine authentication, including CI/CD pipelines. It uses a role_id and secret_id that can be delivered securely and have short TTLs, avoiding long-lived tokens. Other methods either require interactive user flows or static credentials unsuitable for the scenario.

Exam trap

The trap here is selecting OIDC because it sounds modern, but OIDC is for human users, not headless CI/CD pipelines.

Practice this question →

38

MCQhard

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?

A.Create a unique AppRole role for each application

B.Schedule periodic secret ID rotation

C.Reduce the token TTL to 1 minute

D.Add CIDR bindings to the AppRole role

AnswerA

Splitting the shared role into one AppRole per application isolates each SecretID, so revoking a single compromised application's role no longer invalidates credentials used by the other hundreds of applications. This directly resolves the stem's stated inability to revoke access individually.

Why this answer

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.

Exam trap

The trap here is that candidates often choose secret rotation (Option B) as a security best practice, but they fail to recognize that rotation does not solve the fundamental problem of shared credentials and lack of isolation between applications.

How to eliminate wrong answers

Option B is wrong because periodic secret ID rotation does not solve the problem of a single compromised application affecting others; all applications still share the same role, so rotating the secret ID would disrupt all applications simultaneously. Option C is wrong because reducing the token TTL to 1 minute only limits the lifespan of tokens, but it does not isolate applications; a compromised application could still continuously re-authenticate and access resources, and revoking its access would still require revoking the entire role. Option D is wrong because adding CIDR bindings restricts the source IP addresses that can authenticate, but if multiple applications share the same role and originate from different IPs, this could block legitimate traffic; more importantly, it does not allow selective revocation for a single compromised application.

Practice this question →

39

MCQmedium

An operator manages a Vault cluster where several auth methods are enabled at different paths. A developer reports that logging in with the Kubernetes auth method succeeds, but the resulting token has no permissions. The operator confirms the role exists and the service account JWT is valid. Which configuration element is most likely missing?

A.The Kubernetes auth method was enabled at a non-default path, so the policies attached to the role are unreachable.

B.The Vault server's service account lacks RBAC permission to read the TokenReview API in the Kubernetes cluster.

C.The Vault token TTL is shorter than the Kubernetes service account token lifetime, causing immediate expiry.

D.A bound_service_account_names or bound_service_account_namespaces restriction that does not match the workload, or a role that grants no policies.

AnswerD

A Kubernetes auth role must bind the incoming service account JWT to expected service account names and namespaces; if those bindings do not match the pod, login is rejected. Conversely, if the bindings match but the role lists no token_policies, Vault issues a token with only default policy rights, producing the reported no-permissions symptom even though authentication appears to succeed.

Why this answer

A successful Kubernetes login that yields an unprivileged token points to role configuration: either the service account bindings silently exclude the workload, or the role carries no token_policies. Verifying bound_service_account_names, bound_service_account_namespaces, and the role's policy list resolves both variants of the problem.

Exam trap

The trap here is assuming a successful login implies correct authorization, when a role can authenticate a workload yet attach no policies to the issued token.

Practice this question →

40

MCQmedium

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?

A.The OIDC role is misconfigured

B.The client's OIDC token is expired

C.The OIDC provider is down

D.Vault's OIDC cache has old JWKS keys

AnswerD

Vault caches the provider's JWKS to validate OIDC ID token signatures, and that cache persists until its TTL expires. After key rotation, cached keys no longer match the token's `kid`, so signature validation fails until Vault refetches the JWKS. This directly explains the validation failures affecting some users immediately after rotation.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between token expiration (which is a time-based claim validation) and key rotation (which is a cryptographic signature validation failure), leading candidates to incorrectly choose the expired token option when the real issue is stale cached keys.

How to eliminate wrong answers

Option A is wrong because the OIDC role configuration (e.g., allowed redirect URIs, bound claims) does not change when the provider rotates keys; a misconfigured role would cause consistent failures, not a sudden failure after key rotation. Option B is wrong because an expired token would produce a different error (e.g., 'token is expired' or 'token used before issued'), not a generic OIDC response validation failure, and the issue is tied to key rotation timing. Option C is wrong because if the OIDC provider were down, Vault would not be able to fetch the JWKS at all, leading to a connection timeout or discovery failure, not a signature validation failure on a response that was received.

Practice this question →

41

MCQmedium

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

A.Okta

B.AppRole

C.Userpass

D.LDAP

AnswerD

LDAP binds Vault directly to Active Directory, letting users authenticate with their existing corporate domain credentials rather than separate Vault tokens. This satisfies the stem's requirement for Active Directory-backed authentication, since LDAP queries AD as the identity source. Microsoft Entra ID would not meet the on-premises AD constraint here.

Why this answer

LDAP (Lightweight Directory Access Protocol) is the correct choice because it enables Vault to authenticate users against an external corporate Active Directory (AD) server. Vault's LDAP auth method binds to the AD directory using a service account, then validates user credentials via a simple bind operation, allowing seamless integration with existing corporate identity infrastructure.

Exam trap

HashiCorp often tests the misconception that any external identity provider (like Okta) is the default choice for AD integration, but the question specifically asks for the authentication method that directly uses corporate Active Directory credentials, which is LDAP.

How to eliminate wrong answers

Option A is wrong because Okta is a third-party identity provider (IdP) that uses OIDC/SAML, not a direct authentication method for Active Directory; it would require additional configuration and is not the native AD integration method. Option B is wrong because AppRole is a machine-to-machine authentication method that uses role IDs and secret IDs, designed for applications and automation, not for human users with corporate credentials. Option C is wrong because Userpass is a built-in Vault auth method that stores usernames and passwords locally within Vault's internal storage, not against an external corporate Active Directory.

Practice this question →

42

MCQeasy

An administrator wants to allow users to authenticate to Vault using their existing corporate GitHub accounts. Which authentication method should be enabled?

A.LDAP

B.Okta

C.Username & password (userpass)

D.GitHub

AnswerD

GitHub auth lets users authenticate with existing corporate GitHub accounts via OAuth, mapping GitHub team membership to Vault policies. It directly satisfies the requirement to reuse corporate GitHub credentials rather than issuing separate Vault credentials.

Why this answer

The GitHub authentication method in Vault allows users to authenticate using their existing corporate GitHub accounts by mapping GitHub teams to Vault policies. This is the only option that directly integrates with GitHub's OAuth-based authentication flow, enabling single sign-on without requiring additional directory services or identity providers.

Exam trap

HashiCorp often tests the distinction between 'direct integration' (GitHub auth method) and 'federation via an identity provider' (Okta, LDAP), leading candidates to confuse Okta or LDAP as valid options for GitHub authentication.

How to eliminate wrong answers

Option A is wrong because LDAP is used for authenticating against an LDAP directory (e.g., Active Directory or OpenLDAP), not against GitHub accounts. Option B is wrong because Okta is a third-party identity provider that integrates via OIDC/SAML, not a direct GitHub authentication method. Option C is wrong because username & password (userpass) is a built-in Vault auth method for local users, not for federating with external GitHub accounts.

Practice this question →

43

MCQhard

A security engineer is comparing the AppRole and Kubernetes auth methods for a containerized application. The application runs in a Kubernetes cluster and needs to authenticate to Vault. The engineer wants to minimize the risk of secret leakage and avoid manual secret rotation. Which statement best describes the advantage of Kubernetes auth over AppRole in this scenario?

A.Kubernetes auth automatically rotates the Vault token every 24 hours without any configuration.

B.AppRole is always more secure because it supports CIDR binding, while Kubernetes auth does not.

C.Kubernetes auth uses a service account token that is automatically mounted and rotated by Kubernetes, eliminating the need to store a static secret_id.

D.Kubernetes auth requires a secret_id that is stored in a Kubernetes Secret and manually rotated.

AnswerC

Kubernetes auth leverages the pod's service account token, which Kubernetes automatically mounts and rotates. This eliminates the need to store a static secret_id as with AppRole. The application does not manage any long-lived secret, reducing leakage risk and manual rotation overhead. This directly addresses the engineer's goals.

Why this answer

Kubernetes auth uses the pod's service account token, which Kubernetes automatically mounts and rotates. This removes the need to store a static secret_id, reducing leakage risk and manual rotation. AppRole requires a secret_id that must be protected and rotated, making Kubernetes auth advantageous in this containerized scenario.

Exam trap

The trap here is assuming AppRole is always more secure due to CIDR binding, overlooking that Kubernetes auth eliminates static secrets entirely.

Practice this question →

44

Multi-Selecthard

Which THREE of the following are true statements about the AppRole authentication method? (Choose three.)

Select 3 answers

A.The Secret ID contains the token policies

B.Vault can generate a wrapped Secret ID for secure delivery

C.CIDR bindings can restrict which IP addresses can use the Secret ID

D.The Role ID is analogous to a username

E.The Secret ID can only be used once

AnswersB, C, D

Response wrapping lets Vault issue a single-use token carrying the Secret ID, so the credential is never exposed in transit or logs. This satisfies the stem's secure-delivery requirement: the wrapping token can be unwrapped only once, by the intended role, before the Secret ID is revealed.

Why this answer

Option B is correct because Vault's AppRole auth method supports response wrapping: the Secret ID can be returned as a wrapped response, and the single-use wrapping token is delivered to the target application so the Secret ID is never exposed in plaintext in transit. Option C is correct because a Secret ID can have CIDR bindings (secret_id_bound_cidrs) that restrict the source IP addresses allowed to use that Secret ID during login, adding a network-layer constraint. Option D is correct because the Role ID is a non-secret, stable identifier that the application presents at login, functioning much like a username, while the Secret ID acts as the corresponding secret credential.

Option A is not correct because token policies are attached to the AppRole role/token, not embedded in the Secret ID itself; the Secret ID is just a credential value. Option E is not correct because a Secret ID is not inherently single-use — it can be used multiple times unless it is created with the single-use property (e.g., via secret_id_num_uses) or is a wrapped response token, which is single-use.

Exam trap

HashiCorp often tests the misconception that the Secret ID is inherently single-use, when in fact its usage count is configurable via the `secret_id_num_uses` parameter, and by default it has unlimited uses.

Practice this question →

45

MCQhard

An administrator is evaluating Kubernetes auth for workloads running in a cluster. A developer asks whether a pod can authenticate by presenting a service account token directly to Vault without Vault contacting the Kubernetes API. Which statement best describes how the Kubernetes auth method actually validates a login?

A.Vault forwards the service account token to the Kubernetes TokenReview API and checks that the returned identity matches the role's bound service account names and namespaces.

B.Vault compares the token against a static list of service account tokens stored in the role definition at configuration time.

C.Vault decodes the service account token as a JWT and trusts its claims without contacting the cluster, provided the issuer matches the configured value.

D.Vault verifies the service account token locally using a public key cached during configuration, so no API call is needed.

AnswerA

During login, Vault calls the Kubernetes TokenReview endpoint using its configured reviewer credentials, then compares the authenticated identity against the role's bound_service_account_names and bound_service_account_namespaces. This design means Vault must reach the API server, and it also means the reviewer token must retain permission to create tokenreviews resources for logins to succeed.

Why this answer

Kubernetes auth validates a login by presenting the supplied service account token to the cluster's TokenReview API and then checking the confirmed identity against the role's bound service account name and namespace. This keeps the cluster authoritative about token validity and requires Vault to reach the API server and hold a reviewer token with tokenreviews permissions.

Exam trap

The trap here is assuming Vault validates service account tokens offline like a JWT, when it actually delegates validation to the Kubernetes TokenReview API on every login.

Practice this question →

46

MCQeasy

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

A.LDAP

B.Username & password (userpass)

C.AppRole

D.Okta

AnswerC

AppRole authenticates machines via a Role ID (shared, non-secret identifier) paired with a Secret ID (dynamically generated, single-use credential). This two-part split satisfies the stem's requirement for a shared secret plus a dynamic secret for machine authentication.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between human-oriented authentication methods (like userpass or LDAP) and machine-oriented methods (like AppRole), so the trap here is assuming that any method using a 'secret' or 'password' is equivalent, when AppRole's unique two-part structure (static Role ID + dynamic Secret ID) is the key differentiator.

How to eliminate wrong answers

Option A is wrong because LDAP authentication in Vault relies on an external LDAP directory service (like Active Directory) to validate user credentials, not on a shared Role ID and dynamic Secret ID. Option B is wrong because the username & password (userpass) method uses a static username and password stored in Vault's internal database, intended for human users, not a two-part system with a dynamic secret. Option D is wrong because Okta authentication uses OAuth/OIDC flows to delegate authentication to the Okta identity provider, and does not involve a Role ID or Secret ID mechanism.

Practice this question →

47

Drag & Dropmedium

Drag and drop the steps to enable AppRole authentication in Vault into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First enable the auth method, then create the role, then retrieve the RoleID, generate a SecretID, and finally login.

Practice this question →

48

MCQhard

A security engineer is comparing two machine-oriented auth methods for workloads running outside Kubernetes. The workloads cannot use cloud instance identity and must not store a long-lived credential on disk. The engineer wants a method where the workload proves possession of a one-time-use credential that can be issued with a very short TTL and limited use count. Which auth method best fits?

A.Userpass, with each workload assigned a dedicated username and a randomly generated password rotated weekly.

B.Token auth, by pre-generating a periodic token with a long period and distributing it to each workload.

C.AppRole, using a secret ID with num_uses set to 1 and a short secret_id_ttl, paired with the role ID.

D.Cert auth, by issuing each workload a client certificate from the organization's internal CA with a one-year validity.

AnswerC

AppRole splits authentication into a role ID (semi-public identifier) and a secret ID (sensitive, one-time-use credential). Setting num_uses to 1 makes the secret ID invalid after a single login, and a short secret_id_ttl bounds its lifetime. This lets a workload retrieve the secret ID at runtime without persisting a long-lived secret, satisfying the possession-of-one-time-credential requirement.

Why this answer

AppRole is the only listed method that separates a non-sensitive role ID from a sensitive secret ID and supports one-time-use semantics via num_uses plus a short secret_id_ttl. The alternatives all require a persistent credential (password, periodic token, or long-lived certificate), which the scenario explicitly rules out.

Exam trap

The trap here is treating token auth as inherently short-lived, when a pre-issued periodic token is effectively a long-lived credential that renews indefinitely.

Practice this question →

49

MCQmedium

An organization uses Kubernetes pods to access Vault. They want to avoid hardcoding any secrets in the pod definition. Which authentication method should they use?

A.LDAP

B.Kubernetes

C.Username & Password

D.AppRole

AnswerB

Vault's Kubernetes auth method validates the pod's projected service account token against the Kubernetes TokenReview API, mapping it to a Vault role and policy. No static credentials are embedded in the pod definition, satisfying the no-hardcoded-secrets constraint.

Why this answer

The Kubernetes authentication method is correct because it allows pods to authenticate to Vault using their service account token, which is automatically mounted into the pod. This eliminates the need to hardcode any secrets in the pod definition, as Vault verifies the token against the Kubernetes API server and issues a temporary Vault token based on the pod's identity.

Exam trap

HashiCorp often tests the misconception that AppRole is the best choice for automated workloads, but the trap here is that AppRole still requires a SecretID to be stored somewhere (e.g., a Kubernetes Secret), whereas Kubernetes auth uses the pod's own identity to eliminate any hardcoded secrets entirely.

How to eliminate wrong answers

Option A is wrong because LDAP authentication requires a username and password or LDAP bind credentials, which would still need to be stored in the pod definition or an external secret store, defeating the purpose of avoiding hardcoded secrets. Option C is wrong because Username & Password authentication requires embedding static credentials in the pod definition or environment variables, directly violating the requirement to avoid hardcoding secrets. Option D is wrong because AppRole requires a RoleID and a SecretID; while the RoleID can be injected via annotations, the SecretID is a sensitive credential that must be stored securely (e.g., in a Kubernetes secret), which still involves hardcoding or managing secrets outside Vault's native pod identity integration.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Compare authentication methods questions.

Start 20-question session