Developing Solutions for Microsoft Azure

Laut Microsoft-Dokumentation bietet Strong consistency Linearisierbarkeit: Lesevorgänge geben immer den neuesten bestätigten Schreibvorgang zurück. Sie hat die höchste Schreiblatenz, weil Daten synchron über Regionen hinweg repliziert und bestätigt werden müssen. Die fünf Grade von stärkstem bis schwächstem: Strong, Bounded Staleness, Session, Consistent Prefix, Eventual.

Warum die Ablenkungsoptionen falsch sind:

• Eventual: Schwächste Konsistenz mit der niedrigsten Latenz und ohne Ordnungsgarantien.
• Session: Mittlere Stufe; garantiert monotone Lese-/Schreibvorgänge nur innerhalb einer Client-Session.
• Bounded staleness: Nahe an Strong, erlaubt aber ein konfigurierbares Verzögerungsfenster (Zeit oder Operationen).

Prüfungstipp: Kenne alle fünf Grade in der richtigen Reihenfolge. Strong = Linearisierbarkeit + höchste Latenz. Schreiblatenz entspricht 2x RTT zwischen den am weitesten entfernten Regionen.

Laut Microsoft-Dokumentation bewirkt ein Trigger, dass eine Function ausgeführt wird, und definiert, wie sie aufgerufen wird. Jede Function muss genau einen Trigger haben. Bindings verbinden Functions deklarativ mit externen Ressourcen für Eingabe/Ausgabe, ohne Verbindungs-Boilerplate schreiben zu müssen. Eine Function kann mehrere Input- und Output-Bindings haben, aber nur einen Trigger.

Warum die Ablenkungsoptionen falsch sind:

• 'Trigger sends data out; binding receives in': Umgekehrt: Triggers rufen die Function auf; bindings behandeln Daten-I/O in beide Richtungen.
• 'Same thing with different names': Triggers und bindings erfüllen grundlegend unterschiedliche Zwecke (Aufruf vs. Datenverbindung).
• 'Triggers work only with HTTP': Triggers unterstützen HTTP, timer, queue, blob, Cosmos DB, Event Hub und viele weitere Services.

Prüfungstipp: Ein Trigger pro Function (Aufruf). Mehrere bindings erlaubt (Daten-I/O). Bindings sind deklarativ: kein SDK-Verbindungscode nötig.

System-assigned managed identities sind an den Lebenszyklus einer einzelnen Azure-Ressource gebunden: Sie werden mit der Ressource erstellt und mit der Ressource gelöscht (1:1-Beziehung). User-assigned managed identities sind eigenständige Azure-Ressourcen mit unabhängigem Lebenszyklus, die von mehreren Ressourcen gemeinsam genutzt werden können (n:m). Analyse der Distraktoren: Beide Varianten sind kostenlos – es gibt keinen Kostenunterschied. Beide unterstützen dieselben Authentifizierungsmechanismen – keine Unterscheidung zwischen Zertifikat und Secret. Beide können über RBAC auf dieselben Azure-Dienste zugreifen – der Zugriffsumfang hängt von den Rollenzuweisungen ab, nicht vom Identitätstyp. Ref: learn.microsoft.com/entra/identity/managed-identities-azure-resources/overview

Auto-Instrumentierung (codeless attach) aktiviert das Monitoring mit Application Insights ohne jede Codeänderung. In App Service aktivierst du sie über das Azure-Portal oder die CLI. Sie erfasst automatisch Request-Telemetrie, Dependency Tracking, Exception-Logging und Performance Counter für .NET, Java, Node.js und Python. Analyse der Distraktoren: Manuelle SDK-Instrumentierung erfordert das Hinzufügen von NuGet-/npm-Paketen und Codeänderungen. Custom Telemetry Processors erfordern eine SDK-Integration und Code zum Filtern oder Verändern der Telemetrie. Das OpenTelemetry SDK erfordert ebenfalls Codeänderungen, um Exporter zu konfigurieren. Auto-Instrumentierung tauscht Anpassungstiefe gegen die Geschwindigkeit einer Einrichtung ganz ohne Code. Ref: learn.microsoft.com/azure/azure-monitor/app/codeless-overview