Zertifizierungen

RHCE mit der EX294: dein Weg vom RHCSA zur Ansible-Automatisierung

Der RHCE ist heute eine reine Ansible-Prüfung, nichts anderes. Wer Playbooks, Rollen und Variablen sicher schreibt, besteht. Wer nur RHCSA-Wissen mitbringt und Ansible überfliegt, fällt durch, egal wie gut die Linux-Grundlagen sitzen.

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. Die EX294 heißt Red Hat Certified Engineer exam for Red Hat Enterprise Linux und prüft praktisch ausschließlich Automatisierung mit Ansible. Wer sich mit alten Prüfungszielen vorbereitet, lernt an der Sache vorbei.

Dazu kommt die Reihenfolge. Red Hat vergibt den RHCE nur, wenn zum Zeitpunkt der bestandenen EX294 eine aktive 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 eine bestandene EX294 zwar Punkte, 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 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                              # Syntaxpruefung, sonst sperrst du dich aus

# Vom Steuerknoten aus Schluessel 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
stdout_callback   = 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. stdout_callback = yaml macht Fehlermeldungen lesbar, das spart beim Suchen mehr Zeit, als es klingt.

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 ist ansible-doc die einzige Dokumentation, und sie reicht vollständig aus. 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 ueberhaupt 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, systemdenabled und state getrennt 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 pruefen, 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 Rueckweg
  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 zuruecklegen
      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

# Ueberlebt 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 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. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Gut zu wissen

Häufige Fragen zu RHCE-Zertifizierung EX294

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Kann ich die EX294 ohne RHCSA ablegen?
Ablegen kannst du die Prüfung, den RHCE-Titel bekommst du damit aber nicht. Red Hat vergibt den RHCE nur, wenn zum Zeitpunkt der bestandenen EX294 eine gültige 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 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 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Die Schulung war genau das richtige, um mein Verständnis zu erweitern. Vielen Dank an den Trainer!
Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“
Trainer gut und verständlich. Unterlagen nur zum lesen (keine Kopierfunktion). Wissenstransfer erfolgreich.
Rückmeldung aus dem Kurs „SUSE Linux Enterprise 15 High Availability Deployment – HAE311v15“
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.