Why does a stored workload object keep the declared spec and the live status as two separate blocks?

middlemust knowfreq 60%

answer

intent against observation
you write one, the platform writes the other
a diff needs a stable side
editing status changes nothing lasting
the gap names the outstanding work

basics

~20 s

Because they have different authors and different jobs: the declared block is intent, written by the team; the status block is observation, written back by the platform. Keeping them apart is what makes the difference between them readable.

solid answer

~40 s

The declared block is what you want and the status block is what is. You write the first one and nothing about the end state is ever taken from the second, which the platform overwrites with whatever it currently observes. Separating them gives you a stable statement of intent to diff changes against, and a live report to compare it with — if intent and observation were merged into one document, every reading would silently rewrite the thing you meant to compare against. It also explains two behaviours that surprise people: editing the status block changes nothing on the cluster, and a temporary gap between four declared copies and two ready ones is not an error but the platform reporting that it has not finished.

code

yaml · 13 lines

yaml

declared:
  replicas: 4
  imageDigest: orders-api@9f2c1a7b3d4e
  perCopy:
    memory:
      reservation: 512Mi

status:
  observedReplicas: 3
  readyReplicas: 2
  lastObservedAt: 2026-09-19T11:04:02Z
  unplaced:
    - reason: no host has 512Mi unreserved

go deeper

for a junior

Remember which side is which: the declared block is what someone asked for, the status block is what the platform sees. Editing the second one does not change the cluster.

for a middle

Explain the authorship rule and why the split exists at all: a comparison needs one side that only changes when a human changes it, and one side that changes on its own.

for a senior

Show the incident habit. Read the pair as a subtraction, say whether the remainder is shrinking or stuck, and decide between changing the intent and changing the capacity it is running into.

for a principal

The judgment is what the organisation is allowed to do with the gap. Auto-adjusting intent to match reality makes dashboards green and makes shortfall unmeasurable across an estate.

Two blocks, two authors

A stored workload object usually has two halves, and the split is not cosmetic. The declared block is the part a human or a pipeline writes: the image, the copy count, the reservation and ceiling, the storage request, the exposure. The status block is the part the platform writes: how many copies it currently observes, how many are ready to take traffic, when it last changed its mind, and why a copy that should exist does not.

The authorship rule is one-way and worth saying out loud in an interview: you write intent, the platform writes observation, and the platform takes nothing about the end state from the block it wrote itself. That is why an engineer who edits a status field to say four copies are ready achieves precisely nothing — the value is overwritten the next time the platform looks, and it was never an input in the first place.

What each block is for

	Declared block	Status block
written by	the team, through a change to the document	the platform
answers	what should be true	what is true right now
stability	changes only when someone changes it	changes constantly, without anyone acting
reviewed	yes — it is what a diff is taken against	no — it is a reading, not a proposal
editing it	changes what the cluster is aiming at	changes nothing that lasts

The gap between them is information, not an error

The two blocks are expected to disagree. Four declared copies against two ready ones means one of a small number of things, and the status block usually says which:

the workload was changed seconds ago and the difference has not been closed yet;
a copy cannot be placed, because no host has enough unreserved capacity for its reservation;
a copy is running but has not yet reported itself ready to serve;
a copy keeps failing, so the set never reaches its declared size;
something the platform cannot fix is in the way, such as storage that cannot be bound.

What makes this readable is precisely that neither block moved to accommodate the other. The declared block did not quietly drop to two because two is what exists, and the status block did not report four because four is what was asked for. A system that merged them would have nothing left to compare.

What goes wrong when the two are confused

Reading status to learn intent. Someone asks what the team meant this service to look like and reads the observed copy count. On a bad day that number is a symptom, not a decision.
Reading the declared block to learn health. A dashboard that shows the declared count shows a number that cannot go wrong: it says four during a total outage, because four is still what is wanted.
Editing status to make an alarm stop. It stops until the next observation, and the underlying difference is untouched.
Treating any gap as a bug. Most gaps are the platform mid-flight. The signal is a gap that is not closing, and the status block is where the reason is written.
Diffing the wrong half. A change proposal is a change to intent. If a review shows observed values, the reviewer is being asked to approve a reading.

Reading the pair during an incident

The practical habit is to read them as a subtraction. Take the declared block as the target, take the status block as the position, and the remainder is the platform's outstanding work plus whatever is preventing it. If the remainder is shrinking, the system is working and the answer is to wait. If it is stuck, the status block names the obstacle and the decision is whether to change the intent — fewer copies, a smaller reservation, a different image — or to change the world the intent is running into, usually by adding capacity.

This also settles a question people argue about: when the two disagree for hours, which one do you edit? You edit the declared block only if the intent was wrong. Editing it to match observed reality is how a cluster quietly loses its statement of what it was supposed to be doing, and the incident ends with no record that anything was ever different.

A note on who else reads status

