Microsoft AZ-400: CI/CD-Pipelines mit Azure Pipelines — Lernleitfaden

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Teil des Microsoft DevOps Engineer Expert AZ-400 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Azure Pipelines bietet End-to-End CI/CD als Code mit mehrstufigen YAML-Pipelines, die Build, Test und Release vereinheitlichen und gleichzeitig die Kontrolle für Unternehmen gewährleisten. Die Beherrschung der YAML-Erstellung, Trigger, Agents, Variablen, Vorlagen, Deployment-Jobs, Artefakte, Caching und Service-Verbindungen ist unerlässlich, um skalierbare, sichere und wiederholbare Auslieferungssysteme zu erstellen.

Erstellung mit YAML und Vorlagen

Eine YAML-Pipeline besteht aus Stages, Jobs und Steps. Stages modellieren Lebenszyklus-Grenzen wie Build, Test, Release; Jobs werden auf Agents ausgeführt und können parallel laufen; Steps sind Aufgaben oder Skripte, die innerhalb eines Jobs ausgeführt werden. Abhängigkeiten werden explizit über dependsOn deklariert, was eine feingranulare Orchestrierung und bedingte Ausführung ermöglicht. Mehrstufiges YAML konsolidiert CI und CD, unterstützt Fan-In/Fan-Out-Muster und bindet Genehmigungen an Umgebungen (Environments) anstatt an ein eigenständiges Release-Konstrukt.

Vorlagen (Templates) ermöglichen die Komposition und Wiederverwendung auf verschiedenen Granularitätsebenen:

Step-Vorlagen: kapseln eine Abfolge von Aufgaben (z. B. Tool-Setup, Wiederherstellung, Build, Test) zur Wiederverwendung über Repositories hinweg.
Job-Vorlagen: bündeln Steps mit einer spezifischen Agent-Spezifikation und Strategie (z. B. ein Test-Matrix-Job).
Stage-Vorlagen: bündeln ganze Stages, einschließlich Genehmigungen, Bedingungen und Umgebungs-Targeting, für konsistente Promotion-Abläufe.
Extends-Vorlagen: erzwingen die Vererbung von Pipelines. Ein extends auf oberster Ebene referenziert eine zentrale Vorlage, die erforderliche Stages/Jobs/Steps und Governance vorschreibt. Dies ist ein mächtiges Werkzeug für unternehmensweite Richtlinien, um sicherzustellen, dass jedes Team Sicherheitsscans, Compliance-Prüfungen und Namenskonventionen erbt.

Die Auswertung von Vorlagen erfolgt zur Compile-Zeit vor der Laufzeitausführung. Verwenden Sie ${{ }} für Template-Ausdrücke, um die Pipeline-Struktur zur Compile-Zeit zu verzweigen (z. B. um bestimmte Jobs nur für main einzuschließen). Die Makro-Syntax $(var) und Laufzeitausdrücke $[ ] werden zur Laufzeit aufgelöst, was beeinflusst, wann Secrets und Variablengruppen verfügbar sind. Speichern Sie gemeinsam genutzte Vorlagen in einem zentralen Repo und importieren Sie sie über resources repositories; pinnen Sie sie an einen Branch oder Tag für deterministische Builds.

Trigger, Agents, Variablen und Ausdrücke

Trigger steuern die Einstiegspunkte der Automatisierung:

CI-Trigger starten Pipeline-Durchläufe, wenn Code in verfolgte Branches gepusht wird. Pfadfilter für include und exclude reduzieren unnötige Ausführungen. Batch ermöglicht das Zusammenfassen mehrerer Pushes.
PR-Trigger validieren Pull Requests. Konfigurieren Sie Ziel-Branches und Pfadfilter und aktivieren Sie das automatische Abbrechen von überholten Durchläufen.
Geplante Trigger (Scheduled Triggers) laufen auf Basis von Cron-Ausdrücken, um nächtliche Builds oder periodische Validierungen mit Zeitzonensteuerung zu unterstützen.
Pipeline-Trigger werden ausgelöst, wenn eine vorgeschaltete Pipeline einen neuen Durchlauf oder ein neues Artefakt veröffentlicht. Deklarieren Sie Pipeline-Ressourcen und fügen Sie trigger: true mit Branch-Filtern hinzu, um Pipelines über Repositories oder Projekte hinweg zu verketten.

Agents und Agent-Pools bestimmen, wo Jobs ausgeführt werden:

