skip to content

Your organisation runs dozens of in-memory tiers built for a private network it no longer has — what exposure contract do you set?

level: principalimportance: should knowfreq 34%

answer

  1. classify by contents, not by product
  2. mandate only what every store has
  3. in-process controls cannot be standardised
  4. the unclassified instance is the incident

basics

~20 s

Write the contract against what each tier holds, not which store a team chose. Placement and routing are required everywhere because they are the only controls every store in this class has; the rest scales with whether the contents are replaceable.

solid answer

~50 s

I would not write it as "configure your store properly", because the in-process controls differ across this family — some servers offer per-owner credential rules, some one shared credential, some no identity step at all — and a rule that cannot be stated uniformly gets waived. So the contract runs on two axes. First, classification by contents: a tier holding state that exists nowhere else, such as sessions, claims and deduplication records, is treated as a system of record for exposure purposes; a tier holding a replaceable copy is not. Second, controls ordered by universality: placement and deny-by-default routing are mandatory for everyone because every store can be placed; the server's credential check and per-owner rules are mandatory *where the server has them*; encrypting the hop and the copies on disk is mandatory for the first class. Then a per-instance inventory that is actually reviewed, because the instance nobody classified is the one that leaks.

go deeper

for a junior

The organisational version of this question is about rules that hold across many teams and several different stores, not about the settings of one instance.

for a middle

The mechanics to bring: which controls are universal across this class of store and which are per-product features, since only the universal ones can be written as a requirement everyone can meet.

for a senior

Show that the posture follows the contents — non-replaceable state raises the bar — and that you verify what each instance listens on rather than trusting a declared configuration.

for a principal

Own the cost side: name which tiers deliberately get less and why, what an encrypted hop and a terminating component cost to run, and what you do about the instances nobody has classified yet.

## Why the contract cannot be "configure each store properly" The organisation does not have one store; it has whichever members of this class each team picked, and their in-process controls genuinely differ. Some servers check a shared credential, some express per-owner credential rules, some have no identity step at all. Some terminate an encrypted connection; some need a component beside the process to do it. Some deployments are managed instances where nobody can reach the host and the platform supplies the network rules. A requirement written against a feature only some stores have is unmeetable for the rest, so it gets waived — and a waived requirement is worse than a narrower one that is enforced, because it teaches everyone that the contract is negotiable. ## Axis one: classify by contents The posture follows what the tier holds, not its label and not its product: - **Non-replaceable state** — sessions, claims, leases, deduplication records. Losing it is an identity and correctness incident; reading it hands over material the application already trusts. Treat the tier as a system of record for exposure purposes even though it is not one for durability purposes. - **A replaceable copy** — entries that can be recomputed from an origin. Exposure costs confidentiality of whatever those rows were, plus the ability of an attacker to plant entries the application will believe, plus a cold origin if it is emptied. Real, but a different tier of control. The classification travels with the data, not the environment, which is why a lower environment loaded from a copy of the real thing inherits the production posture or does not get the data. ## Axis two: order controls by whether every store has them | Control | Status in the contract | Why | |---|---|---| | Network placement and deny-by-default routing | Mandatory for every instance | The only control every store in this class has, whoever built it | | The server's credential check | Mandatory **where the server has one** | Absent entirely on some stores; cannot be a universal rule | | Per-owner credential rules | Mandatory for shared instances where supported, narrowest workable scope | Expressiveness varies; confirm what they can exclude | | Encrypting the hop | Mandatory for non-replaceable state crossing any shared network | Terminated in the server or in a component beside it | | Encrypting the copies on disk, and their backups | Mandatory for non-replaceable state; forbidden to write copies at all where it is cheaper | Backup retention, not the entry's lifetime, is the real exposure window | ## The inventory that finds the instance nobody classified Every incident of this shape I have seen came from an instance that was not on anyone's list. The inventory question that works is short and answerable regardless of product: 1. Which address is the **running process** listening on? 2. Which networks can route to that address, and which callers are on the allowed list? 3. Does the server check a credential at all — none, one, or per-owner rules? 4. Does the deployment write copies to disk, where do they land, and who can read the backups? 5. What class of contents is it holding, and who says so? None of those five depends on a feature being present to be answered, which is exactly why they can be asked of every team. ## What this costs, and where you deliberately do less A contract that pretends to be free is not owned by anybody: - Encrypting the hop costs connection setup time and a per-byte cost, and where the server cannot terminate it, an extra component beside every instance to run, upgrade and page on. - Per-owner rules cost coordination — someone has to decide the scopes and keep them current as prefixes change. - Forbidding copies on disk for a tier holding non-replaceable state means accepting a colder restart, and that trade belongs to the owning team with the exposure stated. So say out loud which tiers get less: a tier holding a replaceable copy, on a closed segment, reached only by its own callers, may reasonably get placement and routing and nothing more. Writing that exception down is what keeps the mandatory parts credible. ## What not to standardise Do not standardise the product, and do not standardise on a control that only the dominant store in the class implements — that is how a fleet ends up with a rule that half the instances silently fail. Standardise the questions, the classification and the two universal controls; let the in-process controls be "the strongest this server can express, recorded per instance". And name the underlying fact in the contract's first paragraph: this class of store was designed for a network the organisation no longer has, so the perimeter it assumed must now be reconstructed deliberately around each instance.

  • Where do development and test instances sit in this contract?
    In scope, because they are the reliable source of incidents: they are loaded with copies of real data and placed casually. The rule that works is that classification follows the data rather than the environment's name, so a test tier holding real session records inherits the production posture or is not given that data.
  • Why not simply require an encrypted hop and a credential on everything?
    Because some stores in this class have no identity step to require, so the rule is unmeetable for those teams and will be waived — and a waived rule devalues the rest. State the universal controls as requirements and the per-product ones as "the strongest the server can express", then verify per instance which that turned out to be.
  • Which single inventory fact finds the worst instances fastest?
    The address the running process listens on, joined with which networks can route to it. That pair surfaces the accidentally routable instance whatever the product is, needs no product feature to answer, and can be collected from the platform rather than from the team that owns the tier.

saying these in an interview costs you the question

  • Mandates a credential every store in the class is assumed to have.
  • Treats a private subnet as the whole of the contract.
  • Applies the strictest posture everywhere and watches it get waived.
  • Leaves lower environments holding real data out of scope.
  • Assumes each store can report who connected, so no inventory is needed.