Container Operations And Lifecycle practice questions

podman health status api_gw

Why it fails: podman health is not a top-level subcommand.

podman ps --filter health=unhealthy

Why it fails: While ps has filters, health checking filter syntax is different, and this does not provide a direct quick view of status like inspect formatting does.

podman status api_gw

Why it fails: podman status is not a valid command.

systemctl enable --container web_frontend

Why it fails: systemctl does not take a --container flag directly for Podman generation.

podman export systemd web_frontend

Why it fails: podman export extracts container filesystem contents into a tarball.

podman systemd generate --name web_frontend

Why it fails: The syntax is podman generate systemd, not podman systemd generate.

podman ports proxy_svr

Why it fails: podman ports is not a valid subcommand.

podman inspect --ports proxy_svr

Why it fails: There is no --ports flag in podman inspect.

podman ps --filter port=80

Why it fails: While ps has filter options, it does not output mapped host ports in a custom formatted list like inspect formatting does.

--health-enabled=false

Why it fails: --health-enabled is not a valid flag.

--disable-health

Why it fails: --disable-health is invalid.

--no-healthcheck

Why it fails: --no-healthcheck is not a standard Podman run flag (it is Docker-compatible in some contexts, but --health-cmd=none is the explicit Podman syntax).

podman terminate runaway_job

Why it fails: podman terminate does not exist.

podman halt runaway_job

Why it fails: podman halt is invalid.

podman stop --force runaway_job

Why it fails: While podman stop --force works, podman kill is the direct command for sending specific signals like SIGKILL.

podman exec

Why it fails: podman exec runs a command inside an already running container.

podman run

Why it fails: podman run creates and starts a new container from an image, rather than starting an existing stopped container.

podman up

Why it fails: podman up is not a standard Podman command for single container management.

podman list-ports

Why it fails: podman list-ports does not exist.

podman env

Why it fails: podman env is not a valid Podman command for running containers.

podman show-env

Why it fails: podman show-env is invalid.

podman kill --remove container_name

Why it fails: podman kill does not accept a --remove flag.

podman delete --force container_name

Why it fails: podman delete is not a valid command.

podman stop --rm container_name

Why it fails: podman stop does not accept the --rm flag.

systemctl system-wide-users

Why it fails: This command is invalid.

/etc/containers/rootless.conf

Why it fails: This file is not the standard location for rootless user mappings.

/var/lib/podman/subuid.conf

Why it fails: Subordinate UID mappings are configured in system files /etc/subuid and /etc/subgid, not /var/lib/podman/subuid.conf.

podman export systemd app_server > /etc/systemd/system/app_server.service

Why it fails: The 'podman export' command exports a container's filesystem to a tar archive, not a systemd unit file.

podman service generate --container app_server --output ~/.config/systemd/user/

Why it fails: This is a syntactically invalid command structure for Podman.

podman systemd create --name app_server > ~/.config/systemd/user/container-app_server.service

Why it fails: Podman has no 'systemd create' subcommand.

Run 'podman config app_prod' to print a summary of environment variables and limits.

Why it fails: There is no 'podman config' subcommand.

Run 'podman diff app_prod' to view changes to the container's file system, which is primarily used for tracking modifications rather than initial configuration.

Why it fails: While 'podman diff' shows filesystem changes, it is not used for inspecting general configuration, network settings, or volumes in the context of general troubleshooting.

podman generate systemd --new --name web_proxy > /etc/systemd/system/container-web_proxy.service, then systemctl daemon-reload and systemctl enable --now container-web_proxy.service

Why it fails: Writing the unit to /etc/systemd/system creates a system-level service, but rootless Podman containers require a user-level systemd unit because they run under the user's session and rely on user-specific storage and configuration. Running systemctl without --user would try to manage it as root, which cannot access the user's rootless container storage. This approach would fail to start the container correctly.

podman generate systemd --new --name web_proxy > ~/.config/systemd/user/container-web_proxy.service, then systemctl --user daemon-reload and systemctl --user start container-web_proxy.service

