Microsoft AZ-400: Containerisierung und Kubernetes — 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

Containerisierung und Kubernetes bilden die Grundlage für modernes DevOps auf Azure, indem sie reproduzierbare Builds, sichere Verteilung und eine deklarative, selbstheilende Laufzeitorchestrierung kombinieren. Um dies zu beherrschen, muss man verstehen, wie Images zusammengestellt und optimiert werden, wie Registries Inhalte replizieren und attestieren, wie AKS konzipiert und ohne Unterbrechung aktualisiert wird, wie Progressive Delivery implementiert wird und wie Workloads End-to-End abgesichert werden. Über reines Kubernetes hinaus werden Sie Helm für das Packaging, GitOps für die Synchronisierung (Reconciliation) und – im Serverless-Bereich – Azure Container Apps mit Dapr und KEDA nutzen, um Microservices-Muster und ereignisgesteuerte Skalierung zu vereinfachen. Die folgenden Abschnitte fassen die Plattformentscheidungen und operativen Praktiken zusammen, die Sie zur Implementierung robuster, konformer Pipelines und resilienter Produktionscluster benötigen.

Grundlagen für Build und Registry: Docker und ACR

Ein performantes Container-Image beginnt mit einem deterministischen Dockerfile und einem disziplinierten Build-Kontext. Multi-Stage-Builds ermöglichen es Ihnen, kompilierintensive Toolchain-Phasen von kleinen Laufzeit-Images zu trennen. Kompilieren Sie beispielsweise ein .NET- oder Go-Binary in einer Builder-Stage und kopieren Sie dann nur das kompilierte Artefakt in ein Distroless- oder minimales Basis-Image (z. B. mcr.microsoft.com/dotnet/runtime-deps oder gcr.io/distroless/base), was zu kleineren Angriffsflächen und schnelleren Pull-Zeiten führt. Jeder Befehl RUN, COPY und ADD erzeugt eine Schicht (Layer); strukturieren Sie Dockerfiles neu, um die Treffer im Layer-Cache zu maximieren, indem Sie selten geänderte Schritte nach hinten verschieben und Befehle logisch gruppieren, ohne die Lesbarkeit zu beeinträchtigen. Fügen Sie immer eine .dockerignore-Datei hinzu, um bin/obj, node_modules, Tests, Dokumentationen und Secrets auszuschließen; ein zu großer Build-Kontext verlangsamt Uploads und verringert die Effektivität des Remote-Cache. Verwenden Sie deterministische Paketinstallationen (Version-Pins, Lock-Dateien) und Build-Argumente mit Bedacht; umgebungsspezifische Dateien sollten über die Laufzeitkonfiguration und nicht über unveränderliche Images bereitgestellt werden.

Azure Container Registry (ACR) ist das Rückgrat für die Speicherung und Verteilung von Images. Nutzen Sie ACR Tasks, um Builds nach Azure auszulagern: Quick Tasks für On-Demand-Builds (az acr run), automatisierte Tasks, die durch Git-Commits, Basis-Image-Updates oder Zeitpläne ausgelöst werden, und mehrstufige Task-YAMLs für Multi-Arch-Images mit Buildx. Geo-Replikation (Premium-SKU) spiegelt Artefakte über Regionen hinweg und minimiert so die Pull-Latenz und Egress-Kosten für Multi-Region-Deployments von AKS/ACA; kombinieren Sie dies mit Private Endpoints und Repository-bezogenem RBAC für das Prinzip der geringsten Rechte (Least Privilege). Aktivieren Sie Content Trust, um Images zu signieren und deren Herkunft zu überprüfen: Docker Content Trust/Notary und sich entwickelnde OCI-Signatur-Ökosysteme (z. B. cosign) können bei der Zulassung (Admission) über OPA Gatekeeper-Constraints durchgesetzt werden, die Signaturen für geschützte Namespaces erfordern. Integrieren Sie Schwachstellen-Scans: Microsoft Defender for Cloud scannt Images beim Push und im Ruhezustand (at rest), zeigt CVEs mit Korrekturanleitungen an und kann Deployments über Azure Policy und CI-Prüfungen steuern; implementieren Sie eine Automatisierung zur Aktualisierung von Basis-Images, um bekannte anfällige Layer zu reduzieren.

