EX188 Storage And Configuration Practice Test 4 — 15 Questions

Question 1

Which TWO methods can be used to supply environment variables to a Podman container? (Choose TWO)

Accepted Answer

Using the -e or --env flag. Option C is correct because Podman supports the -e or --env flag to pass individual environment variables directly on the command line, e.g. podman run -e MYVAR=value image, which sets the variable inside the container. Option E is correct because the --env-file flag lets you supply a file containing KEY=value lines that Podman reads and injects as environment variables into the container. The other options are not valid Podman flags: --environment-map (A), --var-file (B), and --inject-env (D) do not exist in Podman's CLI, so they cannot be used to supply environment variables.

Answer

Using the --environment-map flag

Answer

Using the --var-file flag

Answer

Using the --inject-env flag

Question 2

Which TWO options can be specified when mounting a Podman secret into a container? (Choose TWO)

Accepted Answer

type=env. Option A (type=env) is correct because Podman secrets support being exposed to a container as environment variables, which is selected with the type=env mount option (e.g., podman run --secret mysecret,type=env). Option D (type=mount) is correct because the default and explicitly supported way to inject a secret is as a file mounted into the container's filesystem, specified with type=mount (e.g., --secret mysecret,type=mount). The remaining options do not belong: type=volume, type=tmpfs, and type=bind are not valid secret type values for Podman secrets — tmpfs and bind are storage/mount concepts used elsewhere (e.g., --mount type=tmpfs or type=bind), and volume is a storage driver concept, none of which are accepted as the secret type parameter.

Answer

type=volume

Answer

type=tmpfs

Answer

type=bind

Question 3

Which THREE commands are valid when inspecting or managing Podman storage volumes? (Choose THREE)

Accepted Answer

podman volume inspect. Option B, `podman volume inspect`, is correct because it is the standard subcommand for retrieving detailed JSON metadata about a named volume, including its mountpoint, driver, labels, and options. Option C, `podman volume rm`, is correct because it removes one or more volumes from Podman storage, optionally with `--force` to remove volumes in use. Option D, `podman volume create`, is correct because it is the canonical command for creating a new named volume, supporting flags such as `--driver`, `--label`, and `--opt`. Option A, `podman volume modify`, is not a valid Podman subcommand (unlike `podman volume` operations such as `ls`, `prune`, or `exists`), and Option E, `podman volume edit`, also does not exist; Podman has no built-in volume editing command, so volume attributes must be changed by recreating the volume or using supported flags at creation time.

Answer

podman volume modify

Answer

podman volume edit

Question 4

Which TWO commands are used to manage Podman secrets? (Choose TWO)

Accepted Answer

podman secret create. Option A, `podman secret create`, is correct because it is the command used to create a new secret in Podman's secret store, reading the secret value from a file or stdin and registering it under a given name for later use by containers. Option D, `podman secret ls`, is correct because it lists all secrets currently stored in the Podman secret store, allowing administrators to verify which secrets exist. The other options are not valid Podman subcommands: `podman secret compile`, `podman secret update`, and `podman secret modify` do not exist in Podman's CLI, so they cannot be used to manage secrets.

Answer

podman secret compile

Answer

podman secret update

Answer

podman secret modify

Question 5

Which TWO actions occur when a container is run with ephemeral storage (the default behavior without volume mounts)? (Choose TWO)

Accepted Answer

The container has its own writable scratchpad layer separate from the image. Option B is correct because when a container runs without any volume mounts, Docker (or a similar container runtime) creates a writable container layer on top of the read-only image layers, using a copy-on-write union filesystem such as overlay2; this scratchpad layer is where all runtime changes (new files, modified files, deleted files) are stored, keeping the underlying image immutable. Option D is correct because that writable layer is tied to the container's lifecycle: when the container is removed with docker rm (or docker run --rm), the layer and all data written to it are deleted, which is why ephemeral storage does not persist. Option A is wrong because image layers are read-only and are never written back to; changes go to the separate writable layer via copy-on-write. Option C is wrong because ephemeral container-layer data does not survive container deletion or host reboots unless a volume or bind mount is used. Option E is wrong because host files are not automatically synchronized into container storage; host access requires an explicit bind mount or volume.

Answer

All container changes are written directly back to the read-only image layer

Answer

