HashiCorp Vault Associate (003) Question 91
Single answer3e Explain orphaned tokensA platform team uses Vault to issue temporary tokens to CI/CD jobs. During troubleshooting, an engineer notices that some job tokens continue to exist even after the token that created them has been revoked. The team wants to understand why this happened and what orphaned tokens mean in practice. Which statement best explains this behavior?
- A
The job tokens are orphaned tokens, which do not have a parent token and therefore are not automatically revoked when the creating token is revoked.
- B
The job tokens are batch tokens, and batch tokens are stored in the token store until their parent is revoked.
- C
The job tokens are periodic tokens, which ignore token hierarchies and cannot be revoked through normal token revocation.
- D
The job tokens are root tokens, which remain valid regardless of parent-child relationships in the token tree.
Show answer and explanation
Correct answer: A
Explanation
Vault organizes most service tokens in a parent-child hierarchy. Normally, revoking a parent token also revokes its descendants. Orphaned tokens are an exception: they have no parent, so they are not removed by revoking the token that originally created them. This behavior is important in real environments such as CI/CD, where teams may intentionally create tokens that should outlive a provisioning token or authentication flow. Candidates should recognize that orphaned tokens affect revocation behavior, not token privilege level. HashiCorp Vault documentation on tokens and token hierarchies explains that orphan tokens exist outside the normal parent-child revocation chain, which is why they persist until explicitly revoked or until they expire.
- A. Correct.
Correct. In Vault, orphaned tokens have no parent in the token hierarchy. Because they are not linked to a parent token, revoking the token that originally created or submitted the request does not automatically revoke them through the normal parent-child cascade. This is the key operational behavior the team is observing.
- B. Incorrect.
Incorrect. Batch tokens are a separate token type optimized for scalable, lightweight use cases and are not persisted in the token store the same way service tokens are. The scenario describes behavior tied to token parentage and revocation hierarchy, which is the defining characteristic of orphaned tokens, not batch tokens.
- C. Incorrect.
Incorrect. Periodic tokens are renewable tokens that require renewal within a configured period, but they still can be revoked. Their renewal model does not mean they ignore token hierarchy. Someone might choose this option because periodic tokens have unusual lifecycle behavior, but that is unrelated to why child tokens survive revocation of the creating token.
- D. Incorrect.
Incorrect. Root tokens are highly privileged tokens, but the scenario does not indicate these job tokens have root privileges. A token continuing to exist after its creator is revoked is explained by orphan status, not by being a root token. This distractor targets the misconception that persistence after revocation implies elevated privilege.