EX200 Manage containers Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Ensure the user has a running systemd user instance (loginctl enable-linger).

  Why this is correct

  Rootless Podman relies on a per-user systemd instance to manage the lifecycle of container processes and services. `loginctl enable-linger` ensures that this user instance starts automatically at boot and persists after the user logs out, which is essential for containers running in the background. Without linger, containers may be terminated when the user session ends.

• ✓

  Configure subordinate UID and GID ranges for the user in /etc/subuid and /etc/subgid.

  Why this is correct

  Rootless containers need a range of sub-UIDs and sub-GIDs to map a non-root user to root inside the container namespace. Entries in /etc/subuid and /etc/subgid allocate these ranges; `useradd` can set them via --subuid-start or they can be edited manually. If no range is defined, Podman cannot perform the necessary UID/GID mapping and rootless operation fails.

• ✗

  Add the user to the 'docker' group to access the Docker socket.

  Why it's wrong here

  Podman is a separate container engine that does not depend on the Docker daemon or its Unix socket. Rootless Podman communicates directly with the kernel through user namespaces and a user-space network stack like slirp4netns, or via the podman.socket systemd unit for API access. Adding the user to the 'docker' group would grant access to a rootful socket, presenting a security risk while being completely unnecessary for Podman.

• ✓

  Enable user namespaces in the kernel if not already enabled.

  Why this is correct

  User namespaces are a kernel feature that allows unprivileged users to map their UID to root inside a container, which is fundamental to rootless Podman. While most distributions compile CONFIG_USER_NS=y, some hardened kernels disable it or subsume it behind the `kernel.unprivileged_userns_clone` sysctl. If user namespaces are disabled or restricted, even with correct subuid/subgid configuration, rootless container creation will fail.

• ✗

  Grant the user sudo privileges to run podman commands.

  Why it's wrong here

  Rootless Podman is intentionally designed to operate without sudo by leveraging user namespaces and the caller's unprivileged UID. Running `podman` with sudo would execute the container as root on the host, removing the security boundaries that rootless operation provides. Sudo is not required; instead, the necessary capabilities come from subgid/subuid mappings and systemd user session management. Granting sudo is both unnecessary and a potential privilege-escalation risk.

Go deeper

Related to this question