You must set one fetch path as the standard for every team in the estate — what decides it?
answer
- a platform decision with a migration attached
- can a fetcher reach every host
- per-workload identity, or nothing gained
- count teams, not services
- name the exception route up front
basics
~20 sHost uniformity, whether the platform can attest one workload apart from another, how many teams would otherwise carry a client, and who is paged when the fetcher cannot reach the store — plus a documented exception route.
solid answer
~50 sTreat it as a platform decision with a migration attached rather than a preference. Four inputs decide it: whether a fetcher can be placed on **every** host you run, including the parts nobody wants to touch; whether the platform can tell one workload from another, because a per-workload companion buys nothing at the store if the store still authenticates one identity; how many teams and release cadences a client library would have to cross; and who carries the failure when the fetcher cannot reach the store. Then state what you accept. A shared fetcher is an estate-wide dependency your team owns, and one whose compromise reaches every value it may read on that host. Publish an exception route for workloads that resolve a name at run time, and say up front what migrating off the standard would cost.
go deeper
Recall that estates usually pick one way for workloads to obtain credentials, rather than letting each service invent its own, and that the choice is between a host helper, a companion and self-fetch.
Explain how each path differs in what it needs on the host, which identity the store authenticates, and what a store change costs, since those are the inputs a standard is chosen on.
Argue a choice against a concrete estate — host uniformity, identity capability, team count — and name the failures the standard is accepting rather than eliminating.
Own the whole commitment: the migration in, the exception route, the operating cost, the measurements that would tell you it is failing, and the conditions under which you would change it.
## Why this is a lead's decision Picking a fetch path for one service is an engineering choice. Picking one for an estate is a commitment: to operate a component on every machine, or to put a dependency into every team's build, for as long as the standard stands. It comes with a migration in (everything currently doing something else) and a migration out (whenever the standard changes), and both are paid by teams who did not make the choice. That is what makes it open-ended rather than a matter of recalling which path is best — there is no best, only a fit against a particular estate. ## The four inputs 1. **Can a fetcher be placed on every host?** A host helper standard requires something resident on each machine, kept current. Estates almost always contain hosts that fail this: an appliance, a fleet owned by another group, machines with no configuration ownership. A standard that cannot reach part of the estate is not a standard; it is a default plus an unmanaged remainder. 2. **Can the platform distinguish one workload from another?** Per-workload fetching only narrows grants and sharpens attribution if the store authenticates something workload-shaped. Where the platform cannot provide that, a companion per workload is deployment hygiene and nothing more, and fixing the identity becomes the prerequisite piece of work rather than a later refinement. 3. **How many teams would carry a client?** Count teams and release cadences, not services. Thirty services across two teams is an upgrade; thirty across ten teams is a programme, because the migration finishes when the slowest team finishes. 4. **Who owns the failure?** When the fetch cannot complete, something must decide what happens. A shared fetcher concentrates that decision — and the pager — in the platform team. A client in every service distributes both, and the estate then has as many behaviours as services. ## What each standard actually commits you to | Standard | You own | You accept | |---|---|---| | Helper on the host | a component on every machine, and its grant | one identity per machine, a grant that is the union of what that machine runs, and an estate-wide dependency | | Companion per workload | a deployment pattern every team adopts | one more process beside every workload, and a benefit that depends on per-workload identity existing | | Service fetches for itself | a client library and its upgrades | the store's address in every codebase, and the next store change measured in teams | The right-hand column is the honest part of the decision, and it is the part most standards documents omit. A standard nobody has written the costs down for gets re-litigated by every team that hits one of them. ## The exception route is part of the standard Some workloads genuinely cannot use the house path — most often because the name they need is only known at run time, per tenant or per job, and no fetcher outside the process can resolve what it was never told. Write that exception down, with the condition that qualifies for it and what the exception owes in return (a narrower grant, a named owner, a review date). An unwritten exception route does not prevent exceptions; it just means they are made silently and never revisited. ## Knowing whether it worked Pick the measurements before you publish, because they are the only defence against a standard that is true on paper: - **How many services still fetch outside the standard**, and whether that count is falling. A growing exception list means the standard is wrong for part of the estate. - **How long an address or store change takes end to end**, from decision to the last service on the new value. This is the number the standard was supposed to improve. - **How wide the standard fetcher's grant has grown.** Shared fetchers accrete names as new workloads land, and a grant that started narrow rarely narrows on its own. ## The answer's shape A strong answer names the inputs, commits to one path **for this estate**, states what it accepts, and says what it would take to change its mind — a new class of host, an identity capability arriving, an exception list crossing some threshold. An answer that names a favourite path without the estate it fits is the failure mode this question is designed to find.
- What makes a mixed estate reject a host-helper standard?Hosts you cannot install on, or cannot keep current: an appliance, a fleet another group owns, machines with no configuration ownership. The standard then has to be a path that needs nothing resident on the host, or the estate needs two standards with a stated boundary between them.
- How would you know a year later whether the standard is working?Count the services still fetching outside it and time an address change end to end. A growing exception list says the standard is wrong for part of the estate; an address change still taking a quarter says the coupling you standardised on is not the one you thought.
- What is the argument against standardising at all?That different parts of the estate genuinely differ, and a single path forces a bad fit somewhere. The answer is usually a small number of named paths with the conditions for each, rather than either one universal rule or an open field where every team invents its own.
saying these in an interview costs you the question
- Picks a path without asking what the hosts look like
- Standardises on a companion where the store sees one identity anyway
- Assumes teams migrate because a standard document says so
- Forgets the shared fetcher becomes a dependency someone is paged for
- Publishes a standard with no documented exception route
- Judges the choice only on the day-one rollout