Before trusting a hosted broker's setting sheet, which three states can a broker setting be in, and why does that matter?

## Why a setting sheet is not evidence A hosted broker's published sheet, and the management surface it comes with, answer one question: is this setting **present**? Candidates routinely treat that as an answer to a different question: do I **control** it? The gap between those two is where migrations go wrong, and the way to close it is to insist that every setting on your requirement list be classified into one of three states before you commit. ## The three states 1. **Withheld.** The tier does not offer the setting at all. There is no field, no attribute, no way to state it. This is the honest failure: it shows up on the first read of the sheet, it is easy to argue about in a design review, and it costs you nothing but the decision. 2. **Fixed.** The setting is visible and carries a value, and that value cannot be changed. You have lost the choice but kept the information. This is far better than it sounds: a known constant is designable. If the pinned value is three copies, or a durability grade, you can write the rest of the system around it and say honestly what the system guarantees. 3. **Silently ignored.** The management surface accepts your value, stores it, and echoes it back on the next read, while the broker underneath does something else entirely. You have lost the choice *and* the information, and you have also lost the signal that would have told you. Everything looks configured. Nothing is. ## Why the third state is the expensive one The first two states are visible at purchase time, by reading. The third is visible only by measurement, and usually only under the exact condition the setting was there to govern — a node lost, a principal that should have been denied, a crash mid-write. That is the worst possible moment to learn it, because it is the moment you were relying on the setting. | State | Choice | Information | When you find out | |---|---|---|---| | Withheld | lost | kept — the absence is explicit | reading the sheet | | Fixed | lost | kept — the value is readable | reading the sheet | | Silently ignored | lost | lost — the echo is misleading | during the incident it governs | ## How a setting slips between states A setting does not sit still, and this is what makes a one-off check insufficient: - A tier is upgraded, and a setting that used to be honoured becomes advisory, because the provider changed the implementation beneath the same surface. - A workload is moved from a provisioned-capacity tier to a consumption-priced tier of the same product; the surface is the same, but the underlying architecture is not, and some settings no longer attach to anything. - An **interface-compatible tier** is adopted — a service that speaks a well-known client protocol but is a different implementation underneath. These accept a broad vocabulary on purpose, because accepting it is how they claim compatibility; whether each accepted item is honoured is a separate question and often an undocumented one. - A setting is honoured at one scope and ignored at another — accepted per stream, but overridden by a tier-wide value the tenant cannot see. ## The check that separates honoured from ignored Three steps, in order, and only the third is decisive: 1. **Write** the value you need. If this is refused, the setting is withheld, and you are done. 2. **Read the effective value back**, from the broker's own view rather than from the form you just submitted. A read that returns something other than what you wrote tells you it is fixed, or clamped into a supported range. 3. **Observe the behaviour the setting governs**, on a trial cluster, under the condition it exists for. A value that reads back correctly and does not change what the cluster does is an ignored setting. ## What varies across platforms Do not assume one universal shape here. Some tiers publish their pinned values openly and are easy to classify as fixed. Others expose a surface inherited from an engine they only partially implement, which is where silent acceptance is most common. Others again replace the layer a setting belongs to — where writes land in a replicated storage service rather than on a node's own disk, a flush setting has nothing to attach to, and whether the tier withholds it or accepts and ignores it is a product decision, not a law. The answer an interviewer wants is the classification and the probe, not a claim about a particular vendor.