EX200 Manage containers Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  --mount

  Why this is correct

  The --mount option is the correct choice because it provides an explicit, structured way to define a bind mount with comma-separated key=value syntax, such as type=bind,source=/host/logs,destination=/var/log/nginx. It allows specifying advanced parameters like bind-propagation (e.g., rshared, rslave) and read-only enforcement, which are essential for reliably persisting container logs outside the container. Unlike -v or --volume, --mount does not guess whether the source is a file, directory, or named volume, making it the most deterministic and production-safe approach for this task.

• ✗

  --volume

  Why it's wrong here

  --volume is the long form of -v and, like its shorthand, accepts key=value pairs such as volume=/host/logs:/var/log/nginx, but it does not support explicit mount propagation or fine-grained control over mount type and read-only settings. When using --volume, Podman infers the mount type based on whether the source exists or contains a slash, which can lead to unexpected behavior if the host path doesn't exist. For a straightforward bind mount it works, but it lacks the explicitness and advanced capabilities of --mount, making it a less reliable option for production persistence.

• ✗

  --bind

  Why it's wrong here

  There is no --bind option in the podman run command; it is a catch-all flag that does not exist in the Podman or Docker CLI reference. To create a bind mount, you must use --mount type=bind,source=/host/logs,destination=/var/log/nginx or the -v/--volume shorthand. Selecting --bind would immediately result in an error (e.g., unknown flag), so it is not a viable way to persist logs outside the container.

• ✗

  -v

  Why it's wrong here

  The -v option (shorthand for --volume) is commonly used for volume mounts, but it has significant limitations for advanced persistence scenarios. It automatically creates a directory on the host if the source path does not exist, and it does not allow you to specify mount propagation or explicit bind-mount type. While -v works for simple cases, its implicit behavior and lack of support for propagation options make it unsuitable when you need deterministic, production-grade log persistence; --mount is the safer alternative.

Go deeper

Related to this question