Microsoft Certified: DevOps Engineer Expert — der Schlussstein, den ich Prüfung für Prüfung gebaut habe

Im Juli 2022 habe ich AZ-400 bestanden und Microsoft Certified: DevOps Engineer Expert erworben — die einzige Microsoft-Zertifizierung auf Expert-Niveau, die ich besitze, und die, die ich als Schlussstein des Weges betrachte. Sie kam nicht aus dem Nichts. Achtzehn Monate zuvor, im Januar 2021, hatte ich den Azure Developer Associate erworben, und der erwies sich als die tragende Voraussetzung: Man kann das Expert-Zertifikat nicht allein über AZ-400 erlangen. Man muss bereits entweder Azure Administrator Associate oder Azure Developer Associate halten, bevor die Prüfung einem das Expert-Zertifikat verleiht. Bei mir war es der Entwickler-Weg, und darin steckt eine angenehme Logik — man beweist, dass man bauen kann, und dann beweist man, dass man bauen und betreiben kann.

Was DevOps Engineer Expert tatsächlich ist

Lass mich mit dem beginnen, was der Name nicht ganz verrät. „DevOps Engineer Expert" klingt, als wäre es eine Zertifizierung fürs Pipeline-Klempnern — ein bisschen YAML verdrahten, einen grünen Haken bekommen, den Badge einsammeln. Das ist es nicht, und Microsoft ist darin ungewöhnlich deutlich. Die offizielle Zertifizierung beschreibt einen DevOps-Engineer als „Entwickler oder Infrastruktur-Administrator, der außerdem Fachexpertise darin hat, mit Menschen, Prozessen und Produkten zu arbeiten, um die kontinuierliche Wertschöpfung in Organisationen zu ermöglichen." Menschen und Prozesse stehen in diesem Satz zuerst, vor den Produkten. Diese Reihenfolge ist Absicht.

Das strukturelle Detail, das viele überrascht, ist die Voraussetzung. Dies ist ein Expert-Zertifikat, und Microsoft überreicht es nicht auf Basis einer einzigen Prüfung. Bevor AZ-400 einem das Expert-Zertifikat verleihen kann, muss man bereits eine von zwei Associate-Zertifizierungen halten: Azure Administrator Associate oder Azure Developer Associate. Die Zertifizierungsseite führt genau aus diesem Grund „Voraussetzungen: 2 Zertifizierungen" auf — der Expert-Badge ist die Kombination aus dem Associate-Fundament plus AZ-400, nicht die Prüfung für sich allein.

Ich kam durch die Entwickler-Tür. Ich hatte den Azure Developer Associate im Januar 2021 erworben, was bedeutete, dass sich die Teile beim Ablegen von AZ-400 im Juli 2022 zum Expert-Zertifikat zusammenfügten. Wer Azure nur administriert und nie darauf entwickelt hat, käme stattdessen durch die Administrator-Tür und landete am selben Ort. So oder so zwingt das Design dazu, echte Tiefe auf einer Seite der Dev/Ops-Trennlinie nachzuweisen, bevor es einen als die Person zertifiziert, die beide Seiten überspannt.

Auch über das Etikett „Expert" lohnt sich Ehrlichkeit. Die Prüfung ist breit statt in einem einzelnen Werkzeug tief. Wie Microsofts eigene Prüfungsarchitekten es bei der Einführung der Zertifizierung formulierten: „Als DevOps-Engineer muss man über sehr viele verschiedene Bereiche etwas wissen." Man muss kein fehlerfreies Bash schreiben oder C++ aus dem Kopf kompilieren können; man muss wissen, wann eine bestimmte Technik, ein Skript oder ein Drittanbieter-Werkzeug die richtige Wahl ist — und wann nicht. Die Breite ist der Punkt.

Was es tatsächlich zertifiziert

