EX188 Storage And Configuration — 15 Questions

Question 1

A Podman secret named 'db_password' has been created. How is this secret made accessible inside a running container?

Accepted Answer

podman run --secret db_password,type=mount myapp. Podman secrets are exposed to containers using the --secret flag, which by default mounts the secret as a file under /run/secrets/<name> inside the container. The syntax 'podman run --secret db_password,type=mount myapp' correctly mounts the secret named db_password into the container. The type=mount is the default behavior, making the secret available as a file.

Answer

podman run --env SECRET=db_password myapp

Answer

podman run --inject-secret db_password myapp

Answer

podman run --use-secret db_password myapp

Question 2

Which command lists all named volumes currently managed by Podman?

Accepted Answer

podman volume ls. `podman volume ls` is the correct command to list all named volumes managed by Podman. It is the standard subcommand, analogous to `podman ps` for containers and `podman images` for images.

Answer

podman volume list

Answer

podman ls volumes

Answer

podman volume show

Question 3

Which flag is used with 'podman run' to create an ephemeral, writable container layer scratchpad that is automatically destroyed when the container stops?

Accepted Answer

podman run (no special volume flags). By default, podman run creates a writable container layer on top of the image using an overlay or vfs storage driver, and this layer is ephemeral—it is destroyed when the container is removed. No special volume flag is needed to get a scratchpad that disappears when the container stops and is removed. The container's writable layer is the default behavior.

Answer

podman run --rm-storage

Answer

podman run --volatile

Answer

podman run --ephemeral

Question 4

A container needs to read a secret named 'api_key' injected as a file at '/run/secrets/api_key'. What is the default destination path inside the container when mounting a secret without specifying a target?

Accepted Answer

/run/secrets/. When a secret is mounted into a container without an explicit target path, the container runtime (Docker Swarm, Podman, or Kubernetes with the default configuration) places it under /run/secrets/. This is the standard, POSIX-compliant location for runtime secrets, and the file is named after the secret itself — so 'api_key' becomes /run/secrets/api_key. The application can then read the secret as a regular file, avoiding environment-variable leakage.

Answer

/var/run/secrets/

Answer

/app/secrets/

Answer

/etc/secrets/

Question 5

A rootless Podman container needs to access a host directory. Due to user namespace mapping, file ownership appears different inside the container. Which flag can be added to the mount to adjust UID/GID mapping behavior if supported?

Accepted Answer

podman run -v /host/path:/container/path:U. Volume mount options can include specific flags, and Podman handles rootless UID/GID mapping automatically, but misconfigurations can be troubleshot using mount options. Wait, let's look at standard options like 'U' for chown.

Answer

podman run -v /host/path:/container/path:ns

Answer

podman run -v /host/path:/container/path:uid=root

Answer

podman run -v /host/path:/container/path:map

Question 6

An administrator wants to pass custom options to a volume driver when creating a volume. Which flag should be used?

Accepted Answer

podman volume create --opt type=nfs .... The 'podman volume create --opt' flag (short for --option) passes driver-specific options when creating a volume, such as type=nfs, o=addr=..., or device=... for the local driver. This is the documented mechanism for supplying custom options to the volume driver at creation time.

Answer

podman volume create --options ...

Answer

podman volume create -o-drv ...

Answer

podman volume create --driver-opt ...

Question 7

An engineer needs to inspect the content and metadata of an existing Podman secret named 'my_secret' without outputting the raw secret value in plain text if masked, or viewing its metadata. Which command inspects the secret?

Accepted Answer

podman secret inspect my_secret. podman secret inspect displays the metadata of a secret — its ID, name, driver, creation time, and labels — without revealing the secret's value. This is exactly what the question asks for: inspecting metadata without exposing the plaintext secret. The other listed subcommands either do not exist or would reveal the secret value.

Answer

podman secret cat my_secret

Answer

podman secret show my_secret

Answer

podman secret view my_secret

Question 8

When using the '--mount' flag, what parameter specifies the type of mount being performed (e.g., bind, volume, tmpfs)?

Accepted Answer

type=. The '--mount' flag uses the 'type=' parameter to specify the mount type, such as 'bind', 'volume', or 'tmpfs'. This is the correct syntax for defining the mount type in Podman and Docker.

Answer

kind=

Answer

method=

Answer

mount-type=

Question 9

Which TWO commands help clean up unused or dangling Podman storage resources? (Choose TWO)

Accepted Answer

podman system prune. Option C, `podman system prune`, is correct because it removes all unused Podman data, including stopped containers, dangling images, unused networks, and (with the appropriate flags) unused volumes, directly cleaning up dangling storage resources. Option E, `podman volume prune`, is correct because it specifically removes all unused volumes not referenced by any container, which is a core part of cleaning up dangling storage. Options A (`podman storage wipe`) and D (`podman volume clean`) are not valid Podman subcommands, so they cannot perform any cleanup. Option B, `podman system clean`, is also not a real Podman command; the actual cleanup command is `podman system prune`.

