Tag coverage is at 98% and teams still argue about their bill every month. Roughly a fifth of the spend is shared - the service mesh, the log pipeline, NAT gateways, the Kafka cluster, and the commitment discounts. How would you allocate it?

What the interviewer is testing

Whether you know that allocation exists to change behaviour, not to produce an accurate invoice. Candidates who reach straight for a metering design have optimised precision; the job is to make each team's number something that team can actually move.

The clarifying questions that change the answer

• What decision is this number for — a budget, a pricing model, or an engineering priority? Pricing needs defensible precision; prioritisation needs a ranking.
• Can the team change the driver? If not, allocating on it produces resentment and no saving.
• Is the platform team's budget allowed to carry a residual, or must every cent land on a product team?

A strong answer's arc

Three methods, chosen per cost, not once for everything.

1. Even split. Cheap, and it teaches nothing. It penalises small teams and makes the biggest consumer invisible. Acceptable only for costs that are genuinely a fixed platform tax, such as an identity provider's base fee.
2. Proportional to a driver. Mesh cost by bytes through the proxy, log pipeline by GB ingested per source, Kafka by partitions plus bytes produced, NAT by gigabytes processed per source. This is the default, and the driver must be one the team controls. Splitting NAT by headcount would be arithmetic with no lever attached.
3. Direct metering. A real per-request cost trace. Reserve it for the handful of costs where the pricing model depends on it, because the engineering to maintain it usually exceeds the spend it reallocates.

Then handle the residual explicitly. Whatever cannot be attributed becomes a visible platform line, owned by the platform team's budget, and its size is a platform KPI that should fall over time. Hiding the residual by spreading it destroys every team's ability to trust their number.

Then decide which price teams see. Unblended cost makes a team look expensive for running on-demand capacity it never chose. Showing amortised commitment cost — the discounted rate spread across the term — is the honest default, because it charges teams the rate the organisation actually pays and keeps the commitment decision where it belongs, with the platform. The gap between amortised and on-demand is the platform team's savings, and it should be reported as such.

Common weak answers

• "Split it evenly, it's only 20%." The 20% is precisely the part teams argue about, because it is the part they cannot explain.
• "Build per-request cost attribution." A quarter of engineering for precision nobody needed. Allocation has to be accurate enough to rank teams and trends, not to invoice them.
• "Move to chargeback and the behaviour will follow." Chargeback with an unactionable driver produces gaming and finance tickets, not efficiency.

What a strong answer adds

A statement of the precision target up front — "accurate to about 10%, stable month to month, and every line traceable to a driver the owner can change" — and a note that allocation stability matters more than allocation accuracy. A number that moves 30% because the methodology changed destroys the trust that makes anyone act on it, and the failure is silent: teams quietly stop opening the report.

The decision rule to state out loud: choose a driver the owner can change, and if no such driver exists, leave the cost in the platform residual rather than allocating it. An unallocated cost that someone owns beats an allocated cost nobody can act on. In production this is the difference between a report that changes a roadmap and one that generates a monthly argument.