HashiCorp Vault Associate (003) Question 216
Single answer8c Explain the uses of Shamir secret sharing and unsealingA company runs a production Vault cluster using Shamir seal with a 5-key, 3-key-threshold configuration. After a full cluster restart during a maintenance window, the operations team needs to bring Vault back online. The security team also wants to ensure that no single administrator can unseal Vault alone. Which action should the team take to meet both requirements?
- A
Have one administrator enter any 1 of the 5 unseal keys on each Vault node, because all shares contain the full master key.
- B
Collect any 3 of the 5 unseal key shares and enter them to unseal each sealed Vault node, ensuring the threshold is met without giving one person enough shares to act alone.
- C
Use the initial root token to unseal the cluster, because root privileges bypass the need for unseal key shares.
- D
Regenerate a new set of unseal keys after every restart, because Shamir secret sharing requires fresh shares each time Vault is sealed.
Show answer and explanation
Correct answer: B
Explanation
Shamir secret sharing in Vault is used to split the unseal key into multiple shares so that no single person must hold the entire secret. Vault administrators define both the total number of shares and the threshold required to reconstruct enough key material to unseal Vault. In a 5-share, 3-threshold setup, any 3 shares can be used, which supports operational resilience and separation of duties. Unsealing is the process of providing the threshold number of shares so Vault can decrypt the encryption key that protects the storage barrier and resume normal operation. This is distinct from authentication with tokens such as the root token. HashiCorp documentation for Vault initialization and seal/unseal behavior describes that Shamir shares are used for manual unseal unless auto-unseal is configured, and that rekey is a separate operation if an organization wants to change shares or threshold.
- A. Incorrect.
Incorrect. In Shamir secret sharing, each unseal key is only a share of the underlying secret; a single share is not sufficient unless the threshold is 1. In a 5-key, 3-key-threshold configuration, any 3 shares are required to reconstruct enough of the key material for unsealing. A common misconception is that each share is a complete copy of the master key, but Vault uses threshold-based key splitting specifically to avoid that risk.
- B. Correct.
Correct. With Shamir seal, Vault splits the unseal key into shares and requires a configured threshold of those shares to unseal. In this scenario, any 3 of the 5 shares can be used. This supports separation of duties because no single administrator holding fewer than 3 shares can unseal Vault alone. In practice, the required threshold must be provided for each sealed node that needs unsealing.
- C. Incorrect.
Incorrect. The initial root token is used for administrative access after Vault is unsealed; it does not replace the unseal process. When Vault is sealed, the barrier is locked and normal API operations, including token-based privileged actions, are unavailable until the node is unsealed. This option reflects a common confusion between authentication/authorization and the seal/unseal mechanism.
- D. Incorrect.
Incorrect. Vault does not require unseal keys to be regenerated after every restart. The same unseal key shares remain valid until they are explicitly rotated or rekeyed through an administrative operation. Restarting or resealing Vault does not itself trigger generation of new shares. This distractor targets the misconception that Shamir shares are one-time-use values.