An interviewer says - we run one Kubernetes platform for 40 product teams and finance wants each team's true cost next quarter. How do you allocate it and what do you refuse to allocate?

What the interviewer is testing

Whether you understand that allocation is an incentive system, not an accounting exercise. Any method that adds up will satisfy finance. Only some methods cause teams to make better decisions, and a few cause actively harmful ones. The second question - what you refuse to allocate - is where the senior answer lives.

The clarifying questions that change the answer

• Showback or chargeback? Showback informs; chargeback moves budget and changes behaviour, including behaviour you did not intend. Ask which, because the accuracy bar is far higher when money actually moves.
• What decision should this change? If the goal is to stop waste, usage-based allocation works. If it is to decide whether a product is viable, you need fully loaded cost including the platform team's salaries.
• What is the tagging and namespace discipline today? Allocation quality is bounded by it, and the honest first deliverable is often a coverage number rather than a bill.
• How is the platform funded now, and is a team allowed to leave if it dislikes the price? If not, the chargeback is a tax, and pricing it precisely gives false comfort.

A strong answer's arc

1. Split the bill into three buckets. Direct - compute, storage and transfer attributable to a namespace. Shared - control plane, ingress, mesh, logging pipeline, image registry, CI. Platform team - people and the tools they run.
2. Allocate direct cost by measured usage, and specifically by requests rather than limits for CPU and memory, because requests are what the scheduler reserves and therefore what the team actually consumes from the cluster. Billing on usage rather than requests rewards under-requesting, which causes evictions and noisy-neighbour problems - the metric chooses the failure mode.
3. Allocate shared cost by a simple, published driver - share of direct spend, or share of pods - and say openly that it is an approximation. Spend an afternoon on this, not a quarter. Precision here buys nothing and costs trust.
4. Report idle and overhead as their own line, owned by the platform team. Unallocated headroom, the redundancy ceiling, failed nodes and reservation waste belong to the platform, because the platform is the only party that can reduce them. Smearing them across teams hides the one number the platform should be judged on.
5. Publish a unit price per resource per month and keep it stable for a quarter, so teams can plan. A price that moves weekly cannot inform any decision.
6. Pair the bill with the lever. Every invoice line links to the action that would reduce it: right-size requests, move a workload to interruptible capacity, drop log volume, change retention. An allocation with no accompanying lever produces resentment and no savings.

What I refuse to allocate

• Redundancy and headroom held for availability targets the company set. Charging a team for the empty third of a three-zone fleet invites it to argue for less resilience.
• Spare capacity bought to absorb growth, which is a central bet, not a team's consumption.
• Migration and modernisation work done for the estate's benefit.
• The cost of a platform decision teams could not influence, such as a mandated security agent on every node. Charge people for what they chose; absorb centrally what you chose for them.

Common weak answers

• "Tag everything and the problem solves itself." Tags give you direct cost, which is typically 60–80% of the bill. The argument is always about the rest.
• "Charge by limits, it is simpler." It bills teams for capacity the cluster never reserved and rewards setting limits low, which causes throttling.
• "Allocate everything, perfectly." The pursuit of completeness is how allocation projects consume a quarter and ship a spreadsheet nobody acts on.

What a strong answer adds

The failure mode of the programme itself: the chargeback that makes a team refuse a reliability improvement because it shows up on their line. Name it, and propose the countermeasure - reliability spend funded centrally, efficiency spend charged back - along with one review a quarter where the biggest allocated line is examined jointly by the platform and the product team rather than sent as an invoice.