Knowledge + Practice

CCNA Auth Methods Questions

60 questions · Auth Methods topic · All types, answers revealed

Practice these questions Exam hub All questions

1

MCQhard

A large enterprise uses Azure Active Directory as its identity provider. They want to authenticate users to Vault using Azure AD tokens. However, they require that Vault validate the token's signature and claims without contacting Azure AD every time. Which authentication method should they use?

A.LDAP authentication

B.OIDC authentication

C.Token authentication

D.Azure authentication

AnswerB

OIDC can be configured to use cached JWKS keys, allowing offline validation.

Why this answer

Option B (OIDC authentication) is correct because OpenID Connect (OIDC) allows Vault to validate an Azure AD token's signature and claims locally using the provider's JWKS (JSON Web Key Set) endpoint, without requiring a round-trip to Azure AD for every authentication request. This satisfies the requirement for offline token validation while still leveraging Azure AD as the identity provider.

Exam trap

HashiCorp often tests the distinction between OIDC (which supports offline token validation via JWKS) and the Azure auth method (which relies on Azure-specific MSI tokens and requires online calls), leading candidates to mistakenly choose 'Azure authentication' when the question explicitly requires no contact with Azure AD.

How to eliminate wrong answers

Option A is wrong because LDAP authentication is designed for direct binding to an LDAP directory (like Active Directory on-premises) and cannot validate Azure AD tokens or perform OIDC-based token signature verification. Option C is wrong because token authentication in Vault uses Vault's own internal token system, not external Azure AD tokens, and requires Vault to manage the token lifecycle rather than validating third-party tokens. Option D is wrong because 'Azure authentication' is not a standard Vault auth method; Vault's Azure auth method uses Azure Managed Service Identity (MSI) tokens for VMs, not user Azure AD tokens, and it validates tokens by calling the Azure Instance Metadata Service (IMDS) or Azure Resource Manager, not by local signature verification.

Practice this question →

2

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

Uses EC2 instance metadata to sign a request, no secrets stored.

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 →

3

MCQeasy

Which authentication method allows a user to authenticate using a one-time password (OTP) generated by an authenticator app?

A.Okta

B.Userpass

C.GitHub

D.LDAP

AnswerA

Okta supports TOTP via the Okta API.

Why this answer

Okta supports Time-based One-Time Password (TOTP) as an authentication factor, which is the standard method used by authenticator apps like Google Authenticator or Microsoft Authenticator. TOTP generates a temporary code based on a shared secret and the current time, as defined in RFC 6238, and Okta's multifactor authentication (MFA) policies can require this OTP for user login. This makes Okta the correct choice for authenticating with an OTP from an authenticator app.

Exam trap