AKS-Plattform und Workload-Bereitstellung

Erstellen Sie AKS-Cluster mit standardmäßig sicheren Einstellungen: verwaltete Identität, Azure AD-Integration für RBAC, Azure CNI für VNET-Integration, Netzwerkrichtlinie (Azure oder Calico), Azure Key Vault Provider (Secrets Store CSI) für die Nutzung von Secrets und private Cluster mit autorisierten IP-Bereichen. Wählen Sie für die Workload geeignete Knotenpools: System-Pools für kritische Komponenten der Steuerungsebene; Benutzer-Pools für Anwendungen; GPU-Pools für ML; Spot-Pools für kostensparende zustandslose Jobs; Windows-Knotenpools für Windows-Container. Verwenden Sie Taints/Tolerations und Topology Spread Constraints, um die Zeitplanung (Scheduling) und Ausfallsicherheit zu steuern. Skalieren Sie automatisch mit dem Cluster Autoscaler und dem Horizontal Pod Autoscaler pro Deployment; ziehen Sie ephemere Betriebssystem-Datenträger und Verfügbarkeitszonen für eine bessere Leistung und Ausfallsicherheit in Betracht.

Planen Sie Upgrades, um Störungen zu minimieren. AKS aktualisiert zuerst die Steuerungsebene, dann die Knotenpools. Verwenden Sie max-surge bei Knotenpool-Upgrades, um Surge-Kapazität hinzuzufügen, Knoten ordnungsgemäß zu leeren (drain) und PodDisruptionBudgets zu respektieren. Nutzen Sie automatische Upgrade-Kanäle (rapid/stable/patch-only) für eine vorhersehbare Kadenz; trennen Sie die Upgrades von System- und Benutzer-Pools, um den „Blast Radius“ (Auswirkungsradius) zu begrenzen. Führen Sie regelmäßig Node-Image-Upgrades durch, um Kernel-/Laufzeit-Fixes auch ohne eine Erhöhung der Kubernetes-Version zu übernehmen, und pinnen Sie kompatible CNI/CSI-Versionen. Verwenden Sie Blue-Green-Knotenpools für unterbrechungsfreie Plattformänderungen – sperren (cordon) und leeren (drain) Sie Green nach Blue und schalten Sie über nodeSelector/Affinity um.

Deployments in Kubernetes unterstützen nativ Rolling Updates mit maxUnavailable und maxSurge, um die Kapazität während des Rollouts aufrechtzuerhalten; kombinieren Sie dies mit Readiness/Liveness Probes und Startup Probes, um verfrühten Traffic zu verhindern. Blue-Green-Delivery auf Kubernetes wird durch den Betrieb paralleler Deployments (Blue und Green) und das Umschalten eines stabilen Service-Selektors oder Endpoint-Objekts auf die Zielversion implementiert; dies ermöglicht ein nahezu sofortiges Fallback durch das Ändern von Labels. Canary-Delivery wird am besten am Edge über einen Ingress durchgeführt: NGINX Ingress unterstützt gewichtete Canary-Deployments über Annotationen; der Application Gateway Ingress Controller (AGIC) kann den Traffic auf mehrere Backends aufteilen; Service Meshes ermöglichen Traffic Shifting mit granularen Richtlinien und Telemetrie. Für robuste Pipelines validieren Sie mit Smoke-Tests und App Insights-Verfügbarkeitsprüfungen, bevor Sie die Gewichtung erhöhen.

