What Docker objects do you manage day to day, and what happens to container data?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
Images (templates), containers (running instances), plus networks, volumes, and plugins. A container can freely create/modify/delete files in isolation, but anything not stored in a volume or bind mount disappears when the container is removed — containers are ephemeral by design.
Detailed explanation
Images are read-only templates; containers are runnable instances you create, start, stop, move, and delete via CLI or API. You attach containers to one or more networks, attach storage, or even commit a container's state as a new image. Isolation is tunable — you control how separated a container's network, storage, and subsystems are from the host and peers — but the default is relatively well isolated. The critical lifecycle fact: a container is defined by its image plus the options passed at create/start time, and when it is removed, any state not in persistent storage vanishes. That is why databases mount volumes and config/code uses bind mounts: the writable layer is per-container and dies with it. docker ps shows only running containers; add -a to see stopped ones still holding their (doomed) writable state.
Official docs:Docker docs: Docker overview
Example
docker ps # running only
docker ps -a # + stopped (writable layer still on disk, at risk)
docker stop db && docker rm db # state outside volumes is gone
# Persist it instead:
docker run -d -v postgres_data:/var/lib/postgresql postgres:18Interview tip
Say 'ephemeral by design' early, then split state into three buckets: image (shared template), writable layer (dies with container), volumes/mounts (survives). That model answers every follow-up.
Common mistakes
- Assuming files written inside a container survive
docker rm. - Listing only images and containers and forgetting networks and volumes.