HashiCorp Vault Associate (003) Question 191
Single answer7b Explain how to seal and unseal VaultA company runs a Vault cluster for internal applications. During a maintenance event, the security team intentionally seals the active Vault node to prevent any reads or writes until checks are complete. After the maintenance window, an operator needs to restore service. Which action should the operator take to unseal Vault when the cluster is using Shamir seal and auto-unseal is not configured?
- A
Authenticate to Vault with a root token and run
vault operator unsealonce. - B
Provide enough valid unseal key shares, using
vault operator unsealmultiple times until the unseal threshold is met. - C
Restart the Vault server so it automatically reads the master key from storage and becomes unsealed.
- D
Run
vault status -unsealon any standby node so the active node inherits the unsealed state.
Show answer and explanation
Correct answer: B
Explanation
This question tests the operational difference between sealing and unsealing in a real maintenance scenario. Sealing immediately locks Vault's encrypted data barrier so Vault stops serving reads and writes. In a Shamir-sealed deployment, unsealing requires entering enough unseal key shares to meet the threshold defined at initialization. Tokens such as the root token do not replace unseal keys. Restarting the process also does not help unless auto-unseal has been configured with a supported external seal mechanism such as a cloud KMS or HSM. A practical best practice is to protect and distribute unseal key shares among trusted custodians so no single person holds all shares. HashiCorp documentation for Vault's seal/unseal process and Shamir key shares describes that unseal is a threshold-based operation and that unseal state is handled per node.
- A. Incorrect.
Incorrect. A root token is not used to unseal Vault. Unsealing is a cryptographic operation that reconstructs the key needed to decrypt the barrier key, and with Shamir seal this requires unseal key shares. Authentication tokens, including the root token, are used only after Vault is unsealed and able to process requests.
- B. Correct.
Correct. With Shamir seal, Vault starts in a sealed state after startup or after an operator seals it. To unseal it, an operator must submit the required number of distinct unseal key shares until the configured threshold is reached. This is commonly done with repeated
vault operator unsealcommands, each with a different key share. - C. Incorrect.
Incorrect. Restarting Vault does not unseal a Shamir-sealed server unless auto-unseal is configured with a supported external KMS/HSM. In a Shamir setup, Vault cannot recover the needed key material from storage alone, so a restart leaves it sealed.
- D. Incorrect.
Incorrect.
vault statusis used to check seal status, not to unseal a node. Also, unsealing is performed per node. A standby node does not cause the active node to become unsealed by inheritance. Each node in the cluster must be unsealed unless auto-unseal is configured.