What's the difference between Vault's Shamir unseal and auto-unseal via a cloud KMS or Transit seal, and what's the failure mode unique to auto-unseal?
Quick Answer
Shamir unseal requires humans to manually supply key shares after every restart; auto-unseal delegates that to an external key management service (cloud KMS, or another Vault cluster's Transit engine) so Vault unseals itself automatically on startup. The failure mode unique to auto-unseal is that Vault now has an external dependency it needs to be available at startup — if the KMS key is deleted/inaccessible, or (for Transit auto-unseal) the upstream Vault's token has expired or that cluster is down, the dependent Vault cannot unseal at all, even with all the 'right' local configuration.
Detailed Answer
With Shamir unseal, the root key material never leaves Vault's own process memory and reconstructing it depends purely on humans supplying key shares — there's no external service dependency, but there IS an operational cost: every restart (planned maintenance, crash, node replacement) requires paging someone with key shares, which doesn't scale well for HA clusters that might restart nodes routinely.
Auto-unseal removes that human dependency by having Vault call out to an external key provider (AWS KMS, GCP Cloud KMS, Azure Key Vault, or Vault's own Transit secrets engine hosted by a separate 'seal' Vault cluster) to decrypt an internally-stored, KMS-wrapped copy of the root key automatically on startup — no human involvement needed for a routine restart.
The tradeoff is a new external dependency and its own failure modes: if the cloud KMS key is deleted, disabled, or the IAM permissions allowing Vault to call it are revoked, the dependent Vault cannot unseal even though its own storage and configuration are perfectly intact. Transit auto-unseal has a documented failure mode where the token Vault uses to authenticate to the upstream Transit-hosting Vault cluster expires or isn't renewed correctly — if that token becomes invalid, the seal wrapper health check starts failing and the dependent Vault cannot complete its unseal on a subsequent restart, effectively creating a hard dependency on the upstream Vault cluster's own availability and the auto-unseal token's lifecycle being actively managed. Production deployments using Transit auto-unseal need their own monitoring on that token's validity and the upstream cluster's health, since a failure there is invisible until the exact moment you need to restart the dependent Vault.
Interview Tip
Bring up the Transit auto-unseal token expiry failure mode specifically — it's a real, documented operational gotcha that shows you've read past the marketing description of auto-unseal's convenience.