Microsoft Azure Administrator (AZ-104) — Übungsfragen und Probeprüfung

Die richtige Antwort ist Falsch. Wenn du eine virtuelle Maschine in einer einzelnen Verfügbarkeitszone bereitstellst, ist sie an diese Zone gebunden. Fallen die Rechenzentren hinter dieser Zone komplett aus, geht die VM mit ihnen unter — eine zonale VM ist vor Ausfällen in *anderen* Zonen geschützt, nicht vor dem Ausfall ihrer eigenen. In der offiziellen Dokumentation heißt es: „Viele Azure-Regionen bieten Verfügbarkeitszonen, also voneinander getrennte Gruppen von Rechenzentren innerhalb einer Region. Jede Verfügbarkeitszone hat eine unabhängige Stromversorgung, Kühlung und Netzwerkanbindung.“ Schutz vor dem kompletten Ausfall eines Rechenzentrums entsteht dadurch, dass du Ressourcen *über mehrere* Verfügbarkeitszonen verteilst oder zonenredundante Dienste nutzt: Fällt eine Zone aus, laufen die Instanzen in den übrigen Zonen weiter. Die Option „Wahr“ (Wahr) ist falsch, weil sie den Vorteil einer Bereitstellung über mehrere Zonen beschreibt und nicht den einer einzelnen VM in einer einzigen Zone. Für eine einzelne zonale VM ist der komplette Ausfall des Rechenzentrums ihrer eigenen Zone genau das Szenario, gegen das sie nicht geschützt ist — deshalb empfiehlt Microsoft, VMs für Hochverfügbarkeit über Verfügbarkeitszonen zu verteilen. (Quelle: https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview)

Warnungsregeln für die Protokollsuche sind die richtige Wahl, weil sie eine KQL-Abfrage (Kusto Query Language) in einem festgelegten Intervall gegen Daten in einem Log Analytics-Arbeitsbereich auswerten. Wenn das Abfrageergebnis eine bestimmte Bedingung erfüllt (z. B. Anzahl der HTTP-500-Fehler > 10), wird die Warnung ausgelöst. Laut der Microsoft-Dokumentation kannst du mit Azure Monitor-Warnungen ‚auf Basis jeder Metrik- oder Protokolldatenquelle in der Datenplattform von Azure Monitor warnen‘. Warnungen für die Protokollsuche funktionieren konkret so, dass sie in regelmäßigen Abständen Protokollabfragen gegen Daten aus Log Analytics oder Application Insights ausführen.

Warum die einzelnen falschen Optionen nicht passen:

• A. Smart Detection-Warnung: Smart Detection ist eine Funktion von Application Insights, die mithilfe von Machine Learning automatisch Leistungsanomalien und mögliche Probleme erkennt. Sie erlaubt dir nicht, eigene KQL-Abfragen mit bestimmten Schwellenwerten und Auswertungsintervallen zu definieren — sie arbeitet proaktiv und automatisch und wird in dieser Form nicht von dir konfiguriert.

• C. Metrikwarnungsregel: Metrikwarnungen werten in regelmäßigen Abständen numerische Metrikdaten aus (z. B. CPU-Auslastung in Prozent, Arbeitsspeichernutzung). Sie können über ‚Metrikwarnungen für Protokolle‘ zwar auch mit Metriken aus Log Analytics arbeiten, aber im Szenario ist ausdrücklich von der Auswertung einer KQL-Abfrage gegen Log Analytics-Daten die Rede, und genau das kennzeichnet eine Warnungsregel für die Protokollsuche und keine Metrikwarnungsregel.

• D. Warnungsregel für das Aktivitätsprotokoll: Warnungen zum Aktivitätsprotokoll werden durch Verwaltungsereignisse an Azure-Ressourcen ausgelöst, die im Aktivitätsprotokoll aufgezeichnet werden, etwa wenn eine VM deallokiert oder eine Ressource erstellt bzw. gelöscht wird. Sie werten keine KQL-Abfragen gegen Anwendungstelemetrie oder benutzerdefinierte Protokolldaten aus.

(Quelle: https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview)