CCNA Storage And Configuration Questions

`podman volume inspect` returns a volume's configuration as JSON, including its mountpoint, driver, and labels, satisfying the stem's requirement to inspect storage volumes. It queries volume metadata directly rather than container or image state, which is the axis distinguishing volume subcommands from other Podman inspection commands.

This command correctly uses the short -v syntax to mount the named volume pgdata at the container path /var/lib/postgresql/data. The volume name is specified before the colon, and the container path after, which is the standard format for named volumes in Podman. The environment variable sets the database password. This is the simplest and most common way to attach a named volume to a container.

podman volume rm removes one or more named volumes by passing their names as arguments, directly satisfying the requirement to delete specific volumes. Other volume subcommands create, inspect or prune volumes, but only rm targets named volumes for deletion.

Podman secrets store credentials encrypted at rest and inject them as tmpfs-mounted files, never as environment variables. The `type=mount` flag writes the secret to `/run/secrets/pass` inside the container, satisfying the requirement to avoid plaintext environment variables while keeping credentials readable only within the container's memory-backed filesystem.

Podman mounts secrets under /run/secrets by default, using the secret's name as the filename, so db_password appears at /run/secrets/db_password without any destination flag. This satisfies the stem's constraint of specifying no target path, unlike /etc or /var locations that require explicit configuration.

The type=env parameter on --secret injects the secret's value directly as an environment variable inside the container rather than mounting it as a file under /run/secrets. This matches the application's requirement for environment-variable exposure using Podman's native secret handling.

The `--mount` flag requires explicit key-value pairs, so `type=bind` declares a bind mount rather than a named volume or tmpfs. `source` and `destination` map the host directory to the container path, satisfying the stem's demand for correct advanced syntax. The comma-separated form is parsed without ambiguity, unlike `-v` shorthand.

type=env injects the secret's value directly into the container as an environment variable, readable by processes via standard environment lookups. This satisfies the scenario's requirement for a valid Podman secret mounting option, though environment variables are more readily exposed through process inspection than file-mounted secrets.

The --driver flag specifies which volume driver Podman uses when creating the volume, overriding the default local driver. Naming nfs here instructs Podman to provision the volume through the NFS driver plugin, matching the requirement for a non-default driver.

The --mount flag attaches volumes or bind mounts to a container, accepting key-value parameters such as type, source, and destination. It satisfies the stem's requirement for mounting storage at container runtime, and is the modern, more explicit alternative to the legacy --volume flag.

The :U option tells Podman to adjust the ownership of the host directory so that it matches the UID/GID mapping inside the container. In rootless mode, the container's UID 1000 corresponds to a different host UID (often in the high range) due to user namespace remapping. Using :U ensures the container process has write access by changing the host directory's ownership to the mapped UID. This is the recommended solution for permission issues with bind mounts in rootless containers.

The -e or --env flag passes a single variable directly on the podman run command line, setting it inside the container at launch. This satisfies the requirement to supply environment variables without needing an external file, ideal for quick, ad-hoc values.

The `:ro` suffix on the `-v` bind mount sets the mount's read-only attribute in the kernel, so writes to `/container/data` fail with EROFS. This directly satisfies the stem's constraint of preventing accidental modification of the host directory, while still exposing its contents to the container.

The :ro option mounts the file as read-only inside the container, preventing any writes. This directly meets the requirement to read but not modify, and it uses a bind mount to map the specific host file. It is the correct and safe choice.

The writable layer sits atop the container's image and is destroyed with the container, so logs and temporary state written there vanish on restart. This is ephemeral container storage, the default pattern absent any mounted volume.

A bind mount maps an existing absolute host path, such as /home/user/data, straight into the container's filesystem namespace, rather than creating an isolated volume. This satisfies the stem's requirement of linking a specific host path directly into the container filesystem.

For a non-root user, Podman stores named volumes under the user's home directory because rootless containers cannot write to `/var/lib/containers`. The default rootless storage path is `~/.local/share/containers/storage`, with named volumes placed in its `volumes/` subdirectory, satisfying the non-root constraint in the stem.

A container image's layers are read-only, so any writes at runtime go to a thin writable layer created on top of the image. This copy-on-write scratchpad is unique to each container instance and persists only for that container's lifetime.

The podman volume create command creates a named volume, and podman volume inspect displays detailed information about it, including the mount point on the host. This is the correct sequence to both create the volume and find its location. The inspect output includes fields such as Mountpoint, which shows where the data is stored on the host filesystem.

podman volume inspect returns the volume's full low-level configuration, including mountpoint, driver, labels and options, in JSON form. This directly satisfies the stem's requirement for displaying detailed configuration, a capability unique to the inspect subcommand within the volume suite.

`podman volume inspect app_vol` returns the volume's full configuration as a JSON array, exposing Mountpoint, Driver, Options, Labels and Scope. This directly satisfies the stem's requirement for low-level mount point and driver detail in JSON, unlike `podman volume ls`, which lists names only.

The --env-file flag reads the named local file and injects each KEY=VALUE pair as environment variables inside the container, so app.env's multiple configuration variables become available to the application at runtime without manual --env entries.

