Your workloads declare no reservation or ceiling, so the scope's default is stamped onto each — what goes wrong later?

seniorshould knowfreq 41%

answer

a scope rule, not a spec field
a budget can only add declared numbers
a placeholder, never a measurement
too low squeezes, too high drains
the effective numbers are not in the spec

basics

~20 s

A scope default is a placeholder chosen for the whole scope, not a measurement of your workload. Too low, and it is throttled or killed against a ceiling nobody sized for it; too high, and unused headroom drains the scope's budget while the hosts sit idle.

solid answer

~50 s

A default injected by the scope is not the same thing as a field default in your spec: it is a rule attached to the named scope that fills in a reservation and a ceiling for any workload there that declares none, and it is usually paired with a cap on how much a single workload may declare. It exists because a budget over aggregate reservations can only add up numbers that exist, so effectively nothing runs in a budgeted scope without one. The trouble is whose number it is. If the stamped reservation is below what the workload really needs, the scheduler places it as though it were nearly free and it fights for CPU on a crowded host. If the stamped ceiling is below its real peak, a memory-hungry renderer is killed at that ceiling. If both are generous, the scope reads full while the hosts are half idle.

code

yaml · 18 lines

yaml

scope: reports

workloadDefaults:          # stamped when a workload declares none
  cpuCoresReserved: 0.1
  cpuCoresCeiling: 1
  memoryGiBReserved: 0.25
  memoryGiBCeiling: 0.5

workload:
  name: report-renderer
  declared: {}             # nothing declared by the team
  effective:               # what the scheduler and runtime actually see
    cpuCoresReserved: 0.1
    cpuCoresCeiling: 1
    memoryGiBReserved: 0.25
    memoryGiBCeiling: 0.5

# the numbers enforced at runtime appear nowhere in the team's own spec

go deeper

for a junior

Recall that a scope can fill in a reservation and a ceiling for a workload that declares none, and that those numbers come from the scope rather than from the workload's own document.

for a middle

Explain why a budget makes injection necessary — an aggregate of declarations cannot count a workload that declared nothing — and distinguish a default injected by the scope from a field default in the spec.

for a senior

Show the consequences you have actually chased: latency that tracks other tenants because the stamped reservation was tiny, a process killed at a memory ceiling nobody chose, and a budget full while hosts sit idle.

for a principal

The lever to weigh is that the platform team's default silently sets every undeclaring team's runtime shape. Decide whether that default should be generous, hostile enough to force teams to declare, or absent with creation refused instead.

Two different things called a default

The word default covers two mechanisms in this material, and mixing them up is where the confusion starts.

A field default in the spec is part of the workload document's own schema: a field you left out takes a value the schema says it takes. It is visible to anyone reading the schema, and it is the same everywhere the schema is.
A default injected by the scope is a rule attached to the named scope. At creation time, a workload in that scope that declares no reservation or no ceiling has one written into it. Which numbers get written depends entirely on which scope you created the workload in.

The second one is what a platform team configures when it onboards a new team, and it typically carries more than defaults: a floor and a ceiling on what any single workload in the scope may declare, so that one workload cannot claim the whole budget on its own.

Why a budget forces a number onto every workload

A budget over aggregate reservations can only add up declarations that exist. A workload that declares nothing contributes nothing to the total, which would let the scope's real consumption walk straight past its ceiling while the accounting stayed comfortable. So a budgeted scope cannot tolerate undeclared workloads. Either the platform refuses a workload that declares nothing, or it stamps the scope's own default onto it — and the practical effect is the same: in a budgeted scope, everything running has a number attached, whether or not anyone chose it deliberately.

What goes wrong when the number is the scope's, not yours

The stamped value is a convention chosen by whoever set up the scope, often copied from the last scope they set up. It has never seen your workload.

Stamped number	What the scheduler and runtime then do	The symptom
Reservation far below real appetite	The scheduler subtracts almost nothing from a host's capacity and packs the workload onto a busy machine	Latency that moves with other tenants' load and cannot be reproduced anywhere quiet
CPU ceiling below real peak	The runtime throttles the process at the ceiling — it stays alive and runs slower	Tail latency that flattens at a ceiling no one remembers declaring
Memory ceiling below real peak	The process is killed when it crosses the ceiling	A renderer that dies on the largest report and restarts cleanly on small ones
Reservation far above real appetite	The scheduler reserves capacity that the process never uses, and the scope's total climbs	The scope's budget reads full while the hosts run half idle, and the next team's workload is refused

Note the direction on the middle two rows, because it is the classic way this gets stated backwards: a CPU ceiling throttles and the process survives; a memory ceiling kills it. A default that is wrong on CPU produces a slow service, and a default that is wrong on memory produces a dead one.

The part that is invisible in review

The expensive property of an injected default is that it is not in your spec. The document in your repository says nothing about reservations, so:

a reviewer reading the spec cannot predict the shape the workload will run at;
the same spec produces different behaviour in two scopes, which is exactly the failure that looks like an environment mystery;
changing the scope's default silently changes every workload that relied on it, with no change to any workload document at all.

That last point is worth stating plainly to an interviewer: the injected default is a platform-team lever that moves your workload's runtime shape without touching anything you own.

Choosing numbers of your own

The fix is not to argue about the default; it is to stop depending on it.

Measure first. Watch the workload's steady-state CPU and memory over a period that includes its real peak — for a report renderer, the largest report anyone actually runs, not the average one.
Set the reservation near steady state. The reservation is what the scheduler subtracts when it places the workload, so it should describe what the workload normally needs. Padding it is how a scope's budget gets consumed by headroom nobody uses.
Set the ceiling above the worst observed peak, with margin. The ceiling is what the runtime enforces on the running process, so it is the number that decides whether an unusual-but-legitimate workload is throttled or killed.
Revisit after the workload changes. A number declared once and never re-measured is the same kind of guess the stamped default was — it has just moved into your repository, where at least it is reviewable.

