Troubleshooting practice questions

An administrator is troubleshooting a container that fails its health check repeatedly. The container definition needs a health check that runs curl -f http://localhost/ || exit 1 every 30s, with a 5s timeout and 3 retries, starting after a 10s grace period. Which flag combination implements this correctly in podman run?

Trap 1: podman run --healthcheck="curl -f http://localhost/" --interval=30…

The flags must use the --health- prefix (e.g., --health-cmd, --health-interval).

Trap 2: podman run --health-probe="curl -f http://localhost/"…

--health-probe and --health-delay are invalid options; the correct flags are --health-cmd and --health-start-period.

Trap 3: podman run --check-command="curl -f http://localhost/"…

--check-command and --check-period are invalid flag names.

A
podman run --healthcheck="curl -f http://localhost/" --interval=30 --timeout=5 --retries=3 webapp
Why wrong: The flags must use the --health- prefix (e.g., --health-cmd, --health-interval).
B
podman run --health-probe="curl -f http://localhost/" --health-delay=10s webapp
Why wrong: --health-probe and --health-delay are invalid options; the correct flags are --health-cmd and --health-start-period.
C
podman run --health-cmd="curl -f http://localhost/ || exit 1" --health-interval=30s --health-timeout=5s --health-retries=3 --health-start-period=10s webapp
These are the correct exact flags for configuring container health checks in Podman.
D
podman run --check-command="curl -f http://localhost/" --check-period=30s webapp
Why wrong: --check-command and --check-period are invalid flag names.

Question 2hardmultiple choice

A security engineer is troubleshooting why signature verification fails when pulling an image from a trusted registry. The policy file (/etc/containers/policy.json) specifies 'signedBy' using a GPG key, but the transport uses 'dir://'. Where must the public GPG key be imported for Podman to successfully verify the signature?

Trap 1: Into ~/.config/containers/policy.d/keys/

This directory path does not exist for key management.

Trap 2: Into /etc/containers/certs.d/keys/

Certs.d is for TLS certificates, not GPG keys.

Trap 3: Into /var/lib/containers/sigstore/

sigstore stores signature blobs, not the trusted public keys directly.

A
Into the local GnuPG keyring using 'gpg --import'
Podman uses the GnuPG keyring to verify signatures when configured with GPG verification.
B
Into ~/.config/containers/policy.d/keys/
Why wrong: This directory path does not exist for key management.
C
Into /etc/containers/certs.d/keys/
Why wrong: Certs.d is for TLS certificates, not GPG keys.
D
Into /var/lib/containers/sigstore/
Why wrong: sigstore stores signature blobs, not the trusted public keys directly.

Question 3hardmultiple choice

An administrator is troubleshooting container exit codes. A container exited with code 137. What does this specific exit code typically signify in container engines?

Trap 1: The container executed an invalid system call blocked by seccomp.

Blocked system calls typically result in SIGSYS (exit code 159).

Trap 2: The container encountered an application-level syntax error.

Application errors usually result in exit code 1 or specific application-defined codes.

Trap 3: The container startup script had a permission denied error.

Permission errors generally result in exit code 126 or 127.

A
The container was terminated forcefully by SIGKILL (often due to Out-Of-Memory).
Signal 9 (SIGKILL) added to base 128 results in 137, commonly triggered by the kernel OOM killer.
B
The container executed an invalid system call blocked by seccomp.
Why wrong: Blocked system calls typically result in SIGSYS (exit code 159).
C
The container encountered an application-level syntax error.
Why wrong: Application errors usually result in exit code 1 or specific application-defined codes.
D
The container startup script had a permission denied error.
Why wrong: Permission errors generally result in exit code 126 or 127.

Question 4hardmulti 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 wrong: podman exec-top is invalid.
B
podman adjust
Why wrong: 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 wrong: podman modify is not a valid subcommand.
E
podman top
podman top displays the running processes inside a container.

Question 5mediummultiple choice

You are troubleshooting a build where a RUN instruction fails because it cannot reach a remote URL to download a file. The local network uses an HTTP proxy. How should you pass the proxy settings to the build command without hardcoding them into the image?

Trap 1: podman build --proxy http://proxy.example.com:8080 .

There is no --proxy flag for podman build.

Trap 2: podman build --env HTTP_PROXY=http://proxy.example.com:8080 .

The --env flag applies to runtime, not build time.

Trap 3: podman build --set-proxy http://proxy.example.com:8080 .

--set-proxy is not a valid flag.

A
podman build --proxy http://proxy.example.com:8080 .
Why wrong: There is no --proxy flag for podman build.
B
podman build --env HTTP_PROXY=http://proxy.example.com:8080 .
Why wrong: The --env flag applies to runtime, not build time.
C
podman build --build-arg HTTP_PROXY=http://proxy.example.com:8080 .
Passing build arguments allows injecting proxy settings securely.
D
podman build --set-proxy http://proxy.example.com:8080 .
Why wrong: --set-proxy is not a valid flag.

Question 6mediummulti select

An administrator is troubleshooting a misbehaving container and needs to examine its output logs and event history. Which TWO commands are appropriate for this task? (Choose TWO)

