Scenario practice questions

Which TWO options are valid flags for the 'podman build' command to specify build arguments and tags? (Choose two.)

Trap 1: --volume

--volume mounts a host path or named volume into the build container; it does not pass build-time variables or name the resulting image. It is tempting because volumes are common in 'podman run', but for 'podman build' the argument flag is --build-arg and the tag flag is --tag.

Trap 2: --publish

--publish maps container ports to host ports at run time; it neither defines build arguments nor tags an image during 'podman build'. It is tempting because it is a familiar 'podman run' flag, but the build command's argument and tag flags are --build-arg and --tag.

Trap 3: --env-file

--env-file supplies environment variables to the running container at runtime, not build arguments or image tags during 'podman build'. It is tempting because it resembles --build-arg in passing variables, but build arguments require --build-arg, and tagging requires --tag.

A
--volume
Why it fails: --volume mounts a host path or named volume into the build container; it does not pass build-time variables or name the resulting image. It is tempting because volumes are common in 'podman run', but for 'podman build' the argument flag is --build-arg and the tag flag is --tag.
B
--publish
Why it fails: --publish maps container ports to host ports at run time; it neither defines build arguments nor tags an image during 'podman build'. It is tempting because it is a familiar 'podman run' flag, but the build command's argument and tag flags are --build-arg and --tag.
C
--build-arg
--build-arg passes a named variable into the build at run time, letting a Containerfile consume values such as versions or credentials without hard-coding them. It satisfies the stem's requirement for specifying build arguments, distinct from --tag, which names the resulting image.
D
-t / --tag
The `-t` / `--tag` flag assigns a name and optional tag to the resulting image in `name:tag` format, satisfying the stem's requirement to specify tags during `podman build`. It directly addresses the tagging half of the question, letting you label the built image for later reference.
E
--env-file
Why it fails: --env-file supplies environment variables to the running container at runtime, not build arguments or image tags during 'podman build'. It is tempting because it resembles --build-arg in passing variables, but build arguments require --build-arg, and tagging requires --tag.

Question 2easymultiple choice

An administrator wants to immediately stop and remove a running container named temp_test in a single command. Which command should be used?

Trap 1: podman kill --remove temp_test

podman kill sends SIGKILL but accepts no --remove flag, so the container is signalled and left present. It tempts those wanting immediate termination, yet kill suits only stopping a process; podman rm --force temp_test stops and deletes in one command.

Trap 2: podman delete --force temp_test

Podman has no delete subcommand; the verb for removing containers is rm, so this fails before any force flag is parsed. It tempts administrators who expect Docker-style or object-store naming, but podman rm --force temp_test is the real single-command stop-and-remove.

Trap 3: podman stop --rm temp_test

podman stop has no --rm flag, so the container halts but is never removed, failing the single-command requirement. It tempts administrators familiar with docker run --rm, which auto-deletes on exit; here podman rm --force temp_test performs both actions.

A
podman kill --remove temp_test
Why it fails: podman kill sends SIGKILL but accepts no --remove flag, so the container is signalled and left present. It tempts those wanting immediate termination, yet kill suits only stopping a process; podman rm --force temp_test stops and deletes in one command.
B
podman delete --force temp_test
Why it fails: Podman has no delete subcommand; the verb for removing containers is rm, so this fails before any force flag is parsed. It tempts administrators who expect Docker-style or object-store naming, but podman rm --force temp_test is the real single-command stop-and-remove.
C
podman stop --rm temp_test
Why it fails: podman stop has no --rm flag, so the container halts but is never removed, failing the single-command requirement. It tempts administrators familiar with docker run --rm, which auto-deletes on exit; here podman rm --force temp_test performs both actions.
D
podman rm -f temp_test
The -f flag forces removal of a running container, sending SIGKILL and deleting it without a prior stop step. This satisfies the requirement to stop and remove temp_test in a single command, unlike plain podman rm, which fails on running containers.

Question 3hardmulti select

An administrator is troubleshooting process execution and live configuration updates on a running container. Which TWO commands allow interacting with processes or updating resource limits on the fly? (Choose TWO)

Trap 1: podman exec-top

podman exec-top is invalid.

Trap 2: podman adjust

podman adjust does not exist.

Trap 3: podman modify

podman modify is not a valid subcommand.

A
podman exec-top
Why it fails: podman exec-top is invalid.
B
podman adjust
Why it fails: podman adjust does not exist.
C
podman update
podman update modifies container resource limits like CPU shares on a running container.
D
podman modify
Why it fails: podman modify is not a valid subcommand.
E
podman top
podman top displays the running processes inside a container.

