Wie bestehen Sie AZ-400 und werden Microsoft Certified: DevOps Engineer Expert?

AZ-400 ist die Prüfung für DevOps Engineer Experts, die DevOps-Prozesse, Automatisierung, Sicherheit und kontinuierliche Bereitstellung in Azure- und GitHub-nahen Umgebungen entwerfen und umsetzen können müssen, während AZ-104 vor allem den Betrieb von Azure-Ressourcen prüft.

Die Prüfung AZ-400: Designing and Implementing Microsoft DevOps Solutions ist der zentrale Prüfungsschritt für die Zertifizierung Microsoft Certified: DevOps Engineer Expert. Stand: Juli 2026 sollte die offizielle Microsoft-Learn-Seite vor der Anmeldung geprüft werden, weil Microsoft Prüfungsdetails, Rollenbeschreibungen und Skills measured regelmäßig aktualisiert. Besonders wichtig ist eine Änderung, die in vielen älteren Artikeln noch falsch dargestellt wird: Für den Titel DevOps Engineer Expert werden keine formalen Vorzertifizierungen mehr als Pflicht genannt; Kenntnisse im Umfang von Azure Administration oder Azure Development bleiben jedoch fachlich sinnvoll.

AZ-400 ist keine reine Tool-Prüfung. Sie misst, ob Kandidaten verstehen, wie Teams Code versionieren, Builds automatisieren, Tests und Sicherheitsprüfungen einbauen, Artefakte verwalten, Releases steuern und Feedback aus laufenden Systemen zurück in die Entwicklung bringen. Azure DevOps bleibt dabei relevant, doch GitHub-Themen wie GitHub Actions, Repository-Strategien und Sicherheitsintegration haben deutlich mehr Gewicht bekommen. Wer nur klassische Azure-DevOps-Release-Pipelines auswendig lernt, bereitet sich zu eng vor.

Was AZ-400 heute tatsächlich prüft

Der Kern der Prüfung ist die Fähigkeit, DevOps als Arbeitsmodell zu gestalten. Dazu gehören Quellcodeverwaltung, Branching-Strategien, Continuous Integration, Continuous Delivery, Release-Gates, Sicherheits- und Compliance-Kontrollen, Paket- und Artefaktverwaltung sowie Monitoring. In Prüfungsszenarien wird selten isoliert gefragt, welcher Button in welchem Portal gedrückt wird. Typischer sind Situationen, in denen ein Team ein Ziel erreichen muss: schnellere Releases, weniger manuelle Freigaben, sichere Geheimnisverwaltung, reproduzierbare Infrastruktur oder bessere Nachvollziehbarkeit von Änderungen.

Aus praktischer Sicht fallen drei Themen besonders häufig schwer. Erstens unterschätzen viele Teams den Wechsel von Classic Releases zu YAML-Pipelines, weil Logik, Variablen, Templates und Berechtigungen plötzlich als Code gepflegt werden. Zweitens wird Secret-Management oft zu spät gelernt; Service Connections, Azure Key Vault und Pipeline-Berechtigungen sind prüfungsrelevant und im Betrieb kritisch. Drittens sind Environments, Approvals und Checks nicht nur Prüfungsstoff, sondern auch ein realistischer Weg, um Deployment-Geschwindigkeit und Governance miteinander zu verbinden.

Auch das Tool-Ökosystem bleibt wichtig. Azure steht neben Plattformen wie Microsoft Azure, AWS und Google Cloud in einem breiteren Cloud-Kontext, doch AZ-400 konzentriert sich auf Microsoft-nahe DevOps-Lösungen. Gleichzeitig sollten Kandidaten Integrationen verstehen, etwa mit Jenkins, SonarQube oder GitHub. Für Codequalität wird in Cloud-Szenarien häufig SonarCloud diskutiert, während SonarQube in selbstverwalteten Umgebungen verbreitet ist.

