HashiCorp Vault Associate (003) Question 71
Single answer3a Choose between service and batch tokens based on use caseA platform team is integrating Vault with a high-volume API gateway. Each incoming client request needs a short-lived Vault token to read a single secret and then disappear. The team expects tens of thousands of tokens per minute and wants to minimize storage overhead on the Vault cluster. The tokens do not need child tokens, renewal, or accessors for later lookup. Which token type is the best fit for this use case?
- A
Use a service token, because service tokens are optimized for very high creation rates and do not require server-side storage.
- B
Use a batch token, because batch tokens are lightweight, do not require storage in the token store, and are intended for high-volume, short-lived use cases.
- C
Use a service token, because only service tokens can be used to read secrets from Vault.
- D
Use a batch token, because batch tokens support all token features, including renewal, child token creation, and token accessor lookup.
Show answer and explanation
Correct answer: B
Explanation
The best answer is batch token because the scenario emphasizes very high issuance volume, short-lived usage, and a desire to reduce server-side storage overhead. In Vault, service tokens are the default general-purpose token type and are stored so Vault can support features like renewal, revocation tracking, token hierarchy, and accessors. Batch tokens are intended for lightweight, scalable use cases where those features are unnecessary. HashiCorp documentation and Vault best practices describe batch tokens as suitable for high-volume, ephemeral workloads, while service tokens are preferred when you need full token lifecycle management.
- A. Incorrect.
Incorrect. This reverses the characteristics of the token types. Service tokens are persisted and tracked by Vault, which makes them appropriate when you need features such as renewal, revocation tracking, child tokens, or token accessors. They are not the best choice when the primary goal is minimizing storage overhead for very high token volume.
- B. Correct.
Correct. Batch tokens are designed for scalable, high-throughput, short-lived use cases. They are not persisted in the token store the way service tokens are, which reduces storage overhead on the Vault cluster. This makes them a good fit when tokens are ephemeral and you do not need features such as renewal, periodic behavior, child token creation, or accessor-based management.
- C. Incorrect.
Incorrect. Both service and batch tokens can be used for authentication and authorization to access Vault data, subject to attached policies and other constraints. The misconception here is confusing token capabilities with token management features. The deciding factor in this scenario is lifecycle and storage behavior, not whether the token can read a secret.
- D. Incorrect.
Incorrect. Batch tokens intentionally trade off management features for scale and efficiency. They do not support the full set of service token capabilities such as renewal, creating child tokens, or accessor lookup in the same way service tokens do. This option is plausible because batch tokens sound like a superset for performance, but they are actually more limited.