Zertifizierungen

RHCE über die EX294: eine reine Ansible-Prüfung

Die EX294 prüft fast nur Ansible: Wer Playbooks, Rollen und Variablen sicher schreibt, besteht, wer mit RHCSA-Wissen allein antritt, fällt trotz solider Linux-Grundlagen durch.

6 Kapitel mit allen Befehlen
IT-Fachkraft bereitet sich mit Laptop und Notizen auf eine Zertifizierungsprüfung vor
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum der Weg zum RHCE so oft falsch geplant wird

Viele Admins kennen den RHCE noch aus der Zeit, in der er ein breites Engineer-Examen mit Netzwerkdiensten, Webserver und Storage war. Seit RHEL 8 ist das nicht mehr so. Red Hat führt die EX294 inzwischen als Red Hat Certified Advanced System Administrator in Ansible Exam. Geprüft wird fast ausschließlich Automatisierung mit Ansible, dazu kommen grundlegende Git-Operationen und die Arbeit mit VS Code. Wer sich mit alten Prüfungszielen vorbereitet, lernt an der Sache vorbei.

Dazu kommt die Reihenfolge. Den Titel Red Hat Certified Engineer in Ansible vergibt Red Hat nur, wenn neben der EX294 auch die RHCSA vorliegt. Die RHCSA erwirbst du über die EX200, und dorthin führen entweder RH124 Red Hat System Administration I zusammen mit RH134 Red Hat System Administration II oder der komprimierte Rapid Track RH199 für Admins mit vorhandener Linux-Erfahrung. Ohne diesen Unterbau bringt dir eine bestandene EX294 nur den Red Hat Certified Advanced System Administrator in Ansible, aber keinen RHCE-Titel.

Der dritte typische Fehler betrifft die Vorbereitung selbst. Die EX294 ist eine reine Praxisprüfung am System ohne Multiple-Choice, und bewertet wird der Zustand der verwalteten Hosts am Ende, nicht der Weg dorthin. Playbooks, die nur einmal durchlaufen, aber beim zweiten Lauf Dinge kaputt machen oder von Hand nachgepflegte Konfiguration voraussetzen, fallen dabei durch. Wer Ansible bisher als Skript-Ersatz benutzt hat, muss sich an idempotente Module, saubere Variablenebenen und Rollen gewöhnen.

Miniatur-Szene: Prüfungstisch mit versiegeltem Zertifikat, Stempel, Handbüchern und einer Medaille
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Die Stufen vom Einstieg zum RHCE

  1. 01 RH124 und RH134 oder RH199
  2. 02 EX200 bestehen, RHCSA aktiv
  3. 03 AU294 Automation with Ansible
  4. 04 Playbooks, Rollen, Collections üben
  5. 05 EX294 als Praxisprüfung
  6. 06 RHCE in Ansible erreicht
Was du mitnimmst

So baust du den Pfad zum RHCE sinnvoll auf

Der Weg besteht aus zwei Stufen, die inhaltlich wenig miteinander zu tun haben. Zuerst die klassische Systemadministration bis zur RHCSA, danach die Automatisierung bis zur EX294. Bei cmt findest du beide Stufen im Programm, sodass du die Kurse in der passenden Reihenfolge und wahlweise vor Ort oder Live-Online belegen kannst.

Einstieg über RH124 und RH134 oder direkt RH199

Wenn du aus einer anderen Distribution kommst oder länger nicht mit RHEL gearbeitet hast, sind RH124 Red Hat System Administration I und RH134 Red Hat System Administration II der gründliche Weg. Bist du bereits als Linux-Admin im Tagesgeschäft, deckt der Rapid Track RH199 denselben Stoff in kompakterer Form ab.

RHCSA-Themen wirklich sitzen lassen

In der EX294 arbeitest du unter Zeitdruck auf mehreren Hosts. Wenn systemd-Units, SELinux-Kontexte, LVM, Benutzer- und Rechteverwaltung sowie firewalld nicht ohne Nachdenken funktionieren, kostet dich das Zeit, die du für die Automatisierung brauchst.

Automatisierung mit AU294 aufbauen