Von Microsoft gehostete Agents (Microsoft-hosted agents) stellen kurzlebige VMs auf ubuntu-latest, windows-latest oder macOS-Images mit vorinstallierten Toolsets bereit. Sie sind ideal für Elastizität und minimalen Wartungsaufwand. Planen Sie die Parallelität durch den Kauf von parallelen Jobs und berücksichtigen Sie die Grenzen für das Aufwärmen des Caches.
Selbstgehostete Agents (Self-hosted agents) laufen auf Ihrer eigenen Infrastruktur für benutzerdefinierte Toolchains, Zugriff auf private Netzwerke und vorhersagbare Leistung. Härten Sie den Host, schränken Sie den ausgehenden Datenverkehr (Egress) bei Bedarf ein und rotieren Sie das Agent-PAT, das zur Registrierung des Agents verwendet wird. Nutzen Sie Skalierungsgruppen (Scale Sets) oder containerisierte Agents für Elastizität.
Agent-Pools gruppieren Agents logisch und werden zur Delegierung von Berechtigungen verwendet. Vergeben Sie „Use“-Rechte auf Projektebene für Pools und isolieren Sie sensible Workloads durch dedizierte Pools. Jobs geben einen Pool und optional demands an, um Agents mit den erforderlichen Fähigkeiten auszuwählen.

Variablen und Parameter steuern die Konfigurierbarkeit:

Pipeline-Variablen sind Schlüssel-Wert-Paare, die für Tasks als Umgebungsvariablen und über das $(name)-Makro verfügbar sind. Geheime Variablen (Secret Variables) werden in Protokollen maskiert und niemals in Template-Ausdrücken zur Compile-Zeit offengelegt. Kennzeichnen Sie sie in der Library oder in der Pipeline als geheim (secret).
Variablengruppen (Variable Groups) zentralisieren gemeinsam genutzte Werte und Secrets in der Library. Verknüpfen Sie sie mit Azure Key Vault, um Secrets zur Laufzeit zu beziehen und sicherzustellen, dass die Werte nicht in der Pipeline gespeichert werden. Steuern Sie die Pipeline-Berechtigungen, um einzuschränken, welche Pipelines eine Gruppe verwenden dürfen.
Laufzeitparameter (Runtime Parameters) definieren stark typisierte Eingaben zum Zeitpunkt des Anstoßens (string, number, boolean, object) und werden zur Compile-Zeit über ${{ parameters.* }} ausgewertet, um die Pipeline zu formen (z. B. Aktivieren/Deaktivieren von Stages). Bevorzugen Sie Parameter, wenn Sie die Pipeline-Struktur ändern müssen; bevorzugen Sie Variablen, wenn Sie Laufzeitwerte innerhalb von Steps benötigen.
Ausdrücke (Expressions): Verwenden Sie ${{ }} für Template-Logik zur Compile-Zeit, $(var) für Makro-Substitution und $[condition()] für Laufzeit-Bedingungen in Eigenschaften. Setzen Sie Variablen aus Tasks über Logging-Befehle und geben Sie Ausgaben über isOutput-Variablen zwischen Jobs weiter.

Deployments, Umgebungen, Strategien und Gates

Deployment-Jobs bieten erstklassige CD-Semantik. Ein Deployment-Job zielt auf eine Umgebung ab und wird gemäß einer Strategie ausgeführt, die Rollouts und Lifecycle-Hooks steuert:

Umgebungen repräsentieren Deployment-Ziele (z. B. dev, test, prod) und können Ressourcen wie Kubernetes-Cluster, virtuelle Maschinen oder generische „none“-Ressourcen für plattformunabhängige Deployments enthalten. Umgebungen vereinheitlichen Telemetrie, Genehmigungen und Prüfungen.
Genehmigungen und Prüfungen sind mit Umgebungen und Service Connections verknüpft. Genehmigungen erfordern benannte Genehmiger, bevor das Deployment fortgesetzt wird. Prüfungen fungieren als Gates, die Bedingungen wie Geschäftszeiten, erforderliche Arbeitselemente, Azure Monitor-Signale, den Aufruf von REST-APIs oder Azure Functions und den Schutz von Branches auswerten. Diese verhindern eine Höherstufung (Promotion), wenn Leistungs-Baselines oder Compliance-Bedingungen nicht erfüllt sind.
Strategien bestimmen, wie Updates ausgerollt werden:
- runOnce wendet Änderungen in einer einzigen Welle an, mit preDeploy- und postDeploy-Hooks.
- rolling führt das Deployment in Batches über Instanzen hinweg durch, mit maxParallel- und Fehlerschwellenwerten für einen sicheren Fortschritt.
- canary verlagert den Traffic schrittweise in Inkrementen, mit routeTraffic- und postRouteTraffic-Phasen zur Validierung vor dem vollständigen Rollout.
- blue-green (auch Red/Black genannt) wird durch das Deployment in eine parallele Umgebung oder einen Slot und das Umschalten des Traffics am Load Balancer oder durch einen App Service Slot-Swap implementiert. Obwohl Blue-Green keine benannte YAML-Strategie ist, wird sie durch Umgebungen, Routing und Swap-Tasks realisiert und ermöglicht ein schnelles Rollback durch die Rückverlagerung des Traffics.

