HashiCorp Vault Associate (003) Question 70
Single answer3a Choose between service and batch tokens based on use caseA platform team is integrating HashiCorp Vault with two different workloads. The first is a CI/CD job that runs for a few minutes, reads a secret once, and then exits. Thousands of these jobs may run in parallel during release windows. The second is a long-running internal service that must renew its token, create child tokens for helper processes, and continue operating even during extended runtimes. The team wants to minimize storage overhead for short-lived jobs while preserving full token lifecycle features for the long-running service. Which approach should they choose?
- A
Use batch tokens for both workloads, because batch tokens reduce storage usage and support renewal for long-running services
- B
Use service tokens for both workloads, because service tokens are the default token type and are appropriate for any scale of short-lived jobs
- C
Use a batch token for the CI/CD job and a service token for the long-running internal service
- D
Use a service token for the CI/CD job and a batch token for the long-running internal service
Show answer and explanation
Correct answer: C
Explanation
In Vault, service tokens are the normal persisted tokens used when a workload needs full token lifecycle management, including renewal and features tied to token hierarchy and revocation tracking. Batch tokens are intended for scalable, short-lived, non-renewable use cases and are not stored in the token store the same way service tokens are, which reduces storage overhead for large numbers of ephemeral clients. In this scenario, the CI/CD jobs are short-lived and high-volume, so batch tokens are the best fit. The long-running internal service needs renewal and child token creation, so it should use a service token. This aligns with HashiCorp Vault guidance on token types and selecting batch versus service tokens based on workload behavior and operational requirements.
- A. Incorrect.
Incorrect. Batch tokens are well suited for high-volume, short-lived workloads because they are lightweight and reduce storage overhead. However, they do not provide the full lifecycle behavior needed by long-running services, such as renewal and the broader parent/child token management expectations commonly associated with service tokens. Choosing batch tokens for the long-running service would prevent required operational behavior.
- B. Incorrect.
Incorrect. Service tokens are appropriate when a workload needs features such as renewal, revocation tracking, and child token creation. However, using service tokens for very high-volume, short-lived CI/CD jobs can create unnecessary persistence and storage load compared with batch tokens. This option ignores the stated goal of minimizing storage overhead for ephemeral jobs.
- C. Correct.
Correct. Batch tokens are designed for lightweight, high-scale, short-lived use cases such as ephemeral jobs that read a secret and exit. Service tokens are the right choice for long-running services that need full token lifecycle capabilities, including renewal and child token creation. This pairing matches both workloads' operational requirements and the team's scaling goal.
- D. Incorrect.
Incorrect. This reverses the recommended usage. A CI/CD job that runs briefly and does not need token renewal is a good candidate for a batch token. A long-running service that must renew its token and create child tokens requires a service token. Using a batch token for the long-running service would remove needed capabilities.