Microsoft AZ-204: Azure Functions und Serverless Computing — 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 Functions ist ein serverloser Compute-Dienst, der für ereignisgesteuerte und kurzlebige Workloads optimiert ist. Er abstrahiert die Infrastruktur, sodass Sie sich auf Code konzentrieren können, der auf Ereignisse von HTTP-Endpunkten, Warteschlangen, Blobs, Datenänderungs-Feeds und Streaming-Diensten reagiert. Sie wählen einen Hostingplan aus, der das Skalierungs-, Preis- und Kaltstartverhalten bestimmt, binden Ihren Code mit deklarativen Bindungen an Trigger und Datenquellen und erstellen optional langlebige, zuverlässige Workflows mit Durable Functions. Robuste Konfiguration, wiederholbare Bereitstellung und umfassende Beobachtbarkeit (Observability) mit Application Insights runden die Plattform für Systeme auf Produktionsniveau ab.

Hostingpläne, Skalierung und Kaltstarts

Die Auswahl eines Hostingplans bestimmt die Ausführungsmerkmale und die Kosten.

• Consumption-Plan (Verbrauchsplan):

  • Skalierung und Preise: Bezahlung pro Ausführung und Ressourcenverbrauch. Die Plattform skaliert automatisch auf Basis von Ereignissen. Die Anzahl der Instanzen wird bei Inaktivität auf null skaliert.
  • Ausführungsgrenzen: Das Timeout für Funktionen ist für Nicht-HTTP-Funktionen auf bis zu 10 Minuten konfigurierbar; HTTP-Funktionen haben aufgrund der Client-Konnektivität praktisch kürzere Timeouts.
  • Kaltstart: Kaltstarts treten nach Leerlaufzeiten oder beim Aufskalieren (Scale-Out) auf, wenn neue Instanzen initialisiert werden. Die Startzeit hängt von der Sprache, den Abhängigkeiten und der App-Größe ab.
  • Netzwerk/Features: Unterstützt standardmäßig öffentliche Netzwerke. Eingeschränkter Funktionsumfang im Vergleich zum Premium-Plan (z. B. keine VNET-Integration). Bereitstellungsslots (Deployment Slots) sind nicht verfügbar.

• Premium-Plan:

  • Skalierung und Preise: Skaliert auf Basis von Ereignissen, hält aber „vorgewärmte“ Instanzen bereit, um Kaltstarts zu vermeiden. Die Abrechnung erfolgt nach Core-Sekunden und Arbeitsspeicher, der für aktive und vorgewärmte Instanzen zugewiesen ist.
  • Ausführungsgrenzen: Praktisch unbegrenzte Ausführungsdauer (abhängig von den Einschränkungen des HTTP-Clients). Empfohlen für latenzempfindliche oder intensivere Workloads.
  • Kaltstart-Minimierung: Vorgewärmte Instanzen halten die Laufzeitumgebung (Runtime) aktiv. Sie steuern die Anzahl der vorgewärmten Instanzen pro Plan und sorgen so für eine vorhersagbare Latenz bei Lastspitzen.
  • Netzwerk/Features: VNET-Integration, private Endpunkte, größere Instanzgrößen und Bereitstellungsslots werden unterstützt.

• Dedicated-Plan (App Service):

  • Skalierung und Preise: Läuft auf bereitgestellten App Service-Instanzen mit manuellen oder automatischen Skalierungsregeln. Sie bezahlen für den zugrunde liegenden App Service-Plan, unabhängig von der Nutzung.
  • Ausführungsgrenzen: Kein von der Plattform vorgegebenes Timeout für die Hintergrundausführung. Ideal, wenn Sie bereits über freie App Service-Kapazitäten verfügen oder eine konsistente Leistung benötigen.
  • Kaltstart-Minimierung: Aktivieren Sie „Always On“, um die App geladen zu halten. Kein Skalieren auf null; die Instanzen bleiben aktiv („warm“).

Wählen Sie den Consumption-Plan für kostenoptimierte, sporadische Workloads, den Premium-Plan für Anforderungen mit geringer Latenz und VNET-Bedarf und den Dedicated-Plan, wenn Sie mit bestehender App Service-Kapazität konsolidieren oder volle Kontrolle benötigen. Für extrem niedrige Latenzzeiten reduziert der Premium-Plan mit vorgewärmten Instanzen oder der Dedicated-Plan mit „Always On“ die Kaltstarts. Minimieren Sie die Auswirkungen von Kaltstarts weiter, indem Sie Abhängigkeiten reduzieren, „Run-From-Package“ verwenden und Clients verzögert (lazy) initialisieren.

