HashiCorp Vault Associate (003) Question 99
Single answer3f Describe how to create tokens based on needA platform team uses Vault to provide credentials to different workloads. A CI pipeline needs a short-lived token for a single deployment job, while a long-running internal service needs a token that can periodically renew itself without requiring a user to log in again. The security team also wants to avoid creating orphaned long-lived credentials unless necessary. Which token creation approach best meets these requirements?
- A
Create a batch token for the CI pipeline job, and create a service token for the long-running internal service
- B
Create a service token for the CI pipeline job, and create a batch token for the long-running internal service
- C
Create batch tokens for both the CI pipeline job and the long-running internal service because batch tokens are more secure in all cases
- D
Create service tokens for both the CI pipeline job and the long-running internal service because service tokens are required for all authenticated clients
Show answer and explanation
Correct answer: A
Explanation
Vault supports different token types for different operational needs. Service tokens are the default general-purpose tokens: they are stored by Vault, can be renewed, can create child tokens when policy allows, and are appropriate for persistent or long-running clients. Batch tokens are optimized for lightweight, short-lived workflows and are not renewable. In practice, this means ephemeral CI/CD jobs are often good candidates for batch tokens, while services that must keep running and renew access should use service tokens. This aligns with Vault best practices to issue the least-capable token that still satisfies the workload's requirements, reducing operational and security risk. See Vault documentation on token types, especially the differences between service tokens and batch tokens, and guidance around token lifecycle and renewal.
- A. Correct.
Correct. Batch tokens are designed for lightweight, short-lived use cases such as ephemeral jobs and high-scale machine workflows. They are not renewable and do not support features like child token creation, which makes them a good fit for a single CI deployment job. Service tokens are the general-purpose tokens stored by Vault, support renewal, and are appropriate for long-running services that need to maintain access over time. This matches the requirement to choose token types based on operational need while avoiding unnecessary long-lived credential patterns.
- B. Incorrect.
Incorrect. This reverses the intended use cases. A CI job that runs briefly usually does not need a renewable, stateful service token. Meanwhile, a long-running service typically should not use a batch token because batch tokens are not renewable and are intended for ephemeral workloads. Choosing a batch token here would force the service to reauthenticate frequently or fail when the token expires.
- C. Incorrect.
Incorrect. Batch tokens are useful, but they are not the right choice for every workload. A common misconception is that their lightweight nature makes them universally preferable. In reality, batch tokens trade off functionality: they are not renewable and are not suitable when a client needs longer-term token lifecycle management. The internal service in this scenario specifically needs periodic renewal, which batch tokens do not provide.
- D. Incorrect.
Incorrect. Service tokens are flexible, but they are not required for every client. Another common misconception is to default all applications to service tokens. For short-lived CI jobs, that adds unnecessary state and capability when a batch token is often more appropriate. The question asks for the best fit based on need, not just what is generally supported.