EX294 Deploy Ansible Automation Platform Practice Question
An administrator is deploying a containerized Ansible Automation Platform 2.4 on RHEL 9. After running the installer, the `automation-controller` containers fail to start, and the installer log reports that the `podman` service is not running. The administrator confirms that `podman` is installed. Which action should the administrator take to resolve the failure?
⚠ Common exam trap
The trap here is assuming that an installed Podman binary is sufficient, when the installer actually requires the Podman API socket service to be running.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Enable and start the `podman.socket` service, then rerun the installer
The containerized AAP installer relies on the Podman API, which is exposed by `podman.socket`. When that socket is inactive, container operations fail even though the Podman binary is present. Enabling and starting `podman.socket`, then rerunning the installer, restores the API endpoint and allows the AAP container services to start successfully.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enable and start the `podman.socket` service, then rerun the installer
Why this is correct
Containerized AAP uses Podman to run its services, and the installer expects the Podman API socket to be available. Enabling and starting `podman.socket` provides that API endpoint. Rerunning the installer after the socket is active allows the container services to start, resolving the reported failure.
- ✗
Add the `awx` user to the `docker` group and restart the `automation-controller` service
Why it's wrong here
There is no Docker group involvement in a Podman-based deployment, and the `automation-controller` service is itself a container managed by the installer. Adding a user to a nonexistent group does nothing. The reported error specifically concerns the Podman service not running, so this action leaves the actual problem unresolved.
- ✗
Set `container_runtime=podman` in the inventory and rerun `setup.sh`
Why it's wrong here
The container runtime variable is not the issue; Podman is already the runtime, and the binary is installed. The problem is that the Podman API socket service is not active. Setting the runtime variable again does not start the socket, so the installer would fail the same way on the next run.
- ✗
Install the `docker-ce` package and configure the installer to use Docker instead of Podman
Why it's wrong here
AAP 2.4 containerized deployments are built around Podman on RHEL. Switching to Docker is not a supported configuration and would require changes the installer does not provide. The failure is a missing service, not an unsupported container runtime, so replacing Podman does not address the root cause.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX294 question from scratch — 392 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Red Hat exam blueprint
This EX294 practice question is part of Courseiva's free Red Hat certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the EX294 exam.