Question 4easymultiple choice

A developer needs to pass several environment variables to a container from a file named web.env. The file contains lines such as DB_HOST=localhost and DB_PORT=5432. Which Podman run flag should be used to load these variables into the container?

Trap 1: --config web.env

There is no --config flag for podman run that loads environment variables. The --config option is not part of Podman's run command; it may exist in other tools but not here. Using it will result in an error. Environment variables must be passed with --env or --env-file.

Trap 2: --environment-file web.env

Podman does not have an --environment-file flag. The correct flag is --env-file. Using an incorrect flag name will cause Podman to return an error about an unknown option, and the container will not start. Always verify flag names with podman run --help when unsure.

Trap 3: --env web.env

The --env flag is used to set a single environment variable directly, either as KEY=VALUE or just KEY to inherit from the host. If you pass a filename like web.env, Podman will treat it as a variable name or value, not read the file. This does not load variables from a file and will not achieve the desired result.

A
--config web.env
Why it fails: There is no --config flag for podman run that loads environment variables. The --config option is not part of Podman's run command; it may exist in other tools but not here. Using it will result in an error. Environment variables must be passed with --env or --env-file.
B
--env-file web.env
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.
C
--environment-file web.env
Why it fails: Podman does not have an --environment-file flag. The correct flag is --env-file. Using an incorrect flag name will cause Podman to return an error about an unknown option, and the container will not start. Always verify flag names with podman run --help when unsure.
D
--env web.env
Why it fails: The --env flag is used to set a single environment variable directly, either as KEY=VALUE or just KEY to inherit from the host. If you pass a filename like web.env, Podman will treat it as a variable name or value, not read the file. This does not load variables from a file and will not achieve the desired result.

Question 5hardmultiple choice

You are building an image with a multi-stage Containerfile. The final stage uses `FROM registry.access.redhat.com/ubi9/ubi-minimal` and you want to copy only the compiled binary from a builder stage named `builder` into `/usr/local/bin/app`. Which Containerfile line correctly copies that artifact?

Trap 1: RUN cp --from=builder /src/app /usr/local/bin/app

RUN executes a command inside the current stage's container filesystem. There is no cp option called --from that reaches into another build stage, so this command would fail. Multi-stage artifact transfer is a build-time feature of the COPY instruction, not a runtime shell command, so RUN cannot perform this copy from the builder stage.

Trap 2: COPY --from=0 /src/app /usr/local/bin/app

COPY --from=0 is syntactically valid and refers to the first build stage by index, but in this scenario the first stage may not be the builder if the Containerfile declares stages in a different order. The scenario explicitly names the stage `builder`, so referencing it by name is the correct and unambiguous approach. Relying on index 0 risks copying from the wrong stage.

Trap 3: ADD --stage=builder /src/app /usr/local/bin/app

ADD does not support a --stage flag. The flag that references another build stage is --from, and it is only valid on COPY (and on FROM for external images). Using ADD with an unsupported flag will cause the build to fail or be misinterpreted, so this line does not correctly copy the artifact from the builder stage.

A
RUN cp --from=builder /src/app /usr/local/bin/app
Why it fails: RUN executes a command inside the current stage's container filesystem. There is no cp option called --from that reaches into another build stage, so this command would fail. Multi-stage artifact transfer is a build-time feature of the COPY instruction, not a runtime shell command, so RUN cannot perform this copy from the builder stage.
B
COPY --from=0 /src/app /usr/local/bin/app
Why it fails: COPY --from=0 is syntactically valid and refers to the first build stage by index, but in this scenario the first stage may not be the builder if the Containerfile declares stages in a different order. The scenario explicitly names the stage `builder`, so referencing it by name is the correct and unambiguous approach. Relying on index 0 risks copying from the wrong stage.
C
ADD --stage=builder /src/app /usr/local/bin/app
Why it fails: ADD does not support a --stage flag. The flag that references another build stage is --from, and it is only valid on COPY (and on FROM for external images). Using ADD with an unsupported flag will cause the build to fail or be misinterpreted, so this line does not correctly copy the artifact from the builder stage.
D
COPY --from=builder /src/app /usr/local/bin/app
The COPY instruction supports the --from flag, which references a previous build stage by its name or index. Here, `builder` is the named stage, so COPY --from=builder pulls the compiled artifact from that stage's filesystem into the final image. This keeps the final image minimal because only the binary is transferred, not the entire build toolchain.

Question 6mediummulti select

An administrator needs to export container contents or create new images from containers. Which TWO commands accomplish these actions? (Choose TWO)

Trap 1: podman extract

podman extract unpacks files from a saved image tar; it does not export running container contents or build new images. It is tempting as an archive operation, but the correct tools are podman export and podman commit.

Trap 2: podman push-container

`podman push-container` is not a Podman subcommand; no such verb exists in the CLI, so it cannot export container contents or commit a new image. It is tempting because `podman push` genuinely transfers a local image to a registry, which would be the right choice when publishing an already-built image rather than creating one from a container.

Trap 3: podman save

podman save archives an image to a tar file for transport, not container contents or new images. It is tempting because it moves images between hosts, but the scenario requires podman export for contents or podman commit to create images.

A
podman extract
Why it fails: podman extract unpacks files from a saved image tar; it does not export running container contents or build new images. It is tempting as an archive operation, but the correct tools are podman export and podman commit.
B
podman push-container
Why it fails: `podman push-container` is not a Podman subcommand; no such verb exists in the CLI, so it cannot export container contents or commit a new image. It is tempting because `podman push` genuinely transfers a local image to a registry, which would be the right choice when publishing an already-built image rather than creating one from a container.
C
podman commit
`podman commit` creates a new image from a container's current writable layer, satisfying the requirement to create new images from containers. It captures filesystem changes made inside a running or stopped container, unlike `podman export`, which streams the filesystem as a tar archive without producing a reusable image.
D
podman export
podman export writes a container's filesystem to a tar archive without image metadata, satisfying the stem's requirement to export container contents. It differs from commit, which builds an image rather than a flat filesystem archive.
E
podman save
Why it fails: podman save archives an image to a tar file for transport, not container contents or new images. It is tempting because it moves images between hosts, but the scenario requires podman export for contents or podman commit to create images.

Question 7easymultiple choice

A running Podman container named 'dbapp' is unresponsive, and a technician needs to immediately and forcefully terminate it without waiting for a graceful shutdown timeout. Which Podman command should be executed?

Trap 1: podman stop --force dbapp

podman stop --force sends SIGKILL only after the default ten-second timeout expires, so termination is not immediate. It is tempting because --force implies abruptness, but it still waits; the correct approach sets a zero timeout to skip the graceful phase entirely.

Trap 2: podman terminate dbapp

Podman has no terminate subcommand, so the command fails outright and the container keeps running. It is tempting because terminate mirrors terminology from other container runtimes, but Podman's equivalent forceful stop is achieved through stop with a zero timeout or rm -f.

Trap 3: podman rm -f dbapp

podman rm -f removes the container as well as killing it, so the stopped container and its writable layer are deleted, which the scenario does not request. It is tempting because it does terminate immediately, and it would be correct if the container also needed removing.

A
podman stop --force dbapp
Why it fails: podman stop --force sends SIGKILL only after the default ten-second timeout expires, so termination is not immediate. It is tempting because --force implies abruptness, but it still waits; the correct approach sets a zero timeout to skip the graceful phase entirely.
B
podman kill dbapp
`podman kill dbapp` sends SIGKILL by default, terminating the container's processes immediately without the graceful stop timeout that `podman stop` honours. This satisfies the stem's requirement to forcefully terminate the unresponsive container at once, rather than waiting for a clean shutdown sequence.
C
podman terminate dbapp
Why it fails: Podman has no terminate subcommand, so the command fails outright and the container keeps running. It is tempting because terminate mirrors terminology from other container runtimes, but Podman's equivalent forceful stop is achieved through stop with a zero timeout or rm -f.
D
podman rm -f dbapp
Why it fails: podman rm -f removes the container as well as killing it, so the stopped container and its writable layer are deleted, which the scenario does not request. It is tempting because it does terminate immediately, and it would be correct if the container also needed removing.

Question 8hardmultiple choice

A rootless Podman user must run a container that needs to write to a bind-mounted host directory. The container consistently fails with permission denied. The host directory is owned by the user and has mode 0775. SELinux is enforcing. Which action will allow the container to write to the directory without disabling SELinux?

Trap 1: Change the host directory mode to 0777 to eliminate permission…

Loosening file permissions does not resolve SELinux label mismatches. Even with 0777, the container process may still be denied by SELinux because the type context on the directory is not accessible to the container domain. This change also weakens host security without addressing the root cause.

