HashiCorp Vault Associate (003) Question 219
Single answer8c Explain the uses of Shamir secret sharing and unsealingA company runs Vault with the integrated storage backend in a production environment. After a full cluster restart for maintenance, the operators find that Vault is sealed. The security team requires that no single administrator be able to unseal Vault alone, but they also want recovery from a restart to be possible without restoring from backup. During initialization, Vault was configured to use Shamir seal with 5 key shares and a threshold of 3. Which action should the operations team take to bring Vault back online while meeting the security requirement?
- A
Provide any 3 of the 5 unseal key shares to Vault so it can reconstruct the master key in memory and unseal the node
- B
Use the root token generated at initialization to unseal Vault because root tokens bypass seal requirements
- C
Restore the Vault data from backup because Shamir key shares cannot be used after a full cluster restart
- D
Have all 5 key holders submit their shares because Vault requires every Shamir share to unseal after a restart
Show answer and explanation
Correct answer: A
Explanation
This question tests practical understanding of how Shamir secret sharing supports Vault unsealing. In a Shamir-based setup, Vault divides the unseal key into multiple shares and defines a threshold number required to reconstruct it. With 5 shares and a threshold of 3, any 3 valid shares can unseal Vault. This design is commonly used to enforce separation of duties so that no single person can unseal Vault alone. Unsealing is required after Vault starts in a sealed state, such as after a restart, unless another seal mechanism such as auto-unseal is configured. The root token does not unseal Vault, and backups are unrelated to routine unsealing when storage remains healthy. This aligns with HashiCorp Vault documentation and best practices around Shamir unseal keys, threshold-based recovery, and operational security.
- A. Correct.
Correct. With Shamir seal, Vault splits the unseal key into shares and requires only the configured threshold to unseal. In this scenario, 3 of the 5 shares are sufficient. This meets the requirement that no single administrator can unseal Vault alone, while still allowing the cluster to be recovered after restart without restoring data from backup. Vault reconstructs the necessary key material in memory during the unseal process.
- B. Incorrect.
Incorrect. A root token is for authenticated administrative access after Vault is unsealed; it does not replace the unseal process. A common misconception is that the root token can override all controls, but seal status is a foundational protection mechanism and must be cleared before tokens can be used.
- C. Incorrect.
Incorrect. A restart does not require restoring from backup if the storage is intact. Shamir unseal keys are specifically used to unseal Vault after startup when using Shamir seal. Backups are for data recovery scenarios such as storage loss or corruption, not normal post-restart unsealing.
- D. Incorrect.
Incorrect. Vault does not require all shares unless the threshold was configured to equal the total number of shares. Here the threshold is 3, so requiring all 5 would misunderstand how Shamir secret sharing works. The purpose of Shamir shares is to balance security and operability by requiring only a subset.