A containerized application writes logs to /var/log/app.log. The administrator wants to ensure logs persist even if the container is removed. Which approach should be used?
Mounting a Docker volume at /var/log stores log data outside the container's writable layer, on the host's volume storage, so it survives container removal. This directly satisfies the persistence constraint, unlike bind mounts tied to host paths or ephemeral layer writes, which are destroyed with the container.
Why this answer
Docker volumes are managed by Docker and persist independently of the container lifecycle. By mounting a volume at /var/log, the application writes logs directly to the volume, ensuring the data survives container removal and can be reused by other containers.
Exam trap
The trap here is that candidates may confuse bind mounts with Docker volumes, thinking that any host-path mapping provides automatic persistence, or they may assume that docker logs retains logs after container removal, when in fact it only works for running or stopped containers, not removed ones.
How to eliminate wrong answers
Option A is wrong because copying logs to a bind mount after they are written is not a native Docker approach; bind mounts rely on host directory paths and do not automatically persist logs if the container is removed without explicit copying. Option B is wrong because setting the log driver to syslog sends logs to the system's syslog service, but this does not guarantee persistence of the log file at /var/log/app.log within the container; it changes the output destination, not the file storage. Option C is wrong because redirecting logs to stdout and using docker logs only captures logs in the container's stdout stream, which is ephemeral and lost when the container is removed; docker logs does not provide persistent file storage.