Kodieren Sie die Deployment-Logik als einen Deployment-Job pro Umgebungs-Stage. Nutzen Sie Umgebungsprüfungen für robuste Gates anstelle von Ad-hoc-Script-Polling. Wenn Secrets benötigt werden, rufen Sie diese über eine Service Connection aus Azure Key Vault ab, anstatt sie in Variablen einzubetten.

Artefakte, Caching und Service Connections

Artefakte und Caching verbessern die Wiederverwendung und Leistung:

Pipeline-Artefakte sind die native Methode, um Build-Ausgaben zu veröffentlichen und zu konsumieren. Verwenden Sie PublishPipelineArtifact, um benannte Artefakte zu veröffentlichen, und DownloadPipelineArtifact, um sie aus dem aktuellen oder einem bestimmten Lauf abzurufen. Sie sind für Zuverlässigkeit und die gemeinsame Nutzung über Stages hinweg in YAML optimiert. Wenn Sie Artefakte aus einer anderen Pipeline konsumieren, deklarieren Sie eine Pipeline-Ressource und verwenden Sie deren Artefakt-Ressourcennamen für einen präzisen Abruf.
Universal Packages ermöglichen die versionierte, unveränderliche Verteilung von Binärdateien über Azure Artifacts für nicht sprachspezifische Assets (z. B. CLI-Tools, Datendateien). Veröffentlichen und laden Sie sie mit den Universal Packages-Tasks herunter, organisieren Sie sie über Feed-Ansichten (z. B. Prerelease vs. Release) und verwalten Sie die Aufbewahrung in den Feeds.
Pipeline-Caching beschleunigt die Wiederherstellung von Abhängigkeiten. Der Cache-Task verwendet einen Schlüssel (Key) und einen Pfad. Schlüssel sollten Lockfiles (package-lock.json, Pipfile.lock, packages.lock.json, go.sum) sowie Betriebssystem- und Tool-Versionen hashen, um eine präzise Invalidierung zu gewährleisten. Restore Keys ermöglichen Fallback-Übereinstimmungen für teilweise Cache-Treffer. Vermeiden Sie das Einbetten von Secrets in Cache-Pfade, beachten Sie die Größenbeschränkungen des Caches und deaktivieren Sie das Caching für ephemere Tools, wenn Lockfiles instabil sind. Beobachten Sie cacheHitVar, um das Task-Verhalten zu verzweigen.

Service Connections definieren die Identität, die Azure Pipelines verwendet, um auf externe Systeme zuzugreifen:

Typen umfassen Azure Resource Manager (für Azure-Abonnements und Ressourcengruppen), GitHub (Lese-/Schreibzugriff auf Repositories, Statusberichte) und Docker/Container Registry (Docker Hub, ACR). Weitere existieren für AWS, GCP, generische Service-Endpunkte und Paket-Registries.
OIDC-Föderation (Workload Identity Federation) beseitigt langlebige Secrets durch den Aufbau einer Vertrauensbeziehung zwischen Azure DevOps und Cloud-Identitätsanbietern. Konfigurieren Sie für ARM eine Entra ID-Anwendung mit einer föderierten Anmeldeinformation, die an den Azure DevOps-Issuer und die Repository/Pipeline-Claims gebunden ist. Zur Laufzeit tauscht Azure DevOps ein kurzlebiges Token gegen ein Cloud-Zugriffstoken aus, wodurch Service Principal-Secrets entfallen und das Risiko des Abflusses von Anmeldeinformationen reduziert wird.
Scoping und Governance sind entscheidend. Beschränken Sie den Geltungsbereich von ARM-Connections auf das geringstmögliche Berechtigungsniveau (idealerweise auf Ressourcengruppenebene mit benutzerdefiniertem RBAC). Deaktivieren Sie „Allen Pipelines Zugriffsberechtigung erteilen“ und autorisieren Sie stattdessen Pipelines explizit. Fügen Sie Genehmigungen und Prüfungen zu Service Connections hinzu, um vor der Verwendung eine manuelle Überprüfung oder eine Richtlinienvalidierung zu erfordern.

