Offizielle Zertifizierungen: Ansible
Stand: 15. Juli 2026
Quelle: https://www.redhat.com/en/services/certifications
Dieses Dokument ordnet den Workshop zu offiziellen Red-Hat-Zertifizierungspfaden ein. Es erfindet keine Prüfungen und kopiert keine echten Prüfungsfragen.
1. Offizielle Quelle
Vertiefung und Abgabebeispiel zu Offizielle Quelle
Eine vollständige Bearbeitung von Offizielle Quelle besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.
| Abgabeteil | Inhalt | Mindestqualität |
|---|---|---|
| Zielbeschreibung | Was soll nach dem Lauf gelten? | messbar und ohne implizite Annahmen |
| Scope-Nachweis | Welche Hosts sind betroffen? | Ausgabe von --list-hosts oder Inventory-Graph |
| Umsetzung | Welche Dateien wurden geändert? | kleine, reviewbare YAML-Dateien |
| Validierung | Wie wurde geprüft? | Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf |
| Risikoentscheidung | Was kann schiefgehen? | Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet |
Minimalartefakte für Offizielle Quelle
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
Für Rollen oder Collections wird die Struktur erweitert:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Prüferwartung für Offizielle Quelle
Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.
Transfer in reale Teams
Im Teamkontext wird Offizielle Quelle zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.
Praxisbezug zu Offizielle Quelle
Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Offizielle Quelle immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.
| Prüffrage | Erwartete Antwort |
|---|---|
| Welche Hosts sind betroffen? | Pattern, Gruppe, --limit und Inventory-Ausgabe sind dokumentiert. |
| Welche Datenquellen wirken? | group_vars, host_vars, Defaults, Extra Vars und Facts sind bekannt. |
| Welche Rechte werden benötigt? | become ist tasknah und fachlich begründet. |
| Wie wird Erfolg bewiesen? | Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor. |
Beispielablauf für Offizielle Quelle
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.
Review-Kriterien für Offizielle Quelle
- Inventory und Pattern sind enger als
all, sofern kein guter Grund dokumentiert ist. - Module aus
ansible.builtinoder klar geprüften Collections werden bevorzugt. - Shell- oder Command-Tasks haben
changed_when,failed_whenoder eine Begründung. - Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
- Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
- Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
- Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.
Typische Fehler bei Offizielle Quelle
| Fehlerbild | Ursache | Diagnose |
|---|---|---|
| falsche Hosts getroffen | Pattern oder Inventory falsch verstanden | --list-hosts, ansible-inventory --host |
unreachable |
SSH, Benutzer, Python oder Netzwerkproblem | -vvvv, SSH-Test, Inventory-Variablen |
| unerwartete Änderung | Modul nicht idempotent oder falsche Datenquelle | zweiter Lauf, Diff, Variablenprüfung |
| Secret-Leak | Debug, Diff oder Log nicht begrenzt | no_log, Vault, CI-Artefakte prüfen |
| Handler läuft nicht | kein changed oder falscher Handlername |
Task-Ergebnis und Handler-Name prüfen |
Betriebsnotiz für Offizielle Quelle
Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.
Die verbindliche Quelle ist die Red Hat Zertifizierungsseite. Dort werden Level, Voraussetzungen, Exams und Pfade gepflegt.
2. Aktuelle Ansible-bezogene Pfade
Vertiefung und Abgabebeispiel zu Aktuelle Ansible-bezogene Pfade
Eine vollständige Bearbeitung von Aktuelle Ansible-bezogene Pfade besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.
| Abgabeteil | Inhalt | Mindestqualität |
|---|---|---|
| Zielbeschreibung | Was soll nach dem Lauf gelten? | messbar und ohne implizite Annahmen |
| Scope-Nachweis | Welche Hosts sind betroffen? | Ausgabe von --list-hosts oder Inventory-Graph |
| Umsetzung | Welche Dateien wurden geändert? | kleine, reviewbare YAML-Dateien |
| Validierung | Wie wurde geprüft? | Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf |
| Risikoentscheidung | Was kann schiefgehen? | Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet |
Minimalartefakte für Aktuelle Ansible-bezogene Pfade
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
Für Rollen oder Collections wird die Struktur erweitert:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Prüferwartung für Aktuelle Ansible-bezogene Pfade
Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.
Transfer in reale Teams
Im Teamkontext wird Aktuelle Ansible-bezogene Pfade zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.
Praxisbezug zu Aktuelle Ansible-bezogene Pfade
Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Aktuelle Ansible-bezogene Pfade immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.
| Prüffrage | Erwartete Antwort |
|---|---|
| Welche Hosts sind betroffen? | Pattern, Gruppe, --limit und Inventory-Ausgabe sind dokumentiert. |
| Welche Datenquellen wirken? | group_vars, host_vars, Defaults, Extra Vars und Facts sind bekannt. |
| Welche Rechte werden benötigt? | become ist tasknah und fachlich begründet. |
| Wie wird Erfolg bewiesen? | Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor. |
Beispielablauf für Aktuelle Ansible-bezogene Pfade
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.
Review-Kriterien für Aktuelle Ansible-bezogene Pfade
- Inventory und Pattern sind enger als
all, sofern kein guter Grund dokumentiert ist. - Module aus
ansible.builtinoder klar geprüften Collections werden bevorzugt. - Shell- oder Command-Tasks haben
changed_when,failed_whenoder eine Begründung. - Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
- Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
- Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
- Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.
Typische Fehler bei Aktuelle Ansible-bezogene Pfade
| Fehlerbild | Ursache | Diagnose |
|---|---|---|
| falsche Hosts getroffen | Pattern oder Inventory falsch verstanden | --list-hosts, ansible-inventory --host |
unreachable |
SSH, Benutzer, Python oder Netzwerkproblem | -vvvv, SSH-Test, Inventory-Variablen |
| unerwartete Änderung | Modul nicht idempotent oder falsche Datenquelle | zweiter Lauf, Diff, Variablenprüfung |
| Secret-Leak | Debug, Diff oder Log nicht begrenzt | no_log, Vault, CI-Artefakte prüfen |
| Handler läuft nicht | kein changed oder falscher Handlername |
Task-Ergebnis und Handler-Name prüfen |
Betriebsnotiz für Aktuelle Ansible-bezogene Pfade
Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.
Die Red Hat Seite nennt für Ansible unter anderem:
| Pfad | Anforderungen laut offizieller Seite |
|---|---|
| Red Hat Certified Systems Administrator im Ansible-Pfad | EX200: Red Hat Certified System Administrator exam |
| Red Hat Certified Engineer in Ansible | EX200 und EX294: Red Hat Certified Advanced System Administrator in Ansible exam |
| Ansible Specialist | EX374, EX417, EX457 oder EX467 |
| Red Hat Certified Architect in Ansible | EX200, EX294 und mindestens drei Specialist-Prüfungen aus dem Ansible-Bereich |
Genannte Specialist-Prüfungen:
- EX374: Red Hat Certified Specialist in Developing Automation with Ansible Automation Platform exam
- EX417: Red Hat Certified Specialist in Microsoft Windows Automation with Ansible exam
- EX457: Red Hat Certified Specialist in Ansible Network Automation exam
- EX467: Red Hat Certified Specialist in Managing Automation with Ansible Automation Platform exam
3. Workshop-Mapping
Vertiefung und Abgabebeispiel zu Workshop-Mapping
Eine vollständige Bearbeitung von Workshop-Mapping besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.
| Abgabeteil | Inhalt | Mindestqualität |
|---|---|---|
| Zielbeschreibung | Was soll nach dem Lauf gelten? | messbar und ohne implizite Annahmen |
| Scope-Nachweis | Welche Hosts sind betroffen? | Ausgabe von --list-hosts oder Inventory-Graph |
| Umsetzung | Welche Dateien wurden geändert? | kleine, reviewbare YAML-Dateien |
| Validierung | Wie wurde geprüft? | Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf |
| Risikoentscheidung | Was kann schiefgehen? | Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet |
Minimalartefakte für Workshop-Mapping
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
Für Rollen oder Collections wird die Struktur erweitert:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Prüferwartung für Workshop-Mapping
Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.
Transfer in reale Teams
Im Teamkontext wird Workshop-Mapping zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.
Praxisbezug zu Workshop-Mapping
Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Workshop-Mapping immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.
| Prüffrage | Erwartete Antwort |
|---|---|
| Welche Hosts sind betroffen? | Pattern, Gruppe, --limit und Inventory-Ausgabe sind dokumentiert. |
| Welche Datenquellen wirken? | group_vars, host_vars, Defaults, Extra Vars und Facts sind bekannt. |
| Welche Rechte werden benötigt? | become ist tasknah und fachlich begründet. |
| Wie wird Erfolg bewiesen? | Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor. |
Beispielablauf für Workshop-Mapping
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.
Review-Kriterien für Workshop-Mapping
- Inventory und Pattern sind enger als
all, sofern kein guter Grund dokumentiert ist. - Module aus
ansible.builtinoder klar geprüften Collections werden bevorzugt. - Shell- oder Command-Tasks haben
changed_when,failed_whenoder eine Begründung. - Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
- Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
- Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
- Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.
Typische Fehler bei Workshop-Mapping
| Fehlerbild | Ursache | Diagnose |
|---|---|---|
| falsche Hosts getroffen | Pattern oder Inventory falsch verstanden | --list-hosts, ansible-inventory --host |
unreachable |
SSH, Benutzer, Python oder Netzwerkproblem | -vvvv, SSH-Test, Inventory-Variablen |
| unerwartete Änderung | Modul nicht idempotent oder falsche Datenquelle | zweiter Lauf, Diff, Variablenprüfung |
| Secret-Leak | Debug, Diff oder Log nicht begrenzt | no_log, Vault, CI-Artefakte prüfen |
| Handler läuft nicht | kein changed oder falscher Handlername |
Task-Ergebnis und Handler-Name prüfen |
Betriebsnotiz für Workshop-Mapping
Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.
| Workshop-Bereich | Relevante Kompetenzen |
|---|---|
| Fundamentals | Inventory, Playbooks, Module, Idempotenz, Diagnose |
| Intermediate | Variablen, Facts, Templates, Rollen, Includes, Vault-Grundlagen |
| Professional | Collections, CI, Orchestrierung, mehrere Inventories, Controller-/AWX-Einordnung |
| Advanced + Security | Least Privilege, Secret-Flows, Supply Chain, Execution Environments, Security Review |
4. Vorbereitung ohne Prüfungsfragen
Vertiefung und Abgabebeispiel zu Vorbereitung ohne Prüfungsfragen
Eine vollständige Bearbeitung von Vorbereitung ohne Prüfungsfragen besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.
| Abgabeteil | Inhalt | Mindestqualität |
|---|---|---|
| Zielbeschreibung | Was soll nach dem Lauf gelten? | messbar und ohne implizite Annahmen |
| Scope-Nachweis | Welche Hosts sind betroffen? | Ausgabe von --list-hosts oder Inventory-Graph |
| Umsetzung | Welche Dateien wurden geändert? | kleine, reviewbare YAML-Dateien |
| Validierung | Wie wurde geprüft? | Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf |
| Risikoentscheidung | Was kann schiefgehen? | Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet |
Minimalartefakte für Vorbereitung ohne Prüfungsfragen
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
Für Rollen oder Collections wird die Struktur erweitert:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Prüferwartung für Vorbereitung ohne Prüfungsfragen
Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.
Transfer in reale Teams
Im Teamkontext wird Vorbereitung ohne Prüfungsfragen zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.
Praxisbezug zu Vorbereitung ohne Prüfungsfragen
Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Vorbereitung ohne Prüfungsfragen immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.
| Prüffrage | Erwartete Antwort |
|---|---|
| Welche Hosts sind betroffen? | Pattern, Gruppe, --limit und Inventory-Ausgabe sind dokumentiert. |
| Welche Datenquellen wirken? | group_vars, host_vars, Defaults, Extra Vars und Facts sind bekannt. |
| Welche Rechte werden benötigt? | become ist tasknah und fachlich begründet. |
| Wie wird Erfolg bewiesen? | Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor. |
Beispielablauf für Vorbereitung ohne Prüfungsfragen
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.
Review-Kriterien für Vorbereitung ohne Prüfungsfragen
- Inventory und Pattern sind enger als
all, sofern kein guter Grund dokumentiert ist. - Module aus
ansible.builtinoder klar geprüften Collections werden bevorzugt. - Shell- oder Command-Tasks haben
changed_when,failed_whenoder eine Begründung. - Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
- Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
- Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
- Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.
Typische Fehler bei Vorbereitung ohne Prüfungsfragen
| Fehlerbild | Ursache | Diagnose |
|---|---|---|
| falsche Hosts getroffen | Pattern oder Inventory falsch verstanden | --list-hosts, ansible-inventory --host |
unreachable |
SSH, Benutzer, Python oder Netzwerkproblem | -vvvv, SSH-Test, Inventory-Variablen |
| unerwartete Änderung | Modul nicht idempotent oder falsche Datenquelle | zweiter Lauf, Diff, Variablenprüfung |
| Secret-Leak | Debug, Diff oder Log nicht begrenzt | no_log, Vault, CI-Artefakte prüfen |
| Handler läuft nicht | kein changed oder falscher Handlername |
Task-Ergebnis und Handler-Name prüfen |
Betriebsnotiz für Vorbereitung ohne Prüfungsfragen
Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.
Der Workshop bereitet über Konzepte, Labs und Reviewfähigkeit vor. Er enthält keine echten Prüfungsfragen. Gute Vorbereitung bedeutet, Aufgaben selbst auszuführen, Fehler zu analysieren und Evidence sauber zu dokumentieren.
5. Grenzen
Vertiefung und Abgabebeispiel zu Grenzen
Eine vollständige Bearbeitung von Grenzen besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.
| Abgabeteil | Inhalt | Mindestqualität |
|---|---|---|
| Zielbeschreibung | Was soll nach dem Lauf gelten? | messbar und ohne implizite Annahmen |
| Scope-Nachweis | Welche Hosts sind betroffen? | Ausgabe von --list-hosts oder Inventory-Graph |
| Umsetzung | Welche Dateien wurden geändert? | kleine, reviewbare YAML-Dateien |
| Validierung | Wie wurde geprüft? | Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf |
| Risikoentscheidung | Was kann schiefgehen? | Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet |
Minimalartefakte für Grenzen
submission/
inventory/hosts.yml
playbooks/site.yml
evidence.md
cleanup.md
Für Rollen oder Collections wird die Struktur erweitert:
submission/
ansible.cfg
collections/requirements.yml
inventory/hosts.yml
roles/<role>/defaults/main.yml
roles/<role>/tasks/main.yml
roles/<role>/handlers/main.yml
playbooks/site.yml
evidence.md
Prüferwartung für Grenzen
Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.
Transfer in reale Teams
Im Teamkontext wird Grenzen zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.
Praxisbezug zu Grenzen
Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Grenzen immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.
| Prüffrage | Erwartete Antwort |
|---|---|
| Welche Hosts sind betroffen? | Pattern, Gruppe, --limit und Inventory-Ausgabe sind dokumentiert. |
| Welche Datenquellen wirken? | group_vars, host_vars, Defaults, Extra Vars und Facts sind bekannt. |
| Welche Rechte werden benötigt? | become ist tasknah und fachlich begründet. |
| Wie wird Erfolg bewiesen? | Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor. |
Beispielablauf für Grenzen
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --list-hosts
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
ansible-playbook -i inventory/hosts.yml playbooks/site.yml
Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.
Review-Kriterien für Grenzen
- Inventory und Pattern sind enger als
all, sofern kein guter Grund dokumentiert ist. - Module aus
ansible.builtinoder klar geprüften Collections werden bevorzugt. - Shell- oder Command-Tasks haben
changed_when,failed_whenoder eine Begründung. - Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
- Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
- Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
- Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.
Typische Fehler bei Grenzen
| Fehlerbild | Ursache | Diagnose |
|---|---|---|
| falsche Hosts getroffen | Pattern oder Inventory falsch verstanden | --list-hosts, ansible-inventory --host |
unreachable |
SSH, Benutzer, Python oder Netzwerkproblem | -vvvv, SSH-Test, Inventory-Variablen |
| unerwartete Änderung | Modul nicht idempotent oder falsche Datenquelle | zweiter Lauf, Diff, Variablenprüfung |
| Secret-Leak | Debug, Diff oder Log nicht begrenzt | no_log, Vault, CI-Artefakte prüfen |
| Handler läuft nicht | kein changed oder falscher Handlername |
Task-Ergebnis und Handler-Name prüfen |
Betriebsnotiz für Grenzen
Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.
Vor Buchung immer die offizielle Seite prüfen, weil Namen, Versionen, Pfade und Blueprints geändert werden können.