Your requirements name four broker settings a hosted tier must honour — how do you prove it does before migrating?

## Why the requirement list has to be rewritten first A requirement that names a setting is untestable on a tier that does not have that setting, and it is also untestable on a tier that has a setting with the same name and different behaviour. So the first move is translation: every requirement becomes a sentence about something the cluster must be **seen to do**. - Not "we must be able to set the copy count to three" but "a write must not be acknowledged unless three independent failures would be needed to lose it." - Not "we need our own authorization component" but "a principal outside this list must be refused when it attempts to read this stream, and the refusal must be visible in an audit trail we can export." - Not "we need control of flush behaviour" but "an acknowledged write must survive the simultaneous loss of the machine that accepted it." The translated form has two virtues. It is neutral about how the tier achieves it, which is the only fair way to compare tiers that are built differently. And it is **observable**, which is what makes the next step possible at all. ## The probe, per requirement 1. **Write** the value or the rule the requirement needs. A refusal here ends the investigation for that setting: it is withheld. 2. **Read the effective value back** from the broker's own view rather than from the form you submitted. A different value coming back means the setting is fixed, or clamped into a range the tier supports. 3. **Drive the trial cluster into the condition the setting governs** and record what happens. A restart under write load. A principal that your rules should deny. A stream left to reach the tier's storage behaviour. This is the only step that distinguishes a setting the tier honours from one it accepted and disregarded. 4. **Record the verdict with its date and the tier's version.** The classification is evidence, and evidence has a shelf life. ## Deciding which refusal is fatal Not every refusal rules a tier out, and a candidate who says otherwise has not run this exercise on a real purchase. The test is whether the requirement can be met somewhere you still control: | Refusal | Usually survivable when | Usually fatal when | |---|---|---| | Copy count fixed below what you wanted | the tier's own guarantee already meets the loss budget you must honour | an external rule states a number and the tier's is lower | | Own identity or decision component refused | the tier's rule model expresses the same rules and exports an audit trail | the rules depend on attributes only your own component knows | | Flush behaviour not exposed | the tier's durability promise is written down and covers the case | your loss budget is tighter than anything the tier will commit to | | Cleanup or storage behaviour narrowed | the application can tolerate the tier's behaviour | a legal or contractual rule requires the behaviour it refuses | The pattern is the same each time: a refusal is decisive when the requirement comes from **outside** the team — a regulator, a contract, a customer promise, a stated loss budget — and nothing in a layer you still own can make up the difference. It is merely inconvenient when the requirement is internal, or when a compensating control exists at the application or estate level. ## When the trial cluster cannot be driven into the condition This happens, and it is worth saying out loud rather than pretending the test always completes. You often cannot fail a node on someone else's cluster on demand, and you may not be able to reproduce a storage-layer failure at all. Three honest responses: - Ask the provider to state the behaviour in writing, and treat the written statement — not a conversation — as the evidence. A contractual commitment is weaker than a measurement but far stronger than an assumption. - Approximate the condition: a rolling maintenance period the provider schedules, a deliberate client-side fault, a load profile that pushes the tier into the behaviour indirectly. - Mark the requirement **unproven** and carry it as a named risk with a compensating control, rather than letting it quietly become "met". ## Why this is re-run, not done once The withheld set is a product decision, and products move. A tier upgrade can turn an honoured setting advisory. A move between purchase shapes of the same product can change the architecture underneath an unchanged surface. Adoption of an interface-compatible tier — one that speaks a familiar client protocol over a different implementation — brings a surface that accepts a broad vocabulary on purpose, where acceptance is a compatibility claim rather than a promise. None of these changes anything in your own configuration, so nothing triggers a review unless you schedule one. ## What an interviewer is listening for The weak answer is "we would ask the provider". The strong answer has three parts in order: requirements rewritten as behaviours, a trial cluster driven into each behaviour's condition, and an explicit rule-out rule that separates the refusal you can design around from the one that ends the evaluation. Being able to say which of your four requirements you would abandon, and which you would walk away over, is the part that shows the exercise has actually been done.