HashiCorp Vault Associate (003) Question 12
Single answer1b Choose an authentication method based on use caseA company is deploying HashiCorp Vault for two different client types. First, a set of CI/CD jobs running on GitHub-hosted runners must authenticate to Vault without storing long-lived Vault tokens in the pipeline configuration. Second, a small operations team needs interactive CLI access to Vault using their existing corporate identity provider with MFA enforcement handled outside Vault. Which combination of authentication methods best fits these requirements?
- A
Use the JWT/OIDC auth method for the GitHub Actions jobs and the OIDC auth method for the operations team
- B
Use the token auth method for the GitHub Actions jobs and the userpass auth method for the operations team
- C
Use the AppRole auth method for the GitHub Actions jobs and the token auth method for the operations team
- D
Use the Kubernetes auth method for the GitHub Actions jobs and the LDAP auth method for the operations team
Show answer and explanation
Correct answer: A
Explanation
The key is to choose authentication methods based on the client type and trust source. For ephemeral CI/CD workloads on GitHub-hosted runners, Vault's JWT/OIDC auth method is well suited because Vault can validate the signed identity token issued to the workflow, avoiding static Vault credentials. For human operators, OIDC is commonly the best choice when an organization already uses an external identity provider and wants centralized SSO and MFA policies. In contrast, token auth is not ideal as a primary login mechanism because it requires token distribution beforehand, and userpass duplicates identity management inside Vault. Kubernetes auth is specific to Kubernetes service accounts, and LDAP is more suitable when direct directory authentication is required rather than federated OIDC login. These recommendations align with Vault documentation and best practices to prefer short-lived, identity-based authentication methods over long-lived shared secrets whenever possible.
- A. Correct.
Correct. GitHub Actions can present OIDC/JWT identity tokens to Vault, allowing the pipeline to authenticate dynamically without storing long-lived Vault tokens. For human operators, the OIDC auth method is a strong fit when the organization already has an external identity provider and wants SSO and MFA enforced by that provider. This matches common Vault best practices: use short-lived, externally verifiable identity for machine workflows where available, and use federated identity for interactive human access.
- B. Incorrect.
Incorrect. Using the token auth method for CI/CD jobs usually implies distributing a Vault token to the pipeline ahead of time, which is exactly what the scenario wants to avoid. Userpass is also generally a weaker choice for enterprise operator access when an external identity provider already exists, because it creates separate credentials in Vault rather than integrating with corporate SSO and upstream MFA.
- C. Incorrect.
Incorrect. AppRole can be appropriate for machine authentication in some environments, but it often requires careful handling of RoleID and SecretID and does not directly leverage GitHub-hosted runner identity the way JWT/OIDC does. The second half is clearly a poor fit: token auth is not an authentication system for interactive users tied to corporate identity; it assumes the user already has a token and does not provide SSO or external MFA integration.
- D. Incorrect.
Incorrect. Kubernetes auth is designed for workloads running inside Kubernetes using service account tokens, not for GitHub-hosted runners. LDAP can be a valid human authentication choice in some organizations, but the scenario specifically calls for using the existing corporate identity provider with MFA handled outside Vault; OIDC is the more direct fit for modern SSO/MFA federation in this case.