Klassisch vs. YAML und Migration

Klassische Pipelines verwenden den visuellen Designer mit getrennten Build- und Release-Konzepten. Sie bieten eine aufgabenbasierte Erstellung, Variablenverwaltung, Release-Umgebungen und Gates. YAML-Pipelines bieten Pipeline-as-Code, eine mehrstufige Vereinheitlichung, Vorlagen und eine robuste Versionierung mit dem Repository. Die Feature-Parität ist weitgehend erreicht: Genehmigungen und Prüfungen für Umgebungen ersetzen Release-Gates; Deployment-Jobs bilden Umgebungen ab; Pipeline-Artefakte ersetzen Build-Artefakte; und Vorlagen sowie extends implementieren eine zentrale Governance im großen Stil. Verbleibende Unterschiede betreffen typischerweise UI-basierte manuelle Eingriffe und einige Nischenfunktionen des Release-Designers, die in YAML durch „Manual Validation“-Aufgaben und Umgebungsprüfungen abgedeckt werden.

Ein pragmatischer Migrationspfad ist:

Inventarisieren Sie klassische Build- und Release-Definitionen, Aufgaben, Variablen, Umgebungen, Genehmigungen und Gates.
Konvertieren Sie den Build mit dem Assistenten in YAML oder exportieren Sie ihn nach YAML, und refaktorisieren Sie ihn dann in Vorlagen für Wiederverwendbarkeit und Wartbarkeit.
Modellieren Sie jede Release-Umgebung als YAML-Stage mit einem Deployment-Job, der auf eine Umgebung abzielt. Übersetzen Sie Release-Gates in Genehmigungen und Prüfungen für Umgebungen (z. B. Azure Monitor-Abfrageprüfungen, Arbeitselement-Abfrageprüfungen).
Lagern Sie gemeinsam genutzte Variablen in Variablengruppen aus und verknüpfen Sie Key Vault für Geheimnisse. Ersetzen Sie Service-Principal-Secrets durch OIDC-gestützte Dienstverbindungen.
Ersetzen Sie Release-Artefakt-Trigger durch Pipeline-Ressourcen-Trigger. Veröffentlichen Sie Pipeline-Artefakte in der CI und konsumieren Sie sie in den CD-Stages.
Validieren Sie die Parität, indem Sie vorübergehend beide Pipelines ausführen, und stellen Sie dann um und nehmen Sie die klassischen Definitionen mit entsprechenden Rollback-Plänen außer Betrieb.

Praktisches Problemszenario

Starbucks standardisiert die Bereitstellung für eine Microservices-Plattform und muss von klassischen Releases auf YAML migrieren, während gleichzeitig Performance-Gates durchgesetzt, das Risiko von Anmeldeinformationen reduziert und Builds beschleunigt werden sollen.

Erstellen von mehrstufigem YAML mit extends-Vorlagen

Vorgehensweise: Erstellen Sie eine zentrale extends-Vorlage auf Organisationsebene, die gemeinsame Stages für statische Analyse, SCA und Sicherheitsprüfungen sowie Standardbenachrichtigungen einfügt. Jede Service-Pipeline erweitert diese Vorlage und definiert servicespezifische Build- und Deploy-Stages.
Begründung: extends erzwingt eine einheitliche Governance und hält die Service-Pipelines schlank, während die erforderlichen Compliance-Schritte garantiert werden.

Implementieren von CI-, PR-, Zeitplan- und Pipeline-Triggern

Vorgehensweise: Konfigurieren Sie CI- und PR-Trigger mit Pfadfiltern für jeden Dienst; fügen Sie einen nächtlichen Zeitplan für langlaufende Integrationstests hinzu; verketten Sie eine Packaging-Pipeline, um eine Deployment-Pipeline über Pipeline-Ressourcen auszulösen.
Begründung: Gewährleistet schnelles Feedback zu Code-Änderungen, regelmäßige Zustandsprüfungen und eine deterministische Beförderung bekannter Artefakte.