Ältere Markt- und Trenddaten können einordnen, warum DevOps-Rollen gefragt bleiben. Der ursprüngliche Artikel verwies auf eine IMARC-Prognose zum DevOps-Markt und auf Cloud-Marktanteilsdaten von The Register. Solche Quellen ersetzen jedoch nicht die Prüfungsvorbereitung. Auch Google Trends kann Suchinteresse zeigen, sagt aber nichts darüber aus, welche Fähigkeiten ein Arbeitgeber im Interview tatsächlich prüft.

AZ-104 oder AZ-204 zuerst?

Die sinnvolle Reihenfolge hängt vom beruflichen Hintergrund ab. Wer aus dem Betrieb kommt, sollte Lücken eher entlang von AZ-104 schließen: Identitäten, Netzwerke, Storage, virtuelle Maschinen, Governance, Monitoring und Ressourcenverwaltung. Wer aus der Entwicklung kommt, sollte eher die Denke von AZ-204 nachziehen: App Services, Functions, Container, Authentifizierung, Messaging, Datenzugriff und SDK-nahe Arbeit. Für AZ-400 zählt am Ende die Verbindung beider Seiten, weil DevOps Engineering genau zwischen Entwicklung, Betrieb, Sicherheit und Produktlieferung arbeitet.

Das bedeutet nicht, dass erst eine andere Prüfung bestanden werden muss. Entscheidend ist, ob Kandidaten Azure-Services sicher genug verstehen, um Automatisierung und Deployment-Entscheidungen begründen zu können. Ein Administrator mit wenig Entwicklungserfahrung sollte Git, Pull Requests, Build-Logik, Tests und Artefakte gezielt üben. Eine Entwicklerin mit wenig Betriebserfahrung sollte Identitäten, Rollen, Netzwerkgrenzen, Key Vault, Monitoring und Deployment-Ziele vertiefen. Im Zweifel ist ein kleines End-to-End-Projekt wertvoller als das parallele Sammeln von Zertifizierungsstoff ohne praktische Verbindung.

Ein Praxisprojekt, das auf Prüfung und Job einzahlt

Ein gutes AZ-400-Projekt beginnt nicht mit einer großen Architektur. Es reicht eine kleine Webanwendung, ein Repository, eine Pipeline und eine Azure-Umgebung. Wichtig ist, dass der gesamte Weg sichtbar wird: Repository, Build, automatisierte Tests, Codequalitätsprüfung, Artefakt, Staging-Deployment, manuelle Freigabe für Produktion, Secret-Management und Telemetrie. Dieser durchgängige Nachweis zählt auch im Hiring stärker als reine Theorie, weil er zeigt, dass Kandidaten den Lieferprozess als System verstanden haben.

Die Lernumgebung sollte bewusst moderne Muster enthalten. YAML statt nur Classic Releases, Infrastructure as Code mit Bicep oder Terraform, Secrets über Azure Key Vault statt Pipeline-Variablen im Klartext, Environments mit Approvals und Monitoring über Application Insights oder Log Analytics. Diese Themen treten in der Prüfung nicht immer als einzelne Fragen auf, sondern als verknüpfte Szenarien: Eine Pipeline soll sicherer werden, eine Bereitstellung reproduzierbar sein oder ein Team braucht bessere Rückmeldung nach einem Release.

Das folgende Beispiel zeigt eine verkürzte Multi-Stage-Pipeline. Es eignet sich, um Build, Test, Artefakterstellung, Secret-Bezug und Deployment-Gates gemeinsam zu üben. Namen sind bewusst realistisch gewählt; in einer echten Umgebung sollten Service Connections, Key Vaults und Environments über Rollen und Freigaben sauber abgesichert sein.

Example — Multi-Stage-YAML-Pipeline mit Build, Tests und Staging-Deployment

trigger:
  branches:
    include:
      - main

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: Release
  artifactName: az400-webapp

stages:
- stage: Build
  jobs:
  - job: BuildAndTest
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: restore
        projects: src/Az400Demo.Web/Az400Demo.Web.csproj

    - task: DotNetCoreCLI@2
      inputs:
        command: test
        projects: tests/Az400Demo.Tests/Az400Demo.Tests.csproj
        arguments: --configuration $(buildConfiguration)

    - task: DotNetCoreCLI@2
      inputs:
        command: publish
        publishWebProjects: false
        projects: src/Az400Demo.Web/Az400Demo.Web.csproj
        arguments: --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)

    - publish: $(Build.ArtifactStagingDirectory)
      artifact: $(artifactName)