Data persists automatically across host reboots and container deletions

Answer

Host files are automatically synchronized into the container storage

Question 6

Which TWO statements are true regarding Podman bind mounts? (Choose TWO)

Accepted Answer

They link a specific host path directly into the container filesystem. Option D is correct because a Podman bind mount maps an explicit host directory or file path directly into a container path (e.g., -v /host/dir:/container/dir), unlike named volumes that Podman manages under its storage root. Option E is correct because bind mounts expose the host filesystem's ownership, mode bits, and SELinux labels to the container, so permission denials or SELinux AVC denials on the host path directly affect container access (often requiring :z/:Z relabeling or correct UID/GID mapping). Option A is wrong because bind mounts are host paths that persist after the container is removed; only anonymous volumes may be cleaned up. Option B is wrong because bind mounts can be mounted read-only using the :ro (or :ro,Z) mount option. Option C is wrong because that describes Podman-managed named volumes stored in Podman's volume database, not bind mounts, which reference host paths directly.

Answer

They are automatically deleted when the container is removed

Answer

They cannot be mounted in read-only mode

Answer

They are managed entirely inside Podman's internal volume database without host paths

Question 7

Which TWO flags can be used to mount volumes or bind mounts when running a container? (Choose TWO)

Accepted Answer

--mount. Option A (--mount) is correct because it is the modern, explicit Docker flag for attaching volumes, bind mounts, and tmpfs mounts, using comma-separated key=value pairs such as type=bind,source=/host/path,target=/container/path. Option B (-v or --volume) is correct because it is the classic Docker shorthand for the same purpose, using the colon-separated syntax source:target[:options], and it remains fully supported for both named volumes and bind mounts. The unmarked options do not belong: --store-path is not a Docker run flag (it relates to storage configuration concepts, not container mounting), --attach-storage is not a valid Docker CLI option, and --link-volume is not a recognized Docker flag for attaching volumes or bind mounts.

Answer

--store-path

Answer

--attach-storage

Answer

--link-volume

Question 8

Which THREE inspection or cleanup actions can be performed on Podman secrets? (Choose THREE)

Accepted Answer

List existing secrets with 'podman secret ls'. Option A is correct because 'podman secret ls' is the standard subcommand that enumerates all secrets currently stored in Podman's secret store, showing IDs and names. Option B is correct because 'podman secret inspect' retrieves metadata about a secret (such as ID, name, driver, and timestamps) without exposing the secret payload. Option E is correct because 'podman secret rm' deletes one or more secrets from the store, which is the supported cleanup action. Option C is not a real Podman subcommand; secrets are created via 'podman secret create' and are not compiled into a binary format. Option D is also invalid because Podman does not support editing secret values in place; secrets are immutable and must be removed and recreated to change their contents.

Answer

Compile secrets into binary format with 'podman secret compile'

Answer

Edit secret values in-place with 'podman secret edit'

Question 9

Which TWO conditions are required for a non-root (rootless) user to successfully bind mount a host directory into a container? (Choose TWO)

Accepted Answer

The user must have read/write access to the host directory on the host file system. Option B is correct because a rootless user can only bind mount a host directory into a container if that user actually has read/write permissions on the source directory in the host filesystem; without those permissions, the mount would be denied or the container process could not access the content. Option E is correct because when SELinux is enforcing, the host directory must carry a label that the container process is allowed to access, typically applied with the :z or :Z volume option so the bind mount is not blocked by SELinux policy. Option A is not required and is generally impossible for a non-root user, since directly editing kernel mount tables requires root privileges. Option C is incorrect because disabling user namespaces would remove the very mechanism that enables rootless containers, not help bind mounting. Option D is incorrect because the whole point of a rootless container is to operate without root privileges on the host.

Answer

Direct modification of the host kernel mount tables

Answer

Disabling user namespaces across the system

Answer

Root privileges on the host operating system

Question 10

An administrator needs to create a persistent storage volume that Podman can manage independently of any specific container lifecycle. Which command accomplishes this?

Accepted Answer

podman volume create mydata. `podman volume create mydata` is the correct command to create a named volume that Podman manages independently of any container's lifecycle. Named volumes persist after containers are removed and can be mounted into multiple containers, making them ideal for persistent data. This is the direct Podman equivalent of `docker volume create`.

Answer

podman volume init mydata

Answer

podman storage volume-add mydata

Answer

podman create volume --name mydata

Question 11

You are configuring a container to consume a Podman secret named db_password. By default, where within the container's file system will this secret be mounted if no destination path is specified?

Accepted Answer

/run/secrets/db_password. When a Podman secret is consumed without an explicit destination, Podman mounts it at /run/secrets/<secret-name> inside the container. This mirrors the Docker Swarm convention and uses /run because it is a tmpfs-backed runtime directory, keeping the secret out of the image layers and off persistent storage. Thus db_password appears at /run/secrets/db_password.

Answer

/secrets/db_password

Answer

/etc/secrets/db_password

Answer

/var/run/secrets/db_password

Question 12

You need to pass sensitive database credentials to a Podman container securely without storing them in plaintext environment variables. Which sequence of commands correctly creates and injects the secret?

Accepted Answer

podman secret create db_pass secret.txt && podman run --secret db_pass,type=mount,target=/run/secrets/pass myapp. Podman secrets are created with 'podman secret create' and injected into a container using '--secret'. Specifying type=mount and target=/run/secrets/pass mounts the secret as a file inside the container, avoiding plaintext environment variables. This is the secure, supported pattern for delivering credentials to a container.

Answer

podman volume create db_pass && podman run --volume db_pass:/run/secrets/pass myapp

Answer

podman secret create db_pass secret.txt && podman run --env-file secret.txt myapp

Answer

podman secret add db_pass secret.txt && podman run -e SECRET=db_pass myapp

Question 13

Which TWO actions can be performed using the podman volume management command suite? (Choose two.)

Accepted Answer

Display detailed low-level configuration of a volume using podman volume inspect. Option B is correct because `podman volume inspect` is a real subcommand of the `podman volume` suite that outputs detailed low-level JSON configuration for a named volume, including its mountpoint, driver, labels, and options. Option E is correct because `podman volume prune` is a valid subcommand that removes all volumes not currently referenced by any container, freeing unused storage. Option A is incorrect because there is no `podman volume resize` subcommand; volume size limits are not managed that way in Podman. Option C is incorrect because `podman volume encrypt` does not exist; Podman does not provide a volume-encryption subcommand in its volume suite. Option D is incorrect because `podman volume convert` is not a real subcommand and bind mounts cannot be converted into named volumes via the volume management suite.

Answer

Modify the size limit of an existing volume using podman volume resize

Answer

Encrypt a managed volume at rest using podman volume encrypt

Answer

Convert a bind mount to a named volume using podman volume convert

Question 14

You have a file named config.env containing multiple KEY=VALUE pairs. Which flag allows you to load these configurations into a container as environment variables?

Accepted Answer

--env-file config.env. The --env-file flag allows you to specify a file containing KEY=VALUE pairs that will be loaded as environment variables in the container. This is the standard way to pass multiple environment variables from a file. The file format is simple: each line is a KEY=VALUE pair, and comments are supported with #.

Answer

--config-file config.env

Answer

--volume config.env:/etc/env

Answer

--secret file=config.env

Question 15

Which TWO types of storage mechanisms are natively supported by Podman for container data persistence? (Choose two.)

Accepted Answer

Host bind mounts referencing directories on the host filesystem. Option B is correct because Podman natively supports host bind mounts, where a directory or file on the host filesystem is mapped directly into the container using the -v or --mount flag (e.g., -v /host/path:/container/path), making it a first-class persistence mechanism. Option D is correct because Podman also natively supports managed named volumes, which are created and tracked in Podman's own storage graph (typically under /var/lib/containers/storage/volumes for root or ~/.local/share/containers/storage/volumes for rootless users) and persist independently of container lifecycle. Option A is not a native Podman storage mechanism; NFS exports would have to be mounted on the host first and then exposed via a bind mount, and shared memory block devices are not a Podman persistence type. Option C is incorrect because direct Fibre Channel LUN mapping is a host-level storage concern handled by the OS, not something Podman natively provides to containers. Option E is incorrect because HDFS is a distributed filesystem service external to Podman and is not a natively supported container storage driver.

Answer

Shared memory block devices via NFS exports

Answer

Direct Fibre Channel LUN mapping inside containers

Answer

Distributed HDFS cluster mounts