HashiCorp Vault Associate (003) Question 65
Single answer3 Vault tokensA platform team is integrating a build system with Vault. Each build job should receive a token that can read only a specific path in the KV secrets engine and should stop working automatically after the job completes. The team also wants the token to be revocable if the parent login is revoked. Which approach best meets these requirements?
- A
Create a service token with the required policy and a short TTL from the build system's parent token
- B
Create a batch token with the required policy and a short TTL from the build system's parent token
- C
Create a periodic token so the build job can keep renewing it until the pipeline ends
- D
Create a root token with a short TTL so it automatically expires after the job completes
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use a short-lived service token with a narrowly scoped policy. In Vault, service tokens are the standard token type for most use cases and support features such as renewal, accessors, cubbyhole, and parent-child token hierarchies. That hierarchy matters here because revoking the parent can revoke its children. Batch tokens are intended for scalable, ephemeral workloads, but they trade away some management and revocation behavior and are therefore a poor fit when hierarchical revocation is required. Periodic tokens are useful when a client should keep a token alive through renewal, not when the desired behavior is automatic expiration after a short job. Root tokens should not be used for application workloads. This aligns with Vault best practices around least privilege, short TTLs for machine identities, and careful use of token types as described in the Vault token documentation.
- A. Correct.
Correct. A service token supports parent-child relationships, can carry policies limiting access to only the required KV path, and can be revoked through normal token revocation workflows. If the parent token is revoked, child service tokens are also revoked through the token hierarchy. Using a short TTL helps ensure the token becomes unusable shortly after the build job finishes.
- B. Incorrect.
Incorrect. Batch tokens are lightweight and useful for high-scale machine workflows, but they do not participate in the same revocation and accessor management model as service tokens. They are not the best choice when the requirement explicitly includes revocation tied to the parent login. A candidate might choose this because batch tokens are often recommended for ephemeral jobs, but the parent-linked revocation requirement points to service tokens instead.
- C. Incorrect.
Incorrect. Periodic tokens are designed for cases where a token must remain valid indefinitely as long as it is renewed before each period expires. That does not match the goal of having the token naturally expire after a short-lived build job. It also introduces unnecessary renewal logic for a use case that benefits from simple short-lived tokens.
- D. Incorrect.
Incorrect. Root tokens bypass policy restrictions and should be tightly controlled and rarely used. Even with a short TTL, issuing a root token to a build job violates least-privilege best practices because it grants unrestricted access far beyond the single KV path required.