HashiCorp Vault Associate (003) Question 67
Single answer3 Vault tokensA platform team uses Vault to issue tokens for a CI/CD system. They want each pipeline run to receive a short-lived token that automatically expires after the job finishes, but they do not want the CI/CD token to create long-lived child tokens that could outlive the original job. Which token setting best meets this requirement?
- A
Issue a periodic token so it can be renewed indefinitely by the pipeline
- B
Issue a batch token so it can create child tokens without being stored in Vault
- C
Issue an orphan token so it is not affected by parent token revocation
- D
Issue a service token with the no_parent capability disabled so child tokens inherit the parent lifetime
Show answer and explanation
Correct answer: C
Explanation
Vault token parent-child relationships are important for limiting blast radius and ensuring derived credentials do not outlive the original identity. Service tokens participate in the token store and can create child tokens. By preserving the normal parent-child relationship, child tokens are revoked when the parent expires or is revoked, which is a strong fit for short-lived CI/CD use cases. Orphan tokens break that relationship, so they are not suitable when you want automatic downstream revocation. Batch tokens are optimized for scalable, lightweight use cases but cannot create child tokens, so they do not satisfy the child-token control requirement in the way described. Periodic tokens are primarily about renewal behavior, not preventing descendants from outliving the original token. These behaviors are covered in Vault documentation for token types, token hierarchies, and token lifecycle management.
- A. Incorrect.
Incorrect. A periodic token is designed to be renewed repeatedly as long as the client continues renewing it. That is useful for long-running services, but it does not address the requirement to prevent long-lived child tokens. In fact, if renewed, it could extend beyond the intended short CI/CD job lifetime.
- B. Incorrect.
Incorrect. Batch tokens are lightweight and not persisted in the token store, but they are more limited than service tokens. A key limitation is that batch tokens cannot create child tokens. Someone might pick this because it sounds short-lived and efficient, but the question is specifically about controlling child token behavior for a CI/CD token that should not be able to create long-lived descendants.
- C. Correct.
Correct. An orphan token has no parent, so its lifecycle is independent of any parent token. In this scenario, that is the opposite of what the team wants. They want child tokens, if created, to be tied to the CI/CD token's lifetime so they cannot outlive the job. Choosing an orphan token would remove that safety relationship and is therefore not appropriate.
- D. Incorrect.
Correct. A service token is the standard token type for general Vault interactions and can create child tokens. When child tokens have a parent-child relationship, revoking or expiring the parent causes the children to be revoked as well. That directly supports the requirement that anything issued by the CI/CD job should not outlive the original token. This is the best match for the scenario.