Microsoft AZ-204: Azure App Service und Web-Apps — Lernleitfaden

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Teil des Microsoft Azure Developer Associate AZ-204 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Azure App Service ist eine vollständig verwaltete, HTTP-basierte Hosting-Plattform für Web-Apps, REST-APIs und Backend-Dienste, die Code- und Container-Workloads unter Windows und Linux unterstützt. Sie bietet erstklassige Funktionen für Skalierung, Bereitstellungs-Workflows, Authentifizierung, Netzwerkisolierung, Hintergrundverarbeitung und sichere Konfiguration. Um die Plattform zu beherrschen, ist ein Verständnis der App Service-Pläne und der Skalierung, der Bereitstellungsslots und der Datenverkehrsverwaltung, der CI/CD-Integrationspfade, von Easy Auth, benutzerdefinierten Domänen und TLS, WebJobs, der App Service Environment (ASE) und sicherer Konfigurationsmuster mit Key Vault erforderlich.

Pläne, Skalierung und Bereitstellungsslots

Ein App Service-Plan definiert die Rechenressourcen, die Ihre Apps hosten. Alle Apps in einem Plan teilen sich denselben VM-Pool und dieselbe Skalierungskonfiguration.

• Tarife:

  • Free (F1)/Shared (D1): Nur für Entwicklung und Tests. Kein SLA. Kein benutzerdefiniertes TLS. Keine Bereitstellungsslots.
  • Basic (B1–B3): Dedizierte VMs, manuelles Scale-Out. Kein Autoscale. Eingeschränkte Funktionen.
  • Standard (S1–S3): Fügt Autoscale und Bereitstellungsslots hinzu. Basis für die Produktion.
  • Premium v2/v3 (P1v2/P1v3+): Neuere Rechenleistung, schnellerer Speicher, erweiterte Netzwerkfunktionen, Zonenredundanz (bei unterstützten SKUs) und höhere Skalierbarkeit. Optimal für Unternehmensproduktionen und hohen Durchsatz.
  • Isolated (I1v2+) in ASE: Dediziert für das virtuelle Netzwerk eines Kunden mit Netzwerkisolierung und massiver Skalierbarkeit.

• Scale-up vs. Scale-out:

  • Scale-up (vertikale Skalierung) verschiebt den Plan auf eine höhere SKU für mehr CPU, Arbeitsspeicher, schnellere Datenträger oder erweiterte Funktionen (z. B. Premium v3 für bessere Leistung und Features).
  • Scale-out (horizontale Skalierung) erhöht die Anzahl der Instanzen, um die Last horizontal zu verteilen. Standard und höhere Tarife unterstützen Autoscale mit Regeln, die auf Metriken wie CPU, Arbeitsspeicher (Linux), Länge der HTTP-Warteschlange, Anfragen, benutzerdefinierten Metriken oder Zeitplänen basieren. Basic unterstützt nur manuelles Scale-out. Die Skalierung gilt für alle Apps innerhalb eines Plans.

• Bereitstellungsslots und Slot-Swaps:

  • Standard und höhere Tarife unterstützen mehrere Slots (z. B. Staging und Produktion). Slots laufen auf demselben Plan, jeder mit eigenem Hostnamen und eigener Konfiguration.
  • Ein Swap verschiebt den Inhalt und den Laufzeitzustand von einem Quell-Slot zu einem Ziel-Slot mit nahezu null Ausfallzeit, indem das Ziel vor der Datenverkehrsumschaltung aufgewärmt wird. Verwenden Sie applicationInitialization (Windows) oder Integritätsprüfungen (Health Checks), um die Bereitschaft vor dem Swap sicherzustellen. Ein Swap mit Vorschau ermöglicht die Validierung vor dem Abschluss.
  • Markieren Sie Konfigurationseinträge als Slot-Einstellungen, damit sie bei Swaps an den Slot gebunden bleiben (z. B. Datenbank-Verbindungszeichenfolgen, Geheimnisse und Diagnose-Endpunkte). Nicht markierte Einstellungen werden beim Swap mit dem Code verschoben.

• Datenverkehrs-Routing mit Slots:

  • Leiten Sie einen Prozentsatz des Live-Datenverkehrs an einen Nicht-Produktions-Slot für Canary-Testing (Testen in der Produktion). Cookies binden Benutzer nach der Zuweisung an einen Slot, um die Sitzungskonsistenz zu wahren.

Bereitstellung und CI/CD: GitHub, Azure DevOps und Container-Registries

Das Deployment Center integriert gängige CI/CD-Abläufe:

• GitHub Actions:
  • App Service kann ein Workflow-Grundgerüst mithilfe eines Oryx-Builds oder einer Container-Bereitstellung erstellen. Bei einem Push in einen Branch erstellen und implementieren die Actions den Code im ausgewählten Slot. Unterstützung für Matrix-Builds, Umgebungen und Geheimnisse. Bei Linux-Containern kann der Workflow ein Image erstellen und in ACR oder Docker Hub pushen und dann eine Web-App-Bereitstellung auslösen.
