Task 1.1: Define the purpose of authentication methods

• AIts LDAP username and password, which Vault checks against the directory each time

  Incorrect

  Vault delegates the check to LDAP at login only; afterwards the token, not the directory password, authorizes requests.

• BThe entity ID that the login linked to the script's identity

  Incorrect

  An entity ID identifies the client in audit logs and identity policies; it is not a credential that authorizes a request.

• CThe client token that the LDAP login returned

  Correct

  Authentication verifies the identity once and generates a token, conceptually a session ID; every later request presents that token.

• DThe bind DN and password configured on the LDAP auth mount

  Incorrect

  Those are the mount's own credentials for querying the directory; clients never send them.

Every auth method ends the same way: Vault verifies the client against its source of truth and returns a token with the mapped policies. The client then sends that token with each request until it expires or is revoked.

• AThe userpass auth method at auth/userpass/

  Incorrect

  userpass, like most auth methods, must be enabled before use.

• BThe approle auth method at auth/approle/

  Incorrect

  AppRole must be enabled and configured first.

• CThe token auth method at auth/token/

  Correct

  The token method is built in, is the only one that cannot be disabled, and is there from the start.

• DNone, until an operator enables one

  Incorrect

  The token method is always available; the initial root token uses it.

Most auth methods must be enabled before use. The token method is the exception: it is always mounted and cannot be disabled.

• AEnable ldap once and list both directory servers in its url setting

  Incorrect

  Several URLs on one mount are tried as alternatives for one directory, not as two separate directories.

• BEnable the ldap auth method twice, at ldap-corp/ and ldap-partner/

  Correct

  The same type of auth method can be mounted at several paths, each with its own configuration.

• CEnable ldap for corp and userpass for partner, since one type cannot be enabled twice

  Incorrect

  Nothing stops a type from being enabled at more than one path.

• DEnable ldap once and create a group mapping for each directory

  Incorrect

  Group mappings map groups of one directory to policies; they do not connect a second directory.

Auth methods are enabled at paths. Mounting one type at several paths gives each source its own configuration.

• AIt is revoked when the second token is issued

  Incorrect

  Vault does not revoke earlier tokens on a new login.

• BIt becomes the desktop's token as well, since one user has one token

  Incorrect

  Each successful login generates its own token.

• CIts TTL is reset to match the second token's

  Incorrect

  A new login does not touch other tokens' TTLs.

• DIt stays valid; the second login returned a separate token

  Correct

  Authenticating again yields a new token with the same permissions and does not invalidate the first.

Each login is independent: a user can hold several valid tokens at once, each revoked or expired on its own.

• AOnly one login is needed; Vault cannot require several auth methods in sequence

  Correct

  Only one authentication is required, and it is not possible to force a user through multiple auth methods, though some methods support MFA.

• BA role on the LDAP mount that requires a GitHub login first

  Incorrect

  Auth methods cannot be chained; each one issues a token on its own.

• CMounting both methods at the same path for one login that runs both checks

  Incorrect

  Every mount needs its own unique path.

• DSetting the same token_policies on both mounts to issue the token after the second login

  Incorrect

  Matching policies do not link the mounts; each login still returns a token by itself.

Vault supports many auth methods at once, and any single successful login returns a token. Extra factors come from MFA features, not from chaining methods.