The status block is not write-only. People read it, deployment gates read it, and other automation reads it to decide when to proceed. That does not make it an input to the end state — it remains a report, and anything derived from it is derived from an observation that may be seconds old. Designs differ in how much they let one workload's status influence another's, but none of them treat a workload's own status as the statement of what that workload should be.

## Two blocks, two authors A stored workload object usually has two halves, and the split is not cosmetic. The **declared block** is the part a human or a pipeline writes: the image, the copy count, the reservation and ceiling, the storage request, the exposure. The **status block** is the part the platform writes: how many copies it currently observes, how many are ready to take traffic, when it last changed its mind, and why a copy that should exist does not. The authorship rule is one-way and worth saying out loud in an interview: *you write intent, the platform writes observation, and the platform takes nothing about the end state from the block it wrote itself*. That is why an engineer who edits a status field to say four copies are ready achieves precisely nothing — the value is overwritten the next time the platform looks, and it was never an input in the first place. ## What each block is for | | Declared block | Status block | |---|---|---| | written by | the team, through a change to the document | the platform | | answers | what should be true | what is true right now | | stability | changes only when someone changes it | changes constantly, without anyone acting | | reviewed | yes — it is what a diff is taken against | no — it is a reading, not a proposal | | editing it | changes what the cluster is aiming at | changes nothing that lasts | ## The gap between them is information, not an error The two blocks are *expected* to disagree. Four declared copies against two ready ones means one of a small number of things, and the status block usually says which: - the workload was changed seconds ago and the difference has not been closed yet; - a copy cannot be placed, because no host has enough unreserved capacity for its reservation; - a copy is running but has not yet reported itself ready to serve; - a copy keeps failing, so the set never reaches its declared size; - something the platform cannot fix is in the way, such as storage that cannot be bound. What makes this readable is precisely that neither block moved to accommodate the other. The declared block did not quietly drop to two because two is what exists, and the status block did not report four because four is what was asked for. A system that merged them would have nothing left to compare. ## What goes wrong when the two are confused - **Reading status to learn intent.** Someone asks what the team meant this service to look like and reads the observed copy count. On a bad day that number is a symptom, not a decision. - **Reading the declared block to learn health.** A dashboard that shows the declared count shows a number that cannot go wrong: it says four during a total outage, because four is still what is wanted. - **Editing status to make an alarm stop.** It stops until the next observation, and the underlying difference is untouched. - **Treating any gap as a bug.** Most gaps are the platform mid-flight. The signal is a gap that is not closing, and the status block is where the reason is written. - **Diffing the wrong half.** A change proposal is a change to intent. If a review shows observed values, the reviewer is being asked to approve a reading. ## Reading the pair during an incident The practical habit is to read them as a subtraction. Take the declared block as the target, take the status block as the position, and the remainder is the platform's outstanding work plus whatever is preventing it. If the remainder is shrinking, the system is working and the answer is to wait. If it is stuck, the status block names the obstacle and the decision is whether to change the intent — fewer copies, a smaller reservation, a different image — or to change the world the intent is running into, usually by adding capacity. This also settles a question people argue about: when the two disagree for hours, which one do you edit? You edit the declared block only if the intent was wrong. Editing it to match observed reality is how a cluster quietly loses its statement of what it was supposed to be doing, and the incident ends with no record that anything was ever different. ## A note on who else reads status The status block is not write-only. People read it, deployment gates read it, and other automation reads it to decide when to proceed. That does not make it an input to the end state — it remains a report, and anything derived from it is derived from an observation that may be seconds old. Designs differ in how much they let one workload's status influence another's, but none of them treat a workload's own status as the statement of what that workload should be.

The two blocks have disagreed for hours. Which one do you change?
The declared block, and only if the intent itself was wrong. If the intent is right, the fix is in the world the intent is running into — capacity, storage, a broken image — and the status block usually names which. Editing the declared block down to match reality is how a cluster loses the record of what it was supposed to be doing.
Does anything actually read the status block?
Yes: people, release gates and other automation all read it, and that is its purpose. What it never is, is a statement of intent. Nothing about the end state is taken from it, so overwriting a status value changes no decision — the next observation replaces it.
Why not let the declared copy count follow reality when copies cannot be placed?
Because then the shortfall becomes invisible. A declared count that drifts down to whatever fits records the cluster's limitations as if they were the team's decision, and the difference that told you capacity was short disappears at exactly the moment you needed it.

saying these in an interview costs you the question

Edits the status block to make the workload look healthy
Says the declared block updates itself to match what is running
Treats every gap between declared and observed as proof of a bug
Reads the status block to find out what the team intended
Thinks the declared copy count is the number currently ready

Why does a stored workload object keep the declared spec and the live status as two separate blocks?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two blocks, two authors

What each block is for

The gap between them is information, not an error

What goes wrong when the two are confused

Reading the pair during an incident

A note on who else reads status

▾common follow-ups3 questions

▾red flags5 flags

Two blocks, two authors

What each block is for

The gap between them is information, not an error

What goes wrong when the two are confused

Reading the pair during an incident

A note on who else reads status

answer

go deeper