- stage: Deploy_Staging
  dependsOn: Build
  jobs:
  - deployment: DeployWebApp
    environment: az400-staging
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureKeyVault@2
            inputs:
              azureSubscription: sc-az400-demo-staging
              KeyVaultName: kv-az400-demo-staging
              SecretsFilter: AppInsightsConnectionString

          - task: AzureWebApp@1
            inputs:
              azureSubscription: sc-az400-demo-staging
              appType: webAppLinux
              appName: app-az400-demo-staging
              package: $(Pipeline.Workspace)/$(artifactName)/**/*.zip

Die Pipeline trennt Build und Deployment in Stages, veröffentlicht ein Artefakt und nutzt Key Vault, statt Secrets direkt in YAML abzulegen. Für die Prüfung ist dabei weniger die Syntax allein entscheidend als die Begründung: Warum gibt es ein Environment? Wo werden Approvals gesetzt? Welche Identität darf auf Key Vault zugreifen? Wie wird nach dem Deployment geprüft, ob die Anwendung gesund ist?

Ein realistischer Lernplan für sechs Wochen

Ein berufsbegleitender Plan sollte nicht davon ausgehen, dass jeden Abend mehrere Stunden konzentriertes Lernen möglich sind. Realistischer sind mehrere kurze Einheiten pro Woche plus ein längerer Hands-on-Block. Die folgenden sechs Wochen funktionieren besonders gut, wenn bereits Azure-Grundlagen vorhanden sind; wer bei Git, Azure-Rollenmodell oder App-Bereitstellung unsicher ist, sollte vorab Zeit für Grundlagen einplanen.

1. Woche 1: Prüfen Sie die aktuelle Microsoft-Learn-Seite zu AZ-400, lesen Sie die Skills measured und richten Sie Repository, Azure DevOps oder GitHub sowie eine kleine Demo-App ein.
2. Woche 2: Üben Sie Versionskontrolle, Branch Policies, Pull Requests, Code Reviews und eine einfache CI-Pipeline mit Build und automatisierten Tests.
3. Woche 3: Ergänzen Sie Artefaktverwaltung, Paketversionierung, Container Registry oder Azure Artifacts und dokumentieren Sie, wie Builds reproduzierbar werden.
4. Woche 4: Bauen Sie eine Multi-Stage-YAML-Pipeline mit Staging und Produktion, Environments, Approvals und Rollback-Überlegungen.
5. Woche 5: Integrieren Sie Sicherheit und Compliance durch Key Vault, Service Connections mit geringem Berechtigungsumfang, Code Scanning sowie SonarQube oder SonarCloud.
6. Woche 6: Ergänzen Sie Monitoring mit Application Insights oder Log Analytics, wiederholen Sie schwache Prüfungsbereiche und erklären Sie Ihr Demo-Projekt laut in Interview-Logik.

Der Fortschritt lässt sich gut an vier Fragen prüfen. Kann die Pipeline nach einem Commit automatisch bauen und testen? Kann ein Artefakt nachvollziehbar einer Version und einem Deployment zugeordnet werden? Sind Secrets, Berechtigungen und Freigaben so gelöst, dass sie auch in einem Team tragfähig wären? Gibt es Telemetrie, die nach einem Release zeigt, ob die Anwendung funktioniert? Wer diese Fragen sauber beantworten kann, bewegt sich näher an dem Kompetenzniveau, das AZ-400 abfragt.

Strukturiertes Training kann sinnvoll sein, wenn die Zeit knapp ist oder Lücken schwer einzuordnen sind. Das AZ-400 Training von Readynez ist eine mögliche Option, wenn ein geführter Lernrahmen mit Prüfungsausrichtung gebraucht wird; das eigene Hands-on-Projekt bleibt dennoch unverzichtbar.

Typische Fehler in der Vorbereitung