Why it fails: This sequence correctly reloads the user systemd daemon and starts the service, but it uses start instead of enable. Starting the service only runs it now; it does not configure it to start automatically after a reboot. To ensure the container restarts after a host reboot, the administrator must enable the unit, which creates the necessary symlinks for automatic startup at boot.

podman generate systemd --new --name web_proxy > ~/.config/systemd/user/container-web_proxy.service, then systemctl daemon-reload and systemctl enable --now container-web_proxy.service

Why it fails: The unit file location is correct for a user unit, but the systemctl commands omit the --user flag. Without --user, systemctl operates on system services and will not find or manage the user unit. The administrator would need to run systemctl --user daemon-reload and systemctl --user enable --now to properly activate the service for the user session, making this sequence incomplete and ineffective.

Run the container with the --privileged flag to grant all capabilities.

Why it fails: Using --privileged grants the container all capabilities and disables many security restrictions, which is excessive and poses a significant security risk. While it would allow binding to port 80, it violates the principle of least privilege. The administrator should seek a more granular solution. In rootless mode, --privileged may not even work as expected because the user lacks the necessary privileges to grant all capabilities.

Set the container's user to root by adding --user root to the podman run command.

Why it fails: Running the container as root with --user root does not help in a rootless Podman setup because the root user inside the container is mapped to an unprivileged user on the host via user namespaces. The container's root does not have real root privileges on the host, so it still cannot bind to privileged ports. This approach does not solve the permission issue and may introduce other security concerns.

Configure the container to use a port mapping from a high port on the host to port 80 in the container, such as -p 8080:80.

Why it fails: Mapping a high host port to port 80 in the container does not resolve the permission denied error inside the container. The error occurs because the container process attempts to bind to port 80 within its own network namespace, which still requires privilege. Port mapping only changes how external clients connect; it does not grant the container process the ability to bind to a privileged port internally.

podman monitor --stream

Why it fails: Podman has no monitor subcommand; events are surfaced through podman events, so this command fails outright. It tempts administrators expecting a Docker-style monitoring verb, but podman events with --stream is the actual mechanism for watching container lifecycle activity system-wide in real time.

podman logs --follow --events

Why it fails: podman logs retrieves stdout/stderr output from a container and does not accept an --events flag, so it cannot report lifecycle transitions. It tempts administrators associating 'follow' with real-time output, but podman events --stream is the correct command for observing creation, starting and stopping across the whole system.

podman system trace

Why it fails: podman system trace records system-level operations such as events and file descriptors, not container lifecycle events. The tempting overlap is the word "system", but lifecycle monitoring requires podman events, which streams creation, start and stop activity. Trace suits debugging low-level Podman internals instead.

podman up -d --name webapp docker.io/library/httpd

Why it fails: podman up is not a podman subcommand; podman has no equivalent of Docker Compose's up, so the command fails outright. It is tempting because up reads naturally as start and run, and it is the correct verb in Compose-based tooling such as podman-compose when launching a defined multi-container stack.

podman container create -d --name webapp docker.io/library/httpd

Why it fails: podman container create only builds a stopped container; without a subsequent start it never runs, so the background requirement is unmet. It is tempting because create accepts --name and the image and is the correct first step when a container must be pre-created with specific settings before being started later.

podman start -d docker.io/library/httpd --name webapp

Why it fails: podman start only starts an existing, already-created container and takes no image argument, so it cannot create webapp from httpd. It is tempting because it does run containers in the background, which is the correct choice when the container has already been created and merely needs restarting.

podman inspect --logs db_cache

Why it fails: `podman inspect` returns container configuration metadata such as environment variables, mounts and network settings, not captured stdout. It is tempting because inspect is the go-to command for examining a container's state, and it would be correct for retrieving config details, but the stem asks for prior log output, which only `podman logs` retrieves.

podman output db_cache

