What does a workload spec for an order service declare, and what does it deliberately leave out?

juniormust knowfreq 74%

answer

end state, not steps
a destination, not a route
image, count, reservation, ceiling, storage, exposure
reservation places it, ceiling constrains it
omitted fields still apply

basics

~20 s

A workload spec declares the end state: which image, how many copies, what each copy reserves and may not exceed, what storage it needs, and how it is reached. It leaves out the steps, the hosts and the current situation.

solid answer

~40 s

A workload spec is a description of the finished picture, not a script. It names the image to run — normally by digest, so the document means the same bytes everywhere — the number of interchangeable copies that should exist, the reservation and ceiling for CPU and memory per copy, any storage request with its access mode, and how the workload is exposed. What it does not contain is a sequence: no pull step, no start step, no host names, no ordering between fields. It also says nothing about what is running right now, which is read back separately. Fields you leave out still apply to the running workload, because the schema or the surrounding scope may supply a value the document never shows.

A workload spec is a description of the finished picture, not a script. It names the image to run — normally by digest, so the document means the same bytes everywhere — the number of interchangeable copies that should exist, the `reservation` and `ceiling` for CPU and memory per copy, any storage request with its access mode, and how the workload is exposed. What it does not contain is a sequence: no pull step, no start step, no host names, no ordering between fields. It also says nothing about what is running right now, which is read back separately. Fields you leave out still apply to the running workload, because the schema or the surrounding scope may supply a value the document never shows.

code

yaml · 17 lines

yaml

workload: orders-api
imageDigest: orders-api@9f2c1a7b3d4e
replicas: 4
perCopy:
  cpu:
    reservation: 0.5
    ceiling: 2
  memory:
    reservation: 512Mi
    ceiling: 1Gi
storage:
  - request: 20Gi
    accessMode: single-writer
    mountPath: /var/lib/orders
expose:
  port: 8080
  as: orders-api

go deeper

for a junior

Recall the shape: the document says which image, how many copies, how much resource each gets, what storage it needs and how it is reached. It states the end state and never the steps to get there.

for a middle

Explain the field-by-field mechanics, and especially the split between a reservation, which the scheduler subtracts from a host's free capacity, and a ceiling, which the runtime enforces on the process once it is running.

for a senior

Show that you read the effective object rather than the file: name the fields nobody wrote, where their values came from, and which omission would bite this workload first in production.

for a principal

The trade-off is how much a platform should inject on a team's behalf. Rich defaults make specs short and reviews misleading; empty defaults make every spec long and every omission visible.

A statement of the destination

A workload spec is the document a team hands to a cluster to say what should exist. It is written in a structured data format, stored by the platform as an object, and it reads as a set of assertions about the finished picture: this image, this many copies, this much resource per copy, this storage, reachable this way. Nowhere in it is there a verb meaning "and then do this". The spec for an order service is the same document whether the cluster currently runs zero copies, three copies or six, because it describes where the cluster should end up and not the distance it has to travel.

That is the idea an interviewer is checking. Someone who has only ever started containers by hand tends to describe a spec as a saved command line with the flags moved into a file. It is not. A command line is a step, and a step is only meaningful from a particular starting point; a spec is a destination and is meaningful from any starting point.

The fields that carry the end state

Field	What it declares	Who acts on it
image identity	the exact bytes to run, normally named by digest	the node agent that fetches and starts it
copy count	how many interchangeable copies should exist at once	the controller that keeps the set at that size
reservation	how much CPU and memory to set aside for each copy	the scheduler, which subtracts it from a candidate host's free capacity
ceiling	the most a copy may consume once it is running	the runtime on the host, which throttles CPU and kills on memory
storage request	how much durable space, and with what access mode	the storage layer, which binds a backing volume to the copy
exposure	the port the process listens on and the name others use	the networking layer

Two of those rows are the ones candidates most often swap. A reservation is a placement input: it is the amount the scheduler treats as spoken for on whichever host it picks, so a copy whose reservation does not fit anywhere simply never starts. A ceiling is a runtime input: the process is allowed to run until it reaches it, and then the host acts — a CPU ceiling slows the process down and leaves it alive, while a memory ceiling gets the process killed. Declaring a large reservation makes a workload hard to place; declaring a small ceiling makes it easy to place and easy to kill.

What the spec deliberately leaves out

The steps. There is no fetch-then-start-then-register sequence, because the platform decides the steps from the difference between this document and what it sees.
The hosts. You declare the shape of a copy and, at most, rules about the kind of host it may land on. You do not name machines, and you do not pick which copy goes where.
The current situation. The document is not a report. What is actually running is read back separately, beside the spec, and is written by the platform rather than by you.
The path from here to there. How a changed spec reaches the copies that are already running — in what order, how many at a time, with what pauses — is a separate subject with its own settings.
Ordering between fields. The spec is a set of simultaneous assertions, not a program; nothing in it executes before anything else.

Fields nobody wrote still apply

A spec is almost never complete. Most fields have a defined behaviour when absent, and platforms differ in how they fill the gap: some inject a value from the surrounding scope so that a workload declaring no ceiling still gets one, others leave the field genuinely empty. The consequence for a reader is the same either way — the document you review and the effective object the platform stores are not the same document. Anyone reasoning from the diff alone is reasoning about the part that someone chose to write down.

