The only thing that drives value for these kind of certificates is enterprise consulting.
Many RFPs and consulting partners do gatekeeping where certain deals or access to products is only available when those doing project delivery have a certain amount of certified people on the company or delivery team.
So in these cases, one can have a degre from number one top university, still won't win the project deal or be allowed into the products developer portal.
For starters, Podman doesn't support anything like Docker Compose ( https://docs.docker.com/compose/ ) out of the box, which makes it harder to orchestrate deployments that need multiple containers locally.
There is podman-compose as a drop-in ( https://github.com/containers/podman-compose ), but last i checked it wasn't supported by or developed by RedHat themselves, hence no first-party support. In addition to that, the feature parity just isn't there.
Also, there is no docker.sock, which tools like Portainer ( https://www.portainer.io/ ) need to interface with Docker, hence no control web apps and other tools are available for Podman.
Besides that, there is also Docker Swarm ( https://docs.docker.com/engine/swarm/ ), a lightweight orchestrator which can be a simpler alternative to Kubernetes in smaller and more resource constrained environments, which isn't available in Podman. In addition to that, Docker Swarm's deployment format is also extremely similar to the Docker Compose one (with additional functionality added for multi node clusters), which allowed for getting started with container orchestration in a more simple fashion.
If you're in a Kubernetes shop and simply need something for Kubernetes to interface with, then containerd (which Docker uses internally) and Podman are largely comparable.
In other circumstances, Podman doesn't have complete feature parity with Docker, despite popular claims and despite its architectural improvements.
Disclaimer: I work for Red Hat which is the main force behind Podman
I mostly agree, however I don't think saying that Podman lacking a docker.sock is a lack of feature parity, since that's actually considered a feature of Podman. The daemon model that Docker uses has security implications that are non-trivial. Podman chooses not to be a daemon by choice. There is a sister project called CRI-O that has a daemon which will get you the daemonized portion if that's what you want. It has a similar API and a CLI called crictl to drive it. It's not widely used outside of Kubernetes, but it is available if you want it. If you're trying to compare apples to apples, it should be docker vs podman/cri-o, not docker vs podman.
Podman also has some features that Docker does not have, such as the ability to create, run, and export Pods (same YAML definition as Kubernetes, which is mighty convenient).
I used to use docker-compose all the time, but I've found I largely don't need it anymore since I can put the various dev services into the same Pod. This is even more convenient since from every container you can just reference "localhost" since the Pod shares a network namespace between containers. It's not a perfect solution though, and certainly isn't a drop-in for docker-compose (although nobody working on Podman has claimed it is, either).
All that said Docker still has it's place. There are tools that need the docker sock in order to work. One that I wrote (called Dory) is a good example of one that won't work on Podman/CRI-O without significant work.
Even though these kinds of certified exams are taken online, it is monitored by a human proctor (from a partner exam platform like Pearson). The proctor will check your environment like webcam, mic, the number of windows opened, running processes, the number of connected displays etc.
Don't expect the proctor is tech enthusiastic enough to understand various kinds of Linux Desktop environments.