HashiCorp Vault Associate (003) Question 79
Single answer3b Describe root token uses and lifecycleA security team is finishing the initial deployment of HashiCorp Vault in production. During initialization, they generated the initial root token and used it to enable audit logging, configure authentication methods, and create tightly scoped admin policies. The team now wants to reduce long-term risk while still preserving a safe way to perform emergency recovery tasks later. Which action is the BEST next step regarding the root token?
- A
Keep the initial root token in daily operational use because it bypasses policy restrictions and reduces administrative overhead
- B
Revoke the initial root token after setup and rely on the generate-root process with quorum of unseal/recovery key holders if a new root token is ever needed
- C
Store the initial root token in plain text on the Vault server so operators can retrieve it during outages without involving other teams
- D
Convert the initial root token into a periodic service token so it can be safely renewed and used for ongoing administration
Show answer and explanation
Correct answer: B
Explanation
Vault's initial root token is created at initialization and is intended for initial setup and exceptional administrative actions. Because it has unrestricted privileges, HashiCorp guidance is to avoid using it for everyday operations. Instead, administrators should create scoped policies and use non-root tokens for normal work. After bootstrapping, organizations commonly revoke the initial root token and retain the ability to create a new one later using the generate-root process, which requires participation from enough unseal key holders or recovery key holders depending on the seal configuration. This supports a secure break-glass lifecycle: use root only when necessary, minimize its lifetime, and avoid persistent operational dependence on it.
- A. Incorrect.
Incorrect. The root token is intended for bootstrapping, recovery, and other exceptional situations, not routine administration. Because it is effectively unrestricted, using it for day-to-day work greatly increases blast radius if it is exposed or misused. Best practice is to use least-privilege tokens tied to policies for normal operations.
- B. Correct.
Correct. This is the recommended operational pattern. After initial configuration, the initial root token should generally be revoked or otherwise tightly controlled to minimize risk. If a root token is needed later, Vault supports generating a new one through the generate-root workflow, which requires quorum from authorized key holders. This preserves break-glass access without leaving a highly privileged token in regular circulation.
- C. Incorrect.
Incorrect. Storing the root token in plain text on the Vault server is a serious security risk. Anyone who gains access to that host could obtain unrestricted access to Vault. This option also undermines separation of duties and the security controls around root-token generation and use.
- D. Incorrect.
Incorrect. A root token is not something you 'convert' into a safer operational token for normal use. The misconception here is that renewability changes the security model. Even if a token can be renewed, a root token still has root-level privileges, so it remains inappropriate for routine administration.