AU294 Red Hat Enterprise Linux Automation with Ansible ist der offizielle Kurs zur Prüfung. Dort geht es um Inventories, ansible.cfg, Tasks und Handler, Variablen und Facts, Templates mit Jinja2, Rollen und Ansible Content Collections sowie um die mitgelieferten RHEL System Roles.

Idempotenz und Fehlerbehandlung üben

Schreibe deine Playbooks so, dass ein zweiter Lauf keine Änderungen mehr meldet. Nutze passende Module statt command und shell, setze creates oder changed_when bewusst ein und arbeite mit blocks, rescue und failed_when, wenn ein Schritt fehlschlagen darf.

Secrets und Zielauswahl beherrschen

Ansible Vault für verschlüsselte Variablen, Host- und Gruppenvariablen an der richtigen Stelle sowie saubere Muster für die Auswahl der Zielhosts gehören zum Prüfungsstoff und ersparen dir im Betrieb später viel Aufräumarbeit.

Nach der Prüfung im Betrieb weiterdenken

Wenn der Titel steht, beginnt die eigentliche Arbeit an einer wartbaren Automatisierung. Kurse wie der Ansible Kompaktkurs oder Ansible für Fortgeschrittene helfen dir, gewachsene Playbook-Sammlungen in Rollen, Collections und eine nachvollziehbare Struktur zu überführen.

Tutorial

Übungsumgebung aufbauen, Handgriffe drillen, Prüfung simulieren

Die EX294 ist eine praktische Prüfung, also übst du praktisch. Der Ablauf hier baut zuerst ein Labor mit Steuerknoten und verwalteten Systemen, richtet dann das Projektlayout ein, drillt die Module und Fehlerbehandlung und endet mit einer Simulation unter Zeitdruck. Alle Beispiele laufen mit ansible-core auf einem RHEL-Derivat.

01

Schritt 1: Labor aufbauen, so wie es in der Prüfung aussieht

Ein Steuerknoten und vier verwaltete Systeme reichen, um jede Aufgabenart abzudecken: Gruppen, Ausnahmen pro Host, ein System mit abweichender Rolle.

Steuerknoten und Zugang einrichten
sudo dnf install -y ansible-core
ansible --version

# Auf jedem verwalteten Knoten denselben Automatisierungsnutzer
sudo useradd -m devops
echo 'devops ALL=(ALL) NOPASSWD: ALL' | sudo tee /etc/sudoers.d/devops
sudo chmod 0440 /etc/sudoers.d/devops
sudo visudo -c                              # Syntaxprüfung, sonst sperrst du dich aus

# Vom Steuerknoten aus Schlüssel verteilen
ssh-keygen -t ed25519 -N '' -f ~/.ssh/id_ed25519
for h in node1 node2 node3 node4; do ssh-copy-id devops@$h; done

visudo -c prüft alle Dateien unter /etc/sudoers.d/ mit. Eine kaputte Zeile dort kostet dich im Labor eine Neuinstallation und in der Prüfung die Aufgabe.

02

Schritt 2: Projektlayout, das dir Zeit spart

In der Prüfung zählt jede Minute. Ein Projektverzeichnis mit eigener Konfiguration erspart dir bei jedem Aufruf mehrere Optionen auf der Kommandozeile.

ansible.cfg im Projektverzeichnis
[defaults]
inventory         = ./inventory
remote_user       = devops
host_key_checking = False
roles_path        = ./roles
collections_path  = ./collections
callback_result_format = yaml

[privilege_escalation]
become          = True
become_method   = sudo
become_user     = root
become_ask_pass = False

Mit diesen Werten reicht später ansible-playbook site.yml ohne weitere Optionen. callback_result_format = yaml gibt Ergebnisse und Fehlermeldungen lesbar als YAML aus, das spart beim Suchen mehr Zeit, als es klingt. Die früher übliche Zeile stdout_callback = yaml setzt die Collection community.general voraus, die eine reine ansible-core-Installation nicht mitbringt.

inventory mit Gruppen und Untergruppen
[dev]
node1

[prod]
node[2:3]

[balancers]
node4

[webservers:children]
dev
prod

[webservers:vars]
http_port=80

