HashiCorp Vault Associate (003) Question 73
Single answer3a Choose between service and batch tokens based on use caseA platform team is integrating HashiCorp Vault with a high-volume API gateway. Each incoming client request needs a short-lived Vault token to read one secret, and the team wants to minimize storage overhead on the Vault cluster. The token does not need to create child tokens, renew itself, or be looked up later. Which token type is the best fit for this use case?
- A
Use a service token, because service tokens are required for any token that reads secrets from Vault
- B
Use a batch token, because batch tokens are intended for lightweight, high-scale, short-lived use cases with minimal storage impact
- C
Use a service token, because batch tokens cannot be used for secret access and only support authentication workflows
- D
Use a batch token, because batch tokens support renewal and token accessor operations without creating server-side state
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use a batch token. In Vault, service tokens are the default stateful tokens and support features such as renewal, revocation tracking, accessors, and creating child tokens. Batch tokens are lightweight and intended for high-scale, short-lived workloads where those management features are unnecessary. This makes batch tokens a strong fit for request-per-token patterns, such as API gateways or ephemeral application requests, especially when minimizing storage overhead is a priority. HashiCorp Vault documentation and training materials emphasize choosing batch tokens for high-throughput, non-renewable, non-persistent use cases, while service tokens are appropriate when token lifecycle management and server-side tracking are required.
- A. Incorrect.
Incorrect. Service tokens can read secrets, but they are not required for all secret reads. Service tokens are stateful and stored by Vault, making them better suited when you need features such as renewal, revocation tracking, child token creation, or accessor-based operations. In this scenario, the team explicitly wants to minimize storage overhead and does not need those lifecycle features.
- B. Correct.
Correct. Batch tokens are designed for scalable, short-lived, high-throughput use cases. They are non-persistent and do not require the same server-side storage as service tokens, which reduces storage and performance impact on the Vault cluster. Since the token only needs to read a secret briefly and does not need renewal, lookup, or child-token creation, a batch token is the best choice.
- C. Incorrect.
Incorrect. This reflects a common misconception. Batch tokens can be used to access secrets, subject to their attached policies and the capabilities of the auth method issuing them. They are not limited to authentication-only workflows. The key limitation is not secret access, but the reduced lifecycle management features compared with service tokens.
- D. Incorrect.
Incorrect. Batch tokens do not support the full set of token management features associated with service tokens. In particular, they are not renewable and do not provide the same accessor and lookup behavior because they are not stored like service tokens. This option incorrectly combines the scalability advantage of batch tokens with capabilities they do not have.