skip to content

A container is created, runs, stops and is later removed — what triggers each of those transitions?

level: middleimportance: must knowfreq 60%

answer

  1. a record, not just a process
  2. created is not yet running
  3. the first process defines running
  4. stopped still holds its exit status
  5. removal is what destroys the record

basics

~20 s

Creation builds the container from its spec without running anything; a start request executes its first process, which is what running means; the container stops when that process ends, by itself or because it was asked to; removal is a separate request that destroys the record.

solid answer

~50 s

Four things happen and three of them are requests. **Created** means the container exists — its settings are bound, its private writable layer is set up — but nothing is executing. A **start** request makes the runtime execute the first process, and the container is **running** for exactly as long as that process lives. It becomes **stopped** when that process ends: because it finished, because it failed, or because it was asked to stop and did. Stopping is not disappearing — the record survives with the identity, the exit code and the output captured while it ran, which is why you can still read why it ended. **Removal** is a separate step, sometimes automatic, that destroys that record and the container's private writable layer. A start on a stopped container reuses the same container; a replacement creates a new one.

code

pseudocode · 5 lines
pseudocode
created  --start request-->            running
running  --first process returns-->    stopped(exit_code = returned value)
running  --stop request, process ends--> stopped(exit_code recorded)
stopped  --start request-->            running   # same container, same record
stopped  --remove request-->           gone      # record and exit code destroyed

go deeper

for a junior

Know the four words and their order: created, running, stopped, removed. Running means the container's first process is alive; removal is a separate action from stopping.

for a middle

Explain each transition by what triggers it, and separate the record from the process — the exit code and the captured output belong to the record and survive the stop.

for a senior

Show why it matters operationally: removing containers the moment they stop destroys the evidence for why they stopped, and what a platform calls a restart may be a new container entirely.

for a principal

Set the retention policy deliberately: how long stopped containers and their captured output are kept, what is shipped off the host before removal, and what that costs against the debugging it buys.

## Four states, and why they are separate A container is a record the runtime keeps, not just a running process. Keeping those two ideas apart is the whole of this question. - **Created.** The container exists. Its image is resolved, its settings are bound to it, its private writable layer and its mounts are prepared. Nothing is executing. A container can sit here indefinitely. - **Running.** The runtime has executed the container's first process, and the container is running for exactly as long as that process is alive. There is no separate "the container is up" fact underneath it. - **Stopped.** That first process has ended. The container still exists as a record: its identity, its exit code, and the output it captured while running are all still there. - **Removed.** The record is destroyed, along with the container's private writable layer. From here the container is not a thing you can inspect, restart or ask about. ## What triggers each transition 1. **To created** — a create request naming an image and the settings the container will run with. Those settings are bound now, which is why changing them later generally means a new container rather than a restart of this one. 2. **To running** — a start request. The runtime executes the first process; the moment it is alive, the container is running. 3. **To stopped** — the first process ends. Three ways in: it completed its work, it failed, or it was asked to stop and it ended in response. Whichever it was, the status it left is recorded against the container. 4. **To removed** — a removal request. Some platforms issue it automatically when a container ends, some when a replacement is created, and some never until you ask. It is always a distinct step from stopping. ## Stopped is not removed This is the distinction interviewers are really probing, because most confusion about "where did it go" lives here. | | a stopped container | a removed container | |---|---|---| | identity | still exists and is still listed | gone | | exit code | recorded and readable | gone with the record | | output captured while running | still readable | discarded with the record | | private writable layer | still there, still attached to this container | destroyed | | can it run again | yes, as the same container | no; only a new container from the same spec | The practical consequence: a stopped container is the evidence. It is how the reason a run ended stays available after the run. A platform configured to remove containers the instant they stop is throwing that evidence away, and a workload whose failures are hard to explain often has exactly that setting somewhere in its history. ## Where designs differ The four states above are the common core, and the shape of the model is the same everywhere, but not every platform draws the same extra lines. - Some expose an intermediate state while the container is stopping — the stop has been requested, the process has not ended yet. - Some offer a **paused** state, where the processes are frozen but still resident. Paused is not stopped: nothing has exited, so there is no exit code, and resuming continues exactly where it was. - Some remove a container automatically as soon as it stops; others keep every stopped container until a cleanup pass removes it. - Where a cluster scheduler is involved, what looks like a restart is often not one: rather than starting the same container again, it creates a fresh container from the same spec, and the old record is removed once it is no longer needed. Because of that last point, "it restarted" is an ambiguous statement about a container, and it is worth being precise about whether the same container ran again or a new one took its place — the two keep and discard completely different things. ## Why this gets asked It is a first-screen question with a real answer underneath it. A weak candidate merges created and running, or assumes a stopped container is already gone. A strong one names the process boundary — running is defined by the first process being alive — and knows that the exit code and the output are properties of a *record* that outlives the process and dies at removal, not at the stop.

  • The container's first process forks a helper that is still alive when the first process ends. What state is the container in?
    Stopped. The container is running for as long as its first process is, so when that process returns, the container's run is over and its status is recorded. Whatever the helper was doing does not keep the container alive; it is ended along with the rest of the container's processes.
  • Why can a stopped container be started again while a removed one cannot?
    Because a stopped container still has its record and its private writable layer, so the runtime has everything it needs to execute the first process again with the same identity. Removal destroys both. After that the only option is a new container created from the same spec, which starts with a fresh writable layer.

saying these in an interview costs you the question

  • Uses created and running interchangeably, as if creating a container starts it
  • Thinks a stopped container is already gone and its exit status unreadable
  • Believes removing a container also deletes the image it was created from
  • Says a stopped container's processes are frozen and resume where they left off
  • Cannot name what moves a container from running to stopped