Helm bündelt Kubernetes-Manifeste in Charts, die aus Chart.yaml, Templates und einer standardmäßigen values.yaml bestehen. Values-Dateien werden deterministisch übereinandergelegt; verwenden Sie Overlays mit values.<env>.yaml und einen „global“-Block für chartübergreifende Einstellungen. Bevorzugen Sie Helm 3 mit OCI-basiertem Chart-Speicher in ACR (

undefined

), was RBAC und Geo-Replikationsparität mit Images ermöglicht. Installieren Sie in Azure Pipelines Helm in einer festgeschriebenen Version (HelmInstaller) und führen Sie das Deployment (HelmDeploy) über eine Kubernetes/Azure Resource Manager Service Connection durch; Template-Linting sowie Dry-Run und Diff (helm diff plugin) sollten Releases steuern (gate). Vermeiden Sie es, Secrets in Values-Dateien zu committen; integrieren Sie external-secrets oder den CSI Key Vault, um Secrets zur Laufzeit zu materialisieren. Versionieren Sie Charts semantisch und pinnen Sie die appVersion an den Image-Digest, um die Nachverfolgbarkeit zu gewährleisten.

Betrieb, Sicherheit und Traffic-Steuerung

GitOps mit Flux oder Argo CD stellt sicher, dass Cluster kontinuierlich zu einem deklarierten Zustand konvergieren. Flux v2 lässt sich nativ über die Azure CLI/Extension in AKS integrieren, gleicht in einem Intervall Sources (Git/OCI/Bucket) und Kustomizations ab und beinhaltet eine Image-Automatisierung, um Helm/Kustomize basierend auf Richtlinien auf neue Tags zu aktualisieren. Argo CD verfolgt Applications und deren Zustand (Health), unterstützt SSO mit Azure AD und kann in Pull-basierten „App-of-Apps“-Modellen für mandantenfähige Trennung betrieben werden. Beide erkennen Abweichungen (Drift) und können diese automatisch korrigieren, Events/Alerts ausgeben und Progressive Delivery unterstützen; kombinieren Sie sie mit Flagger, um Canaries und A/B-Tests mit NGINX, Istio oder Linkerd zu automatisieren, wobei die Hochstufung auf Basis von Metriken und der Rollback bei SLO-Verletzungen erfolgt.

Sicherheit beginnt in der Lieferkette (Supply Chain) und wird bei der Zulassung (Admission) und zur Laufzeit durchgesetzt. Scannen Sie Images kontinuierlich mit Defender for Cloud und implementieren Sie Gates in CI/CD. Übernehmen Sie die Kubernetes Pod Security Standards (baseline/restricted) mit Pod Security Admission Labels auf Namespaces, um standardmäßig privilegierte Container, hostPath und unsichere sysctls zu blockieren. Setzen Sie Unternehmensrichtlinien mit OPA Gatekeeper durch: Constraint-Templates verbieten privilegierte Container, fordern genehmigte Registries, erzwingen Ressourcenlimits und verlangen signierte Images oder das Vorhandensein einer SBOM. Wenden Sie Netzwerkrichtlinien an, um erlaubten Pod-zu-Pod- und Egress-Traffic zu definieren; AKS unterstützt Azure Network Policies (mit Azure CNI) und Calico. Ergänzen Sie dies durch Azure Firewall oder NVA-Egress-Kontrolle und Application Gateway WAF für Ingress. Härten Sie Workloads mit Non-Root-Benutzern, schreibgeschützten Root-Dateisystemen, seccomp- und AppArmor-Profilen sowie regelmäßigen Node-Image-Upgrades. Aktivieren Sie Audits und Bedrohungserkennung über Defender for Kubernetes und aggregieren Sie Telemetriedaten in Azure Monitor Container Insights; standardisieren Sie Logs/Traces mit OpenTelemetry.

Ein Service Mesh (Istio oder Linkerd) fügt einheitliches Traffic-Management, Verschlüsselung und Beobachtbarkeit (Observability) hinzu. Verwenden Sie DestinationRules/VirtualServices (Istio) oder ServiceProfiles (Linkerd), um Wiederholungsversuche (Retries), Timeouts, Circuit Breaking und gewichtetes Routing zu definieren. Aktivieren Sie Mutual TLS (mTLS) für Service-zu-Service-Verschlüsselung und -Identität; erzwingen Sie Richtlinien wie „STRICT“ mTLS, um Lücken zu schließen. Exportieren Sie Metriken nach Prometheus und Dashboards nach Grafana; erfassen Sie verteilte Traces (Jaeger/Zipkin) und leiten Sie sie über OpenTelemetry Collectors an Application Insights oder Azure Monitor weiter. Mesh-basierte Canaries und Fault Injection ermöglichen zuverlässige Tests und Progressive Delivery, wobei Flagger die Analyse anhand von SLOs automatisiert.

