Manage containers

An administrator is tasked with deploying a containerized application on a Red Hat Enterprise Linux 8 server that is part of a high-security environment. The application must run as a non-root user inside the container. The container image is based on Red Hat Universal Base Image (UBI) and exposes port 443 for HTTPS. The administrator needs to ensure that the container can be restarted automatically if it crashes and that the application logs are persisted on the host in /var/log/app. The application requires a configuration file that is generated dynamically at startup and must be accessible to the container. The administrator has created a systemd service file for the container but wants to use Podman's built-in features to manage the container. Which approach meets all requirements?

A container named 'web1' was created and ran briefly before exiting with status 0. The administrator needs to restart it and attach to the running container's console. Which command should be used?

A user wants to run a container that will restart automatically unless explicitly stopped by the administrator. Which podman run option should be used?

A team wants to run a container as a non-root user inside the container for security. Which instruction should be included in the Containerfile?

Based on the exhibit, which command should be used to start the container named 'mycontainer'?

A system administrator wants to run a container as a systemd service that restarts automatically after a system reboot. Which approach follows Red Hat best practices?

A container exits immediately with status 1. The administrator runs 'podman logs container' but sees no output. What is the most likely reason for the missing logs?

A company runs a critical web application in a container on a Red Hat Enterprise Linux 9 server. The container is started via a systemd service called 'webapp.service'. The service unit file was generated using 'podman generate systemd --new --name webapp'. Recently, after a kernel update and reboot, the service fails to start the container. The administrator runs 'systemctl status webapp.service' and sees 'Active: failed (Result: exit-code)' and 'Process: 1234 ExecStart=/usr/bin/podman run ... (code=exited, status=125)'. The administrator also checks 'journalctl -u webapp.service' and sees: 'Error: unable to start container: container create failed: OCI runtime error: container_linux.go:380: starting container process caused: exec: "/usr/bin/app.sh": stat /usr/bin/app.sh: no such file or directory'. The container image was built locally using a Containerfile that includes 'COPY app.sh /usr/bin/app.sh'. The administrator verifies the image is present locally. What should the administrator do to resolve this issue?

A system administrator is troubleshooting a container that fails to start with the error: 'Error: cannot start container: listen tcp4 :80: bind: address already in use'. The container is intended to serve HTTP traffic on port 80. What is the most appropriate first step to resolve this issue?

A developer is running Podman as a non-root user on a Red Hat Enterprise Linux 8 system. The developer successfully runs a container, but notices that after logging out of the SSH session, the container stops. The developer wants the container to continue running even after disconnecting from the SSH session. The container is a simple web server that listens on port 8080. The developer has already enabled lingering for the user account using 'loginctl enable-linger'. However, the container still stops upon logout. What additional step should the developer take to ensure the container persists after logout?

Refer to the exhibit. A container named 'db' is running on the host. An administrator runs `podman inspect db` and sees the above output snippet. What can be concluded about the container's network configuration?