HashiCorp Vault Associate (003) Question 30
Single answer1f Configure authentication methods using the API, CLI, and UIA platform engineer must enable GitHub authentication for a Vault cluster so developers can sign in through the UI. The engineer already has a token with permissions to manage auth methods. They want the auth method mounted at the custom path github-dev so it is clearly separated from any future GitHub auth configuration. Which action correctly configures this authentication method?
- A
Run
vault auth enable -path=github-dev githubor send a POST request to/v1/sys/auth/github-devwith{ "type": "github" }; in the UI, enable a new auth method of type GitHub and set the path togithub-dev. - B
Run
vault secrets enable -path=github-dev githubor send a POST request to/v1/sys/mounts/github-devwith{ "type": "github" }; in the UI, add a new secrets engine named GitHub atgithub-dev. - C
Run
vault auth enable github-devbecause the auth type must match the mount path; the API path must be/v1/auth/github-dev/configto create the method. - D
Run
vault login -method=github path=github-devfirst; Vault automatically creates the GitHub auth method at that path when the first user logs in.
Show answer and explanation
Correct answer: A
Explanation
To configure an authentication method in Vault, you must enable it through the auth system interface, not through the secrets engine interface. For CLI usage, the standard pattern is vault auth enable [-path=<mount>] <type>. For API usage, auth methods are enabled with the system auth endpoint at /v1/sys/auth/:path, with a request body that includes the auth method type. In the UI, admins perform the same operation by enabling a new auth method and specifying its path. After the auth method is enabled, additional configuration such as GitHub organization or team mappings would be applied to the auth method's configuration endpoints. This matches Vault best practices and documentation for managing auth methods via CLI, API, and UI.
- A. Correct.
Correct. Authentication methods are enabled under the system auth endpoint, not the secrets engine endpoint. In the CLI,
vault auth enable -path=github-dev githubenables the GitHub auth method at a custom mount path. Using the API, enabling an auth method is done with a POST to/v1/sys/auth/:pathand a payload specifying the auth type, such as{ "type": "github" }. In the UI, administrators can enable an auth method by selecting the auth type and specifying the mount path. This is the correct way to make the GitHub auth method available atgithub-dev. - B. Incorrect.
Incorrect. This confuses auth methods with secrets engines.
vault secrets enableand the/v1/sys/mountsAPI are used to enable secrets engines such as KV, Transit, or PKI, not authentication methods. GitHub is an auth method, so it must be managed withvault auth enableor/v1/sys/auth/.... This is a common mistake because both auth methods and secrets engines are mounted at paths, but they use different commands and API endpoints. - C. Incorrect.
Incorrect.
vault auth enable github-devis not valid for enabling a GitHub auth method at a custom path because the first positional argument is interpreted as the auth type, not the mount path. The auth type isgithub, while the custom path must be set with-path=github-dev. Also,/v1/auth/github-dev/configis used for configuring an already-enabled auth method, not for creating or mounting it. Creation happens under/v1/sys/auth/:path. - D. Incorrect.
Incorrect.
vault login -method=githubis used to authenticate against an auth method that already exists. It does not create or mount the auth method automatically. If the auth method is not enabled first, the login attempt fails because Vault has no auth backend mounted at that path. This distractor reflects a misconception that login workflows can implicitly provision auth backends.