A transit-ticketing team packs a web API, a sidecar cron job, and a local database into one container so they can “share localhost.” What Docker design problem does that create?
Select an answer to reveal the explanation.
Short Explanation
One container, one main process—like one employee, one job description. Cramming API, cron, and database together means you cannot restart or scale them apart.
Full Explanation
Docker’s unit of deployment is one main concern per container (one primary process tree). Packing the transit-ticketing web API, a sidecar cron job, and a local database into a single container so they “share localhost” recreates a mini-monolith: you cannot restart the API without touching cron and the database, you cannot scale the API independently of the DB, and a single health check cannot honestly represent three different failure modes. Independent deployability and independent failure domains disappear the moment those concerns share one container lifecycle.
OCIR does not reject multi-process images at push time—the registry stores whatever layers you push; bad design is still pushable. Combining processes does not automatically enable OCI Service Mesh; mesh is a separate networking and policy layer you configure deliberately. Needing one IP per tenancy namespace is not a Docker rule that forces multi-process containers; networking identity and process isolation are separate concerns.
Exam caveat: a true sidecar in Kubernetes is still a separate container in the same pod—sharing the network namespace without stuffing every binary into one image. Operational check: if one component needs a hotfix, ask whether you can rebuild and roll only that concern; if the answer is “we must redeploy API, cron, and DB together,” the mini-monolith problem is confirmed and the team should split images and communicate over the network or a shared volume intentionally.