Managing Containers with Podman. This is the skill that lets you run an application in a self-contained, portable package without needing a full virtual machine. For the EX200 exam, mastering Podman means you can deploy, inspect, and troubleshoot software the way modern IT teams do — fast, reliably, and without messing up your host system.
Jump to a section
A simple way to picture Managing Containers with Podman
A container image is a frozen ready-meal in the freezer. It has all the ingredients and spices pre-portioned, just add heat. A running container is that ready-meal after you've microwaved it on a plate — the meal is now active and you can eat it, but the original frozen meal is still in the freezer, untouched. Podman is the chef who takes the frozen meal out of the freezer, puts it on a plate, and microwaves it for exactly the right time.
The key insight for managing containers with Podman is that your host computer — the one you are sat at — is the shared house kitchen. Every container is a separate meal on a separate plate. One container might be spaghetti bolognese, another a Thai green curry. They each have their own plate (their own filesystem), their own set of cutlery (their own processes), and their own spice rack (their own software libraries). But they all share the same kitchen sink (the host operating system's kernel) and the same oven (the CPU). Podman is the house rule: anyone can grab a frozen meal from the freezer, defrost it on the counter (pull the image), microwave it (run the container), eat from it (interact with the application), and when they are finished, they throw the plate in the dishwasher (stop and remove the container). The frozen meal remains ready for the next person.
This analogy works for what EX200 tests because the exam wants you to understand that containers are isolated from each other on the same host. Just as you do not want your Thai curry to taste of bolognese, you do not want one container's broken application to crash another. Podman gives you the controls to manage that isolation.
Podman is an open-source tool for running and managing containers on Linux. A container is a lightweight, standalone, executable package that includes everything needed to run a piece of software: code, runtime, system tools, libraries, and settings. Containers are isolated from each other and from the host system, but they share the host's operating system kernel — the core of the OS that manages hardware and processes. This makes them much faster and more efficient than virtual machines, which each run a full guest OS.
Podman is designed to be a drop-in replacement for Docker, the most famous container tool. It uses the same command syntax (e.g. podman run, podman ps), so if you know Docker, you know Podman. The big difference is that Podman does not require a daemon — a background service that runs constantly with root privileges. Docker runs a daemon called dockerd that has full control over containers. Podman runs containers directly as child processes of the user's shell, using something called the "fork-exec" model. This means each container is started by the user's own user ID, not by a system-wide daemon. This is more secure because an attacker who compromises Podman cannot escalate to root privileges through a daemon.
Let us start with the fundamental concepts. An image is a read-only template. Think of it as a snapshot of a filesystem containing a specific application and all its dependencies. Images are hosted in registries — servers that store and serve images. The default registry for Podman is Red Hat's registry.access.redhat.com, but you can also use Docker Hub, Quay.io, or any private registry. You download (pull) an image using podman pull. For example, podman pull registry.access.redhat.com/ubi8/ubi retrieves the Red Hat Universal Base Image 8. Once pulled, the image sits on your local machine. To create a running environment from that image, you use podman run. This command creates a new writable layer (called the container) on top of the read-only image, and starts the application inside it. The container is ephemeral — changes you make inside it are lost when you stop the container, unless you explicitly commit those changes to a new image.
You can list running containers with podman ps. To see all containers, including stopped ones, use podman ps -a. To stop a running container, use podman stop. To remove a container, use podman rm. To remove an image, use podman rmi. These commands mirror Docker exactly.
Podman also supports pods. A pod is a group of one or more containers that share the same network namespace (they can communicate over localhost) and the same storage. This is borrowed from Kubernetes, the large-scale container orchestration platform. Podman can create and manage pods with podman pod create, podman pod start, etc.
Another key feature is rootless containers. By default, Podman runs containers without root privileges. The user namespace feature maps the root user inside the container to a non-root user on the host. This means even if a container gets compromised, the attacker cannot gain administrative privileges on the host system. This is a major security improvement over older container runtimes.
Managing containers also involves inspecting them. Use podman inspect to view detailed metadata about a container or image in JSON format. Use podman logs to see the application output from a container. Use podman exec to run a command inside a running container — for example, podman exec -it mycontainer /bin/bash opens an interactive shell.
Finally, you can manage images with podman tag to give an image an alias, and podman push to upload an image to a registry.
For EX200, you will need to be comfortable with these commands and concepts. The exam expects you to run containers from Red Hat's official registries, manage container lifecycle (pull, run, stop, remove), inspect their state, and understand the difference between images and containers. You will also need to know how to expose network ports using the -p flag (e.g., -p 8080:80 maps host port 8080 to container port 80) and how to set environment variables with -e.
Pull an image from a registry
You run `podman pull registry.access.redhat.com/ubi8/ubi`. Podman downloads the image layers and stores them locally. If the image already exists, it does nothing. This step ensures you have the template needed to create a container.
Run a container from that image
You run `podman run -d --name myfirstcontainer registry.access.redhat.com/ubi8/ubi sleep 3600`. The `-d` flag detaches the container (runs in background), `--name` gives it an easy-to-remember name, and `sleep 3600` is the command that keeps the container alive for an hour. Without a command like `sleep`, the container would exit immediately.
List and inspect running containers
Run `podman ps` to verify the container is running. Then run `podman inspect myfirstcontainer` to view detailed metadata. You will see the container's ID, state, mounts, and network settings. This helps troubleshoot configurations.
Execute a command inside the running container
Run `podman exec -it myfirstcontainer /bin/bash`. This opens an interactive Bash shell inside the container. You can explore the filesystem, check processes, or debug issues. Type `exit` when done.
Stop and remove the container
First, stop the container with `podman stop myfirstcontainer`. This sends a SIGTERM signal to the main process. Then remove the container with `podman rm myfirstcontainer`. If you skip the stop, you can use `podman rm -f` to force removal. After removal, the container is gone, and you can remove the image with `podman rmi registry.access.redhat.com/ubi8/ubi`.
Imagine you work for a small e-commerce company called ShopFast. The development team has just built a new version of their product catalogue microservice. In the old days, deploying this would involve provisioning a new virtual machine, installing a specific version of Python, the correct library dependencies, and then manually copying the code. That process took hours and often failed because the production server had slightly different library versions than the development laptop.
With Podman, the developer creates a Containerfile (the Red Hat equivalent of a Dockerfile) that specifies exactly what the application needs. They build an image and push it to the company's private registry on Quay.io. The operations team then pulls that image onto the production server using:
podman pull quay.io/shopfast/catalogue:2.4.1
Then they run the container:
podman run -d --name catalogue-v2 -p 3000:3000 quay.io/shopfast/catalogue:2.4.1
The -d flag runs the container in detached mode (background), and --name gives it a human-readable name. Now the new microservice is running on port 3000. The old version, still running on port 3001, stays up until they are ready to switch traffic.
A week later, the server runs out of disk space because the container logs are growing. The administrator runs:
podman logs --tail 50 catalogue-v2
To see the last 50 log lines. They realise the logs are verbose, so they use:
podman exec catalogue-v2 ls /var/log/
To explore the container's filesystem and then clean up old logs with a script. They also run:
podman inspect catalogue-v2 | grep -i mount
To see where the container's writable layer is stored on the host, so they can monitor disk usage.
When the new version is fully tested, they stop and remove the old container:
podman stop catalogue-v1 podman rm catalogue-v1
Then they tag the new image as "latest" and push it back to the registry for other teams. The entire operation, from pulling the image to having the new version live, takes under two minutes. The developer's environment is exactly reproduced because the container image includes the correct Python version and all dependencies.
The EX200 exam tests objective 6.1 “Run and manage containers using Podman and Skopeo”. Expect four to six questions on this topic, mostly in the form of performance-based tasks where you must execute commands in a terminal. Questions rarely ask for theoretical definitions; they ask you to prove you can use the tools.
Here is what the exam specifically tests:
Running a container from a Red Hat registry: You must use podman run with an image from registry.access.redhat.com or registry.redhat.io. The exam will give you an image name. You must know how to pull it and start it. They may ask you to run it in detached mode (-d) and give it a name (--name). They will test port mapping with -p — e.g., expose host port 8080 to container port 80.
Managing container lifecycle: You must be able to list running containers (podman ps), list all containers (podman ps -a), stop a container (podman stop), start a stopped container (podman start), and remove a container (podman rm). They may ask you to remove a container that is still running, which requires podman rm -f or stopping it first.
Inspecting containers and images: You will use podman inspect on a container or an image. They may ask you to find a specific piece of metadata — for example, the IP address of a container, the mounts, or the operating system the image is based on. You must know that inspect outputs JSON and be able to use grep or jq to filter it.
Working with images: You must pull an image (podman pull), list images (podman images), and remove an image (podman rmi). They may test that you cannot remove an image that is in use by a container — you must first remove the container.
Rootless containers: The exam environment runs as a non-root user. By default, Podman runs containers rootlessly. They may ask you to notice that certain commands (like binding to a port below 1024) will fail without root — for example, podman run -p 80:80 will fail. The correct approach is to use a higher port like 8080.
Pods: You must be able to create a pod (podman pod create), list pods (podman pod ps), and run a container inside a pod (podman run --pod mypod). They may ask you to run two containers in the same pod so they can communicate over localhost.
Environment variables: Questions frequently require you to pass environment variables with -e, e.g., podman run -e MYSQL_ROOT_PASSWORD=mysecret ....
Common traps:
Forgetting the -a flag with podman ps to see stopped containers.
Trying to remove an image that a container refers to without first removing the container.
Using podman start on a container that has been removed (you can't start a removed container, only a stopped one).
Confusing podman run (creates and starts a new container) with podman start (starts an existing stopped container).
Not realising that changes inside a container are lost after podman rm — they are not saved back to the image.
Key definitions to memorise:
Image: read-only template.
Container: runnable instance of an image.
Registry: server storing images.
Pod: group of containers sharing network namespace.
Rootless: running containers without root privileges.
Detached mode: container runs in the background.
A container is a runnable instance of a read-only image; changes inside a container are lost when the container is removed unless you commit them.
Podman does not require a daemon; it runs containers as child processes of the user's shell, enhancing security.
Use `podman run -d --name myapp -p 8080:80 registry/image:tag` to deploy a container in detached mode with port mapping.
List all containers, including stopped ones, with `podman ps -a`; just `podman ps` shows only running containers.
You cannot remove an image that a container references; remove the container first with `podman rm` before using `podman rmi`.
Pods in Podman allow multiple containers to share a network namespace, enabling communication over localhost.
Environment variables are passed into containers using the `-e` flag, e.g., `-e DB_HOST=localhost`.
These come up on the exam all the time. Here's how to tell them apart.
Podman
Daemonless architecture (no background service needed)
Rootless containers by default for improved security
Native support for pods and systemd integration
Docker
Requires a daemon (dockerd) running as root
Rootless mode available but not default
Pods not supported natively (only Docker Compose for multi-container groups)
Container
Shares the host OS kernel
Startup in seconds
Isolated processes, not a full OS
Virtual Machine
Runs a full guest OS with its own kernel
Startup in minutes
Full hardware-level isolation
Image
Read-only template
Stored in a registry or locally
Cannot be modified directly
Container
Read-write instance of an image
Ephemeral runtime environment
Can be modified but changes lost on removal
Podman Pull
Downloads an image to local storage
Does not create a container
Can be run independently of run
Podman Run
Creates and starts a container in one step
Automatically pulls the image if not present
Requires an image name as argument
Mistake
Podman is just a different name for Docker and works identically in all situations.
Correct
Podman has the same command-line syntax as Docker but works without a daemon and uses a different security model (rootless by default). Some features like Docker Swarm are not present in Podman.
Because the commands look identical (run, ps, stop, rm), beginners assume they are the same under the hood. The difference only appears when troubleshooting daemon-related errors or security issues.
Mistake
When I run a container and make changes to files inside it, those changes are permanent and saved back to the image.
Correct
Changes to a container's writable layer are ephemeral. They are lost when the container is removed. To save changes, you must explicitly commit the container to a new image using `podman commit`.
In the real world, users often edit configuration files inside a container and expect them to persist. This works until the container is deleted, then the changes vanish, causing confusion.
Mistake
I can only use images from Docker Hub with Podman.
Correct
Podman can pull images from any OCI-compliant registry, including Docker Hub, Quay.io, Red Hat's registries, and private registries. You specify the registry in the image name.
Because Docker Hub is the most well-known registry, beginners assume it is the only source. The EX200 exam specifically uses Red Hat's registries, so this misconception causes failures.
Mistake
A container is like a virtual machine but lighter.
Correct
A container shares the host OS kernel, whereas a virtual machine runs a complete guest OS including its own kernel. Containers are isolated processes, not full operating systems.
The performance benefits are similar (fast startup, low overhead), so the mental model of a mini-VM is tempting. But the security and architecture implications are very different.
Mistake
Podman is only for Red Hat Enterprise Linux and cannot be used on other distros.
Correct
Podman is open source and runs on most Linux distributions, including Fedora, CentOS, Ubuntu, and Debian. It is also available on macOS and Windows via Podman Machine.
Because Podman is developed by Red Hat and heavily integrated into RHEL, beginners assume it is Red Hat-exclusive. This limits their willingness to practise on their own machines.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
`podman run` creates a new container from an image and starts it. `podman start` starts an existing stopped container that was previously created with `podman run` or `podman create`.
Use `podman logs <container-name>` even after the container has stopped. The logs are stored until the container is removed. For stopped containers, you must use the name or ID from `podman ps -a`.
Yes. Just specify the full image path, e.g., `podman pull docker.io/library/nginx:latest`. Podman uses the same OCI image format, so Docker Hub images work.
A container exits when its main process finishes. If you run a container that has no long-running process (like a shell without a terminal), it exits. Use a command like `sleep 3600` or a service entrypoint to keep it alive.
Podman does not include a built-in restart policy like Docker. Instead, use `podman generate systemd` to create a systemd service file, then enable it with `systemctl enable`.
A pod is a group of one or more containers that share the same network namespace and can communicate over localhost. It is used for co-located containers, similar to Kubernetes pods.
You've finished Managing Containers with Podman. Continue through the EX200 study guide to build a complete picture of the exam.
Done with this chapter?