HashiCorp Vault Associate (003) Question 193
Single answer7b Explain how to seal and unseal VaultA company runs a production Vault cluster using Shamir seal with a key threshold of 3 of 5. After a maintenance reboot, an operator confirms the active node is sealed and the application teams report authentication failures. The operator has access to one recovery key, a root token, and three unseal key shares held by different team members. What is the correct action to restore Vault to service?
- A
Use the root token to log in and run a command to unseal the node, because root privileges bypass the seal state
- B
Provide any three valid unseal key shares to the sealed node until it reaches the configured threshold and becomes unsealed
- C
Use the recovery key together with the root token to decrypt the barrier and unseal Vault
- D
Restart the Vault service on all nodes, because sealed state is usually cleared automatically after a cluster reboot
Show answer and explanation
Correct answer: B
Explanation
The correct answer is to provide any three valid unseal key shares because the cluster uses Shamir seal with a 3-of-5 threshold. In Vault, sealing locks the encryption barrier that protects data in storage. Unsealing reconstructs the necessary key material from the required number of key shares. Root tokens are powerful for administration after Vault is unsealed, but they cannot bypass the sealed state. Recovery keys are not interchangeable with unseal keys in a Shamir-sealed deployment. HashiCorp Vault documentation distinguishes clearly between Shamir unseal, where operators manually provide unseal key shares, and auto-unseal, where an external KMS/HSM handles unseal automatically and recovery keys serve different purposes. Best practice is to distribute unseal key shares among trusted custodians and ensure operational runbooks identify the threshold and procedure needed after restarts or seal events.
- A. Incorrect.
Incorrect. A root token cannot be used while Vault is sealed because the API is unavailable for normal authenticated operations until the storage barrier is unsealed. Sealing protects the master key and encrypted data at rest; authentication tokens do not bypass that state. This is a common misconception because root tokens are highly privileged, but they do not replace unseal keys.
- B. Correct.
Correct. With Shamir seal, Vault must be unsealed by submitting enough unseal key shares to meet the configured threshold. In this scenario, the threshold is 3 of 5, so any three valid unseal key shares can be entered on the sealed node. Once the threshold is met, Vault reconstructs the key material needed to decrypt the barrier and resumes service.
- C. Incorrect.
Incorrect. Recovery keys are not used to unseal a Vault protected by Shamir seal. They are associated with auto-unseal configurations and are used for specific recovery operations, not for normal barrier unseal in a Shamir-sealed Vault. Combining a recovery key with a root token will not decrypt the storage barrier in this scenario.
- D. Incorrect.
Incorrect. Restarting Vault does not automatically clear the sealed state for a Shamir-sealed Vault. After a restart, Vault typically remains sealed until the required number of unseal key shares is provided, unless auto-unseal is configured. This option reflects a misunderstanding between manual unseal and auto-unseal behavior.