003 · Domain 1: Authentication methods · 15% of the exam
Task 1.4: Define the purpose of identities and groups
Entities and aliases that tie one person or service to its logins across methods, internal and external groups, policies inherited from entities and groups, and templated policies.
Study it
Entities, aliases and groups: one identity across many logins
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.
Question 1 · choose 1
Alice logs in sometimes through LDAP and sometimes through OIDC. Each method has created its own entity for her, so her personal KV path, templated on identity.entity.id, differs with the login method, and she is counted as two clients. Which change fixes both problems?
APut both of her entities in an internal group and template her path on the group ID
BMerge her logins into one entity that holds one alias on the LDAP mount and one alias on the OIDC mount
CGive her LDAP entity a second alias on the LDAP mount that carries her OIDC username
DTemplate the path on her LDAP alias name, read through the LDAP mount's accessor, instead of the entity ID
Show the answer and why
APut both of her entities in an internal group and template her path on the group ID
Incorrect
The path would match for both logins, but Vault would still see two entities and count two clients.
BMerge her logins into one entity that holds one alias on the LDAP mount and one alias on the OIDC mount
Correct
An entity can hold aliases from different mounts; both logins then resolve to one entity ID and count as one client.
CGive her LDAP entity a second alias on the LDAP mount that carries her OIDC username
Incorrect
An entity cannot have more than one alias for the same auth mount, and an LDAP alias does not match OIDC logins.
DTemplate the path on her LDAP alias name, read through the LDAP mount's accessor, instead of the entity ID
Incorrect
OIDC logins carry no LDAP alias, so the path would still differ, and the second entity remains.
Entities tie one client's accounts across auth methods together through aliases, one alias per mount. Templated policies on the entity ID and client counting both depend on that single entity.
An external group in Vault has an alias for the LDAP group db-admins and carries the db-admin policy. Bob holds a valid token, obtained through the LDAP method, when he is removed from db-admins in the directory. When does his token stop receiving the group's policy?
AAt once, because Vault queries LDAP for group membership on every request
BOnly when an operator removes his entity from the group by hand
COnly when the token expires, because group policies are fixed at issue
DAt his next login or the next renewal of his token
Show the answer and why
AAt once, because Vault queries LDAP for group membership on every request
Incorrect
Vault does not query the directory per request; it updates external group membership only at login or renewal.
BOnly when an operator removes his entity from the group by hand
Incorrect
Manual membership applies to internal groups; external group membership follows the directory.
COnly when the token expires, because group policies are fixed at issue
Incorrect
Identity policies are evaluated at request time, and a renewal already refreshes external membership.
DAt his next login or the next renewal of his token
Correct
Membership of an external group is refreshed from the directory during logins and token renewals, not on every request.
Vault serves as a cache of identity, not its source. For an external group mapped to an LDAP group, a removal in the directory reaches Vault on the user's next login or token renewal.
A contractor logs in through LDAP and through OIDC, and both logins resolve to one identity entity. Her engagement is paused for two weeks: every token tied to that entity must stop working at once, and her access must come back later without re-creating anything. What does Vault provide for this?
ASet disabled to true on her entity until the engagement resumes
BRevoke her current tokens through their accessors before the pause
CRemove her entity from every identity group that grants policies
DLower the max lease TTL on both auth mounts for the two weeks
Show the answer and why
ASet disabled to true on her entity until the engagement resumes
Correct
Tokens associated with a disabled entity cannot be used, but they are not revoked, so setting disabled back to false restores her access.
BRevoke her current tokens through their accessors before the pause
Incorrect
Revocation ends only the tokens that exist now; her next LDAP or OIDC login would issue new tokens that work.
CRemove her entity from every identity group that grants policies
Incorrect
Group policies would go, but her token policies remain and every login still works.
DLower the max lease TTL on both auth mounts for the two weeks
Incorrect
Tuning a mount changes token lifetimes for every user of that mount and does not stop her new logins.
Disabling an entity is a reversible pause: Vault refuses the tokens associated with it but keeps them, and setting disabled back to false restores access.
Group platform has the subgroup sre. Alice's entity is a member of sre only. platform carries the policy infra-read and sre carries the policy oncall. Which group policies does Alice receive?
AOnly oncall, because she is not a direct member of platform
BBoth infra-read and oncall
COnly infra-read, because the parent group's policies override the subgroup's
DNeither, until her entity is added to platform directly
Show the answer and why
AOnly oncall, because she is not a direct member of platform
Incorrect
Indirect membership through a subgroup also grants the parent group's policies.
BBoth infra-read and oncall
Correct
Members of a subgroup are indirect members of the parent and get the policies of both groups.
COnly infra-read, because the parent group's policies override the subgroup's
Incorrect
Group policies add up; none overrides another.
DNeither, until her entity is added to platform directly
Incorrect
No direct membership is needed for inherited policies.
Identity groups can nest. Policies flow down: a subgroup member inherits policies from every group above it.
For audit reports, a team needs to know which value names the entity alias that a Kubernetes auth login creates, with the method's default settings. Which value is it?
AThe service account's name
BThe pod's name
CThe Kubernetes namespace
DThe service account's UID
Show the answer and why
AThe service account's name
Incorrect
The name is available only when alias_name_source is changed from its default.
BThe pod's name
Incorrect
Pods are not used to form the alias name.
CThe Kubernetes namespace
Incorrect
The namespace is a role binding, not the alias name.
DThe service account's UID
Correct
alias_name_source defaults to the service account UID; it can be switched to the service account name.
Each auth method reports its own value to name the alias; for Kubernetes the source is chosen with alias_name_source.