Hier hört der Rahmen „Menschen und Prozesse" auf, ein Slogan zu sein, und wird zum Lehrplan. Die AZ-400-Prüfung misst fünf Kompetenzbereiche, und nur einer davon dreht sich wirklich um Pipelines im engen Sinn:

• Prozesse und Kommunikation entwerfen und implementieren (10–15 %) — Nachverfolgbarkeit und Arbeitsfluss, GitHub Flow, Feedback-Zyklen, Dashboards mit Metriken wie Cycle Time, Lead Time und Time to Recovery, dazu die unglamouröse Disziplin von Dokumentation, Wikis, Release Notes und der Integration von Boards mit GitHub und Teams.
• Eine Source-Control-Strategie entwerfen und implementieren (10–15 %) — Branching-Strategien (trunk-based, Feature Branch, Release Branch), Pull-Request-Workflows, Branch Policies und Protection Rules sowie die wirklich harten Stücke wie das Skalieren eines Git-Repos und das Wiederherstellen oder Bereinigen von Daten aus der Historie.
• Build- und Release-Pipelines entwerfen und implementieren (50–55 %) — das Herzstück: Paketverwaltung, eine Teststrategie mit Quality und Release Gates, YAML-Pipelines, Runner und Agents, Deployment-Muster (blue-green, canary, ring, Feature Flags) und Infrastructure as Code mit Bicep und ARM.
• Einen Sicherheits- und Compliance-Plan entwickeln (10–15 %) — Identitäten und Service Principals, Berechtigungen in GitHub und Azure DevOps sowie die Verwaltung von Secrets und Zertifikaten mit Azure Key Vault und Workload Identity Federation.
• Eine Instrumentierungsstrategie implementieren (5–10 %) — das laufende System überwachen, damit man tatsächlich erfährt, wenn etwas nicht stimmt.

Liest man die Liste als Ganzes, wird die Form klar. Ja, Pipelines sind der größte Einzelblock. Aber volle die Hälfte der Prüfung dreht sich um alles um die Pipeline herum: wie Arbeit fließt, wie Teams kommunizieren, wie man einen Bug zu einem Commit zurückverfolgt, wie man Secrets aus der Source Control heraushält und wie man — in Produktion, um zwei Uhr nachts — weiß, dass das, was man ausgeliefert hat, gesund ist. Ein DevOps-Engineer, der eine schöne Pipeline bauen kann, aber den Feedback-Kreis drumherum nicht entwirft, hat die Aufgabe verfehlt.

Es gibt noch eine Tatsache, die man klar aussprechen sollte, denn sie verändert, wie man jede Zertifizierungsaussage lesen sollte — auch meine: Rollenbasierte und Spezialisierungs-Zertifizierungen von Microsoft verfallen nach einem Jahr. Man erneuert sie kostenlos mit einer kurzen Online-Bewertung, die sechs Monate vor Ablauf öffnet, und die Erneuerung konzentriert sich nur auf das, was sich seit dem letzten Bestehen in der Technologie verändert hat. Wenn ich also sage, dass ich DevOps Engineer Expert seit Juli 2022 halte, meine ich in Wahrheit, dass ich es seither jedes Jahr erneuert habe — was angesichts dessen, wie schnell sich Azure DevOps, GitHub Actions und das IaC-Tooling bewegt haben, wohl die bedeutsamere Aussage ist. Ein vier Jahre altes statisches Zertifikat würde über das heutige Tooling sehr wenig aussagen.

Warum ich mich überhaupt zertifizieren ließ

Ich bin offen: 2022 hatte ich diese Arbeit schon seit Jahren gemacht. Ich brauchte keinen Badge, der mir erklärt, wie man eine Release-Strategie entwirft oder Key Vault verdrahtet. Warum also überhaupt die Prüfung ablegen?

Drei Gründe, in aufsteigender Wichtigkeit.