The short version: an injected default guarantees that a budget can do its accounting. It guarantees nothing at all about whether the number fits your workload, and every failure in this area comes from reading it as though it did.

## Two different things called a default The word *default* covers two mechanisms in this material, and mixing them up is where the confusion starts. - A **field default in the spec** is part of the workload document's own schema: a field you left out takes a value the schema says it takes. It is visible to anyone reading the schema, and it is the same everywhere the schema is. - A **default injected by the scope** is a rule attached to the named scope. At creation time, a workload in that scope that declares no reservation or no ceiling has one written into it. Which numbers get written depends entirely on which scope you created the workload in. The second one is what a platform team configures when it onboards a new team, and it typically carries more than defaults: a floor and a ceiling on what any single workload in the scope may declare, so that one workload cannot claim the whole budget on its own. ## Why a budget forces a number onto every workload A budget over aggregate reservations can only add up declarations that exist. A workload that declares nothing contributes nothing to the total, which would let the scope's real consumption walk straight past its ceiling while the accounting stayed comfortable. So a budgeted scope cannot tolerate undeclared workloads. Either the platform refuses a workload that declares nothing, or it stamps the scope's own default onto it — and the practical effect is the same: **in a budgeted scope, everything running has a number attached, whether or not anyone chose it deliberately.** ## What goes wrong when the number is the scope's, not yours The stamped value is a convention chosen by whoever set up the scope, often copied from the last scope they set up. It has never seen your workload. | Stamped number | What the scheduler and runtime then do | The symptom | |---|---|---| | Reservation far **below** real appetite | The scheduler subtracts almost nothing from a host's capacity and packs the workload onto a busy machine | Latency that moves with other tenants' load and cannot be reproduced anywhere quiet | | CPU ceiling **below** real peak | The runtime throttles the process at the ceiling — it stays alive and runs slower | Tail latency that flattens at a ceiling no one remembers declaring | | Memory ceiling **below** real peak | The process is killed when it crosses the ceiling | A renderer that dies on the largest report and restarts cleanly on small ones | | Reservation far **above** real appetite | The scheduler reserves capacity that the process never uses, and the scope's total climbs | The scope's budget reads full while the hosts run half idle, and the next team's workload is refused | Note the direction on the middle two rows, because it is the classic way this gets stated backwards: **a CPU ceiling throttles and the process survives; a memory ceiling kills it.** A default that is wrong on CPU produces a slow service, and a default that is wrong on memory produces a dead one. ## The part that is invisible in review The expensive property of an injected default is that it is not in your spec. The document in your repository says nothing about reservations, so: - a reviewer reading the spec cannot predict the shape the workload will run at; - the same spec produces different behaviour in two scopes, which is exactly the failure that looks like an environment mystery; - changing the scope's default silently changes every workload that relied on it, with no change to any workload document at all. That last point is worth stating plainly to an interviewer: the injected default is a platform-team lever that moves your workload's runtime shape without touching anything you own. ## Choosing numbers of your own The fix is not to argue about the default; it is to stop depending on it. 1. **Measure first.** Watch the workload's steady-state CPU and memory over a period that includes its real peak — for a report renderer, the largest report anyone actually runs, not the average one. 2. **Set the reservation near steady state.** The reservation is what the scheduler subtracts when it places the workload, so it should describe what the workload normally needs. Padding it is how a scope's budget gets consumed by headroom nobody uses. 3. **Set the ceiling above the worst observed peak, with margin.** The ceiling is what the runtime enforces on the running process, so it is the number that decides whether an unusual-but-legitimate workload is throttled or killed. 4. **Revisit after the workload changes.** A number declared once and never re-measured is the same kind of guess the stamped default was — it has just moved into your repository, where at least it is reviewable. The short version: an injected default guarantees that a budget can do its accounting. It guarantees nothing at all about whether the number fits your workload, and every failure in this area comes from reading it as though it did.

Why does putting a budget on a scope force every workload there to declare something?
Because a budget over aggregate reservations adds up declarations, and a workload with no declaration contributes nothing to that total. If undeclared workloads were allowed, the scope's real consumption could pass its ceiling while the accounting still looked fine. So the platform either refuses the undeclared workload or supplies the scope's own default — either way, nothing runs there without a number attached.
How would you pick numbers to declare instead of accepting the stamped default?
From observed behaviour, not from the scope's convention. Put the reservation near the workload's steady-state usage so the scheduler places it honestly, and the ceiling above its worst observed peak with margin, so an unusually large unit of work is not throttled or killed. Then re-measure when the workload changes shape.

saying these in an interview costs you the question

Treats a stamped default as a measurement of the workload
Thinks an over-large reservation is free because it goes unused
Says a workload is killed when it exceeds its CPU ceiling
Expects the spec in the repository to show the effective numbers
Assumes a scope default removes the need to ever declare anything

Your workloads declare no reservation or ceiling, so the scope's default is stamped onto each — what goes wrong later?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two different things called a default

Why a budget forces a number onto every workload

What goes wrong when the number is the scope's, not yours

The part that is invisible in review

Choosing numbers of your own

▾common follow-ups2 questions

▾red flags5 flags

Two different things called a default

Why a budget forces a number onto every workload

What goes wrong when the number is the scope's, not yours

The part that is invisible in review

Choosing numbers of your own

answer

go deeper