HashiCorp often tests the distinction between an authentication method (like Okta's TOTP) and a protocol or service that can be used as an identity provider but does not natively generate OTPs, leading candidates to confuse GitHub's OAuth or LDAP's directory lookups with actual OTP generation.

How to eliminate wrong answers

Option B (Userpass) is wrong because it refers to a simple username/password authentication method in HashiCorp Vault, which does not generate or use one-time passwords from an authenticator app. Option C (GitHub) is wrong because GitHub authentication typically uses OAuth tokens or SSH keys, not OTPs from an authenticator app, though it can support TOTP as a second factor, the question asks for the authentication method itself, not a service that can be configured with MFA. Option D (LDAP) is wrong because LDAP is a directory protocol for verifying static credentials (username and password) against a directory server, and it has no built-in mechanism for generating or validating time-based one-time passwords.

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

Designed for humans using SSO.

Why this answer

OIDC (OpenID Connect) is an identity layer built on top of OAuth 2.0 that allows human users to authenticate via an external identity provider (IdP) using tokens (ID tokens in JWT format). It is specifically designed for human user authentication, enabling single sign-on (SSO) across applications.

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 allows instances to authenticate using IAM roles without storing static credentials.

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

Multi-Selectmedium

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

Select 3 answers

A.Kubernetes authentication

B.Userpass authentication

C.AppRole authentication

D.Token authentication

E.LDAP authentication

AnswersB, D, E

Userpass creates tokens with configurable TTL and renew.

Why this answer

Userpass authentication (B) is correct because Vault's userpass auth method supports token generation with configurable TTL (time-to-live) and renewable options via the `token_ttl` and `token_renewable` parameters in the auth method configuration or role settings. This allows administrators to enforce session lifetimes and permit token renewal for user accounts authenticated via username/password.

Exam trap

HashiCorp often tests the misconception that all auth methods inherently support TTL and renewable options, but in Vault, only methods that generate a token (like userpass, LDAP, and token auth) directly support these parameters, whereas methods like Kubernetes rely on role-level configuration and do not expose TTL/renewable as native auth method settings.

Practice this question →

7

Matchingmedium

Match each Vault secret engine to its primary purpose.

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

Concepts

Matches

Key-value storage with versioning

Dynamic AWS IAM credentials

X.509 certificate generation

Encryption as a service

Dynamic database credentials

Why these pairings

These are common Vault secret engines and their core functions.

Practice this question →

8

Multi-Selectmedium

Which TWO authentication methods allow a machine to authenticate without storing a static secret? (Choose two.)

Select 2 answers

A.LDAP

B.AppRole

C.Kubernetes

D.Userpass

E.AWS

AnswersC, E

Kubernetes auth uses the pod's service account token, no static secret.

Why this answer

Kubernetes authentication in Vault uses the Kubernetes service account token (a JWT) to authenticate. The JWT is dynamically generated by the Kubernetes API server and is not a static secret stored by the machine; Vault verifies it against the Kubernetes API server's token review endpoint. This allows the machine to authenticate without storing a long-lived static credential.

Exam trap

HashiCorp often tests the misconception that AppRole is a 'secretless' method, but in reality, the RoleID is a static secret that must be stored, and the SecretID, while dynamic, still requires secure distribution, making it not truly stateless.

Practice this question →

9

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 is purpose-built for pods to authenticate using service account tokens.

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 →

10

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 mounted at prod/.

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 →

11

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 teams to policies is required to enforce membership.

Why this answer

Option D is correct because 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 →

12

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

Userpass requires explicit policy assignment; without it, no policies are attached.

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 →

13

Multi-Selecthard

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

Select 2 answers

A.AppRole requires a role_id and secret_id, while Kubernetes requires a service account token.

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

C.Kubernetes authentication uses JWT tokens that are signed by the Kubernetes API server.

D.Both AppRole and Kubernetes support response wrapping for initial credentials.

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

AnswersA, C

AppRole uses two components; Kubernetes uses a single token.

Why this answer

Option A is correct because AppRole authentication indeed requires a RoleID and SecretID to be presented by the client to obtain a Vault token, whereas Kubernetes authentication requires a service account token (a JWT) that is signed by the Kubernetes API server. This is a fundamental difference in the credential material each method uses to prove identity.

Exam trap

HashiCorp often tests the misconception that both methods use a similar two-factor credential model, but the trap is that Kubernetes authentication relies solely on a signed JWT from the Kubernetes API server, not a separate secret_id, and that AppRole tokens are not inherently batch tokens.

Practice this question →

14

MCQhard

A security team notices that some Vault users are authenticating with the Userpass auth method, but they want to enforce password complexity and expiration. What is the best approach?

A.Migrate users to an external identity provider and use LDAP or OIDC auth.

B.Switch to token-based authentication and issue tokens with TTL.

C.Use Vault's password policy plugin with Userpass.

D.Configure password policies in Vault's Userpass auth method.

AnswerA

External IDPs can enforce password policies; Vault can leverage them.

Why this answer

The Userpass auth method in Vault does not natively support password complexity or expiration policies. Migrating to an external identity provider (IdP) via LDAP or OIDC allows the organization to enforce these policies externally, where they are natively supported, and then federate authentication into Vault. This approach leverages the IdP's mature password management capabilities while maintaining Vault's authorization and audit controls.

Exam trap

HashiCorp often tests the misconception that Vault's built-in auth methods (like Userpass) can be extended with plugins or policies to enforce password rules, when in reality Vault delegates such policy enforcement to external identity providers.

How to eliminate wrong answers

Option B is wrong because switching to token-based authentication does not enforce password complexity or expiration; tokens are ephemeral credentials issued after authentication, not a replacement for password policies. Option C is wrong because Vault does not have a 'password policy plugin' for Userpass; password policies are a separate feature but are not directly enforceable within the Userpass auth method itself. Option D is wrong because Vault's Userpass auth method does not support configuring password complexity or expiration policies; it only stores hashed passwords and lacks built-in policy enforcement.

Practice this question →

15

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

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

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 →

16

Multi-Selecteasy

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

Select 3 answers

A.OIDC

B.LDAP

C.SAML

E.AppRole

AnswersA, B, E

OIDC is built-in.

Why this answer

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

Exam trap

HashiCorp often tests the distinction between 'built-in' and 'plugin-based' authentication methods, and the trap here is that candidates mistakenly assume SAML is built-in because it is a common enterprise protocol, but Vault requires a separate plugin for SAML support.

Practice this question →

17

Multi-Selectmedium

Which TWO of the following are valid authentication methods in HashiCorp Vault? (Choose two.)

Select 2 answers

A.GitHub

B.SAML

D.Cloud Foundry

AnswersA, D

GitHub is a valid auth method.

Why this answer

GitHub is a valid authentication method in HashiCorp Vault. It allows users to authenticate using their GitHub personal access tokens, which are mapped to Vault policies based on the user's team membership in a specified GitHub organization. This method is commonly used for integrating Vault with existing GitHub workflows.

Exam trap

HashiCorp often tests the distinction between authentication methods (how you prove identity to Vault) and secrets engines (how Vault generates or stores secrets), leading candidates to mistakenly select SSH or other secrets-engine-related options as authentication methods.

Practice this question →

18

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

Users authenticate but need group-policy mapping to have permissions.

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 →

19

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

Uses external IdP for authentication, no password stored in Vault.

Why this answer

OIDC authentication delegates authentication to an external IdP, Vault never sees the password. LDAP stores hashed passwords at rest, userpass stores hashed passwords, and token is Vault-native.

Practice this question →

20

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

Kubernetes auth uses the pod's service account token.

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 →

21

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

Group membership check fails after bind.

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 →

22

MCQhard

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?

A.The service account was deleted

B.The Vault role's bound_service_account_names is incorrect

C.The Vault server's Kubernetes API address changed

D.The issuer in the Vault configuration does not match the new cluster issuer

AnswerD

Vault's configuration must match the cluster's issuer, which may change on upgrade.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between authentication failures (issuer mismatch, token validation) and authorization failures (role bindings, service account names), so candidates mistakenly choose Option B when the error message explicitly points to the JWT issuer.

How to eliminate wrong answers

Option A is wrong because deleting the service account would cause a different error (e.g., 'service account not found' or 'token not found'), not a JWT issuer validation error. Option B is wrong because `bound_service_account_names` controls authorization (which service accounts are allowed to use a role), not the JWT issuer validation; an incorrect role binding would result in a permission denied error, not an issuer error. Option C is wrong because if the Vault server's Kubernetes API address changed, the error would be a connection or TLS error (e.g., 'dial tcp: lookup' or 'x509: certificate is valid for'), not a JWT issuer validation error.

Practice this question →

23

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

The secret_id is used only during login; once the token is issued, it is separate.

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 →

24

MCQeasy

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

A.Token authentication

B.LDAP authentication

C.AWS IAM authentication

D.Userpass authentication

AnswerC

AWS IAM auth uses instance metadata service to obtain a signed identity, no secrets stored in code.

Why this answer

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

Exam trap

HashiCorp often tests the misconception that token authentication is stateless and secret-free, but the trap here is that tokens themselves are secrets that must be stored and rotated manually, whereas AWS IAM authentication leverages cloud-native identity federation to eliminate stored secrets entirely.

How to eliminate wrong answers

Option A is wrong because token authentication requires a Vault token to be stored somewhere (e.g., in a file or environment variable), which means a secret is still present in source code or configuration, and tokens do not automatically rotate unless explicitly managed. Option B is wrong because LDAP authentication requires storing LDAP credentials (username/password) in source code or configuration, and those credentials are long-lived with no built-in automatic rotation mechanism. Option D is wrong because userpass authentication requires storing a username and password in source code or configuration, and those credentials are static unless manually rotated, which defeats the requirement of no stored secrets and automatic rotation.

Practice this question →

25

MCQhard

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?

A.Update the Vault role to include the policy 'payments-read' in the token_policies parameter.

B.Increase the TTL of the Vault token to give more time for the secret read.

C.Add the microservice's service account to the bound_service_account_names of an existing role that works.

D.Change the authentication method to AppRole for the payment microservice.

AnswerA

The role must specify which policies to attach.

Why this answer

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.

Exam trap

HashiCorp often tests the distinction between creating a policy and attaching it to a role; the trap here is assuming that simply having a policy with the correct path is sufficient, when in fact the policy must be explicitly referenced in the role's `token_policies` parameter.

How to eliminate wrong answers

Option B is wrong because increasing the TTL does not affect permissions; it only extends the token's validity period, which is irrelevant to a permissions error. Option C is wrong because adding the service account to an existing role that works would grant the same policies as that role, but those policies may not include read access to `secret/data/payments/*`, and it would bypass the intended role isolation. Option D is wrong because changing to AppRole is unnecessary; the Kubernetes auth method is already functioning for authentication, and the issue is purely a policy attachment problem, not an authentication method flaw.

Practice this question →

26

Multi-Selectmedium

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

Select 2 answers

A.AWS IAM authentication

B.Token authentication

C.Userpass authentication

D.LDAP authentication

E.Kubernetes authentication

AnswersC, D

Userpass can be configured with MFA by adding an MFA method.

Why this answer

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

Exam trap

HashiCorp often tests the distinction between 'native MFA support' (where the auth method itself can be configured with MFA without external plugins) versus 'MFA can be added externally' (which is possible for all auth methods via login MFA enforcement, but not native to the method).

Practice this question →

27

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 is ideal for non-human clients like CI/CD pipelines.

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 →

28

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

Incorrect bind credentials cause bind failures.

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 →

29

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

secret_id_num_uses limits the number of times a SecretID can be used.

Why this answer

Option D is correct because 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 →

30

MCQmedium

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?

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

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

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

D.Vault's AWS auth method must be configured with the correct region for instance identity validation.

AnswerD

Vault needs to know the region to verify the identity document.

Why this answer

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

Configuring the auth method with the correct region (or a wildcard) allows Vault to validate identity documents from multiple regions.

Exam trap

HashiCorp often tests the misconception that IAM roles are region-specific or that a separate Vault role is needed per region, when the actual issue is the region configuration in the AWS auth method's identity validation logic.

How to eliminate wrong answers

Option A is wrong because the IAM role 'ec2-app-role' is a global AWS resource; IAM roles are not region-specific, so the role exists in all regions. Option B is wrong because the instance already has an IAM role associated; an instance profile is automatically created and attached when an IAM role is assigned to an EC2 instance, and the issue is not about missing instance profiles. Option C is wrong because creating a new Vault role is unnecessary; the existing Vault role can authenticate instances from any region as long as the auth method's region configuration is correct, and the bound_iam_role_arn already matches the role.

Practice this question →

31

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

Group names must match exactly.

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 →

32

MCQhard

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?

A.The second instance does not have the IAM role attached to its instance profile

B.The Vault server's AWS credentials are expired

C.The Vault role for AWS auth is configured with a wrong bound IAM role ARN

D.The IAM role's trust policy does not allow Vault to assume the role

AnswerA

Without the role in the instance profile, the instance cannot sign the request.

Why this answer

Option A is correct because the second instance likely does not have the IAM role 'app-role' attached to its instance profile. For Vault's AWS IAM auth method, the EC2 instance must have the IAM role attached to its instance profile at launch time; the Vault server uses the instance's credentials (via the instance metadata service) to verify the role. If the role is not attached, the instance cannot present valid credentials for authentication, resulting in a permission denied error even though the Vault server and AWS account are healthy.

Exam trap

HashiCorp often tests the distinction between an IAM role being attached to an instance profile versus simply existing in the account, leading candidates to overlook the instance profile attachment requirement and incorrectly blame Vault configuration or trust policies.

How to eliminate wrong answers

Option B is wrong because the question states the Vault server and AWS account are healthy, which implies the Vault server's AWS credentials (used to call AWS STS) are valid and not expired. Option C is wrong because if the Vault role for AWS auth were configured with a wrong bound IAM role ARN, both instances would fail authentication, not just one. Option D is wrong because the IAM role's trust policy controls whether Vault can assume the role (for Vault's own AWS credentials), not whether an EC2 instance can authenticate via the AWS auth method; the trust policy is irrelevant to the instance's authentication flow.

Practice this question →

33

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

AWS auth uses instance metadata, no secrets stored.

Why this answer

Option B (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 →

34

Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

Enable, configure, create role, deploy pod, verify login.

Practice this question →

35

MCQhard

A financial services company runs a microservices architecture on Kubernetes. Each microservice needs to authenticate to Vault to retrieve database credentials. The security team mandates that no secrets (tokens, passwords, certificates) be stored in container images or Kubernetes secrets. They also require that each microservice can only access its own secrets. The platform team is evaluating authentication methods. They consider using AppRole, but are concerned about distributing the SecretID. They also consider Kubernetes auth, but are unsure how to restrict access per microservice. They test with a Kubernetes deployment and find that any pod in the namespace can authenticate to Vault. What should they do to meet all requirements?

A.Use Kubernetes auth with a single role for the namespace, and rely on token TTL to limit exposure.

B.Use AppRole with a unique RoleID and SecretID per microservice, distribute via Kubernetes secrets.

C.Use TLS cert auth, generate a certificate per microservice, and mount as a secret.

D.Use Kubernetes auth, create a role per microservice, bind to specific service account names, and assign appropriate policies.

AnswerD

Kubernetes auth can bind to specific service accounts, and policies enforce access.

Why this answer

Option D is correct because Kubernetes auth allows Vault to authenticate pods via their service account tokens, and by creating a separate Vault role per microservice bound to a specific Kubernetes service account name, each pod can only authenticate to its designated role. This ensures that only pods with the correct service account can retrieve their own secrets, meeting the requirement that no secrets are stored in images or Kubernetes Secrets and that access is restricted per microservice.

Exam trap

The trap here is that candidates may think Kubernetes auth cannot restrict access per pod, but Cisco tests that by binding Vault roles to specific service account names (not just namespaces), you achieve per-microservice isolation without storing any secrets in the cluster.

How to eliminate wrong answers

Option A is wrong because using a single role for the entire namespace would allow any pod in that namespace to authenticate and access all secrets, violating the requirement that each microservice can only access its own secrets. Option B is wrong because distributing the SecretID via Kubernetes Secrets violates the mandate that no secrets be stored in Kubernetes Secrets, and it also introduces the same distribution problem the team was concerned about. Option C is wrong because TLS cert auth would require distributing certificates to each pod, which again involves storing secrets (the private keys) in the container image or as Kubernetes Secrets, violating the mandate.

Practice this question →

36

MCQmedium

A security administrator notices that a Vault client using AppRole authentication is generating a very large number of tokens, causing performance issues. The administrator finds that the same AppRole role is used by multiple applications. What should the administrator do to reduce the number of tokens while maintaining security?

A.Decrease the token TTL on the AppRole role

B.Periodically rotate the secret ID

C.Create separate AppRole roles for each application

D.Set secret_id_num_uses to 1 on the AppRole role

AnswerC

This allows distinct secret IDs and token limits per application.

Why this answer

Option B is correct because creating separate AppRole roles for each application allows better control and reduces token blast radius. Option A is wrong because increasing secret_id_num_uses doesn't limit token count per use. Option C is wrong because decreasing token TTL might cause more frequent renewal but not reduce total token count necessarily.

Option D is wrong because periodically rotating secret IDs doesn't limit token generation.

Practice this question →

37

MCQhard

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?

A.The system backend is configured with a max_ttl that overrides the mount setting.

B.The user has a custom `ttl` set in the userpass configuration for user 'john'.

C.The mount token_ttl is only applied if the user does not specify a `token_policies` parameter.

D.The token was issued with a periodic token and ignores the TTL.

AnswerB

Userpass allows per-user TTL settings that override the mount default.

Why this answer

Option B is correct because the userpass mount allows per-user TTL overrides via the `token_ttl` parameter when creating or updating a user. Even though the mount has a default `token_ttl=24h`, if user 'john' was configured with a specific `token_ttl` of 768 hours, that per-user setting takes precedence over the mount-level default. This is a common way to grant specific users longer token lifetimes without changing the mount's default policy.

Exam trap

HashiCorp often tests the misconception that mount-level settings are absolute, when in fact per-user or per-role overrides can extend token lifetimes beyond the mount's default TTL.

How to eliminate wrong answers

Option A is wrong because the system backend's `max_ttl` sets an upper limit on token lifetimes, but it cannot extend a token beyond the mount's configured TTL; it only caps it. Option C is wrong because the mount `token_ttl` is applied regardless of whether the user specifies `token_policies`; the TTL and policies are independent parameters. Option D is wrong because a periodic token has no explicit TTL and instead relies on a `period` setting, and the output shows a specific duration (768 hours), not a periodic token behavior.

Practice this question →

38

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

Uses the pod's service account token, no manual credential management.

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 →

39

MCQmedium

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?

A.Set secret_id_num_uses to 0 to allow unlimited uses.

B.Create separate AppRoles for each pipeline job.

C.Use response wrapping for the secret ID delivery to ensure each job gets a unique wrapped token.

D.Increase secret_id_ttl to a high value like 24h.

AnswerC

Response wrapping creates a one-time use token independent of secret_id_num_uses.

Why this answer

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

Exam trap

HashiCorp often tests the misconception that increasing TTL or usage limits solves concurrency issues, but the real problem is the race condition inherent in generating and consuming single-use secret IDs concurrently, which response wrapping resolves by providing unique, atomic delivery.

How to eliminate wrong answers

Option A is wrong because setting secret_id_num_uses to 0 (unlimited) would allow any number of uses per secret ID, but it does not address the race condition where concurrent jobs generate and consume secret IDs simultaneously; the underlying issue is contention, not usage limits. Option B is wrong because creating separate AppRoles for each pipeline job would require significant administrative overhead and does not scale; the problem is not the number of roles but the concurrent use of a single role with single-use secret IDs. Option D is wrong because increasing secret_id_ttl to 24h does not resolve the 'secret ID is used' error; the error occurs because the secret ID is consumed by another job, not because it has expired, and the TTL is already unlimited (0).

Practice this question →

40

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

These are Vault Enterprise replication modes.

Practice this question →

41

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

Correct: JWT/OIDC allows token exchange without storing static secrets.

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 →

42

MCQmedium

An administrator needs to enable authentication method for human users that integrates with an existing LDAP directory. The company wants to ensure that Vault can perform group-based policy assignment based on LDAP group membership. Which configuration step is mandatory to map LDAP groups to Vault policies?

A.Set the 'upndomain' parameter to 'company.com'

B.Set the 'users' attribute to 'sAMAccountName'

C.Set the 'groups' attribute to 'memberOf'

D.Set the 'certificate' parameter with the LDAP server certificate

AnswerC

This tells Vault which LDAP attribute holds group membership.

Why this answer

The 'groups' attribute mapping must be set to point to the LDAP attribute containing group membership. The 'users' attribute is for user mapping, 'upndomain' is for UPN suffix, 'certificate' is for TLS.

Practice this question →

43

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 directly authenticates against AD.

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 →

44

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 is designed for machine authentication.

Why this answer

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

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 →

45

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

Allows revoking a single application's access without affecting others.

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 →

46

MCQhard

An organization uses Vault with the JWT/OIDC authentication method. After configuring the provider, users can authenticate, but the scopes requested do not include the email claim needed for policy mapping. What should the administrator do?

A.Add a policy that uses the email claim

B.Modify the OIDC provider's configuration in Vault

C.Create a custom claim mapping in the OIDC auth method

D.Add the 'email' scope to the OIDC auth method config

AnswerD

Adding the scope requests the email claim from the provider.

Why this answer

The email claim is not included in the JWT because the OIDC provider was not requested to issue it. In OIDC, claims are delivered only when the corresponding scope (e.g., 'email') is included in the authentication request. Adding the 'email' scope to the Vault OIDC auth method configuration ensures the provider returns the email claim, which can then be used for policy mapping.

Exam trap

HashiCorp often tests the distinction between configuring the auth method (Vault side) versus the provider side, and the trap here is that candidates mistakenly think they need to modify the external OIDC provider or create a claim mapping, when the fix is simply adding the missing scope to Vault's OIDC configuration.

How to eliminate wrong answers

Option A is wrong because adding a policy that uses the email claim does not cause the claim to appear in the token; the claim must first be requested via the correct scope. Option B is wrong because modifying the OIDC provider's configuration (the external identity provider) is not the correct action; the administrator must adjust Vault's OIDC auth method configuration to request the 'email' scope. Option C is wrong because custom claim mapping is used to rename or transform claims that are already present, not to request new claims that are missing due to an omitted scope.

Practice this question →

47

MCQeasy

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?

A.The backend will be disabled when Vault starts.

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

C.The admin can enable AppRole at another path without issues.

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

AnswerC

Multiple AppRole mounts can exist at different paths.

Why this answer

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

Exam trap

The trap here is that candidates may think the configuration file's path setting locks the auth method to that specific path, preventing it from being enabled elsewhere, when in fact Vault allows multiple mounts of the same auth method type at different paths.

How to eliminate wrong answers

Option A is wrong because the backend defined in the config file will be enabled at the specified path when Vault starts; it is not disabled. Option B is wrong because the admin does not need to modify the config file to change the path; they can simply enable AppRole at another path via the CLI or API. Option D is wrong because Vault will not fail to start; the path in the config file is used for that specific mount, and enabling AppRole at a different path does not conflict with it.

Practice this question →

48

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's cached JWKS may be outdated after key 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 →

49

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 can connect to Active Directory.

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 →

50

Multi-Selecthard

Which THREE factors contribute to the security of the AppRole authentication method? (Choose three.)

Select 3 answers

A.Keeping the RoleID secret

B.Configuring token policies

C.Setting a secret_id_num_uses limit

D.Binding the SecretID to a specific CIDR block

E.Setting a secret_id_ttl

AnswersC, D, E

Prevents replay attacks.

Why this answer

Option C is correct because setting a `secret_id_num_uses` limit restricts the number of times a SecretID can be used to obtain a token from Vault. This prevents replay attacks and limits the blast radius if a SecretID is leaked, as it becomes invalid after the specified number of uses.

Exam trap

HashiCorp often tests the misconception that the RoleID must be kept secret, but in reality it is the SecretID that must be protected, and the RoleID is analogous to a username.

Practice this question →

51

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 uses GitHub personal access tokens.

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 →

52

MCQmedium

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?

A.vault auth disable userpass/

B.vault auth disable token/

C.vault auth disable ldap/

D.vault auth disable approle/

AnswerB

This disables the token auth method at path token/.

Why this answer

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.

Exam trap

The trap here is that candidates assume the default token method cannot be disabled or confuse it with other auth methods like userpass or LDAP, leading them to select an option that disables a different auth method instead of the correct `token/` path.

How to eliminate wrong answers

Option A is wrong because `userpass/` is not the default token authentication method; it is a separate username/password auth method that may or may not be enabled, and disabling it does not affect the default token method. Option C is wrong because `ldap/` is an LDAP-based auth method, not the default token method, and disabling it would not remove the token auth endpoint. Option D is wrong because `approle/` is an AppRole auth method used for machine-to-machine authentication, not the default token method, and disabling it leaves the default token method intact.

Practice this question →

53

Multi-Selectmedium

Which TWO of the following are differences between using Vault's token auth method and other auth methods? (Choose two.)

Select 2 answers

A.Token auth is always enabled and cannot be disabled

B.Token auth does not support policies

C.Token auth is the only method that can create periodic tokens

D.Token auth cannot be used to create a root token

E.Token auth is typically used for Vault's own internal token management, not for end-user authentication

AnswersA, E

Token auth is the default and can't be disabled.

Why this answer

Token auth is always enabled and cannot be disabled because it is the core authentication mechanism that Vault uses internally to represent all authenticated sessions. Every other auth method ultimately produces a Vault token, making the token auth method the foundational layer that cannot be removed or turned off without breaking Vault's entire authentication model.

Exam trap

HashiCorp often tests the misconception that token auth is just another optional auth method like LDAP or AppRole, when in reality it is the mandatory, always-enabled foundation that all other auth methods depend on.

Practice this question →

54

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 secures the Secret ID.

Why this answer

Option B is correct because Vault supports wrapping the Secret ID in a single-use, time-limited JWT-based response-wrapping token. This allows the Secret ID to be securely delivered to the target application without exposing it in transit, as the wrapping token can be unwrapped only by the intended recipient using a separate unwrap operation.

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 →

55

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

Uses Role ID and Secret ID.

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 →

56

MCQhard

A company is migrating from on-premises to cloud and needs to authenticate applications using short-lived credentials. They have a mix of workloads: some on AWS EC2, some on Kubernetes, and some in their own datacenter. Which Vault authentication method provides a unified solution that works across all these environments without requiring a shared secret?

A.AWS IAM authentication

B.JWT/OIDC authentication

C.Kubernetes authentication

D.AppRole authentication

AnswerB

Supports any workload that can present a valid JWT from a trusted OIDC provider, works across cloud and on-prem.

Why this answer

JWT/OIDC authentication is the correct choice because it provides a unified, standards-based method for verifying identity across AWS EC2, Kubernetes, and on-premises environments without requiring a shared secret. By leveraging OpenID Connect (OIDC) identity tokens issued by trusted providers (e.g., AWS IAM Identity Center, Kubernetes service account token, or an on-premises IdP), Vault can validate the token's signature and claims to authenticate workloads. This eliminates the need for pre-shared secrets or per-environment-specific integrations, making it ideal for heterogeneous deployments.

Exam trap

HashiCorp often tests the misconception that Kubernetes authentication is the only way to authenticate Kubernetes workloads, but the question asks for a unified solution across multiple environments, which JWT/OIDC provides by being environment-agnostic.

How to eliminate wrong answers

Option A is wrong because AWS IAM authentication is specific to AWS environments and cannot authenticate workloads running on Kubernetes or on-premises without additional bridging, and it relies on AWS IAM roles and signed requests, not a unified token standard. Option C is wrong because Kubernetes authentication is limited to Kubernetes clusters and requires a Kubernetes service account token or a kubeconfig, making it unsuitable for EC2 or on-premises workloads. Option D is wrong because AppRole authentication requires a pre-shared secret (RoleID and SecretID) to be distributed to each workload, which contradicts the requirement for short-lived credentials without a shared secret and adds operational overhead for secret distribution.

Practice this question →

57

Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

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 →

58

MCQmedium

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

A.secret_id_num_uses=1

B.secret_id_num_uses=1, secret_id_ttl=1h

C.secret_id_ttl=1h

D.secret_id_num_uses=1, secret_id_ttl=60m

AnswerB

Both settings together ensure single use and expiry.

Why this answer

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

Exam trap

HashiCorp often tests the requirement to combine both parameters when a policy mandates both single-use and TTL, leading candidates to pick a single-parameter option (A or C) or to confuse the TTL format (D) as the primary error.

How to eliminate wrong answers

Option A is wrong because it only sets secret_id_num_uses=1, which enforces single-use but does not enforce the 1-hour expiration, leaving the secret_id potentially valid indefinitely until used. Option C is wrong because it only sets secret_id_ttl=1h, which enforces expiration but does not limit the number of uses, allowing the secret_id to be reused multiple times within the hour. Option D is wrong because while it sets both parameters, it uses '60m' instead of '1h'; although functionally equivalent, the question specifies '1 hour' and the correct Vault syntax for the TTL is '1h' (or '60m' is acceptable but less canonical), and more importantly, the option is listed as 'secret_id_ttl=60m' which is technically correct but the exam expects the exact format '1h' as shown in the correct answer.

Practice this question →

59

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

Kubernetes auth uses the pod's service account token, no hardcoded secrets.

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 →

60

Multi-Selectmedium

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

Select 2 answers

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

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

C.Both support response wrapping for secure delivery of credentials.

D.Kubernetes auth authenticates using a service account JWT token, whereas AppRole uses a RoleID and SecretID.

E.AppRole supports CIDR restrictions on the secret ID, but Kubernetes auth does not.

AnswersD, E

Correct key difference.

Why this answer

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

Exam trap

HashiCorp often tests the misconception that Kubernetes auth requires no secret at all, when in fact the JWT token is a secret credential, and that AppRole cannot be used remotely, when both methods can operate across network boundaries if properly configured.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Auth Methods questions.

Start 20-question session