Die Bereichsschreibweise node[2:3] und der Abschnitt :children sind Prüfungsstoff, weil Aufgaben regelmäßig genau so formuliert sind. Gruppenvariablen gehören auf Dauer nach group_vars/, für ein kleines Inventar ist der Abschnitt aber schneller.

Gegenprobe
ansible --version | grep 'config file'
ansible all -m ansible.builtin.ping
ansible all -m ansible.builtin.setup -a 'filter=ansible_default_ipv4'
ansible webservers --list-hosts

Die vier Zeilen prüfen Konfiguration, Erreichbarkeit, Rechteausweitung und Gruppenauflösung in einem Rutsch. Wenn hier etwas klemmt, klemmt später jedes Playbook.

03

Schritt 3: Die Module drillen, die tatsächlich drankommen

In der Prüfung steht nur die mitgelieferte Dokumentation zur Verfügung, und ansible-doc ist darin dein wichtigstes Werkzeug. Wer sie flüssig bedient, gewinnt mehr Zeit als durch auswendig gelernte Optionen.

ansible-doc als Arbeitswerkzeug
ansible-doc -l | grep -i firewall
ansible-doc -s ansible.posix.firewalld       # nur die Optionen, ohne Prosa
ansible-doc ansible.builtin.user | tail -60  # Beispiele stehen am Ende
ansible-galaxy collection list               # was ist überhaupt installiert?

ansible-doc -s gibt dir ein fertiges Task-Gerüst zum Kopieren. Das ist der schnellste Weg von der Aufgabenstellung zum lauffähigen Task, und er funktioniert auch für Module, die du noch nie benutzt hast.

Aufgabentyp, Modul, häufigster Fehler

AufgabenstellungModulStolperstelle
Pakete installierenansible.builtin.dnfstate: latest meldet bei jedem Update changed, für reproduzierbare Läufe nimmst du present
Dienste betreibenansible.builtin.service, systemdstate: started und enabled: true beide setzen, sonst überlebt der Dienst den Reboot nicht
Dateien aus Vorlagenansible.builtin.templateBesitzer, Modus und SELinux-Kontext mitgeben, sonst startet der Dienst mit Zugriffsfehler
Firewallansible.posix.firewalldpermanent: true und immediate: true zusammen, sonst wirkt es erst nach dem Neustart
Nutzer und Gruppenansible.builtin.user, groupPasswörter über den Filter password_hash, niemals im Klartext
SELinuxansible.posix.seboolean, sefcontextNach sefcontext braucht es ein restorecon, sonst bleibt der alte Kontext stehen
Speichercommunity.general.parted, lvol, filesystemReihenfolge einhalten: Partition, Volume, Dateisystem, dann Einhängepunkt
Zeitgesteuerte Aufgabenansible.builtin.cronOhne name legt jeder Lauf einen weiteren Eintrag an
04

Schritt 4: Idempotenz und Fehlerbehandlung üben

Ein Playbook, das beim zweiten Lauf noch Änderungen meldet, ist nicht fertig. Das ist gleichzeitig das Kriterium, an dem sich in der Prüfung entscheidet, ob eine Aufgabe wirklich gelöst ist.

Der Zweitlauf ist die Prüfung
ansible-playbook site.yml --syntax-check
ansible-playbook site.yml --check --diff
ansible-playbook site.yml                    # erster Lauf
ansible-playbook site.yml                    # zweiter Lauf: changed=0 ist das Ziel

--check --diff zeigt dir vorab, was sich ändern würde, inklusive Dateiinhalt. Nicht jedes Modul unterstützt den Prüfmodus vollständig, für Dateien, Pakete und Dienste funktioniert er zuverlässig.

Die drei Muster, die immer gebraucht werden
- name: Zertifikat nur einmal erzeugen
  ansible.builtin.command:
    cmd: /usr/local/bin/mkcert.sh
    creates: /etc/pki/tls/certs/app.pem

- name: Zustand prüfen, ohne changed zu melden
  ansible.builtin.command: systemctl is-enabled nginx
  register: nginx_enabled
  changed_when: false
  failed_when: nginx_enabled.rc not in [0, 1]