Der erste ist strukturelle Ehrlichkeit. Wenn man etwas lange tut, sammeln sich Gewohnheiten an — manche gut, manche bloß vertraut. Die Vorbereitung auf eine breite Prüfung wie AZ-400 zerrt jede Ecke der eigenen Praxis ins Licht und fragt: Ist das immer noch der richtige Weg, oder nur der, den du immer gegangen bist? Aus der Vorbereitung kam ich heraus, nachdem ich ein paar Dinge in unserem eigenen Auslieferungsprozess still modernisiert hatte. Allein das war die Prüfungsgebühr wert.

Der zweite ist die Voraussetzungskette selbst. Den Azure Developer Associate hatte ich im Januar 2021 ohne großen Plan erworben, außer mir selbst zu beweisen, dass ich ihn sauber bestehe. Als ich ihn hatte, war das Expert-Zertifikat direkt erreichbar — eine einzige weitere Prüfung, die unmittelbar auf dem aufbaute, was ich schon hatte. Der von Microsoft entworfene Weg ließ den Schlussstein weniger wie einen separaten Berg wirken und mehr wie den natürlichen Gipfel eines Grats, den ich ohnehin schon entlangging.

Der dritte, und der eigentliche: Ich führe ein Unternehmen, das Auslieferung auf dem Microsoft-Stack an Kunden verkauft, die uns — durchaus berechtigt — Systeme anvertrauen, bei denen Versagen Konsequenzen hat. „Vertrau mir, ich habe Erfahrung" ist ein schwächerer Satz als „hier ist ein unabhängig verifizierbares Expert-Zertifikat, jährlich erneuert, vom Hersteller, auf dessen Plattform wir bauen." Die Zertifizierung ist nicht der Grund, warum wir darin gut sind. Aber sie ist ein glaubwürdiges Kürzel dafür, von dritter Seite — und für eine kleine Firma in Ibbenbüren, die über Substanz statt über Logo-Größe konkurriert, zählen glaubwürdige Kürzel.

Wie es sich in unserer Arbeit bei ThreeBIT zeigt

Das ist der Teil, der mir am meisten am Herzen liegt, denn eine Zertifizierung, die die tatsächliche Arbeit nie berührt, ist bloß Wanddekoration.

Bei ThreeBIT bauen wir Software nicht einfach und werfen sie über eine Mauer. Wir bauen und wir betreiben. Jedes Produkt, das wir ausliefern — Xircuit, Outastory, die maßgeschneiderten Systeme, die wir für Kunden bereitstellen — lebt hinter Pipelines, Infrastructure as Code und Observability, die uns gehören. Das ist der Lehrplan des DevOps Engineer Expert, täglich gelebt statt für eine Prüfung auswendig gelernt.

Das klarste Beispiel, das ich geben kann, stammt aus der frühen Pandemie. Ein Kunde brauchte eine COVID-Testplattform — Registrierung, Terminplanung, Ergebniszustellung, das ganze Programm — und er brauchte sie schnell, denn der gesundheitspolitische Kontext kümmerte sich nicht um unseren Sprint-Takt. Wir lieferten sie in zwei Wochen aus. Dieses Tempo war kein Heldentum und keine Nachtschichten. Es war Infrastructure as Code, damit Umgebungen identisch und wiederholbar standen, Build- und Release-Pipelines, damit jede Änderung über denselben getesteten Pfad in Produktion gelangte, und Instrumentierung, damit wir, sobald es live war und unter echter Last lief, sehen konnten, was passierte, statt zu raten. Das ist, fast Zeile für Zeile, der AZ-400-Kompetenzkatalog — Prozesse, Source Control, Pipelines, Sicherheit, Instrumentierung — angewendet unter echtem Druck. Die Zertifizierung hat das nicht möglich gemacht, aber sie ist der formale Name für genau den Muskel, den wir benutzt haben.

