HashiCorp Vault Associate (003) Question 98
Single answer3f Describe how to create tokens based on needA platform team uses Vault to issue credentials to applications. One legacy application cannot authenticate with an external auth method yet, so the team must manually create a token for it. The application runs continuously on a single server, should be able to renew its own token, and must be restricted to read-only access to secrets under secret/data/payments/*. To reduce risk, the team wants the token to expire automatically if it is not renewed. Which approach best meets these requirements?
- A
Create a service token with the payments-read policy, a limited TTL, and renewable enabled.
- B
Create a batch token with the payments-read policy and a long explicit max TTL so the application can keep using it.
- C
Create a periodic token with the root policy so the application can renew forever without re-authenticating.
- D
Create an orphan token with no TTL so the application is unaffected if the parent token is revoked.
Show answer and explanation
Correct answer: A
Explanation
When creating tokens based on need, choose the token type and settings that match the workload. For a long-running application that must renew its own access, a service token is the standard choice. It supports renewal, participates in Vault's token lifecycle, and works well with least-privilege policies. A TTL should be set so the token expires if it is not renewed, reducing exposure from abandoned or leaked tokens. Batch tokens are better suited to ephemeral, high-volume use cases and are not appropriate here. Orphan tokens affect parent-child revocation behavior, but they do not replace proper TTL and renewal decisions. A periodic token may be useful in some scenarios, but policy scope still must be minimal; using root would be a serious security mistake. This aligns with Vault best practices around token types, TTLs, renewability, and least-privilege policy assignment described in HashiCorp Vault documentation.
- A. Correct.
Correct. A service token is the appropriate token type for long-running services because it supports renewal and is tracked by Vault. Assigning a narrowly scoped policy such as payments-read enforces least privilege. Setting a TTL ensures the token will expire automatically if it is not renewed, which matches the requirement. This is the most practical manual token choice for a legacy application that cannot yet use an auth method.
- B. Incorrect.
Incorrect. Batch tokens are intended for lightweight, high-scale use cases and are not renewable in the same way service tokens are used for long-running applications. They are not the right fit when the application must renew its own token over time. Someone might choose this option because batch tokens can be created quickly and have low overhead, but they do not meet the renewal requirement.
- C. Incorrect.
Incorrect. A periodic token can be renewed indefinitely if renewed before expiry, but assigning the root policy violates least-privilege requirements and creates unnecessary risk. The problem specifically requires read-only access to a limited path, so a root-scoped token is inappropriate even if the renewal behavior sounds attractive.
- D. Incorrect.
Incorrect. An orphan token is detached from a parent token, but that does not by itself satisfy the need for controlled expiration. A token with no TTL would not automatically expire if the application stopped renewing it, which directly conflicts with the requirement. This option reflects the misconception that orphan status is mainly about safety for long-running apps, when the key concern here is renewable, scoped, expiring access.