Entwicklerproduktivität und Serverless-Container auf Azure

DevOps-Integrationstools für AKS optimieren die „Inner Loops“ der Entwicklung. Draft erkennt Sprach-Frameworks und erstellt gerüsthaft Dockerfiles, Helm-Charts und Startkonfigurationen, was die Containerisierung beschleunigt. Bridge to Kubernetes leitet Service-Aufrufe von einem Live-Cluster auf Ihre lokale Workstation um. Dadurch können Sie einen einzelnen Microservice lokal iterieren und debuggen, während der Rest mit echten Daten und Abhängigkeiten im Cluster läuft. Azure Dev Spaces wurde eingestellt; Bridge to Kubernetes ist die unterstützte Lösung für die lokale Entwicklung und lässt sich in VS Code und Visual Studio integrieren.

Azure Container Apps (ACA) bietet eine serverlose, vollständig verwaltete Laufzeitumgebung für Microservices und Jobs, ohne dass Kubernetes verwaltet werden muss. Jedes Deployment erstellt eine Revision; Sie können den Datenverkehr prozentual auf verschiedene Revisionen verteilen, um Blue-Green- oder Canary-Rollouts mit einem einzigen Befehl oder einer YAML-Änderung durchzuführen. Die native Dapr-Integration ermöglicht Service-Aufrufe, Pub/Sub, Bindings, Zustandsspeicher und Secrets ohne maßgeschneiderte Implementierungen. Einsteckbare Komponenten (z. B. Azure Service Bus, Key Vault, Cosmos DB) beschleunigen die Bereitstellung konsistenter, serviceübergreifender Funktionen. KEDA ermöglicht ereignisgesteuertes Autoscaling basierend auf HTTP-Concurrency und mehr als 60 Scalern (Azure Queue/Service Bus, Kafka, Prometheus, benutzerdefiniert) und skaliert für Kosteneffizienz bis auf null. Nutzen Sie ACA-Umgebungen für Netzwerkisolation und VNET-Integration, binden Sie ACR über eine Managed Identity an und verwalten Sie die Konfiguration über containerapps-YAML, um die deklarative Parität mit GitOps-Praktiken zu wahren.

Praktisches Problemszenario

Adobe muss einen multiregionalen Kundenanalyse-Service modernisieren, das Risiko bei Releases reduzieren und gleichzeitig die Sicherheit der Lieferkette und der Laufzeitumgebung erhöhen. Das Team muss Builds standardisieren, sichere Rollouts automatisieren und eine schnelle, konforme Bereitstellung in den USA und der EU gewährleisten.

Implementieren Sie mehrstufige Dockerfiles und .dockerignore für alle Services

Warum: Minimiert die Image-Größe und die Angriffsfläche, verbessert die Trefferquote des Build-Caches und verhindert, dass versehentlich Secrets oder große Test-Assets in das Image aufgenommen werden.

Erstellen und signieren Sie Images mit ACR Tasks und pushen Sie sie in eine georeplizierte ACR

Warum: Cloud-Builds eliminieren lokale Abweichungen; Trigger bei Basis-Image-Updates reduzieren die Anfälligkeit für CVEs. Die Geo-Replikation der Premium-ACR platziert Artefakte nahe bei den AKS-Clustern, was Latenz und Egress-Traffic reduziert. Signaturen ermöglichen die Nachverfolgung der Herkunft.

Aktivieren Sie das Image-Scanning von Defender for Cloud und setzen Sie es über CI-Gates und OPA Gatekeeper durch

Warum: Scans beim Push und im Ruhezustand (at-rest) erkennen CVEs frühzeitig. Gatekeeper-Constraints erzwingen Richtlinien wie „nur genehmigte Registries“, „signierte Images erforderlich“ und Ressourcenlimits, um die Zulassung unsicherer Workloads zu verhindern.

