Your store only serves after a quorum of holders each supply a share — what do you give up if you automate that step instead?
answer
- several people, or nobody at all
- possession of the host is not possession
- the cost is measured in recovery time
- automation relocates protection, never removes it
- shares parked together keep only the ceremony
basics
~20 sAutomating the step buys an unattended restart and gives up the property the quorum existed for: that no single holder, and nothing present on the host alone, can open the store. Protection then rests on whatever guards the automated path.
solid answer
~50 sA threshold of shares means the store cannot be opened by one person, and cannot be opened by whoever controls a node — the parts are elsewhere and several are needed. The price is that no node comes back on its own: every host failure, replacement and scale-out ends with people being woken, so recovery time is bounded by who is awake and reachable rather than by machines. Automating the step reverses both. Restarts complete unattended, and the protection collapses onto whatever guards the automated unwrap path — the node's identity, the access rule on the device or key service, the place the shares were parked. That is not automatically wrong, but it is a different threat model, and the worst version is scripting the existing shares into one place, which keeps the ceremony and deletes the property.
go deeper
Recall that some stores need several people to each supply a part before they will serve, and that this is why such a store does not restart by itself.
Explain both properties the threshold gives — no single holder, and nothing on the host alone — and name the restart cost that comes with them.
Argue the tradeoff with a number: the measured time from total loss to serving, and which downstream services inherit it as their own recovery floor.
Decide it as a standard for other teams — which estates may run attended opening, what the automated path's guard must be worth, and how often the fallback route is rehearsed.
## What the quorum actually buys When the key protecting a store's contents is split into parts and a threshold must be recombined before the store serves, two things become true that are hard to get any other way. - **No single holder can open the store.** One part reveals nothing about the key. Coercing, bribing or compromising one person achieves nothing on its own. - **Nothing present on the host can open it.** An attacker with the disk, the volume snapshot, or even full control of a stopped node still has ciphertext, because the missing input was never on that machine. That second property is the one people underrate. It means possession of the infrastructure is not possession of the contents, and it holds even when the platform boundary has failed. ## What it costs, stated honestly The cost is measured in **recovery time**, and it is paid at the worst hour. | dimension | threshold of shares | automated unwrap | |---|---|---| | node replacement | attended: holders must be found | completes on its own | | recovery time floor | how fast enough people can be reached | seconds, bounded by the unwrap path | | opening requires | several independent humans | whatever can pass as the node | | scales to many nodes | poorly | yes | | survives a stolen host | yes | depends on the guard on the unwrap path | Every service in the estate that cannot start without the store inherits that recovery-time floor. If the store is where the estate's credentials live, a two-hour "find three people at 3am" is a two-hour estate outage, and it is not a security cost, it is an availability cost charged to everyone downstream. ## What automating moves, rather than removes Automation does not delete the protecting key or the encryption; it changes **who must be present**. After automation, opening the store requires one thing: something that can convince the unwrap path it is the node. So the question becomes what guards that, and the honest answer is the whole of it: - the strength of the node's identity, and how hard that is to forge or borrow; - the rule on the device or key service saying which callers may ask it to unwrap; - whether that rule is narrow enough that one compromised host does not become every host; - whether uses of the unwrap path are recorded somewhere a person would notice. That is a defensible posture. It is simply a different one, and the phrase to avoid in an interview is "we automated it, so it's the same but easier". ## The failure mode nobody writes down The common real outcome is neither design. A team keeps the threshold requirement, hits the 3am problem twice, and quietly parks all the shares in one place a script can reach. Now: 1. The restart is unattended, so the operational pain stops and nobody revisits it. 2. The store still reports that a quorum was supplied, so the design looks intact. 3. Every part is reachable by one identity, so the threshold has been reduced to one without anyone deciding to reduce it. This is strictly worse than choosing automation deliberately, because the guard on that one place was never designed to carry the whole protection. If the operational cost is unbearable, change the design and say so — do not keep the ceremony and delete the property. ## How to decide, and what to measure Measure two numbers before arguing about either design. 1. **Time from total loss to serving, at the worst hour**, with the current threshold. Not the number people believe — the number from a rehearsal that actually paged holders. 2. **What that number costs downstream**, in services that cannot start until the store answers. Then pick deliberately. Attended opening is justified where possession of the infrastructure must not equal possession of the contents and the estate can tolerate the floor. Automated opening is justified where the estate cannot, and it obliges you to make the unwrap path's guard as strong as the thing it now carries. Many estates run both: an automatic warm path, with the threshold kept as the cold-start route of last resort — provided that route is rehearsed, because an unrehearsed fallback is a plan, not a capability.
- Does the threshold requirement apply again while the store is running?No. Once recombined, the key is in the process's memory and the store serves until it stops or is deliberately re-locked. The requirement is a start-up event, which is why its cost shows up in recovery time rather than in request latency — and why a long-lived process can hide the cost for months.
- What number should you measure before defending either design?Time from total loss to serving at the worst hour, taken from a rehearsal that genuinely paged holders rather than from an estimate. That number is the floor for every service that cannot start until the store answers, and it is the only figure that makes the tradeoff concrete.
- Can you keep both designs?Commonly yes: an automated path for ordinary restarts with the threshold kept as the cold-start route of last resort. It only works if the fallback is rehearsed on a schedule — an unrehearsed fallback is a plan rather than a capability, and it will be discovered during the incident it existed for.
A night safe that opens only when two managers each turn their own key. The power can be back on at 2am and the safe still stays shut — that is the feature and the bill at the same time.
saying these in an interview costs you the question
- Says automating the step changes nothing about the threat model.
- Claims a threshold of shares also stops an authorised caller reading values.
- Treats the 3am recovery cost as a purely security-side concern.
- Parks every share where one script can reach them and calls it unchanged.
- Assumes the fallback path works without ever having rehearsed it.