- name: Umbau mit Rückweg
  block:
    - name: Neue Konfiguration ausrollen
      ansible.builtin.template:
        src: app.conf.j2
        dest: /etc/app/app.conf
        owner: root
        mode: '0644'
    - name: Dienst neu starten
      ansible.builtin.service:
        name: app
        state: restarted
  rescue:
    - name: Alte Konfiguration zurücklegen
      ansible.builtin.copy:
        src: /etc/app/app.conf.bak
        dest: /etc/app/app.conf
        remote_src: true
  always:
    - name: Dienst muss laufen
      ansible.builtin.service:
        name: app
        state: started

creates macht aus einem beliebigen Befehl einen idempotenten Task. changed_when: false gehört an jeden reinen Prüfbefehl. block/rescue/always ist der einzige eingebaute Rückweg, den Ansible kennt, und er kommt in Aufgaben zur Fehlerbehandlung regelmäßig vor.

05

Schritt 5: Vault und Rollen sicher bedienen

Verschlüsselte Variablen und die Arbeit mit fertigen Rollen sind eigene Aufgabenblöcke. Beides ist schnell gelernt und wird oft zu spät geübt.

Ansible Vault im Alltag
ansible-vault create group_vars/prod/vault.yml
ansible-vault encrypt_string 'GeheimesPasswort' --name 'vault_db_password'
ansible-vault view group_vars/prod/vault.yml
ansible-vault rekey group_vars/prod/vault.yml

echo 'meinvaultpasswort' > ~/.vault-pass && chmod 600 ~/.vault-pass
ansible-playbook site.yml --vault-password-file ~/.vault-pass
# Dauerhaft in ansible.cfg:  vault_password_file = ~/.vault-pass

Übliche Praxis: In der verschlüsselten Datei heißen die Variablen vault_db_password, in einer unverschlüsselten Datei setzt du db_password: "{{ vault_db_password }}". So kannst du weiter nach Variablennamen suchen, ohne die Datei jedes Mal zu entschlüsseln.

Rollen anlegen und mitgelieferte Rollen nutzen
ansible-galaxy init roles/webserver
find roles/webserver -maxdepth 2 -type d

# Mitgelieferte Systemrollen auf RHEL / Rocky / Alma
sudo dnf install -y rhel-system-roles
ls /usr/share/ansible/roles/
ls /usr/share/doc/rhel-system-roles/timesync/

# Debian / Ubuntu und alles ohne RHEL-Paket
ansible-galaxy collection install fedora.linux_system_roles

Zu jeder mitgelieferten Systemrolle liegt unter /usr/share/doc/rhel-system-roles/ ein Beispiel-Playbook. Das zu kennen ist in der Prüfung mehr wert als jede Rolle auswendig zu können, weil du damit in zwei Minuten ein lauffähiges Playbook hast.

06

Schritt 6: Prüfung simulieren, inklusive Reboot

Die letzte Übung ist ein Durchlauf unter Bedingungen, die der Prüfung entsprechen. Der wichtigste Teil daran ist der Neustart am Ende.

Der Abschlusstest
# Alle Knoten neu starten
ansible all -b -m ansible.builtin.reboot

# Überlebt der gebaute Zustand den Reboot?
ansible all -b -m ansible.builtin.shell -a 'systemctl --failed --no-legend'
ansible all -b -m ansible.builtin.shell -a 'findmnt --verify'
ansible all -b -m ansible.builtin.shell -a 'firewall-cmd --list-all'

# Und noch einmal alles durchlaufen lassen
ansible-playbook site.yml

findmnt --verify prüft die /etc/fstab gegen die vorhandenen Geräte. Ein Einhängepunkt, den du nur mit mount gesetzt hast, fällt hier auf, bevor er dich Punkte kostet.

Regeln für die Simulation

  • Der ganze Durchlauf am Stück, ohne Pause und ohne Nachschlagen im NetzNur unter Zeitdruck merkst du, welche Handgriffe noch nicht sitzen. Wer entspannt übt, übt an der Prüfungssituation vorbei.
  • Alle Knoten am Ende neu starten und erneut prüfenWas den Neustart nicht überlebt, zählt nicht. Fehlendes enabled: true und fehlende fstab-Einträge sind die häufigsten Punktverluste überhaupt.
  • Nur ansible-doc und die lokal installierte Dokumentation als NachschlagewerkGenau das steht in der Prüfung zur Verfügung. Wer daran gewöhnt ist, verliert keine Zeit mit Suchen.
  • Unabhängige Aufgaben zuerst lösenAufgaben, die aufeinander aufbauen, blockieren dich, wenn eine davon klemmt. Die Reihenfolge auf dem Blatt ist keine Empfehlung.
  • Am Ende alle Playbooks noch einmal komplett laufen lassenDer Schlusslauf muss fehlerfrei durchgehen und möglichst changed=0 melden. Damit fängst du ab, dass eine spätere Aufgabe eine frühere wieder kaputtgemacht hat.
