HashiCorp Vault Associate (003) Question 69
Single answer3 Vault tokensA platform team is onboarding a CI/CD system to HashiCorp Vault. They want each pipeline run to receive a short-lived token that automatically becomes unusable if the pipeline process exits, and they do not want child tokens created by that pipeline token to outlive it. Which token type best meets these requirements?
- A
A service token, because service tokens support periodic renewal and can be used for long-running workloads
- B
A batch token, because batch tokens are lightweight and intended for high-throughput machine authentication
- C
A root token, because root tokens bypass policy restrictions and are easiest for automation to use
- D
A periodic token, because periodic tokens ignore parent-child relationships and only expire when renewal stops
Show answer and explanation
Correct answer: B
Explanation
For short-lived automated workflows, Vault batch tokens are generally the best fit. They are optimized for high-volume, ephemeral use cases and avoid many of the persistence and feature costs of service tokens. By contrast, service tokens are better when you need features such as renewal, cubbyhole, or full token hierarchy behavior. Root tokens should not be used for routine automation. Periodic describes renewal semantics rather than being the preferred answer to this lifecycle problem. HashiCorp documentation distinguishes service and batch tokens, noting that batch tokens are intended for lightweight machine authentication and short-lived operations, while service tokens are the general-purpose, fully featured token type.
- A. Incorrect.
Incorrect. Service tokens are full-featured tokens that support renewal, cubbyhole, and token creation, but they participate in parent-child token hierarchies. They are not the best fit when the goal is to ensure the token and anything derived from it are tightly bound to the lifecycle of a short-lived process. A candidate might choose this because service tokens are common for applications, but they are heavier-weight and not specifically optimized for this ephemeral use case.
- B. Correct.
Correct. Batch tokens are designed for ephemeral, high-scale machine workflows such as CI/CD jobs. They are lightweight, non-renewable, and do not create storage overhead like service tokens. They are intended for short-lived operations and are suitable when the team wants the token to become invalid after its short TTL without relying on ongoing renewal. In practice, batch tokens are commonly recommended for temporary automated workloads.
- C. Incorrect.
Incorrect. Root tokens should be reserved for initial setup, emergency recovery, or tightly controlled administrative tasks. Using a root token for CI/CD automation is a serious security anti-pattern because it grants unrestricted access and violates least-privilege best practices.
- D. Incorrect.
Incorrect. Periodic tokens are a property related to renewal behavior, not a token type that solves this requirement by itself. A periodic token must be renewed to stay valid and can be useful for certain long-running services, but it does not inherently make the token ideal for short-lived CI/CD jobs. The statement that it ignores parent-child relationships is also incorrect.