HashiCorp Vault Associate (003) Question 72
Single answer3a Choose between service and batch tokens based on use caseA platform team is integrating Vault with two workloads. First, a CI pipeline needs a short-lived token to read a few secrets during a single job run, and the team wants to minimize storage overhead on the Vault server because thousands of these jobs run every hour. Second, a long-running internal application needs a token that can create child tokens for downstream processes and be renewed over time. Which choice best fits these requirements?
- A
Use a batch token for the CI pipeline and a service token for the long-running application
- B
Use a service token for the CI pipeline and a batch token for the long-running application
- C
Use batch tokens for both workloads because they are more lightweight and renewable
- D
Use service tokens for both workloads because only service tokens can access secrets engines
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a batch token for the short-lived, high-volume CI pipeline and a service token for the long-running application. In Vault, service tokens are the default, persisted token type and support features such as renewal, revocation tracking, accessors, and creation of child tokens. Batch tokens are intended for scalable, ephemeral workloads because they are not stored in the token store in the same way and therefore reduce server-side overhead. However, batch tokens trade off functionality: they are not renewable and cannot create child tokens. HashiCorp documentation and training guidance consistently position batch tokens for short-lived machine workflows and service tokens for durable application sessions that need richer lifecycle management.
- A. Correct.
Correct. Batch tokens are designed for lightweight, high-volume, short-lived use cases such as CI jobs or ephemeral workloads. They reduce storage overhead because they are not persisted like service tokens. Service tokens are appropriate for long-running applications because they support features such as renewal and the creation of child tokens, which are needed in this scenario.
- B. Incorrect.
Incorrect. This reverses the intended use cases. A service token would work for the CI pipeline, but it adds unnecessary state and storage overhead for a high-volume ephemeral workflow. A batch token is not appropriate for the long-running application because batch tokens are not renewable and do not support creating child tokens.
- C. Incorrect.
Incorrect. Batch tokens are lightweight, but they are not renewable and do not support child token creation. This option reflects a common misconception that 'lighter weight' makes batch tokens suitable for all use cases. In reality, their reduced functionality makes them a poor fit for long-lived application identity patterns.
- D. Incorrect.
Incorrect. Service tokens can access secrets engines, but batch tokens can also be used to access Vault according to their policies. The issue is not whether they can access secrets engines, but whether the token type supports the operational behavior needed. This option confuses access authorization with token capabilities such as persistence, renewal, and child token creation.