Verwenden einer gemischten Agentenstrategie mit Agent-Pools

Vorgehensweise: Build-Jobs auf von Microsoft gehosteten ubuntu-latest-Agenten für Elastizität; Deploy-Jobs auf selbstgehosteten Agenten innerhalb des Starbucks VNet mit Zugriff auf interne Cluster. Isolieren Sie Agenten nach Pools pro Umgebung und schränken Sie die Pool-Nutzung ein.
Begründung: Gehostete Agenten minimieren den Wartungsaufwand für CI; selbstgehostete Agenten bieten eine sichere Netzwerk-Erreichbarkeit für CD. Das Scoping von Pools erzwingt das Prinzip der geringsten Rechte (Least Privilege).

Verwalten von Variablen mit Variablengruppen und Laufzeitparametern

Vorgehensweise: Platzieren Sie gemeinsam genutzte, nicht geheime Werte in Variablengruppen, rufen Sie Geheimnisse aus Azure Key Vault über verknüpfte Variablengruppen ab und machen Sie einen booleschen Parameter enablePerfGate verfügbar, um Performance-Gates in Nicht-Produktions-Branches umzuschalten.
Begründung: Zentralisierte Konfiguration vermeidet Duplizierung; Key Vault schützt Geheimnisse; Parameter steuern strukturelle Entscheidungen zur Kompilierzeit.

Definieren von Deployment-Jobs mit Umgebungen, Genehmigungen und Prüfungen

Vorgehensweise: Modellieren Sie Dev, Staging und Prod als Umgebungen. Fügen Sie Genehmigungen für Staging und Prod hinzu. Fügen Sie Prüfungen hinzu: Geschäftszeiten für Prod und eine Azure Monitor-Abfrageprüfung, die die Beförderung blockiert, wenn die Latenz im Staging einen Basiswert überschreitet.
Begründung: Genehmigungen und Prüfungen auf Umgebungsebene implementieren eine kontrollierte Beförderung und setzen SLOs vor dem Produktions-Deployment durch.

Anwenden von Canary- und dann Blue-Green-Strategien

Vorgehensweise: Verwenden Sie eine Canary-Strategie im Staging, um Inkremente zu validieren. In der Produktion wird in einem parallelen Slot/einer parallelen Umgebung bereitgestellt und der Traffic ausgetauscht (Blue-Green/Red-Black) mit sofortiger Rollback-Fähigkeit.
Begründung: Canary reduziert das Risiko während der Validierung; Blue-Green minimiert die Bereitstellungszeit und bietet den schnellsten Rollback.

Optimieren mit Pipeline-Artefakten und Caching

Vorgehensweise: Veröffentlichen Sie Build-Ausgaben als Pipeline-Artefakte; konsumieren Sie sie in den Deployment-Stages. Cachen Sie die Wiederherstellung von Abhängigkeiten mit auf Lockfiles basierenden Hash-Schlüsseln und restoreKeys als Fallback.
Begründung: Artefakte gewährleisten eine unveränderliche, nachverfolgbare Beförderung; Caching verkürzt die Build-Zeiten erheblich, ohne die Korrektheit zu beeinträchtigen.

Absichern von Dienstverbindungen mit OIDC und bereichsbezogenen Berechtigungen

Vorgehensweise: Erstellen Sie ARM-Dienstverbindungen mithilfe von Workload Identity Federation, die auf Ressourcengruppen beschränkt sind. Fordern Sie Genehmigungen und Prüfungen für Dienstverbindungen an und deaktivieren Sie „Zugriff auf alle Pipelines gewähren“.
Begründung: Entfernt langlebige Geheimnisse und erzwingt das Prinzip der geringsten Rechte mit auditierbaren Genehmigungen.

Dieses End-to-End-Design bringt die YAML-as-Code-Governance mit unternehmenstauglichen Genehmigungen und Prüfungen in Einklang, beschleunigt die Bereitstellung durch Caching und Artefakte und stärkt die Sicherheit durch OIDC und bereichsbezogene Dienstverbindungen.

← Quellcodeverwaltung und Repository-Verwaltung · Alle Domänen · Infrastructure as Code und Konfigurationsmanagement →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →