Im Mai 2025 habe ich die GitHub-Actions-Zertifizierung – die Prüfung GH-200 – abgelegt und bestanden. Ich möchte ehrlich darüber schreiben, denn eine Zertifizierung ist nur so interessant wie die Arbeit dahinter. Für uns bei ThreeBIT ist GitHub Actions kein Schlagwort auf einer Folie. Es ist die Maschinerie, die fast alles, was wir ausliefern, baut, testet und deployt. Die Zertifizierung fühlte sich also weniger an wie das Sammeln eines Abzeichens, sondern eher wie eine formale Benotung der Technik, die ich jeden einzelnen Tag anfasse.
Was die GitHub-Actions-Zertifizierung ist
Die GitHub-Actions-Zertifizierung ist eines von fünf Credentials in GitHubs offiziellem Zertifizierungsprogramm – neben GitHub Foundations, GitHub Advanced Security, GitHub Administration und GitHub Copilot. Es ist eine spezialisierte, rollenbezogene Zertifizierung und keine breite „Einführung in Git"-Prüfung: Sie setzt voraus, dass man bereits in Repositories lebt und beweisen will, dass man die Arbeit rundherum automatisieren kann.
GitHub beschreibt das Credential als Nachweis von Kompetenz im „Automatisieren von Workflows und Beschleunigen der Entwicklung mit GitHub Actions". Auf der Prüfungsseite trägt es den Code GH-200, und die Prüfung selbst wird über Pearson VUE ausgeliefert – beaufsichtigt, geplant über ein Microsoft-Learn-Konto und in mehreren Sprachen angeboten, darunter Englisch, Spanisch, Portugiesisch (Brasilien), Koreanisch und Japanisch. Man hat 100 Minuten Zeit, und nach bestandener Prüfung erhält man ein digitales Badge sowie ein verifizierbares Zertifikat.
Die offizielle Zielgruppenbeschreibung ist erfreulich konkret: Sie richtet sich an DevOps-Engineers, Softwareentwicklerinnen und IT-Fachleute mit mittlerer Erfahrung in GitHub Actions – Menschen, die bereits Workflows erstellen, Dinge automatisieren und CI/CD-Pipelines verwalten und das formalisieren wollen. Diese Beschreibung passt fast wörtlich auf meine Arbeit, und das ist mit ein Grund, warum ich diese Prüfung gewählt habe und nicht eine allgemeinere Entwickler-Zertifizierung.
Was sie wirklich zertifiziert
Das ist der entscheidende Teil, denn der Name „GitHub Actions" verkauft den Umfang unter Wert. Die Prüfung fragt nicht nur, ob man ein YAML-Snippet in einen .github/workflows-Ordner kopieren kann. Laut den offiziell gemessenen Fähigkeiten prüft sie fünf Bereiche:
- Workflows erstellen und verwalten – Workflows von Grund auf schreiben: Trigger und Events, Jobs und Steps, Matrizen, bedingte Ausführung, wiederverwendbare Workflows – und all das über die Zeit wartbar halten, statt es zu Copy-Paste-Wildwuchs verkommen zu lassen.
- Workflows nutzen und Fehler beheben – Workflows verwenden, die andere geschrieben haben, Logs lesen, Fehlschläge debuggen und verstehen, warum ein Lauf getan hat, was er getan hat. In der Praxis ist das die halbe Miete: Eine Pipeline, die undurchsichtig scheitert, ist schlimmer als gar keine Pipeline.
- Actions erstellen und pflegen – nicht nur Actions aus dem Marketplace konsumieren, sondern eigene bauen: Composite Actions, JavaScript-Actions, Container-Actions, sie versionieren und sie als richtige Software mit einem Lebenszyklus behandeln.
- GitHub Actions im Unternehmen verwalten – die Themen im Organisationsmaßstab: Runner-Gruppen, Richtlinien, das Teilen von Actions und Workflows über viele Repositories hinweg und das Kohärent-Halten einer ganzen Pipeline-Flotte, statt dass jedes Team dasselbe Rad neu erfindet.
- Automatisierung absichern und optimieren – Secrets und Environments, Security-Hardening, Runner-Entscheidungen (GitHub-gehostet versus selbst gehostet) und die Kosten- und Performance-Seite der Automatisierung, an die niemand denkt, bis die Minuten-Rechnung kommt.
Diesen letzten Block würde ich jedem ans Herz legen, der über diese Prüfung nachdenkt. Secrets-Verwaltung, Environment-Schutzregeln und die Entscheidung zwischen gehosteten und selbst gehosteten Runnern sind genau die Themen, die einen Workflow, der „auf meinem Rechner läuft", von einem trennen, dem man ein Produktions-Deployment anvertraut. Ein Workflow mit Schreibrechten, die er nicht braucht, oder ein selbst gehosteter Runner, der ungeprüften Pull Requests ausgesetzt ist, ist ein echtes Sicherheitsloch – und die Prüfung behandelt es als solches.
Das Ganze bildet den CI/CD-Lebenszyklus ab: Commit, Build, Test, Paketierung, Deployment. GitHub Actions ist die Orchestrierungsebene, die diese Stufen verbindet, und die Zertifizierung ist im Grunde ein strukturierter Weg, zu belegen, dass man diese Ebene von Anfang bis Ende versteht – einschließlich der Teile wie Runner und Sicherheit, die man gern ignoriert, bis sie einen einholen.
Warum ich mich überhaupt zertifiziert habe
Ich bin ehrlich: Ich brauchte kein Zertifikat, um meine Arbeit weiter zu machen. Die ehrlichen Gründe, die Prüfung abzulegen, sind etwas interessanter als „macht sich gut auf LinkedIn".
Der erste: Zertifizieren zwingt dazu, die Lücken zu füllen. Wenn man ein Werkzeug durch Benutzen gelernt hat, sammelt man blinde Flecken an – die Funktionen, nach denen man nie gegriffen hat, weil die erste Lösung schon gut genug war. Das Lernen für GH-200 brachte mich dazu, die Teile der Dokumentation zu lesen, die ich übersprungen hatte: die Feinheiten wiederverwendbarer Workflows, die Matrix-Strategien, die ich von Hand gebaut hatte, die Hardening-Hinweise, die ich nur halb kannte. Ich kam mit besseren Workflows heraus, und das ist mehr wert als das Abzeichen.
Der zweite Grund ist Vertrauen. Wir arbeiten mit Kunden in Branchen, in denen ein Bug kein kosmetischer Schönheitsfehler ist – sondern ein verpasster Export, eine fehlgeschlagene Zahlung, ein Compliance-Befund. Die Pipeline, die ihre Software baut und ausrollt, ist Teil dessen, was sie uns anvertrauen. Auf ein vom Hersteller anerkanntes Credential verweisen zu können, das sagt „diese Person versteht CI/CD-Automatisierung, inklusive der Sicherheitsseite", ist ein kleiner, aber realer Baustein dieses Vertrauens. Es ist derselbe Instinkt wie hinter jeder anderen Zertifizierung, die ich halte: Ich lasse mich lieber an einem externen Maßstab messen, als nur zu behaupten, ich wüsste, was ich tue.
Und der dritte Grund ist schlicht: Das ist tägliche Technik für uns. GitHub Actions betreibt unsere Pipelines. Sich in dem zu zertifizieren, was man jeden Tag benutzt, ist die günstigste Weiterbildung, die es gibt – man lernt kein Werkzeug, das man vielleicht irgendwann braucht, sondern schärft eines, an dem die Hand schon liegt.
Wie sie sich in unserer Arbeit bei ThreeBIT zeigt
Hier hört die Zertifizierung auf, abstrakt zu sein. Fast jedes Repository, das wir betreiben, hat eine auf GitHub Actions gebaute CI/CD-Pipeline, und die Form dieser Pipelines ist genau der Stoff, den die Prüfung abdeckt.
Auf der Build-und-Test-Seite kompilieren unsere Workflows unsere .NET-Projekte, lassen die Testsuiten laufen und machen Merges vom Ergebnis abhängig. Ein Pull Request, der den Build oder die Tests bricht, darf nicht gemergt werden – die Pipeline erzwingt das automatisch, sodass die Disziplin nicht davon abhängt, dass jemand daran denkt, nachzusehen. Das sind die Bereiche „Workflows erstellen und verwalten" und „Workflows nutzen und Fehler beheben" in der täglichen Praxis.
Diese Website ist ein gutes Beispiel. Ihre Inhalte sind Markdown, und wir lassen markdownlint bei Pull Requests laufen, damit kaputte Formatierung abgefangen wird, bevor sie die Live-Seite erreicht, und nicht erst danach. Es ist eine kleine, unglamouröse Prüfung – genau die Art Automatisierung, die ihren Lohn leise verdient. (Wir haben außerdem auf die harte Tour gelernt, dass eine Prüfung, die nur bei Pull Requests auslöst, durch einen direkten Push auf den Main-Branch umgangen werden kann – eine eigene Lektion im Pipeline-Design: Die Automatisierung ist nur so gut wie der Weg, durch den man Änderungen zwingt.)
Auf der Deployment-Seite nehmen die Pipelines einen grünen Build und schieben ihn dorthin, wo er hin muss, sodass das Release kein manuelles Ritual ist, das jemand am Freitagnachmittag nervös vollzieht. Deployment-Automatisierung ist der Ort, an dem die Themen „absichern und optimieren" ihren Platz verdienen: die Secrets, mit denen ein Workflow mit Azure spricht, der Environment-Schutz, der ein Deployment ohne die richtigen Freigaben aus der Produktion fernhält, die Wahl des Runners. Diese Dinge richtig zu machen, ist der Unterschied zwischen Automatisierung, der man vertraut, und Automatisierung, die man babysitten muss.
Nichts davon ist exotisch. Das ist gerade der Punkt. Die GitHub-Actions-Zertifizierung bestätigt die gewöhnliche, tragende Automatisierung, die gute Softwareteams aufbauen und dann meist vergessen – bis zu dem Tag, an dem sie sie leise davor bewahrt, etwas Kaputtes auszuliefern. Für einen Microsoft-Stack-Laden wie unseren, der Dinge ausliefert, die beim ersten Mal funktionieren müssen, lohnt es sich, diese gewöhnliche Technik richtig zu verstehen. Das Zertifikat ist nur der Beleg.
Verify: https://www.credly.com/badges/381b4b2a-d0db-4fca-b43a-50a235d13e29
Quellen & weiterführende Links
- Microsoft Learn – GitHub Actions (GH-200) Zertifizierung (Prüfungsdauer, gemessene Fähigkeiten, Zielgruppe, Auslieferung über Pearson VUE): https://learn.microsoft.com/en-us/credentials/certifications/github-actions/
- GitHub Docs – About GitHub Certifications (die fünf Zertifizierungen; was das Actions-Credential bestätigt): https://docs.github.com/en/get-started/showcase-your-expertise-with-github-certifications/about-github-certifications
- GitHub Docs – GitHub Actions documentation (Workflows, Actions, Runner, Sicherheit): https://docs.github.com/en/actions
- GitHub Docs – Security hardening for GitHub Actions: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions
- GitHub Docs – About self-hosted runners: https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
Bildnachweise
Alle Bilder werden unter ihren jeweiligen Creative-Commons- oder Public-Domain-Bedingungen verwendet; wir danken den Urhebern.
- Chemical Genomics Robot — Maggie Bartlett, National Human Genome Research Institute, Public domain, via Wikimedia Commons (source).
- PROJECT BOOT Dev Mode codes Preview css — © Deliveramable, CC BY-SA 4.0, via Wikimedia Commons (source).
- Bacloud.com rack — © Fleshas, CC BY-SA 4.0, via Wikimedia Commons (source).