HashiCorp Vault Associate (003) Question 95
Single answer3f Describe how to create tokens based on needA platform team uses HashiCorp Vault to provide credentials to several workloads. One legacy reporting application cannot use AppRole, Kubernetes auth, or any other login method, so the team must manually create a token for it. The application only needs read access to secrets under secret/data/reports/* for one week, and the security team wants the token to stop working automatically if the application is not actively using it. Which approach best meets these requirements?
- A
Create a service token with a policy granting read on secret/data/reports/*, set a 7-day TTL, and configure an explicit max TTL of 7 days.
- B
Create a batch token with a policy granting read on secret/data/reports/*, set a 7-day TTL, and rely on renewal to keep it active while in use.
- C
Create a periodic token with the required read policy and a 7-day period so it expires after one week whether or not it is renewed.
- D
Create a root token with a 7-day TTL, then restrict the application by documenting that it should only read secret/data/reports/*.
Show answer and explanation
Correct answer: A
Explanation
When creating tokens based on need, the key is choosing the token type and settings that match the workload's behavior and security requirements. For a manually provisioned application token, a service token is usually the right choice because it is renewable, supports normal token lifecycle management, and can be constrained with policies, TTL, and explicit max TTL. In this scenario, the application needs limited read access for up to one week and should stop working automatically if not actively used. A service token with a narrow policy, a TTL, and an explicit max TTL meets that need: it expires if not renewed, and explicit max TTL prevents extension beyond the allowed lifetime. Batch tokens are not renewable, so they are a poor fit when continued use depends on renewal. Periodic tokens are designed to live as long as they are renewed and therefore are better for indefinite service access patterns rather than a hard one-week cap unless additional constraints are configured. Root tokens should be reserved for administrative bootstrap or emergency tasks only. This aligns with Vault documentation and best practices around token types, renewal behavior, TTLs, periodic tokens, and least-privilege policy design.
- A. Correct.
Correct. A manually created service token is appropriate when a client cannot use a normal auth method. Service tokens support renewal and are tracked by Vault, which makes them suitable for longer-lived application use. Setting the token's policy to only allow read access on secret/data/reports/* enforces least privilege. A 7-day TTL combined with an explicit max TTL of 7 days ensures the token cannot live beyond one week, while it will also expire sooner if it is not renewed during use.
- B. Incorrect.
Incorrect. Batch tokens are intended for lightweight, high-scale use cases and are not renewable. The option says to rely on renewal to keep it active while in use, which is not possible with batch tokens. This is a common misconception because batch tokens can be created with policies and TTLs, but they do not provide the same renewal behavior as service tokens.
- C. Incorrect.
Incorrect. Periodic tokens require renewal at the defined period to remain valid and can be useful for ongoing service use, but this option does not satisfy the one-week maximum lifetime requirement as stated. A periodic token can continue indefinitely as long as it is renewed, unless additional limits are imposed. The wording here incorrectly implies it expires after one week regardless of renewal.
- D. Incorrect.
Incorrect. A root token is highly privileged and should not be used for normal application access. Documentation or process is not a security control; the token itself would still have root capabilities. This violates Vault best practices and the principle of least privilege.