Each team has a named space with an agreed throughput quota, but the platform attaches quotas to client credentials rather than spaces — what does the quota actually cover?
answer
- a ceiling has two halves
- the number and what it hangs off
- governance per team, accounting per credential
- the mapping is what rots
basics
~20 sIt covers the credentials enrolled in it, not the team. A quota is a number plus an attachment point, and where that point is a credential rather than the space, per-team budgeting is only as accurate as the credential-to-team mapping.
solid answer
~40 sEvery ceiling has two halves: a number, and the thing it hangs off. Platforms differ on what that thing can be — a named space, a name pattern, a client identity, or nothing finer than the whole cluster. When the policy is written per team and the platform counts per credential, the two are joined by a mapping, and the mapping is where the accuracy goes. A new service with a fresh credential is outside the budget or lands in a default bucket. A credential shared by two teams merges their budgets. Automation and operator credentials are usually nobody's. The fix is structural rather than vigilant: issue credentials as part of creating the space, so a principal cannot exist without a team, and periodically list principals with traffic and no mapping.
go deeper
Take away the shape: a quota is a number plus something it is attached to. If it is attached to a credential, it counts that credential's traffic and nothing else.
Be able to list the attachment points platforms offer — a space, a name pattern, a client identity, the cluster — and say what each one actually counts.
Show the operational consequence: the unenrolled new service, the shared credential, the operator principal budgeted nowhere. Then describe the report that finds them rather than promising to be careful.
Design the mapping out of existence. If credentials are issued by the process that creates a team's space, per-team accounting is structural; if they are issued separately, you have bought yourself a permanent reconciliation.
## A quota is a number and an attachment point It is easy to discuss a ceiling as if it were a single thing — *the team gets so much throughput*. Operationally it is two things: **the number**, and **what the number is attached to**. The number is the part everybody negotiates. The attachment point is the part that decides whether the negotiation meant anything, and it is fixed by the platform rather than by the policy. This leaf is about the second half only. What a broker does at the moment a ceiling is reached — slow the caller, refuse the call, buffer — is a separate subject, and platforms differ there too. ## Where platforms attach a ceiling - **To a named space.** The happy case: the governance unit and the accounting unit are the same object, and a team's traffic is whatever its space carried. - **To a name pattern or prefix.** Close enough, as long as the prefix boundary is itself sound — anything named outside the pattern is outside the budget. - **To a client identity or credential.** Common, and the source of the mismatch in this question: accounting follows the principal, while governance follows the space. - **To the cluster only.** Then there is no per-team ceiling at all, and per-team budgets are an agreement enforced by conversation. | Attachment point | What is counted | What can drift | |---|---|---| | The named space | All traffic to streams in the space | Nothing much; the units agree | | A name pattern | Traffic to matching names | A stream named outside the pattern | | A client credential | Traffic from that principal | Which principals belong to which team | | The cluster | Everything | The whole per-team notion | ## What drifts when the points disagree 1. **The unenrolled credential.** A team adds a service, mints a credential, and its traffic is counted against nothing — or against a default bucket sized for one small client. Neither is what the policy says. 2. **The shared credential.** Two teams use one principal because it was simpler. Their budgets are now one budget, and the number agreed with each of them is meaningless. 3. **The borrowed credential.** One team's automation uses another team's principal for a migration and never stops. Traffic is attributed to the wrong team, and the misattribution is invisible in any report drawn per team. 4. **The nobody credential.** Operator and break-glass principals belong to no team, so their traffic is budgeted nowhere — usually the largest single unbudgeted source on a well-run cluster. Every one of these is a mapping defect, not a capacity defect. The cluster is doing exactly what it was told; it was told something about principals, and someone read the answer as being about teams. ## Closing the gap The durable fix is to remove the opportunity for the mapping to drift rather than to keep correcting it: - **Issue credentials as part of creating the space.** If a principal cannot come into existence outside the process that knows which team it belongs to, the mapping is a by-product instead of a chore. - **Refuse unmapped principals a grant.** A credential that no team claims should not be able to acquire access, which makes the mapping self-enforcing. - **List principals with traffic and no mapping**, on a schedule. This is the one report that finds the borrowed credential and the operator principal, and it is short enough to read. - **State the budget in the units the platform counts in.** If accounting is per credential, the policy should say *the sum over the team's enrolled credentials*, so the sentence is checkable against what the cluster actually measures. ## Why interviewers ask this It separates candidates who have read a policy from candidates who have reconciled one. The give-away weak answer treats the ceiling as if attaching it were the end of the work — *we set a quota per team* — and never asks what the platform is capable of hanging a number off. The strong answer names the attachment points, says which one this platform offers, and describes the mapping as the thing that needs maintaining, because that is the part that silently rots while the dashboard keeps showing a number per team.
- Which attachment points do platforms actually offer?It varies genuinely. Some attach a ceiling to a named space, some to a name pattern, some only to a client identity, and some offer nothing below the whole cluster. Before designing per-team budgets, find out which of those your platform supports, because the policy has to be written in the unit the platform can count.
- How do you stop the credential-to-team mapping drifting?Make credential issuance part of creating the team's space, so a principal cannot exist unattached, and refuse a grant to any principal no team claims. Then run one periodic report: principals with traffic and no mapping. That report is what catches the borrowed credential and the operator principal.
- Does the same problem exist for grants?Yes, in mirror image. Grants are written against a space or a prefix but held by principals, so the same mapping decides who is inside the boundary. The difference is that a missing grant is noticed immediately — someone is refused — while a missing quota enrolment is noticed by nobody, because unbudgeted traffic simply flows.
saying these in an interview costs you the question
- Assumes a ceiling agreed per team automatically covers new credentials
- Treats a grant on a space as if it enrolled the principal in a budget
- Forgets a shared credential merges two teams into one budget
- Believes every platform can attach a ceiling to a named space
- Confuses the attachment point with the dimension the ceiling is expressed in