HashiCorp Vault Associate (003) Question 77
Single answer3b Describe root token uses and lifecycleA security team initializes a new HashiCorp Vault cluster for production. During setup, the lead engineer receives the initial root token and uses it to enable audit logging, create an admin policy, and generate a limited-scope admin token for daily operations. The team wants to reduce long-term risk while preserving a recovery path for rare break-glass situations. Which action should the team take next?
- A
Store the initial root token in a secure vault and use it for periodic administrative tasks so its privileges remain validated
- B
Revoke or avoid retaining the initial root token after bootstrapping, and rely on a new root token generated through the operator-controlled process only when absolutely necessary
- C
Convert the initial root token into a periodic token so it can be safely renewed instead of rotated
- D
Replace the initial root token with a batch token because batch tokens are better suited for highly privileged emergency access
Show answer and explanation
Correct answer: B
Explanation
This question tests understanding of the root token lifecycle and proper operational handling. In Vault, the initial root token created during initialization is highly privileged and intended mainly for bootstrap activities such as enabling auth methods, secrets engines, audit devices, and creating initial policies or admin identities. Best practice is to minimize root token exposure: do not use it for routine administration, and prefer scoped tokens associated with policies. For rare emergency access, Vault provides a generate-root process that requires operator participation and acts as a controlled break-glass path. This aligns with HashiCorp guidance to tightly restrict root token use and rely on least-privilege administrative workflows whenever possible.
- A. Incorrect.
Incorrect. The root token has unrestricted privileges across Vault and should not be used for routine administration. Best practice is to use least-privilege tokens tied to policies for normal operations. Keeping and regularly using the initial root token increases risk and undermines auditability and separation of duties, even if it is stored securely.
- B. Correct.
Correct. The initial root token is intended primarily for bootstrap tasks such as initial configuration. After setup, organizations should avoid day-to-day use of any root token and typically revoke the initial one or otherwise ensure it is not retained for routine access. If true root-level access is needed later, Vault supports generating a new root token via a quorum-based operator process, which is designed as a controlled break-glass mechanism.
- C. Incorrect.
Incorrect. Root tokens are not made safer simply by making them periodic. The core problem is their unrestricted privilege, not just their TTL behavior. Converting or treating a root token like a renewable operational credential is contrary to Vault security best practices.
- D. Incorrect.
Incorrect. Batch tokens are lightweight and non-renewable, but they are not a replacement for root access and are not intended as a safer form of unrestricted administrative credential. Emergency root-level access in Vault is handled through the generate-root workflow, not by swapping token types.