Task 1.6: Configure authentication methods using the API, CLI, and UI

• AExisting userpass tokens keep working until their TTLs run out; only new logins through userpass/ fail

  Incorrect

  Disabling does not wait for TTLs; the method's tokens are revoked immediately.

• BThe command fails while tokens issued by the method are still valid

  Incorrect

  The command does not refuse; it revokes those tokens and waits until revocation completes.

• CEvery token issued through userpass/ is revoked, and those users lose access until they log in again

  Correct

  Disabling an auth method revokes all tokens generated through it, and the command blocks until they are revoked.

• DTokens keep working, and re-enabling userpass/ later restores the users and their passwords

  Incorrect

  Disabling removes the mount and its data, and its tokens are revoked rather than kept.

vault auth disable is immediate for everyone who logged in through that mount. Migrate users first, then disable the old method.

• Avault auth enable corp-ldap

  Incorrect

  The argument is the method type, so corp-ldap is not valid.

• Bvault auth enable -path=corp-ldap ldap

  Correct

  -path sets where the method is mounted, and the argument names the type.

• Cvault auth enable -method=ldap corp-ldap

  Incorrect

  auth enable has no -method flag; the type is the argument.

• Dvault write sys/auth/ldap path=corp-ldap

  Incorrect

  The mount path is part of the sys/auth URL, and the body names the type.

The default path is the type's name; -path changes it and must be unique across auth methods.

• APOST /v1/auth/approle with {"type": "approle"}

  Incorrect

  Paths under auth/ belong to a method once it exists; enabling goes through sys/auth.

• BPOST /v1/sys/mounts/approle with {"type": "approle"}

  Incorrect

  sys/mounts enables secrets engines, not auth methods.

• CPOST /v1/sys/auth/approle with {"type": "approle"}

  Correct

  Auth methods are enabled through sys/auth/<path>, with the method type in the request body.

• DPUT /v1/sys/policy/approle with {"type": "approle"}

  Incorrect

  sys/policy stores ACL policies.

The CLI's vault auth enable calls sys/auth; secrets engines use sys/mounts instead.

• Avault auth tune -default-lease-ttl=72h gh-prod/

  Correct

  auth tune takes the path where the method is enabled and sets its default lease TTL.

• Bvault auth tune -default-lease-ttl=72h github

  Incorrect

  The argument is the enabled path, not the method type.

• Cvault auth enable -path=gh-prod -default-lease-ttl=72h github

  Incorrect

  auth enable creates a new mount and returns an error for a path already in use.

• Dvault write sys/auth/gh-prod default_lease_ttl=72h

  Incorrect

  Writing to sys/auth/<path> enables a method; tuning an existing one goes through sys/auth/<path>/tune.

Tuning changes a mount's settings, such as default and max lease TTLs or token type, without disabling it.

• Avault auth enable -path=userpass/alice userpass

  Incorrect

  That would mount a second userpass method; it does not create a user.

• Bvault policy write alice dev

  Incorrect

  This would upload a policy named alice from a file named dev; it creates no user.

• Cvault write sys/auth/userpass/users/alice password=<pw> token_policies=dev

  Incorrect

  sys/auth manages mounts; users live under auth/userpass/.

• Dvault write auth/userpass/users/alice password=<pw> token_policies=dev

  Correct

  Users are configured under the method's users/ path, with token_policies listing the policies her tokens receive.

After enabling an auth method, configure it under auth/<path>/; users, roles and group mappings all live there.