Trigger und Bindings

Funktionen werden durch Trigger aktiviert und interagieren über Bindings mit Daten. Trigger definieren, wie und wann eine Funktion ausgeführt wird. Bindings stellen deklarativ eine Verbindung zu externen Diensten für die Ein-/Ausgabe her, ohne dass imperativer SDK-Code erforderlich ist.

Gängige Trigger:

• HTTP-Trigger: Stellt Endpunkte für REST-APIs oder Webhooks bereit. Autorisierungsstufen umfassen Anonymous, Function und Admin, die über Schlüssel oder Plattform-Authentifizierung erzwungen werden. Berücksichtigen Sie Idempotenz und Timeouts für langlaufende Aufgaben; lagern Sie diese bei Bedarf in eine Warteschlange oder Durable Functions aus.
• Timer-Trigger: CRON-basierte Zeitpläne werden auf einer einzigen Instanz pro App (pro Timer) ausgeführt. Verwenden Sie NCRONTAB-Ausdrücke mit Zeitzonenkonfiguration. Ideal für Wartungs-, Polling- und Bereinigungsaufträge.
• Azure Storage Queue-Trigger: Reagiert auf Nachrichten in einer Warteschlange. Unterstützt die Verarbeitung von Poison Messages mit einer -poison-Warteschlange, nachdem ein Schwellenwert für die Anzahl der Dequeue-Vorgänge überschritten wurde. Konfigurieren Sie Batch-Größe, Sichtbarkeits-Timeout und Parallelität über host.json.
• Azure Blob Storage-Trigger: Reagiert auf Blob-Erstellungs-/-Aktualisierungsereignisse durch eine Kombination aus Polling und Event Grid-Benachrichtigungen. Verwenden Sie Pfadmuster, um den Geltungsbereich auf Container und Präfixe zu beschränken. Verstehen Sie die Eventual Consistency und das Wiederholungsverhalten bei großen Blob-Uploads.
• Azure Event Hubs-Trigger: Verarbeitet Ereignisströme mit hohem Durchsatz mit Checkpointing. Konfigurieren Sie Partitions-Parallelität, Batch-Größe und Prefetch für den Durchsatz. Geeignet für Telemetrie und Stream-Verarbeitung, wobei die Reihenfolge pro Partition erhalten bleibt.
• Azure Service Bus-Trigger: Unterstützt Warteschlangen- oder Topic-Abonnements. Konfigurieren Sie das Verhalten von maxConcurrentCalls, Prefetch und Auto-Complete. Dead-Letter-Queues (Warteschlangen für unzustellbare Nachrichten) erfassen Nachrichten, die die maximalen Zustellversuche überschreiten, zur späteren Untersuchung.
• Azure Cosmos DB-Trigger: Lauscht auf den Change Feed für Einfüge- und Aktualisierungsvorgänge. Skaliert mit der Anzahl der physischen Partitionen; stellen Sie eine ausreichende RU-Bereitstellung sicher. Verwenden Sie eine Leases-Collection, um das Scale-Out über Instanzen hinweg zu koordinieren.

Bindings:

• Input-Bindings: Liefern Daten in die Funktion, z. B. Blob-Inhalte, Tabellenentitäten, Cosmos DB-Dokumente oder Metadaten von Warteschlangennachrichten. In .NET definieren Attribute (z. B. [BlobInput]) oder function.json das Binding; in anderen Sprachen erfolgt die Konfiguration deklarativ.
• Output-Bindings: Schreiben Daten ohne SDKs, z. B. eine Nachricht in eine Warteschlange einreihen, ein Blob erstellen, an Event Hub/Service Bus senden oder in Cosmos DB schreiben. Funktionen können mehrere Output-Bindings haben oder eine einzelne Ausgabe aus der Funktionssignatur zurückgeben.
• Binding-Ausdrücke: Parametrisieren Sie Verbindungsdetails und Pfade mithilfe von Platzhaltern, z. B. {queueTrigger}, {rand-guid}, und umgebungsbasierten App-Einstellungen. Verbindungseigenschaften verweisen auf die Namen von Anwendungseinstellungen, was die Rotation und Verwaltung von Geheimnissen ermöglicht. Bevorzugen Sie identitätsbasierte Verbindungen mit Managed Identity, wo dies unterstützt wird, um das Einbetten von Geheimnissen zu vermeiden.
• Parallelität und Batch-Verarbeitung: Steuern Sie Parallelität und Batch-Größen in host.json pro Erweiterung (queues, serviceBus, eventHub), um den Durchsatz und die Speichernutzung abzustimmen. Validieren Sie die Handhabung von Poison/Dead-Letter-Nachrichten, um sicherzustellen, dass Fehler sichtbar gemacht werden.

Entwerfen Sie Trigger und Bindings für Idempotenz, Backpressure und Fehlerisolierung. Für Quellen mit At-least-once-Zustellung (Warteschlangen, Event Hubs, Service Bus) schreiben Sie Funktionen so, dass sie idempotent und widerstandsfähig gegenüber Wiederholungsversuchen sind.

Durable Functions: Zuverlässige Orchestrierungsmuster

Durable Functions erweitert Azure Functions um zustandsbehaftete, zuverlässige Orchestrierung für langlebige Workflows unter Verwendung eines Durable Task Frameworks.

Funktionstypen:

• Orchestrator-Funktionen: Beschreiben die Workflow-Logik im Code unter Verwendung deterministischer Konstrukte. Orchestratoren spielen den Zustand bei Ereignissen erneut ab und müssen nicht-deterministische APIs (DateTime.Now, Zufallszahlen, Netzwerkaufrufe) ohne entsprechende Hilfsmittel vermeiden. Verwenden Sie Durable Orchestration Client-APIs, um Instanzen zu starten, abzufragen und zu verwalten.
• Activity-Funktionen: Führen diskrete Arbeitseinheiten aus, wie das Aufrufen externer APIs, die Durchführung CPU-gebundener Operationen oder E/A-Aufgaben. Activities sind wiederholbar und unabhängig skalierbar.
• Entity-Funktionen: Stellen langlebige, adressierbare Entitäten mit kleinem, konsistentem Zustand und Operationen bereit (z. B. Zähler, Gerätestatus). Entitäten verarbeiten serialisierte Operationen mit Single-Threaded-Konsistenz.

Muster:

• Function Chaining (Funktionsverkettung): Reihen Activities in einer definierten Reihenfolge aneinander (A → B → C) und geben die Ergebnisse an die nächste weiter. Nützlich für Pipelines mit Abhängigkeiten.
• Fan-Out/Fan-In: Starten mehrere Activities parallel und fassen die Ergebnisse zusammen. Orchestratoren koordinieren mit einer Semantik, die Task.WhenAll ähnelt. Verwenden Sie dies für die parallele Verarbeitung unabhängiger Aufgaben.
• Menschliche Interaktion (externe Ereignisse): Warten auf externe Eingaben (z. B. eine Genehmigung) mit WaitForExternalEvent, inklusive Timeouts und Eskalation. Kombinieren Sie dies mit Durable Timers, um SLAs und Kompensationslogik zu implementieren.
• Asynchrone HTTP-APIs: Starten Orchestrierungen und geben 202 Accepted mit Status-/Abfrage-URLs zurück. Clients fragen die vom Durable Client-Binding bereitgestellten Statusendpunkte ab, um das Endergebnis oder den Zustand zu erhalten.
• Monitor: Wiederkehrende Prüfpunkte, die nach einem Zeitplan ausgeführt werden, z. B. das Abfragen eines Endpunkts, bis eine Bedingung erfüllt ist, unter Verwendung von Durable Timers, um die Belegung von Rechenressourcen zu vermeiden.
• Aggregator/Entity: Speichern kleinen Zustand neben der Logik mithilfe von Entity-Funktionen für eine feingranulare Koordination ohne einen vollständigen Workflow.

Durable Functions garantieren eine mindestens einmalige (at-least-once) Ausführung von Activities und einen genau einmaligen (exactly-once) Fortschritt des Orchestrator-Zustands. Sie persistieren den Zustand im Speicher (Standard ist Azure Storage); stellen Sie sicher, dass das Speicherkonto die Anforderungen an Durchsatz und Zuverlässigkeit erfüllt. Verwenden Sie benutzerdefinierte Wiederholungsrichtlinien für vorübergehende Fehler und lösen Sie Ereignisse für externe Interaktionen aus. Bei sehr langen Prozessen können Durable Orchestrations dank der integrierten Dauerhaftigkeit Tage bis Monate lang laufen.

← Azure App Service und Web-Apps · Alle Domänen · Azure Storage und Blob Storage →

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

Microsoft durchsuchen →