Reason about container lifecycle transitions and choose a restart policy that matches failure behavior, operator intent, and daemon restarts.

What you will be able to do

Distinguish created state from main process in a realistic container lifecycle and restart policies case.
Interpret the operational evidence and boundary associated with exit evidence.
Choose an appropriate action involving restart policy without exceeding the named workload scope.
Verify maintenance stop through an observable runtime result and reproducible handoff.

Frame Container Lifecycle and Restart Policies

Reason about container lifecycle transitions and choose a restart policy that matches failure behavior, operator intent, and daemon restarts.

A small API exits with a nonzero code during transient failures, but operators also need manual stops to remain respected during maintenance.

Keep declared state, runtime state, observable evidence, access boundaries, and recovery outcomes separate. Begin with the smallest read-only inspection that identifies the exact image, container, Pod, controller, network, storage object, or policy in scope.

Created state

A created container has configuration and filesystem state but its main process is not yet running. Within container lifecycle and restart policies, this role answers one specific container or orchestration question and keeps its own evidence.

Inspect the container state before assuming startup was attempted. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not interpret created as a healthy application state. The observable result is specific: the state record distinguishes creation from execution.

Main process

A container normally remains running while its configured main process remains active. Within container lifecycle and restart policies, this role answers one specific container or orchestration question and keeps its own evidence.

Identify the main process and its expected termination behavior. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not hide a repeatedly failing main process behind blind restarts. The observable result is specific: process behavior explains the container transition.

Exit evidence

Exit status and timing help distinguish successful completion from application failure. Within container lifecycle and restart policies, this role answers one specific container or orchestration question and keeps its own evidence.

Record the exit code and last log events before restarting. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not erase the failed instance before collecting useful evidence. The observable result is specific: exit evidence supports a specific failure interpretation.

Restart policy

A restart policy defines whether Docker restarts a container after exit or daemon restart. Within container lifecycle and restart policies, this role answers one specific container or orchestration question and keeps its own evidence.

Choose no, on-failure, always, or unless-stopped from the service requirement. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not combine competing host and docker restart managers for the same container. The observable result is specific: observed restart behavior matches the declared policy.

Maintenance stop

A manual stop changes how restart policy is applied until an explicit start or daemon transition. Within container lifecycle and restart policies, this role answers one specific container or orchestration question and keeps its own evidence.

Test the selected policy against an intentional maintenance stop. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not assume every policy immediately overrides a manual stop. The observable result is specific: the container remains stopped or restarts exactly as required.

Apply Container Lifecycle and Restart Policies to One Workload

Use one bounded workload decision: A small API exits with a nonzero code during transient failures, but operators also need manual stops to remain respected during maintenance.

First, inspect the container state before assuming startup was attempted. Then, identify the main process and its expected termination behavior. Preserve both observations with the exact resource identity before changing runtime state.

Next, record the exit code and last log events before restarting. After that, choose no, on-failure, always, or unless-stopped from the service requirement. Close the task only after you test the selected policy against an intentional maintenance stop.

Recap Before Practice and Prove

Created state: A created container has configuration and filesystem state but its main process is not yet running. In this workload, inspect the container state before assuming startup was attempted. Preserve the boundary: do not interpret created as a healthy application state.

Main process: A container normally remains running while its configured main process remains active. In this workload, identify the main process and its expected termination behavior. Preserve the boundary: do not hide a repeatedly failing main process behind blind restarts.

Exit evidence: Exit status and timing help distinguish successful completion from application failure. In this workload, record the exit code and last log events before restarting. Preserve the boundary: do not erase the failed instance before collecting useful evidence.

Restart policy: A restart policy defines whether Docker restarts a container after exit or daemon restart. In this workload, choose no, on-failure, always, or unless-stopped from the service requirement. Preserve the boundary: do not combine competing host and docker restart managers for the same container.

Maintenance stop: A manual stop changes how restart policy is applied until an explicit start or daemon transition. In this workload, test the selected policy against an intentional maintenance stop. Preserve the boundary: do not assume every policy immediately overrides a manual stop.