• Azure DevOps:
  • Pipelines (YAML oder klassisch) stellen Build- und Release-Phasen, Genehmigungen, Umgebungsprüfungen und mehrstufige Gates bereit. Verwenden Sie Tasks: Azure Web App, Azure Web App for Container oder AzureCLI für ARM/Bicep-gestützte Bereitstellungen. Variablengruppen und durch Key Vault gestützte Geheimnisse zentralisieren die Konfiguration.
• Container-Registries:
  • App Service for Containers pullt Images von ACR, Docker Hub oder privaten Registries. Konfigurieren Sie Continuous Deployment über ACR-Webhooks zur App; ein Push eines neuen Images löst einen Pull und einen Neustart aus. Anheften nach Tag oder Digest. Für die Produktionssicherheit verwenden Sie Image-Digests und Canary-Slots, bevor Sie das Image für die Produktion freigeben (Promoting).
• Zusätzliche Bereitstellungsmechanismen:
  • Kudu unterstützt Git-basiertes Pushen, Zip Deploy und Run From Package für reproduzierbare Builds. Die .deployment-Datei und benutzerdefinierte Skripte können Build-Schritte koordinieren, bevor die Website Datenverkehr bereitstellt. Für eine Release-Hygiene auf Unternehmensebene kombinieren Sie Slots mit CI/CD, um Integritätsprüfungen und das Aufwärmen vor einem Swap zu validieren.

Sicherheit, Identität, Domänen und TLS

Die Authentifizierung/Autorisierung von App Service (Easy Auth) lagert die Identitätsverwaltung auf die Plattform aus, ohne dass Middleware in Ihrem Code erforderlich ist.

• Anbieter:
  • Microsoft Entra ID (Microsoft Identity Platform), Google, Facebook, GitHub und Twitter sowie jeder OpenID Connect-kompatible Anbieter, einschließlich Entra ID B2C. Konfigurieren Sie Client-IDs/Secrets, Aussteller (Issuer) und zulässige Token-Zielgruppen (Audiences)/Bereiche (Scopes). Wählen Sie die Anmeldeaktion (anonymen Zugriff erlauben vs. Authentifizierung erfordern).
• Token-Speicher und Header:
  • Aktivieren Sie den Token-Speicher, um Zugriffs-/Aktualisierungs-Token (Access/Refresh Tokens), die während des Anmeldevorgangs erhalten wurden, zwischenzuspeichern. Diese sind über /.auth/me abrufbar und über /.auth/refresh aktualisierbar. App Service fügt Benutzer-Claims in die Anfrage-Header ein (z. B. X-MS-CLIENT-PRINCIPAL in Base64), sodass die App die Identität ohne SDK-Abhängigkeiten ableiten kann. Verwenden Sie den Abmelde-Endpunkt der Plattform, um Sitzungen zu löschen.
• Benutzerdefinierte Domänen:
  • Verknüpfen Sie CNAME- (empfohlen) oder A/ALIAS-Einträge mit dem Standard-Hostnamen der App. Bestätigen Sie bei Bedarf den Domänenbesitz mit TXT-Einträgen. Binden Sie den benutzerdefinierten Hostnamen in App Service.
• SSL/TLS-Zertifikate:
  • Erzwingen Sie „Nur HTTPS“ und legen Sie die minimale TLS-Version fest. Binden Sie Zertifikate über SNI (mehrere Zertifikate pro IP) oder IP-basiertes SSL (dedizierte IP). Laden Sie private Zertifikate (PFX) für eine produktionsreife Zertifikatskontrolle hoch. Das App Service Managed Certificate bietet ein kostenloses, sich automatisch verlängerndes, domänenvalidiertes Zertifikat für Nicht-Wildcard-Hostnamen; es kann nicht exportiert werden und erfordert einen unterstützten Tarif. Nutzen Sie die Key Vault-Integration, um private Zertifikate in großem Umfang zu verwalten und automatisch zu rotieren.
• Client-Zertifikate (mTLS):
  • Fordern Sie optional eingehende Client-Zertifikate an und leiten Sie sie zur Validierung an die App weiter. Kombinieren Sie dies mit einer Web Application Firewall und Reverse-Proxys (z. B. Application Gateway) für eine durchgängige TLS-Verschlüsselung (End-to-End TLS).

Hintergrundverarbeitung und isolierte Umgebungen

WebJobs und ASE adressieren Szenarien der Hintergrundverarbeitung und Netzwerkisolierung.