Trap 2: Set the `container_manage_cgroup` boolean to allow container writes.

The container_manage_cgroup boolean controls whether containers can manage cgroups, not whether they can write to bind-mounted host directories. It is unrelated to file label access for volume mounts. Enabling it would not fix the permission denied error caused by an SELinux type mismatch on the mounted directory.

Trap 3: Run `podman run --privileged` to bypass all SELinux checks.

Using --privileged disables SELinux confinement for the container and grants broad capabilities, which is an insecure workaround rather than a proper fix. It does not address the specific label mismatch and unnecessarily weakens isolation. The scenario asks for a solution without disabling SELinux, so this approach is inappropriate.

A
Add the `:Z` option to the volume mount to relabel the host directory for the container.
The :Z option tells Podman to relabel the host directory with a private SELinux label unique to the container. This allows the container process to write while keeping SELinux enforcing. It is the recommended way to handle SELinux denials for bind mounts in rootless mode, and it does not require disabling or weakening SELinux.
B
Change the host directory mode to 0777 to eliminate permission issues.
Why it fails: Loosening file permissions does not resolve SELinux label mismatches. Even with 0777, the container process may still be denied by SELinux because the type context on the directory is not accessible to the container domain. This change also weakens host security without addressing the root cause.
C
Set the `container_manage_cgroup` boolean to allow container writes.
Why it fails: The container_manage_cgroup boolean controls whether containers can manage cgroups, not whether they can write to bind-mounted host directories. It is unrelated to file label access for volume mounts. Enabling it would not fix the permission denied error caused by an SELinux type mismatch on the mounted directory.
D
Run `podman run --privileged` to bypass all SELinux checks.
Why it fails: Using --privileged disables SELinux confinement for the container and grants broad capabilities, which is an insecure workaround rather than a proper fix. It does not address the specific label mismatch and unnecessarily weakens isolation. The scenario asks for a solution without disabling SELinux, so this approach is inappropriate.

Question 9mediummultiple choice

A developer builds a custom image with `podman build -t app:v1 .` but repeatedly gets stale results because an earlier RUN layer that installs packages is cached, even though the repository metadata has changed. The developer wants to force podman to ignore all cached layers for the next build without deleting the local image or build cache. Which command accomplishes this?

Trap 1: podman build --pull=always -t app:v1 .

--pull=always only forces podman to check the registry for a newer version of the base image referenced in FROM. It does not invalidate cached RUN layers in the Containerfile, so the package-install layer that is already cached will still be reused. This option is useful for base image freshness but does not solve the stale layer problem described.

Trap 2: podman build --layers=false -t app:v1 .

Disabling layers with --layers=false makes podman squash all instructions into a single layer in the resulting image, but it does not necessarily force re-execution of cached instructions in the way described. It changes the output image structure rather than reliably invalidating the cache for the RUN instruction that installs packages, so it is not the targeted fix.

Trap 3: podman rmi app:v1 && podman build -t app:v1 .

Removing the local image with podman rmi does not clear the intermediate build cache layers that podman keeps. On the next build, podman can still reuse cached instructions, so the same stale package layer may be produced again. The developer also loses the existing image, which the scenario explicitly wants to avoid.

A
podman build --pull=always -t app:v1 .
Why it fails: --pull=always only forces podman to check the registry for a newer version of the base image referenced in FROM. It does not invalidate cached RUN layers in the Containerfile, so the package-install layer that is already cached will still be reused. This option is useful for base image freshness but does not solve the stale layer problem described.
B
podman build --no-cache -t app:v1 .
The --no-cache flag tells podman to bypass the layer cache entirely and execute every instruction in the Containerfile from scratch, producing fresh layers even for unchanged instructions. It does not delete the local image or the stored cache; it simply instructs this build to avoid reusing cached layers, so the newly fetched repository metadata is honored during the RUN that installs packages.
C
podman build --layers=false -t app:v1 .
Why it fails: Disabling layers with --layers=false makes podman squash all instructions into a single layer in the resulting image, but it does not necessarily force re-execution of cached instructions in the way described. It changes the output image structure rather than reliably invalidating the cache for the RUN instruction that installs packages, so it is not the targeted fix.
D
podman rmi app:v1 && podman build -t app:v1 .
Why it fails: Removing the local image with podman rmi does not clear the intermediate build cache layers that podman keeps. On the next build, podman can still reuse cached instructions, so the same stale package layer may be produced again. The developer also loses the existing image, which the scenario explicitly wants to avoid.