Standortbestimmung

Bist du schon prüfungsreif?

Bevor du Geld und Urlaubstage in eine Prüfung steckst, finde in wenigen Minuten heraus, wo du wirklich stehst. Der Test ist kostenlos, braucht keine Anmeldung und erklärt jede Antwort.

Aus unseren Kursen

Was Teilnehmende über unsere IT-Kurse sagen

Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Rückmeldung aus dem Kurs „SELinux Training: Grundlagen und Administration (SEL1)“
Gut zu wissen

Häufige Fragen zu RHCE-Zertifizierung EX294

Ist deine Frage nicht dabei? Ruf an oder schreib uns, du sprichst direkt mit jemandem aus der Kursberatung.

Frag uns direkt
Kann ich die EX294 ohne RHCSA ablegen?
Ablegen kannst du die Prüfung, sie bringt dir dann den Red Hat Certified Advanced System Administrator in Ansible. Den Titel Red Hat Certified Engineer in Ansible vergibt Red Hat aber erst, wenn auch die RHCSA vorliegt. Sinnvoll ist deshalb, zuerst die EX200 zu bestehen und danach die Automatisierungsprüfung anzugehen.
Was wird in der EX294 konkret geprüft?
Geprüft wird die Automatisierung von RHEL-Systemen mit Ansible. Dazu gehören die Installation und Konfiguration der Steuerungsumgebung, Inventories, Playbooks mit Tasks, Handlern und Variablen, Templates mit Jinja2, Rollen und Content Collections, Ansible Vault, grundlegende Git-Operationen und die Arbeit mit VS Code sowie die Verwaltung typischer Systemaufgaben über passende Module. Alles läuft praktisch am System, es gibt keine Multiple-Choice-Fragen.
Welcher Kurs bereitet auf die EX294 vor?
Der offizielle Vorbereitungskurs ist AU294 Red Hat Enterprise Linux Automation with Ansible. Er baut auf den RHCSA-Inhalten auf und deckt die Prüfungsziele ab. Ein allgemeiner Ansible-Kurs vermittelt zwar dieselben Grundmechanismen, orientiert sich aber nicht am Prüfungsumfang und an der Red-Hat-spezifischen Umgebung.
Wie lange bleibt der RHCE gültig?
Red Hat-Zertifizierungen haben eine begrenzte Laufzeit von üblicherweise drei Jahren. Du verlängerst sie, indem du eine aktuellere Prüfung derselben Linie oder eine anerkannte weiterführende Prüfung ablegst. Da der RHCE eine aktive RHCSA voraussetzt, solltest du beide Laufzeiten im Blick behalten.
Lohnt sich der RHCE, wenn wir gar kein RHEL einsetzen?
Wenn in deiner Umgebung weder RHEL noch ein naher Abkömmling läuft, ist der Titel selbst wenig wert, die Ansible-Kenntnisse dagegen schon. In dem Fall ist ein herstellerneutraler Ansible-Kurs die ehrlichere Wahl. Setzt ihr RHEL produktiv ein oder arbeitet ihr im Red-Hat-Umfeld mit Kunden, ist der RHCE ein belastbarer Nachweis und oft ein Ausschreibungskriterium.

Zuletzt geprüft am 05. Oktober 2026.

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Plane deinen Weg zum RHCE mit uns

Sag uns, wo du gerade stehst, und wir ordnen die Kurse für dich: Einstieg über RH124 und RH134, der Rapid Track RH199 oder direkt AU294, wenn die RHCSA schon steht. Alle Termine gibt es vor Ort und Live-Online, auf Wunsch auch als Inhouse-Schulung für dein Team.