HashiCorp Vault Associate (003) Question 96
Single answer3f Describe how to create tokens based on needA platform team uses HashiCorp Vault to support both human operators and an automated deployment pipeline. The security lead wants each use case to receive a token that matches its operational need with the least risk. Which option is the best approach?
- Human operators need a token they can renew during a work session, but it should eventually expire if they stop using it.
- The deployment pipeline runs unattended and must not require renewal calls during execution.
- The team wants to avoid giving either workflow a longer-lived token than necessary.
- A
Issue periodic tokens to both the human operators and the deployment pipeline so both can be renewed as needed.
- B
Issue a service token with an appropriate TTL to human operators, and a batch token with a limited TTL to the deployment pipeline.
- C
Issue batch tokens to human operators because they are lightweight, and root tokens to the deployment pipeline to avoid expiration during runs.
- D
Issue orphan tokens to both workflows because orphan tokens are isolated from parent token revocation and therefore safest for all use cases.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to create tokens based on workload characteristics, not to use a single token type everywhere. In Vault, service tokens are the general-purpose token type and support features like renewal, child token creation, and full token store persistence, making them suitable for interactive human use when paired with appropriate TTLs. Batch tokens are intended for scalable, lightweight machine workflows and are non-renewable, which fits short-lived unattended jobs that should not depend on renewal logic.
This question tests the practical ability to choose token types based on need: renewable service tokens for people or long-running clients that can renew, and batch tokens for short-lived automated processes. It also reinforces best practices to avoid root tokens except for initial setup or emergencies, and to avoid assuming orphan status alone solves lifecycle or security requirements. These distinctions are consistent with Vault documentation on token types, TTLs, renewal behavior, and secure operational practices.
- A. Incorrect.
Incorrect. Periodic tokens are renewable and are commonly used when an application or user can reliably renew the token. However, the scenario explicitly says the deployment pipeline must not require renewal calls during execution. Giving both workflows periodic tokens does not match the unattended pipeline requirement and introduces unnecessary renewal dependency.
- B. Correct.
Correct. A service token is appropriate for human operators because it supports normal token features such as renewal and can be given a suitable TTL so it expires if no longer used. A batch token is designed for lightweight, non-renewable use cases such as automated workflows and has a TTL but does not require renewal, which aligns with the deployment pipeline requirement. This approach also follows least-privilege and least-lifetime principles by tailoring token type to the actual need.
- C. Incorrect.
Incorrect. Batch tokens are not a good fit for human operators because they are non-renewable and intended for lightweight machine use cases, not interactive sessions that may need renewal. Root tokens should not be used for routine deployment pipelines because they are extremely powerful and violate security best practices. This option combines two common mistakes: using batch tokens for interactive users and overusing root tokens.
- D. Incorrect.
Incorrect. Orphan tokens only describe parent-child revocation behavior; they are not automatically the safest choice for every workflow. Whether a token is orphaned does not by itself address the need for renewal for human operators or non-renewal for the deployment pipeline. Token type and TTL behavior matter more here than simply making tokens orphaned.