Stellen Sie private AKS-Cluster pro Region mit Azure CNI, Netzwerkrichtlinien und Managed Identity bereit

Warum: Private Endpunkte schränken die Exposition der Control Plane ein; Azure CNI integriert sich in Unternehmens-VNETs; Netzwerkrichtlinien beschränken die laterale Bewegung; Managed Identity beseitigt die unkontrollierte Verbreitung von Secrets.

Erstellen Sie separate System- und Benutzer-Knotenpools, fügen Sie Spot-Pools für Batch-Jobs hinzu

Warum: Isoliert kritische Plattform-Pods, stellt kosteneffiziente Kapazität für unkritische Workloads bereit und vereinfacht Upgrades sowie das SLO-Management.

Nutzen Sie Helm für das Packaging, mit in ACR (OCI) gespeicherten Charts, und stellen Sie es über Azure Pipelines bereit

Warum: Konsistente, versionierte Releases mit Werten pro Umgebung. Pipelines führen helm lint, dry-run und diff vor einem helm upgrade aus und verwenden eine Kubernetes-Serviceverbindung, um auf die Zielcluster zuzugreifen.

Stellen Sie Flux v2 für GitOps-Abgleich und Drift-Erkennung bereit, integrieren Sie Flagger für Canaries

Warum: Die deklarative, Pull-basierte Synchronisierung reduziert die Notwendigkeit von Anmeldeinformationen in der CI und stellt die Konvergenz sicher. Flagger automatisiert gewichtete Canary-Deployments anhand von SLOs unter Verwendung von NGINX-Ingress-Metriken und führt bei Fehlern oder Latenzspitzen ein Rollback durch.

Konfigurieren Sie Rolling Updates mit PDBs und Readiness/Startup Probes; verwenden Sie Blue-Green für risikoreiche Komponenten

Warum: Rolling Updates erhalten die Kapazität; Probes schützen den Benutzerverkehr. Blue-Green mit einem Label-Wechsel auf dem Service ermöglicht ein sofortiges Rollback für hochriskante Komponenten wie das API-Gateway.

Führen Sie ein Istio Service Mesh mit striktem mTLS, Retries und Timeouts ein; exportieren Sie Telemetriedaten zu Application Insights

Warum: Mesh-weite Verschlüsselung, robuste Richtlinien für den Datenverkehr und einheitliche Beobachtbarkeit. OpenTelemetry-Kollektoren senden Traces/Metriken an einen zentralen Speicher für SLO-Monitoring und die Triage von Incidents.

Etablieren Sie eine kontrollierte Upgrade-Strategie mit dem AKS Auto-Upgrade-Kanal und Node-Image-Upgrades

Warum: Regelmäßige, vorhersagbare Plattform-Updates reduzieren das Risiko von Zero-Day-Exploits. Max-Surge und PDBs gewährleisten minimale Unterbrechungen; separate Upgrades der Benutzer-Knotenpools begrenzen den Explosionsradius (Blast Radius).

Verwenden Sie Bridge to Kubernetes für die Inner-Loop-Entwicklung; nutzen Sie Draft für das Scaffolding

Warum: Entwickler debuggen lokal mit den Abhängigkeiten im Cluster, ohne diese mocken zu müssen. Draft beschleunigt die konsistente Containerisierung und das Helm-Scaffolding über Teams hinweg.

Lagern Sie Long-Tail-Services auf Azure Container Apps mit Dapr und KEDA aus

Warum: Ereignisgesteuerte, auf null skalierbare Microservices (z. B. für Datenerfassung und -anreicherung) laufen kostengünstig mit integriertem Traffic-Splitting für Canaries; Dapr-Komponenten standardisieren Service-zu-Service-Aufrufe und Pub/Sub ohne maßgeschneiderten Code.

Dieses End-to-End-Design verbindet deterministische Builds mit sicherer Verteilung, deklarativem Betrieb und progressiver Bereitstellung. Adobe erhält dadurch schnelle, risikoarme Releases und eine gehärtete Laufzeitumgebung über alle Regionen hinweg.

← Infrastructure as Code und Konfigurationsmanagement · Alle Domänen · Release-Management und Deployment-Strategien →

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