This is why "what does it leave out" is half the question. The omissions are where surprises live: a workload with no declared ceiling that gets one from its scope, a workload with no declared reservation that the scheduler treats as costing nothing and packs anywhere, a copy count that was never written and defaults to one.

Why this is a first-screen question

It separates candidates who have used a cluster from candidates who have used containers. Both groups can start a process; only one of them can say what the platform is being told and what it is being left to work out. The follow-up is nearly always the same: so what happens when what you declared is not what is running? — which is exactly the point of keeping the declaration and the observation as two different documents.

## A statement of the destination A **workload spec** is the document a team hands to a cluster to say what should exist. It is written in a structured data format, stored by the platform as an object, and it reads as a set of assertions about the finished picture: *this image, this many copies, this much resource per copy, this storage, reachable this way*. Nowhere in it is there a verb meaning "and then do this". The spec for an order service is the same document whether the cluster currently runs zero copies, three copies or six, because it describes where the cluster should end up and not the distance it has to travel. That is the idea an interviewer is checking. Someone who has only ever started containers by hand tends to describe a spec as a saved command line with the flags moved into a file. It is not. A command line is a step, and a step is only meaningful from a particular starting point; a spec is a destination and is meaningful from any starting point. ## The fields that carry the end state | Field | What it declares | Who acts on it | |---|---|---| | image identity | the exact bytes to run, normally named by digest | the node agent that fetches and starts it | | copy count | how many interchangeable copies should exist at once | the controller that keeps the set at that size | | reservation | how much CPU and memory to set aside for each copy | the scheduler, which subtracts it from a candidate host's free capacity | | ceiling | the most a copy may consume once it is running | the runtime on the host, which throttles CPU and kills on memory | | storage request | how much durable space, and with what access mode | the storage layer, which binds a backing volume to the copy | | exposure | the port the process listens on and the name others use | the networking layer | Two of those rows are the ones candidates most often swap. A **reservation** is a *placement* input: it is the amount the scheduler treats as spoken for on whichever host it picks, so a copy whose reservation does not fit anywhere simply never starts. A **ceiling** is a *runtime* input: the process is allowed to run until it reaches it, and then the host acts — a CPU ceiling slows the process down and leaves it alive, while a memory ceiling gets the process killed. Declaring a large reservation makes a workload hard to place; declaring a small ceiling makes it easy to place and easy to kill. ## What the spec deliberately leaves out - **The steps.** There is no fetch-then-start-then-register sequence, because the platform decides the steps from the difference between this document and what it sees. - **The hosts.** You declare the shape of a copy and, at most, rules about the kind of host it may land on. You do not name machines, and you do not pick which copy goes where. - **The current situation.** The document is not a report. What is actually running is read back separately, beside the spec, and is written by the platform rather than by you. - **The path from here to there.** How a changed spec reaches the copies that are already running — in what order, how many at a time, with what pauses — is a separate subject with its own settings. - **Ordering between fields.** The spec is a set of simultaneous assertions, not a program; nothing in it executes before anything else. ## Fields nobody wrote still apply A spec is almost never complete. Most fields have a defined behaviour when absent, and platforms differ in how they fill the gap: some inject a value from the surrounding scope so that a workload declaring no ceiling still gets one, others leave the field genuinely empty. The consequence for a reader is the same either way — **the document you review and the effective object the platform stores are not the same document**. Anyone reasoning from the diff alone is reasoning about the part that someone chose to write down. This is why "what does it leave out" is half the question. The omissions are where surprises live: a workload with no declared ceiling that gets one from its scope, a workload with no declared reservation that the scheduler treats as costing nothing and packs anywhere, a copy count that was never written and defaults to one. ## Why this is a first-screen question It separates candidates who have used a cluster from candidates who have used containers. Both groups can start a process; only one of them can say what the platform is being told and what it is being left to work out. The follow-up is nearly always the same: *so what happens when what you declared is not what is running?* — which is exactly the point of keeping the declaration and the observation as two different documents.

Does declaring six copies in the spec mean six copies will be running?
No. The count is a want, not a guarantee. Each copy has to be placed on a host with enough unreserved capacity for its reservation; if no host has room, that copy stays pending and the workload runs short of its declared count until capacity appears. The spec is satisfied only when the cluster can satisfy it.
In what order are a spec's fields applied?
There is no order. A spec is a set of simultaneous assertions about the end state, not a program, so nothing in it runs before anything else. Ordering questions belong to the platform's own sequencing — what it fetches first, what it waits for — and none of that is expressible in the document.
If a field is missing from the spec, where does its value come from?
From one of two places, and it matters which: the field's own defined default, or a default injected by the scope the workload lives in. Platforms differ on how much they inject. Either way the value does not appear in the document, so you read the effective object the platform stored rather than the file you wrote.

saying these in an interview costs you the question

Describes the spec as the ordered list of commands the platform will run
Says the spec records what is currently running on the cluster
Assumes an omitted field has no effect at all on the running workload
Thinks declaring six copies means six copies are guaranteed to be running
Treats the reservation as the cap the running process may not exceed

What does a workload spec for an order service declare, and what does it deliberately leave out?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

A statement of the destination

The fields that carry the end state

What the spec deliberately leaves out

Fields nobody wrote still apply

Why this is a first-screen question

▾common follow-ups3 questions

▾red flags5 flags

A statement of the destination

The fields that carry the end state

What the spec deliberately leaves out

Fields nobody wrote still apply

Why this is a first-screen question

answer

go deeper