The token tree and cascading revocation, orphan tokens that survive their creator, the ways to create them, and revoke-orphan.
Study it
Token hierarchies and orphan tokens
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
A deployment service's token creates tokens for 300 workers with vault token create. Rotating the deployment service's own token revoked every worker token and caused an outage. Worker tokens must survive that rotation. The deployment service's policy grants update on auth/token/create and auth/token/create/* only, and must not be given sudo. Which approach works?
ACreate the worker tokens with vault token create -orphan using the current policy
BCreate the worker tokens against a token role that has orphan set to true
CCreate them as batch tokens, since batch tokens never have a parent
DCreate the worker tokens with -period=24h, since periodic tokens outlive their parent
Show the answer and why
ACreate the worker tokens with vault token create -orphan using the current policy
Incorrect
Creating an orphan on auth/token/create needs sudo or root, which the service must not have.
BCreate the worker tokens against a token role that has orphan set to true
Correct
A token role can make its tokens orphans, so they are not revoked with their creator, and using it needs no sudo.
CCreate them as batch tokens, since batch tokens never have a parent
Incorrect
Batch tokens can have parents too; the token type does not decide whether a token is an orphan.
DCreate the worker tokens with -period=24h, since periodic tokens outlive their parent
Incorrect
Being periodic changes renewal, not the token tree; the tokens would still be revoked with the parent.
Revoking a parent revokes its children. Orphan tokens start their own tree; a token role with orphan enabled issues them without granting sudo.