Das jüngere Beispiel ist, wie wir KI-gestützte Entwicklung betreiben. Wir geben jedem automatisierten Agenten seinen eigenen isolierten Worktree — seine eigene saubere Kopie des Repositories — damit mehrere parallel arbeiten können, ohne zu kollidieren, und nichts gemergt wird, bevor die Checks durchlaufen. Als Microsoft auf der Build 2026 im Grunde genau dieses Muster als erstklassiges Produkt-Feature zeigte, mussten wir schmunzeln, denn so hatten wir bereits gearbeitet. Dieser Instinkt — die Änderung isolieren, die Verifikation automatisieren, den Merge gaten — ist reines Source-Control-Strategie- und Pipeline-Disziplin-Denken. Es ist die DevOps-Engineer-Expert-Denkweise, gerichtet auf ein brandneues Problem.

Das ist der rote Faden. Der Badge sitzt auf einer Profilseite, aber das Denken dahinter sitzt in jedem Repository, jeder Pipeline und jedem Dashboard, das wir pflegen. Wir bauen für Branchen, in denen ein Bug keine kosmetische Macke ist, sondern ein verpasstes Testergebnis, ein fehlgeschlagener Export oder ein Compliance-Befund — und der ganze Sinn von DevOps, richtig gemacht, ist es, das Ausliefern in solche Umgebungen langweilig zuverlässig zu machen. Das ist die Arbeit. Die Zertifizierung gibt ihr nur einen Namen, den man verifizieren kann.

Verify: https://learn.microsoft.com/api/credentials/share/en-us/buchheister/A8E0808E603D3D42?sharingId=C72B4F60A795D7E4

Quellen & weiterführende Links

• Microsoft — Microsoft Certified: DevOps Engineer Expert (Zertifizierungsdetails, „Menschen, Prozesse und Produkte", 2 Voraussetzungs-Zertifizierungen): https://learn.microsoft.com/credentials/certifications/devops-engineer/
• Microsoft — Exam AZ-400: Designing and Implementing Microsoft DevOps Solutions (gemessene Kompetenzen, Gewichtungen, Bestehensgrenze 700): https://learn.microsoft.com/credentials/certifications/exams/az-400/
• Microsoft — Study guide for Exam AZ-400 (vollständiger Kompetenzkatalog, IaC mit Bicep, Deployment-Muster, Instrumentierung): https://learn.microsoft.com/credentials/certifications/resources/study-guides/az-400
• Microsoft — Level up with Microsoft Certified: DevOps Engineer Expert (Voraussetzung: Azure Administrator Associate ODER Azure Developer Associate): https://learn.microsoft.com/credentials/certifications/posts/level-up-with-microsoft-certified-devops-engineer-expert
• Microsoft — Introducing the Microsoft DevOps Engineer Expert Certification („man muss über sehr viele verschiedene Bereiche etwas wissen"; Bewusstsein für Drittanbieter-Werkzeuge): https://learn.microsoft.com/credentials/certifications/posts/introducing-the-microsoft-devops-engineer-expert-certification
• Microsoft — Credential expiration policies (rollenbasierte und Expert-Zertifizierungen ein Jahr gültig): https://learn.microsoft.com/credentials/support/credential-expiration-policy
• Microsoft — FAQs about renewal (kostenlose jährliche Erneuerungsbewertung, öffnet sechs Monate vor Ablauf, ca. 45 Minuten): https://learn.microsoft.com/credentials/certifications/renew-your-microsoft-certification-faq

Bildnachweise

Alle Bilder werden unter ihren jeweiligen Creative-Commons- oder Public-Domain-Bedingungen verwendet; wir danken den Urhebern.

• 1998.11.16 Pipes — © Hermann Luyken, CC BY-SA 3.0, via Wikimedia Commons (source).
• EFTA00000873 - Control room with multiple monitors a laptop and office supplies on a desk set against a wall-mounted screen setup — Federal Bureau of Investigation, Public domain, via Wikimedia Commons (source).
• The Old Servers — © compujeramey, CC BY 2.0, via Flickr (source).