`podman system df` reports disk usage across Podman's storage, listing images, containers and volumes with total, active and reclaimable space. It directly satisfies the stem's requirement to display disk space statistics covering volumes and containers.

The `destination` key-value pair sets the container-side mount path, satisfying the requirement that `--mount` accepts explicit target parameters. Unlike `--volume`, which uses positional arguments, `--mount` requires named keys such as `destination` (or its alias `target`) to define where the volume appears inside the container.

The podman secret rm subcommand deletes the named secret from Podman's secret store, removing it so containers can no longer reference it. The syntax matches the resource type followed by the verb and the secret's name.

`podman secret ls` queries the local Podman secret store and returns every created secret, satisfying the requirement to list all secrets on the system. Unlike `podman secret inspect`, which requires a named secret, `ls` enumerates them without arguments, matching the administrator's need for a complete inventory.

The -e flag passes a single environment variable into the container at runtime, setting DB_HOST to localhost for the myapp process. This satisfies the requirement to inject one variable directly on the command line rather than through an env file.

`podman secret rm` deletes a stored secret from Podman's secret store, satisfying the requirement to identify valid secret-management subcommands. It mirrors the removal operation available for other Podman objects, letting you clean up secrets no longer needed by containers. This is a genuine subcommand, unlike fabricated flags.

'podman volume create mydata' creates a named volume managed by Podman's volume subsystem, persisting independently of any container's lifecycle. Anonymous volumes tied to a container are removed with it; named volumes survive container deletion, satisfying the persistence constraint.

In an environment file, any line beginning with '#' is treated as a comment and ignored when parsed by '--env-file', so it never becomes a key-value variable. This lets teams annotate configuration without affecting the container's runtime environment.

Podman's bind mount mechanism operates at the file level, not just directories, so a single host file can be mapped to a container path. This suits injecting a configuration file without mounting an entire directory, and the mount is read-write by default unless :ro is appended.

The --env-file flag reads a file of KEY=VALUE pairs and injects each as an environment variable inside the container, satisfying the requirement to load config.env without passing individual -e flags. Docker parses the file line by line at container start.

Bind mounts map a host directory or file directly into the container. The data resides on the host filesystem, so it persists beyond container lifecycles and can be backed up using standard host tools. They are suitable for persistent storage, especially when the data needs to be accessed or managed directly on the host. However, they require careful permission and SELinux configuration.

The --tmpfs flag mounts a memory-backed filesystem inside the container, storing data in host RAM rather than on disk. This delivers the high-performance temporary storage the scenario requires, and contents vanish when the container stops.

The --rm flag deletes the container automatically once it exits, and it also removes any anonymous volumes created with -v that were not given a name. This satisfies the requirement to clean up both the container and its anonymous volumes without manual pruning.

Host bind mounts map an existing host directory straight into the container, so data written by the process lands on the host filesystem and survives container removal. This satisfies the persistence requirement natively, without extra drivers or plugins, because the mount is handled directly by the kernel.

`podman secret ls` enumerates every secret stored in the Podman secret store, satisfying the inspection requirement. It queries the local secret database directly, returning names, IDs, and drivers without exposing secret values. This read-only listing is one of the three permitted inspection or cleanup actions, alongside `podman secret inspect` and `podman secret rm`.

`podman volume create` provisions a named volume in Podman's local storage, satisfying the stem's requirement for a valid named-volume management command. It accepts flags such as `--driver` and `--label`, and the resulting volume persists independently of any container, unlike anonymous volumes created implicitly at runtime.

'podman system df' reports disk usage across containers, images and volumes. Images are listed because their read-only layers consume the bulk of local storage, and the command shows total image size, shared layers and reclaimable space, making images one of the three items the question requires.

'podman secret create' takes the secret name followed by the source file path, so db_secret is created from secret.txt. This satisfies the requirement to build a Podman secret directly from an on-disk file rather than from stdin or an environment variable.

The shared propagation mode lets mounts performed on the host propagate into the container and vice versa, which is exactly the bind-mount behaviour requested. Without it, the default private mode isolates the mount namespace and host mounts never appear inside.

Podman volumes are stored in a Podman-managed location on the host, so no explicit host directory path is required. Creating the named volume with podman volume create my_data satisfies the persistence and host-path-independence constraints before it is mounted into a container.

Rootless bind mounts are performed by the unprivileged user's own UID mapping, so the kernel enforces ordinary file permissions on the source path. Without read/write access to that host directory, the mount either fails or yields an unusable, read-only view.

The --env-file flag reads environment variables from a file and passes them into the container. Each line in the file must be in KEY=VALUE format, which matches the described web.env file. This is the correct way to inject multiple variables without listing them individually on the command line. It is widely used for configuration management in containerized applications.

podman volume prune removes all volumes not referenced by any container, matching the dangling-volume requirement exactly. Unlike podman volume rm, it needs no explicit volume names, so it clears unused volumes in one non-interactive command.

Creating a secret stores sensitive data in Podman's secret store, from which it can be injected into containers at runtime rather than baked into images or environment variables. This is the foundational write operation for the secret management workflow.

Lowercase z relabels content so multiple containers can share the volume.