Ein häufiger Fehler ist, AZ-400 wie eine Sammlung einzelner Azure-DevOps-Funktionen zu behandeln. Die Prüfung fragt jedoch nach Entscheidungen: Welche Branching-Strategie passt zu Release-Frequenz und Risiko? Wo gehören Qualitätsprüfungen hin? Wann ist ein manuelles Approval sinnvoll, und wann verlangsamt es nur den Prozess? Wer nur Menüpunkte wiedererkennt, kommt bei solchen Szenarien schnell an Grenzen.

Ein zweiter Fehler ist eine zu starke Fixierung auf ein einzelnes Tool. Azure DevOps Pipelines, GitHub Actions, GitHub Advanced Security, Azure Repos, GitHub-Repositories und Drittanbieterintegrationen können im selben Lernpfad vorkommen. Kandidaten sollten deshalb die Konzepte hinter den Tools verstehen: Trigger, Runner oder Agents, Secrets, Artefakte, Gates, Policies, Umgebungen, Observability und Feedback Loops.

Ein dritter Fehler betrifft Sicherheit. In Lernprojekten werden Secrets oft bequem als Variablen abgelegt, Service Connections zu breit berechtigt und Freigaben übersprungen. Genau diese Abkürzungen führen in der Praxis zu Risiken. Für AZ-400 sollte Sicherheit nicht erst als separates Kapitel am Ende gelernt werden, sondern in jede Pipeline-Übung eingebaut werden.

Häufige Fragen zu AZ-400

Braucht man AZ-104 oder AZ-204 zwingend vor AZ-400?

Nach der aktuellen Darstellung auf Microsoft Learn werden keine formalen Vorzertifizierungen als Pflicht genannt. Kenntnisse aus Azure Administration oder Azure Development bleiben aber empfohlen, weil AZ-400 voraussetzt, dass Kandidaten Azure-Ressourcen, Entwicklungsprozesse und Betriebsanforderungen miteinander verbinden können.

Reicht Azure DevOps, oder muss GitHub mitgelernt werden?

GitHub sollte mitgelernt werden. AZ-400 ist weiterhin stark mit Azure DevOps verbunden, doch GitHub Actions, Repository-Workflows und Sicherheitsfunktionen rund um Code Scanning und Advanced Security gehören inzwischen zum realistischen Vorbereitungsumfang.

Muss man programmieren können?

Man muss kein Vollzeitentwickler sein, aber grundlegendes Verständnis von Code, Build-Prozessen, Tests, Paketabhängigkeiten und Skripting ist wichtig. Wer YAML, Bash oder PowerShell gar nicht lesen kann, wird sowohl in der Prüfung als auch im Projektalltag Schwierigkeiten haben.

Wie erkennt man, ob man prüfungsbereit ist?

Ein guter Indikator ist, ob Sie ein End-to-End-Demo-Projekt erklären können: vom Commit über Build, Test, Artefakt und Deployment bis zu Monitoring und Feedback. Wenn Sie zusätzlich begründen können, warum bestimmte Sicherheits- und Freigabeentscheidungen getroffen wurden, ist die Vorbereitung deutlich belastbarer als reines Auswendiglernen.

Der nächste sinnvolle Schritt

AZ-400 lohnt sich besonders für Fachkräfte, die DevOps nicht nur bedienen, sondern gestalten möchten. Die Prüfung verlangt ein Denken in Lieferketten: Code muss nachvollziehbar gebaut, geprüft, bereitgestellt, überwacht und verbessert werden. Wer dabei GitHub-Inhalte, YAML-Pipelines, Infrastructure as Code, Key Vault, Environments und Observability gemeinsam übt, baut Fähigkeiten auf, die über die Prüfung hinaus in realen Teams gebraucht werden.

Die beste Vorbereitung verbindet offizielle Prüfungsziele, ein eigenes Praxisprojekt und regelmäßige Lückenkontrolle. Wenn ein Unternehmen oder Team einen strukturierten Lernpfad für AZ-400 plant, kann eine kurze Abstimmung mit Readynez helfen, den Umfang realistisch einzugrenzen und die Vorbereitung auf vorhandene Rollenprofile abzustimmen.