• WebJobs:
  • Kontinuierliche WebJobs laufen ununterbrochen auf jeder Instanz der Web-App und eignen sich für die Verarbeitung von Warteschlangen oder für Ereignisschleifen. Erfordert „Always On“ (Standard und höher), um sie am Laufen zu halten. Die Skalierung folgt der Instanzenanzahl des App-Plans; wenden Sie im Code ein Singleton-Verhalten an, wenn nur ein aktiver Worker gewünscht ist.
  • Ausgelöste WebJobs laufen bei Bedarf oder nach einem Zeitplan (CRON über settings.job). Ideal für Batch-Jobs, ETL oder periodische Wartungsarbeiten.
  • Das WebJobs SDK bietet Trigger und Bindungen für Azure Storage Queues, Service Bus-Warteschlangen/-Themen, Blobs und Timer mit deklarativen Funktionsmethoden und automatischem Checkpointing. Ein durch eine Warteschlange ausgelöster WebJob reagiert sofort auf neue Nachrichten, skaliert mit den App-Instanzen und verwendet die Verarbeitung von Poison Queues zur Fehlerisolierung. Protokolle und Dashboards sind in Kudu zugänglich.
• App Service Environment (ASE):
  • ASEv3 hostet App Service-Pläne innerhalb Ihres VNet mit Isolated v2 SKUs und bietet dedizierte Rechenleistung, Isolierung der Datenebene und private IPs. Wählen Sie ein externes ASE für öffentlichen Ingress oder ein Internal Load Balancer (ILB) ASE, um den gesamten eingehenden Datenverkehr privat innerhalb des VNet zu halten. Integrieren Sie es bei Bedarf mit privatem DNS, Firewalls und NVA/WAF.
  • ASE ermöglicht eine granulare Kontrolle des ausgehenden Datenverkehrs, Netzwerkinspektion und die Einhaltung von Compliance-Vorgaben. Es unterstützt Hosting in großem Maßstab mit vorhersehbaren Netzwerkgrenzen und wird getrennt von den Plan-Instanzen abgerechnet.

Konfiguration, Verbindungszeichenfolgen und Key Vault-Referenzen

Die App-Konfiguration wird zur Laufzeit injiziert und kann Slot-spezifisch sein.

• App-Einstellungen:
  • Schlüssel-Wert-Paare, die der App als Umgebungsvariablen zur Verfügung stehen. Markieren Sie sie als Slot-Einstellungen, um unterschiedliche Werte pro Slot beizubehalten. Nutzen Sie den Pfad für Integritätsprüfungen (Health check path), um fehlerhafte Instanzen während Rollouts aus der Rotation zu entfernen. Änderungen lösen einen Neustart der App aus, es sei denn, in Ihrem Framework sind dynamische Neulademuster konfiguriert.
• Verbindungszeichenfolgen:
  • Werden separat verwaltet und als Umgebungsvariablen bereitgestellt; .NET-Apps erhalten zusätzlich eine anbieterspezifische Konfiguration. Zu den Typen gehören SQLAzure, SQLServer, MySQL, PostgreSQL und Custom. Markieren Sie sie gegebenenfalls als Slot-Einstellungen, um den Austausch von Geheimnissen beim Swapping zu vermeiden.
