A disposable container is useful only when you know which data is disposable. Image files provide a packaged starting point; new ordinary writes in the container's writable layer belong to that instance. Removing the instance removes those changes. A named volume is managed separately and can be attached to a replacement instance. A bind mount maps an existing host path into the container. A tmpfs mount provides temporary storage with its own memory and lifecycle considerations.
These are different lifetime and ownership decisions, not merely alternative path spellings. A named volume is not a backup. A host path can be deleted or changed outside the application. A read-only mount limits writes through that mount but does not encrypt the data or guarantee that another actor cannot alter its source.
Resolve the effective storage location
Suppose /data is a named volume and /data/private is a nested tmpfs mount. A write to /data/records.json reaches the volume. A write to /data/private/key reaches tmpfs because the nested target is more specific. Input order should not decide this result. A write to /database/key does not match /data at all: path containment uses components, not a text prefix.
path = "/data/private/key"
targets = ["/data", "/data/private", "/database"]
matching = [t for t in targets if path == t or path.startswith(t + "/")]
print(max(matching, key=len))A mount can also mask image content at its target. Files that were packaged under that directory may no longer be visible through the mounted path. Docker has specific behavior for initializing an empty named volume from existing container content; our routing function does not simulate population, ownership changes or filesystem I/O. It only identifies the selected mount and reports its stated properties.
Writability and persistence are independent
A read-only bind mount can be persistent, while a writable tmpfs remains temporary. The task returns these as separate fields. Its fallback describes newly written data in the container writable layer, not immutable image data. The relative path is the suffix beneath the selected target; requesting exactly the target yields the empty relative string.
Validate canonical absolute paths before matching, reject duplicate targets, and inspect every mount even when it does not match the requested path. A malformed unused entry is still a malformed plan. This lab prohibits mounting root as a local policy, while real engines offer many mount arrangements outside the exercise's scope. A source path in the fixture is only text: no host directory, device or Docker socket is opened.
Plan replacement, then plan recovery
Before building, trace a database write, a cache write and a temporary secret through the example mount plan. Predict what survives container removal and what can still disappear through explicit volume deletion or host failure. The two bug hunts isolate over-broad prefix matching and selection of the outer mount.
For the optional service project, the durable endpoint writes a greeting under /data; that directory must be writable by the non-root service user on the selected volume. Test permissions and recovery separately when running a real engine. Passing the offline routing lab demonstrates path and lifetime reasoning, not real filesystem isolation, correct permissions, a backup strategy or production readiness.