HashiCorp Vault Associate (003) Question 74
Single answer3a Choose between service and batch tokens based on use caseA platform team is integrating two workloads with Vault. First, a short-lived serverless function needs to read one secret during startup and then exit. It may run thousands of times per minute, and the team wants to minimize storage and operational overhead in Vault. Second, a long-running internal application needs a token that can create child tokens for subprocesses and be explicitly revoked when an incident occurs. Which token choice best fits these requirements?
- A
Use a batch token for the serverless function, and a service token for the long-running application.
- B
Use a service token for the serverless function, and a batch token for the long-running application.
- C
Use batch tokens for both workloads because they are faster and support all token lifecycle features.
- D
Use service tokens for both workloads because only service tokens can access secrets engines.
Show answer and explanation
Correct answer: A
Explanation
The key decision point is whether the workload needs Vault to maintain a full token lifecycle record. HashiCorp documentation and training guidance describe service tokens as the default general-purpose token type, appropriate for long-running applications because they are persisted and support features such as renewal, revocation, and child token creation. Batch tokens are designed for scalable, short-lived, high-throughput scenarios because they are not stored in the token store the same way service tokens are, which reduces storage overhead. That makes batch tokens well suited for ephemeral jobs, serverless functions, and similar one-shot operations. In this scenario, the serverless function should use a batch token, while the long-running application should use a service token.
- A. Correct.
Correct. Batch tokens are intended for lightweight, high-throughput, short-lived use cases where Vault should avoid the storage overhead of creating and tracking a full token entry. They are suitable when the workload just needs to present a token, perform simple reads, and exit. Service tokens are the right fit for long-running applications because they support full token lifecycle features such as renewal, revocation tracking, and creation of child tokens.
- B. Incorrect.
Incorrect. This reverses the recommended use cases. A serverless function that runs briefly and at high volume is a classic batch token scenario. A long-running application that needs operational controls like child token creation and revocation should use a service token. Choosing a batch token for that application would remove important lifecycle capabilities.
- C. Incorrect.
Incorrect. Batch tokens do reduce storage overhead and are useful for high-scale ephemeral workloads, but they do not support all service-token behaviors. In particular, they are not the right choice when a workload needs full lifecycle management, such as creating child tokens or relying on service-token-style revocation semantics.
- D. Incorrect.
Incorrect. Both token types can be used to access Vault according to attached policies. The difference is not whether they can access secrets engines, but how Vault manages them. Service tokens are persisted and support richer lifecycle operations, while batch tokens are optimized for ephemeral, high-volume use cases.