• Key Vault-Referenzen:
  • Referenzieren Sie Geheimnisse direkt in den App-Einstellungen und Verbindungszeichenfolgen mit der speziellen Syntax @Microsoft.KeyVault(SecretUri=https://<vault>.vault.azure.net/secrets/<name>/<version>) oder versionslosen URIs, um Rotationen automatisch zu übernehmen. Weisen Sie der App eine system- oder benutzerseitig zugewiesene verwaltete Identität zu und erteilen Sie ihr dann die Berechtigung „Get secret“ (über RBAC oder eine Zugriffsrichtlinie) für den Vault. Die Plattform löst die Werte auf und aktualisiert sie, ohne die Geheimnisse in der App Service-Konfiguration offenzulegen. Um TLS-Zertifikate aus Key Vault zu verwenden, importieren Sie sie als Zertifikate oder verwenden Sie von der Plattform unterstützte Zertifikatsreferenzen.

Deployment-Slots im Detail und Operational Excellence

Verwenden Sie einen Staging-Slot als CI/CD-Ziel. Nach der Bereitstellung:

• Führen Sie Warm-up-Pings und Integritätsprüfungen durch, um JIT, Caches und Datenbankverbindungen vorzubereiten.
• Validieren Sie Konfigurationsunterschiede mithilfe von Slot-Einstellungen, um Produktionsgeheimnisse und Endpunkte zu isolieren.
• Führen Sie einen Swap mit Vorschau durch, um den Staging-Slot unter dem Produktions-Hostnamen zu testen, bevor Sie den Vorgang abschließen. Wenn Fehler auftreten, brechen Sie den Swap ab, um sofort ein Rollback durchzuführen.
• Für die progressive Bereitstellung (Progressive Delivery) verwenden Sie Traffic Routing, um einen kleinen Prozentsatz an den Canary-Slot zu leiten und die Metriken und Protokolle von App Insights zu überwachen. Erhöhen Sie den Anteil schrittweise und schließen Sie den Swap ab, wenn die SLOs eingehalten werden.

Praktisches Problemszenario

Starbucks führt eine neue Web-Bestellplattform ein, die Lastspitzen bei Werbeaktionen bewältigen, die Integration mit Social Logins ermöglichen, interne APIs schützen und Bestell-Workflows im Hintergrund zuverlässig verarbeiten muss.

1. Wählen Sie den Premium v3 App Service-Plan mit zwei Deployment-Slots (Staging, Produktion)

• Warum: Premium v3 bietet schnellere CPUs und SSDs für Seitenladevorgänge mit geringer Latenz und höheren Durchsatz sowie Slots und automatische Skalierung. Slots ermöglichen Zero-Downtime-Swaps und ein schnelles Rollback bei Lastspitzen während Werbeaktionen.

2. Implementieren Sie CI/CD mit GitHub Actions, um im Staging-Slot bereitzustellen

• Warum: GitHub Actions bietet eine Repository-native Automatisierung. Die Bereitstellung im Staging-Slot ermöglicht Warm-up und Validierung, bevor der Kundenverkehr beeinträchtigt wird. Der Workflow verwendet Oryx, um bei einem Push auf den Main-Branch zu bauen und bereitzustellen, was konsistente Builds sicherstellt.

3. Aktivieren Sie Easy Auth mit Microsoft Entra ID und Google als Provider; aktivieren Sie den Token Store

• Warum: Easy Auth lagert OAuth/OIDC-Flows aus und reduziert so die Angriffsfläche von benutzerdefiniertem Sicherheitscode. Mehrere Provider unterstützen die Anmeldepräferenzen der Verbraucher. Der Token Store vereinfacht nachgelagerte API-Aufrufe (z. B. an einen Mikroservice für Treueprofile) durch die Verwendung von zwischengespeicherten Tokens, die über /.auth-Endpunkte bereitgestellt werden.

4. Konfigurieren Sie benutzerdefinierte Domänen und TLS

• Warum: Binden Sie order.starbucks.com über CNAME ein, erzwingen Sie „Nur HTTPS“ und legen Sie für die Compliance mindestens TLS 1.2 fest. Verwenden Sie ein App Service Managed Certificate für den Staging-Slot, um den Verwaltungsaufwand zu reduzieren, und laden Sie für die Produktion ein PFX von der Unternehmens-CA hoch, um die Marken- und Zertifikatsrichtlinien zu erfüllen.

5. Verwenden Sie das WebJobs SDK mit einem Azure Storage Queue-Trigger für die Bestellabwicklung

• Warum: Ein kontinuierlicher WebJob verarbeitet Nachrichten bei ihrem Eintreffen, entkoppelt den Checkout von der Abwicklung und glättet Lastspitzen. Mit „Always On“ und planbasierter Aufskalierung (Scale-Out) erhöht sich der Durchsatz automatisch mit zusätzlichen Instanzen. Die Verarbeitung von Poison Queues isoliert fehlerhafte Nachrichten, ohne die Pipeline zu unterbrechen.

6. Sichern Sie ausgehende Geheimnisse mit Key Vault-Referenzen und einer systemseitig zugewiesenen verwalteten Identität

• Warum: Geheimnisse befinden sich niemals in der App Service-Konfiguration. Die Identität hat den geringstmöglichen Zugriff (Least Privilege) auf Key Vault, und versionslose Geheimnis-URIs ermöglichen eine nahtlose Rotation.

7. Schützen Sie interne APIs durch Netzwerkkonfiguration

• Warum: Platzieren Sie interne Mikroservices hinter einem Private Endpoint; die öffentliche Web-App ruft sie über VNet-Integration (Premium v3) in einem gesicherten Backend auf. Wenn in Zukunft eine strengere Isolierung erforderlich ist, migrieren Sie die Web-Ebene in eine ILB ASE, um den gesamten eingehenden Datenverkehr privat zu machen und gleichzeitig die App Service-Funktionen beizubehalten.

8. Release-Strategie mit Canary-Deployment und Swap

• Warum: Leiten Sie 5 % des Traffics zum Staging-Slot, um während einer Werbeaktion eine Live-Validierung durchzuführen. Überwachen Sie Latenz, Fehlerbudgets und die Checkout-Konversionsrate über Application Insights. Wenn der Zustand gut ist, führen Sie einen Swap mit Vorschau durch; andernfalls brechen Sie den Vorgang ab und untersuchen das Problem, um die Customer Experience zu erhalten.

Alle Domänen · Azure Functions und Serverless Computing →

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

Microsoft durchsuchen →