Trap 1: podman inspect-logs

podman inspect-logs is not a valid subcommand.

Trap 2: podman history

podman history shows image build layer history, not container logs.

Trap 3: podman trace

podman trace is not used for viewing container log streams.

A
podman inspect-logs
Why wrong: podman inspect-logs is not a valid subcommand.
B
podman logs
podman logs fetches standard output and error logs generated by the container.
C
podman events
podman events monitors container lifecycle events in real time.
D
podman history
Why wrong: podman history shows image build layer history, not container logs.
E
podman trace
Why wrong: podman trace is not used for viewing container log streams.

Question 7hardmulti select

An administrator is troubleshooting an issue where a rootless container cannot access a host file because of SELinux denials. Which THREE statements accurately describe how SELinux interacts with rootless Podman containers on RHEL 9? (Choose three.)

Trap 1: Rootless containers completely disable SELinux enforcement…

Rootless containers do not disable SELinux; security policies remain actively enforced.

Trap 2: Rootless containers require the container host to be booted with…

Rootless containers function fully on SELinux-enforcing systems without disabling SELinux.

A
Rootless containers run under the user's unprivileged process context and are still constrained by SELinux policy rules.
SELinux mandatory access control applies to all processes on the system, including rootless container engines.
B
Rootless containers completely disable SELinux enforcement automatically upon startup.
Why wrong: Rootless containers do not disable SELinux; security policies remain actively enforced.
C
Rootless containers require the container host to be booted with selinux=0 kernel parameter to function.
Why wrong: Rootless containers function fully on SELinux-enforcing systems without disabling SELinux.
D
SELinux MCS (Multi-Category Security) label separation prevents rootless containers from escaping into other users' namespaces.
MCS labeling provides additional isolation boundaries between different container workloads and user sessions.
E
Rootless Podman processes cannot dynamically modify host file security contexts (such as via chcon) unless granted specific administrative capabilities.
Unprivileged users lack the capability to relabel arbitrary host files freely across different security contexts.

Question 8easymultiple choice

You are troubleshooting a container that should have no network access whatsoever for security isolation. Which networking option should you apply?

Trap 1: --network isolated

Incorrect. 'isolated' is not a valid Podman network driver name.

Trap 2: --network bridge

Incorrect. Bridge mode provides standard NAT networking.

Trap 3: --network host

Incorrect. Host mode shares the host network stack entirely.

A
--network isolated
Why wrong: Incorrect. 'isolated' is not a valid Podman network driver name.
B
--network bridge
Why wrong: Incorrect. Bridge mode provides standard NAT networking.
C
--network host
Why wrong: Incorrect. Host mode shares the host network stack entirely.
D
--network none
Correct. The none network mode disables all networking except loopback.

Question 9hardmultiple choice

An administrator is troubleshooting container startup failures and wants to inspect the exact entrypoint and command arguments configured for a container named app_run before it starts. Which inspect format expression retrieves this?

Trap 1: podman ps --format='{{.Command}}' app_run

While ps shows the running command, inspect .Config.Entrypoint and .Config.Cmd provide the raw configured metadata.

Trap 2: podman inspect --format='{{.State.Command}}' app_run

.State.Command does not exist in the inspect output structure.

Trap 3: podman inspect --format='{{.Args}}' app_run

.Args is not the correct JSON path for image configuration entrypoints.

A
podman ps --format='{{.Command}}' app_run
Why wrong: While ps shows the running command, inspect .Config.Entrypoint and .Config.Cmd provide the raw configured metadata.
B
podman inspect --format='{{.State.Command}}' app_run
Why wrong: .State.Command does not exist in the inspect output structure.
C
podman inspect --format='{{.Config.Entrypoint}} {{.Config.Cmd}}' app_run
This inspect format string retrieves both the entrypoint and command configurations.
D
podman inspect --format='{{.Args}}' app_run
Why wrong: .Args is not the correct JSON path for image configuration entrypoints.

Question 10hardmulti select

An administrator is troubleshooting container exit codes and low-level state details. Which TWO of the following inspect format expressions correctly extract container state attributes? (Choose TWO)

Trap 1: podman inspect --format='{{.Metadata.ExitCode}}' container_name

.Metadata is not the correct path for exit codes.

Trap 2: podman inspect --format='{{.Status.Running}}' container_name

Running status is located under .State.Running, not .Status.Running.

Trap 3: podman inspect --format='{{.Exit}}' container_name

.Exit is not a valid JSON path in container inspect output.

A
podman inspect --format='{{.Metadata.ExitCode}}' container_name
Why wrong: .Metadata is not the correct path for exit codes.
B
podman inspect --format='{{.State.StartedAt}}' container_name
This retrieves the timestamp when the container was started.
C
podman inspect --format='{{.Status.Running}}' container_name
Why wrong: Running status is located under .State.Running, not .Status.Running.
D
podman inspect --format='{{.Exit}}' container_name
Why wrong: .Exit is not a valid JSON path in container inspect output.
E
podman inspect --format='{{.State.ExitCode}}' container_name
This retrieves the exit code of the container process.