Why it fails: `podman output` is not a valid Podman subcommand, so it cannot return anything. It is tempting because the name matches the stem's wording about standard output, and a command of that name would be correct if it existed, but Podman exposes container stdout through `podman logs`, not an output subcommand.

podman history db_cache

Why it fails: `podman history` displays image layer build history for an image, not runtime stdout from a container instance. It is tempting because it inspects past activity, and it would be correct for auditing how an image was constructed, but the stem requires the container's captured output before exit, which `podman logs` provides.

podman show redis_cache

Why it fails: Podman has no 'show' subcommand, so the command errors rather than returning JSON. The tempting assumption is that 'show' mirrors inspection verbs in other tools; it would only be valid if Podman implemented such a verb, which it does not.

podman details redis_cache

Why it fails: Podman has no 'details' subcommand, so the command fails rather than producing JSON output. The name suggests descriptive output, but the actual mechanism for low-level configuration and state is 'podman inspect', optionally with '--format json' to guarantee JSON.

podman query --json redis_cache

Why it fails: Podman provides no 'query' subcommand, so this returns an unknown-command error instead of JSON. It is tempting because 'query' suggests structured data retrieval, but that role belongs to 'podman inspect --format json', which emits the container's configuration and state.

podman kill --signal SIGTERM --timeout 30 app_server

Why it fails: podman kill sends the signal but returns immediately without waiting for the container to exit, so no 30-second grace period precedes termination. It is tempting because kill does support signal selection, which is useful when a specific signal must be delivered, but it lacks the wait-and-then-force behaviour required here.

podman halt -s 30 app_server

Why it fails: podman halt does not exist as a Podman subcommand, and -s denotes a signal, not a timeout in seconds. It is tempting because halt is a familiar container-stop verb from other runtimes, where stopping a container gracefully is the goal, but Podman implements that through podman stop.

podman terminate --grace-period=30 app_server

Why it fails: podman terminate is not a Podman subcommand, and --grace-period belongs to Kubernetes, not Podman. It is tempting because Kubernetes users expect a grace period before forced termination, which matches the scenario's intent, but the flag and verb are unavailable in Podman's CLI.

~/.local/share/podman/systemd/

Why it fails: ~/.local/share/podman/systemd/ is not a systemd unit search path; systemd never reads it, so the unit would be ignored. It is tempting because it sits under a podman directory and looks container-specific, but rootless user units belong in ~/.config/systemd/user/ for the user manager to load them.

/etc/systemd/system/

Why it fails: /etc/systemd/system/ is the system-wide unit directory, so a unit placed there runs under the system manager as root, not the user's own systemd instance. It is tempting because it is the standard location for administrator-managed services, but rootless user units must live under the user's systemd path.

/var/lib/containers/systemd/

Why it fails: /var/lib/containers/systemd/ is a Quadlet directory for rootful container units, not a systemd user unit path, so a rootless user manager will not load it. It is tempting because it is container-related and systemd-adjacent, but Quadlet files there are generated into units by the system manager.

podman run --healthcheck="curl -f http://localhost/" --interval=30 --timeout=5 --retries=3 webapp

Why it fails: --healthcheck and --interval are not podman run flags; podman uses --health-cmd, --health-interval, --health-timeout, --health-retries and --health-start-period. It is tempting because the values match the stem, and this style would be correct for Docker Compose healthcheck keys rather than podman CLI flags.

podman run --health-probe="curl -f http://localhost/" --health-delay=10s webapp

Why it fails: --health-probe is not a podman run flag, and the command omits the || exit 1 exit-status logic plus the timeout and retries settings the stem requires. It is tempting because it names a health check, and it would suit a runtime where a single probe command with defaults is acceptable.

podman run --check-command="curl -f http://localhost/" --check-period=30s webapp

Why it fails: --check-command and --check-period are not podman run options, so the health check never registers with the required interval, timeout or retries. It is tempting because the flag names sound like health-check configuration, and such syntax would be correct in a different orchestrator's manifest format.