Answer

podman storage wipe

Answer

podman system clean

Answer

podman volume clean

Question 10

Which TWO SELinux relabeling suffixes can be appended to a Podman volume or bind mount? (Choose TWO)

Accepted Answer

:Z. Option D (:Z) is correct because it tells Podman to relabel the volume or bind mount with a private, unshared SELinux label (using the container_file_t type) so that only the specified container can access it, which is the appropriate choice when a host directory must be dedicated to a single container. Option E (:z) is correct because it applies a shared SELinux relabel (also container_file_t) that allows multiple containers to access the same volume or bind mount simultaneously. The remaining options do not belong: :s is not a valid SELinux relabeling suffix for Podman volumes, and :shared and :private are mount propagation modes (shared, private, slave, etc.) rather than SELinux label suffixes.

Answer

:s

Answer

:shared

Answer

:private

Question 11

Which THREE parameters are valid key-value pairs when using the advanced '--mount' flag with bind or volume types? (Choose THREE)

Accepted Answer

source. When using '--mount', valid keys include type, source (or src), and destination (or target/dst).

Answer

format

Question 12

Which THREE characteristics describe Podman named volumes compared to bind mounts? (Choose THREE)

Accepted Answer

Stored within Podman's designated storage directory on the host. Option C is correct because Podman named volumes are created and stored under Podman's designated storage directory on the host (typically /var/lib/containers/storage/volumes for root or ~/.local/share/containers/storage/volumes for rootless), rather than at an arbitrary user-specified path. Option D is correct because named volumes are fully managed by the Podman engine — Podman creates, tracks, and removes them via commands like podman volume create, podman volume ls, and podman volume rm, so the user does not manage the underlying directory directly. Option E is correct because this engine-managed lifecycle makes named volumes easier to migrate or back up using volume management commands (for example, podman volume export/inspect or mounting the volume into a helper container), since the volume is referenced by name rather than by a fragile host path. Option A is incorrect because named volumes do not need to point to pre-existing host directories; Podman creates the storage location automatically if it does not exist. Option B is incorrect because named volumes are referenced by a simple name, not by an absolute host path, which is a characteristic of bind mounts instead.

Answer

Must always point to pre-existing host directories

Answer

Require absolute paths on the host system during creation

Question 13

Which THREE formatting options or commands can be used with 'podman volume ls' to customize or filter output? (Choose THREE)

Accepted Answer

--filter. Option A (--filter) is correct because 'podman volume ls --filter' accepts key=value filters such as 'dangling=true', 'driver=local', or 'label==' to restrict which volumes are listed. Option B (--format) is correct because 'podman volume ls --format' lets you customize output using Go templates or table/JSON placeholders like '{{.Name}}' or 'json'. Option D (--no-trunc) is correct because 'podman volume ls --no-trunc' disables truncation of the volume name and other fields in the output. Option C (--sort) is not a valid flag for 'podman volume ls' (sorting is achieved via '--format' with template functions or external tools), and Option E (--json-pretty) is not a supported flag for this command, so neither belongs.

Answer

--sort

Answer

--json-pretty

Question 14

Which THREE advanced features or driver options can be utilized when creating Podman named volumes with plugins or specialized drivers? (Choose THREE)

Accepted Answer

Custom volume drivers via the --driver flag. Option A is correct because Podman's `podman volume create` supports the `--driver` flag, which lets you select a custom volume driver (e.g., a plugin-provided driver like `local` or third-party plugins) instead of the default local driver. Option B is correct because the `--opt` flag passes driver-specific options (key=value pairs) to the chosen volume driver, enabling specialized configuration such as mount options or plugin parameters. Option E is correct because `--label` attaches metadata tags (key=value labels) to the named volume, which is useful for organizing, filtering, and managing volumes. Option C is incorrect because Podman volume creation has no `--partition` flag for direct block device partitioning; partitioning is a lower-level storage operation, not a named-volume driver option. Option D is incorrect because `--mlock` is not a Podman volume creation option; memory locking is a container runtime/security setting (e.g., related to `--security-opt` or ulimits), not a volume driver feature.

Answer

Direct block device partitioning via --partition

Answer

Automatic kernel kernel-space memory locking via --mlock

Question 15

A container needs read-only access to a host configuration directory located at /etc/appconfig. Which Podman volume flag configuration correctly achieves this?

Accepted Answer

--volume /etc/appconfig:/app/config:ro. The --volume (or -v) flag uses a colon-separated syntax where the third field specifies mount options; 'ro' is the correct token for read-only. So '--volume /etc/appconfig:/app/config:ro' mounts the host directory read-only inside the container. This is the canonical short-form syntax for read-only bind mounts in Podman.

Answer

--volume /etc/appconfig:/app/config:readonly=true

Answer

--mount type=bind,src=/etc/appconfig,dst=/app/config,mode=ro

Answer

--volume /etc/appconfig:/app/config:readonly