AZ-104 — Virtuelle Computer und Compute: 74 Übungsfragen

Step 1: Anforderungen verstehen — Es wird eine automatisierte, planbare Lösung benötigt, die die gesamte VM (OS, Daten, und konsistenter Anwendungszustand) sicher speichern und wiederherstellen kann. Zusätzlich sollten Retention, Management und einfache Wiederherstellungsoptionen vorhanden sein.

Step 2: Vergleich der Lösungen — Azure Backup (Recovery Services Vault) ist ein Azure-Dienst, der VM-spezifische Backups orchestriert, konsistente Snapshots (VSS für Windows) ermöglicht, Retentionsrichtlinien verwaltet und Wiederherstellungen auf VM-Ebene bzw. Dateiebene erlaubt. Managed Disk Snapshots sind nützlich, aber sie sind niedriger Ebenen-Werkzeuge: Sie müssen eigene Automatisierungs-, Retentions- und Konsistenzlogik implementieren; Snapshots allein liefern nicht unbedingt Anwendungs-konsistente Backups (ohne VSS) und fehlen zentrale Verwaltungstools. Azure Site Recovery (ASR) ist ein Disaster-Recovery-Replicationsdienst, kein Ersatz für Backups; ASR repliziert VMs für Failover, ist aber nicht primär für langfristige Retention/Point-in-Time-Backups gedacht. Eine interne FTP-basierte Kopie ist fehleranfällig, bietet keine konsistente Systemabbildwiederherstellung und verkompliziert Recovery/Compliance.

Step 3: Tradeoffs/Implementierung — Azure Backup bietet einfache Einrichtung im Portal oder per ARM/Bicep, ermöglicht GRS/LRS/Confi­guration der Vault-Replikation und unterstützt application-consistent snapshots (bei Windows via VSS). Tradeoffs: geringfügige Kosten für den Vault und Speicher; wenn Sie sehr kurze RPO/RTO für georedundante Failover benötigen, kombinieren Sie ASR und Backup je nach Szenario. Trap: Viele Admins verwechseln ASR (Replikation/Fallover) mit Backup; ASR ist für Business Continuity/Failover gedacht, nicht für point-in-time langfristige Backups und gesetzliche Aufbewahrungsanforderungen. Warum die falschen Antworten fehlschlagen: - Managed Disk Snapshots via Skript: Funktionieren für kurzfristige, manuelle Zustandskopien, aber benötigen eigene Orchestrierung, Retention-Management, und liefern nicht standardmäßig application-consistent Backups oder einfache Wiederherstellungsoptionen. - Azure Site Recovery: Gut für Replikation und Failover, aber kein Ersatz für Backups, da keine integrierte, langfristige Retention/Punktwiederherstellungsverwaltung geboten wird. - Interne Backup-Software per FTP: Bietet keine Abbildung der gesamten VM inkl. Boot-Volume, keine native Integration in Azure-Restore-Prozesse, erhöht Komplexität und potenzielle Compliance-Probleme. Praxis-Hinweis: Verwenden Sie Recovery Services Vault und konfigurieren Sie Backup-Richtlinien (Schedule, Retention, ggf. GRS für zusätzliche Redundanz) sowie Application-consistent snapshots, um sichere und verwaltbare VM-Backups zu erhalten.

Step 1: Ziel definieren — Das Ziel ist, die Umgebung nicht zu unterbrechen und gleichzeitig einen früheren Zustand der VM verfügbar zu haben, um Dateien zu vergleichen oder in die Produktion zurückzuholen. Dies erfordert das Erstellen einer neuen VM aus dem Wiederherstellungspunkt.

Step 2: Funktionen des Recovery Services Vault nutzen — Azure Backup bietet mehrere Wiederherstellungsarten: Wiederherstellen als neue VM (erzeugt eine neue VM aus dem Snapshot), Wiederherstellen und Ersetzen der bestehenden VM (überschreibt die aktuelle Maschine), Wiederherstellung einzelner Dateien (File-level recovery) und das Wiederherstellen von Festplatten (Restore Disks) zur manuellen Wiederherstellung. Die sicherste Option, um Produktion nicht zu unterbrechen, ist 'Wiederherstellen als neue VM'.

Step 3: Tradeoffs und Follow-up — Erstellen Sie die neue VM in derselben oder einer anderen Ressourcengruppe/Region, prüfen Sie die wiederhergestellten Dateien, und migrieren Sie nur die benötigten Konfigurationen. Tradeoffs: Zusätzliche Kosten durch temporäre VM und Speicher; allerdings minimiert diese Methode das Risiko, produktive Dienste durch eine fehlerhafte Wiederherstellung zu unterbrechen. Trap: Ein häufiger Fehler ist die voreilige Auswahl 'Ersetzen der bestehenden VM' und damit unbeabsichtigtes Zurücksetzen der produktiven Instanz. Ebenfalls wird oft überschätzt, dass Dateiwiederherstellung immer ausreichend ist — einige Konfigurationsänderungen betreffen Systemzustand oder privilegierte Pfade, die besser über eine vollständige VM-Wiederherstellung validiert werden. Warum die falschen Antworten fehlschlagen: - Ersetzen der bestehenden VM direkt: Überschreibt die produktive Maschine und verursacht potenziellen Ausfall oder unerwünschte Nebeneffekte; widerspricht der Anforderung, den Betrieb weiterlaufen zu lassen. - Nur Wiederherstellen einzelner Dateien: Kann funktionieren, wenn nur wenige Dateien betroffen sind, bietet aber keine garantierte Wiederherstellung des gesamten Systemzustands und kann kompliziert sein, wenn Berechtigungen oder Systemdienste betroffen sind. - Exportieren des Backups in ein Storage-Konto und mounten: Kein direkter, standardisierter Weg im Azure Backup-Flow; zusätzlich ist es aufwendig und bietet weniger Komfort als die 'Create VM'-Option. Praxis-Hinweis: Nutzen Sie 'Create VM' aus dem gewünschten Recovery Point, testen Sie die wiederhergestellte Maschine zuerst in einer isolierten Netzwerkkonfiguration, und migrieren Sie nur geprüfte Konfigurationsdateien in die Produktion.

Step 1: Verstehen, wie ARM/Bicep zonale Ressourcen modellieren. In ARM und Bicep legen Sie die Zonen für zonale Ressourcen explizit über die Eigenschaft "zones" fest (z. B. zones: [ '1' ]). Für Microsoft.Compute/virtualMachines-Ressourcen bedeutet das, dass jede VM-Ressource gezielt einer bestimmten Zone zugewiesen wird. Managed Disks sind eigenständige Ressourcen und müssen ebenfalls als zonal oder als Unterstützung für ZRS/regionale Redundanz entsprechend deklariert werden.

Step 2: Umsetzung und Abwägungen. Wenn Sie zonale Redundanz in Templates erreichen wollen, definieren Sie in Ihrer Bicep-Datei oder ARM-Template die VMs mit unterschiedlichen zones-Werten (z. B. '1', '2', '3'). Für Datenintegrität müssen Sie auch die Disks als zonale Ressourcen bereitstellen oder geeignete Replikationsstrategien nutzen (z. B. Read-Access Geo-Redundant Storage für Blob-Backups, oder zonal snapshots). Tradeoffs: Zonal Deployments können zu unterschiedlichen Kosten führen und erfordern, dass abhängige Ressourcen (z. B. Public IPs, NICs) ebenfalls zonal-kompatibel sind. Außerdem hat nicht jede Ressource automatisch Zonensupport; prüfen Sie die Dokumentation.

Step 3: Template-Testing und RBAC/Netzwerküberlegungen. Testen Sie die Template-Deployments in einer Staging-Subscription. Sorgen Sie dafür, dass das Service Principal/Benutzer, das die Template-Deployment ausführt, über die notwendigen RBAC-Rechte verfügt (Contributor/Owner auf Resource Group oder spezifische Rechte). Legen Sie NSGs, UDRs und Load Balancer entweder in der Vorlage an oder verweisen Sie auf bestehende Ressourcen. Nach Deployment validieren Sie Health-Probes und Failover-Verhalten. Trap: Ein häufiger Fehler ist zu glauben, dass Availability Sets in Templates automatisch zonale Redundanz bereitstellen — Availability Sets betreffen Fault/Update Domains innerhalb eines Rechenzentrums, nicht Availability Zones. Ein weiterer Irrtum ist, dass Proximity Placement Groups VMs über Zonen verteilen; tatsächlich zielen sie darauf ab, Ressourcen physisch nahe zu halten und haben nichts mit Zonenausfallsicherheit zu tun. Why each wrong answer fails: - Die Option "Eine einzelne Availability Set-Ressource anlegen und jedem VM-Resource die availabilitySet-Ref zuweisen": Availability Sets schützen vor Hardware-Fehlern innerhalb desselben Rechenzentrums, nicht gegen Zonenausfälle. Sie sind in ARM/Bicep korrekt nutzbar, lösen aber nicht das Requirements nach Availability Zones. - Die Option "Eine Proximity Placement Group in der Vorlage definieren, damit ARM die VMs automatisch über verschiedene Zonen verteilt": Proximity Placement Groups platzieren Ressourcen nahe beieinander (Niedrige Latenz), sie verteilen Ressourcen nicht automatisch über unterschiedliche Availability Zones. Daher erfüllt das nicht die Anforderung zonaler Redundanz. Fazit: Um zonale Redundanz mittels ARM/Bicep zu erreichen, müssen Sie explizit die "zones"-Eigenschaft für VMs setzen und sicherstellen, dass die zugehörigen Disks und abhängigen Ressourcen zonenkonform bereitgestellt werden. Availability Sets und Proximity Placement Groups decken unterschiedliche Szenarien ab und sind keine Ersatzlösung für Availability Zones.

Step 1: Ziel und SLA verstehen — Für ein SLA von bis zu 99,99 % muss die Architektur Zonenausfallsicherheit bieten. Availability Zones sind physisch getrennte Standorte innerhalb einer Azure-Region und schützen gegen Ausfälle auf Rechenzentrumsniveau.

Step 2: Komponenten auswählen — Um Zonenausfallsicherheit zu erreichen, müssen die VMs in unterschiedlichen Availability Zones platziert werden und ein zonenfähiger Load Balancer (Standard Load Balancer) eingesetzt werden, damit der Verkehrsfluss bei Ausfall einer Zone erhalten bleibt.

Step 3: Umsetzung und Tradeoffs — Sie erstellen oder replizieren die VM-Ressourcen in verschiedenen Zonen, konfigurieren den Standard Load Balancer mit Back-End-Pools in mehreren Zonen und überwachen die Gesundheit. Tradeoffs: höhere Netzwerk-Latenz minimal möglich, evtl. zusätzlicher Kostenaufwand für zonenredundante Dienste und konfigurierte Redundanz. Trap: Viele denken, Availability Sets bieten das gleiche Schutzniveau wie Availability Zones; das ist falsch — Availability Sets schützen nur gegen Hardwareausfälle innerhalb desselben Rechenzentrums und liefern typischerweise ein SLA von 99,95 %, nicht 99,99 %. Why each wrong answer fails: Option 1 (Availability Set + Basic Load Balancer) — Basic Load Balancer ist nicht zonenredundant und Availability Sets bieten niedrigeres SLA (bis zu 99,95 %), außerdem Basic LB hat Feature-Einschränkungen; Option 3 (Availability Set innerhalb einer Zone + Standard Load Balancer) — Ein Availability Set ist zonenintern gedacht (was Hardwarefehlertoleranz innerhalb eines Rechenzentrenclusters bietet), aber wenn beide Instanzen in derselben Zone stehen, schützt das nicht gegen Zonen-Ausfall; Option 4 (Einzelne VM + Premium SSD + automatische Reparatur) — Eine einzelne VM ist ein Single Point of Failure; Premium SSD schützt nur Storage-Performance und automatische Reparatur kann VM auf derselben fehlerhaften Hardware neu starten, bietet nicht den gewünschten Multi-Instance-Ausfallschutz. Zusammenfassend: Für 99,99 % SLA müssen Sie zonenverteilte Instanzen und zonenfähige Load-Balancing-Ressourcen verwenden.

Step 1: Nutzen Sie ein VM Scale Set für die Webfarm, da VMSS native Autoscale-Regeln auf Basis von Metriken wie CPU-Auslastung unterstützt. Damit können Sie Anzahl der Instanzen dynamisch an den Bedarf anpassen und das Management identischer VMs zentralisieren.

Step 2: Setzen Sie eine Application Gateway v2 als Layer-7 Load Balancer vor das VMSS ein, um TLS (HTTPS) zu terminieren, Cookie-basierte Sitzungsaffinität zu ermöglichen und optional WAF-Regeln zum Schutz der Webanwendung zu verwenden. Application Gateway bietet zudem integrierte Health Probes und enge Integration mit VMSS-Backend-Pools.

Step 3: Konfigurieren Sie Autoscale Regeln (z. B. zeitbasierte Mindest-/Höchstwerte und CPU-Trigger) und stellen Sie Health Probes so ein, dass nur gesunde Instanzen in den Verkehr gelangen. Testen Sie das Zusammenspiel von Gateway-Probe und VMSS-Upgrades. Trap: Ein häufiger Fehler ist, den Basic Load Balancer zu wählen, weil er günstiger ist; er arbeitet auf L4 und bietet keine Cookie-Affinity oder TLS-Termination. Ebenso ist Traffic Manager ein DNS-basierter Global Traffic Director, kein L7-Load-Balancer für Session-Affinity und TLS-Termination. Why each wrong answer fails: - Option 3: Basic Load Balancer arbeitet Layer 4 und bietet keine native Cookie-basierte Affinity oder TLS-Termination. Source-IP-Affinität kann bei NAT/Proxies fehlerhaft sein und ist nicht gleichwertig mit application-layer session affinity; außerdem fehlen WAF- und TLS-Features. - Option 4: Manuelles Skalieren ist fehleranfällig und nicht reaktiv genug für Lastspitzen; Azure Traffic Manager ist ein DNS-basiertes Routing-Produkt für globales Failover/Geolocation, es ersetzt keinen Layer-7 Load Balancer mit TLS-Termination und Session-Affinity. Beide Maßnahmen würden die gewünschten Anforderungen nicht gleichzeitig erfüllen. Tradeoffs: Application Gateway ist teurer als ein Basic Load Balancer, bietet aber notwendige L7-Funktionen; VMSS vereinfacht Skalierung, verlangt aber stateless- oder zustandsarme App-Architektur, oder externen Speicher für Session-Daten.

Step 1: Verwenden Sie Ephemeral-OS-Disks, wenn VMs kurzlebig und zustandslos sind. Ephemeral OS Disks werden lokal auf dem Host gespeichert (nicht auf verwalteten Platten) und erlauben deutlich schnellere Provisionierung und Neustarts. Prüfen Sie vorab, ob die gewählte VM-Größe und der gewählte VM-Typ Ephemeral-OS unterstützen (nicht alle VM-Serien tun das).

Step 2: Aktivieren Sie für die VMSS oder die VM die system-assigned Managed Identity. Weisen Sie dieser Identität in Azure RBAC spezifische Key Vault-Berechtigungen zu (z. B. Zugriff auf Secrets durch Zuweisung einer Rolle oder Key Vault Access Policies, je nach Vault-Konfiguration). Dadurch kann die VM beim Booten sicher Secrets abrufen, ohne dass Hardcoded Keys in Skripten verteilt werden.

Step 3: Testen Sie das Zusammenspiel von Ephemeral OS und Managed Identity: Stellen Sie sicher, dass die Boot-Extensions/Startskripte die Identity nutzen, um Kurzzeit-Zugriffstokens vom IMDS (Instance Metadata Service) zu erhalten und damit Key Vault Secrets anzufordern. Überwachen Sie Provisionierungszeiten und Eviction/Restart-Verhalten. Trap: Eine häufige Fehlannahme ist, dass Ephemeral-OS-Disks keine Images oder Shared Image Gallery unterstützen oder dass Managed Identities automatisch alle Rechte haben. Tatsächlich müssen Images passend sein und RBAC/Access-Policies bewusst vergeben werden. Why each wrong answer fails: - Option 2: Das direkte Einbetten von Storage-Account-Schlüsseln in Startskripte ist unsicher und widerspricht Best Practices; es erhöht das Risiko von Geheimnis-Leaks und erschwert Rotation/Auditing. Managed Identities sind die sichere Alternative. - Option 4: Die Aussage, Shared Image Gallery sei nicht mit Ephemeral OS Disks kompatibel, ist falsch. Shared Image Gallery-Images können für VMSS mit Ephemeral OS Disk verwendet werden, solange das Image und die VM-Größe Ephemeral unterstützen. Diese Option ist daher irreführend und nicht korrekt als Grund, Shared Image Gallery zu vermeiden. Tradeoffs: Ephemeral OS-Daten gehen beim Neustart verloren — gut für stateless Workloads, ungeeignet für persistente OS-Änderungen. Managed Identities erfordern RBAC-Planung, vermeiden aber Geheimnis-Management und erhöhen Sicherheit und Auditierbarkeit.

Step 1: Ursache verstehen — Wenn VMs mit Customer Managed Keys (CMK) verschlüsselt sind, benötigt der Backup-Dienst Zugriff auf die Schlüsseloperationen (z. B. UnwrapKey/WrapKey), um Snapshot/Backup-Operationen durchzuführen. Fehlt dieser Zugriff, schlägt das Backup fehl.

Step 2: Berechtigung sicher gewähren — Ermitteln Sie das Service Principal oder den vom Recovery Services Vault verwendeten Identitäts-Namen (Azure Backup hat in vielen Fällen eine spezifische Dienstidentität). Gewähren Sie diesem Principal im Key Vault eine Zugriffspolicy (oder verwenden Sie Key Vault RBAC), die nur die minimal erforderlichen Berechtigungen umfasst: für Keys typischerweise Get, UnwrapKey, WrapKey; für Secrets mindestens Get. Dies gewährleistet, dass Backup seine Aufgaben erledigen kann, ohne zu breit gefasste Rechte zu geben.

Step 3: Betriebs- und Sicherheitsaspekte — Trade-offs: Das Gewähren minimaler Rechte ist sicherer als breit gefasste Einstellungen; Sie sollten Änderungen auditieren und automatisieren (z. B. via Azure Policy oder IaC), um Konsistenz zu haben. Prüfen Sie außerdem die Vault-Replikation/Region-Settings (bei Cross Region Restore) und aktivieren Sie ggf. Soft Delete/Access Policy Logging. Trap: Ein häufiger Fehler ist, Key Vault weit zu öffnen (Option 2) oder Verschlüsselung zu deaktivieren (Option 3). Beide Varianten verletzen Sicherheitsanforderungen oder führen zu Compliance-Problemen. Hardcodierte Schlüssel oder Dateibasierte Speicherung (Option 4) sind unsicher und nicht zulässig. Warum die falschen Antworten fehlschlagen: - Option 2 (Key Vault auf "alle Azure-Dienste" öffnen): Diese Einstellung ist zu breit und hebt Sicherheit auf; sie ist nicht gemäß Principle of Least Privilege und kann Angriffsfläche erhöhen. - Option 3 (Verschlüsselung temporär deaktivieren): Deaktivieren von Verschlüsselung ist riskant, kann Compliance verletzen und ist operational aufwendig; es ist keine akzeptable dauerhafte Lösung. - Option 4 (Schlüssel in Textdatei ablegen): Das Speichern von Schlüsseln als Textdateien ist sicherheitskritisch, verletzt grundlegende Sicherheitsprinzipien und ist nicht supported. Fazit: Erteilen Sie präzise, minimal notwendige Key Vault-Rechte an das Recovery Services Vault/service principal für Backup-Operationen. Diese Lösung ist sicher, auditierbar und entspricht Azure Best Practices für CMK-gestützte Backups.

Step 1: Verständnis der verfügbaren Mechanismen — Azure Backup speichert Recovery Points in einer Recovery Services Vault. Um direkt aus einer Vault in eine andere Region wiederherstellen zu können, bietet Microsoft die Funktion Cross-Region Restore (CRR). CRR repliziert erforderliche Sicherungsdaten oder stellt die Möglichkeit bereit, einen Wiederherstellungs-Point in eine andere Region zu restaurieren, wenn die Primärregion beeinträchtigt ist.

Step 2: Konkrete Umsetzung — Aktivieren Sie CRR für die betreffende Recovery Services Vault (Antwort 1). Danach starten Sie im Vault einen Restore-Vorgang und wählen beim Wiederherstellen die Option 'Restore to a different region' bzw. die entsprechende Oberfläche, um Zielregion, Resource Group, virtuelle Netzwerke und Computernamen anzugeben (Antwort 2). Azure Backup übernimmt die notwendigen Schritte und stellt das VM-Abbild in der Zielregion bereit.

Step 3: Tradeoffs, Zugriffs- und Governance-Aspekte — CRR kann zusätzlichen Kosten und Compliance-Anforderungen unterliegen. Prüfen Sie RBAC und Abonnement-/Ressourcengruppen-Berechtigungen in der Zielregion; eventuell müssen Sie Service Principal oder Benutzerrollen in der Zielsubscription konfigurieren. Außerdem sollten Sie Netzwerk- und IP-Design planen (z. B. VNet-Subnetz, NSG, Peering) für die wiederhergestellte VM. Trap: Häufige Fehlannahme — Ein verbreiteter Irrtum ist, dass man einfach den Storage-Account der VM replizieren oder die VM-Datenträger manuell kopieren muss; für Azure Backup-basierte Wiederherstellungen in eine andere Region ist die Aktivierung von CRR und die Verwendung der Vault-Wiederherstellungsoption der korrekte, unterstützte Weg. Azure Site Recovery ist kein Ersatz für Backup-Restore und verfolgt andere Replikations-/Failover-Ziele. Warum jede falsche Antwort scheitert: - Antwort 1 (CRR aktivieren): Richtig — CRR ist die vorgesehene Funktion für Wiederherstellungen in eine andere Region aus einer Recovery Services Vault. - Antwort 2 (Restore und Zielregion wählen): Richtig — Nach Aktivierung von CRR können Sie beim Restore-Prozess eine Wiederherstellung in eine andere Region auslösen und alle notwendigen VM-Parameter wählen. - Antwort 3 (Storage Account auf LRS ändern): Falsch — Das Ändern der Replikationsoption eines Storage Accounts auf LRS (locally redundant storage) verschlechtert sogar die Redundanz; zudem sind VM-Backups in einer Recovery Services Vault gespeichert, nicht direkt in Ihrem VM-Storage-Account, sodass das Umschalten des VM-Storage-Accounts die Backup-Wiederherstellung in eine andere Region nicht herbeiführt. - Antwort 4 (Azure Site Recovery verwenden): Falsch als direkte Maßnahme für Backup-Restore — ASR ist ein Replikationsdienst für Failover/Disaster Recovery (Replikation von laufenden Maschinen) und nicht die native Backup-Wiederherstellungsfunktion; ASR kann zwar Replikation in eine andere Region ermöglichen, ist aber ein separater Ansatz mit unterschiedlichen Einsatzszenarien und erfordert vorherige Replikation/Einrichtung. Fazit: Für eine direkte Wiederherstellung einer gesicherten VM in eine andere Region sollten Sie CRR aktivieren und dann den Restore mit Wahl der Zielregion durchführen. Prüfen Sie zusätzlich Zugriffsrechte und Konfigurationsanforderungen in der Zielumgebung.

Step 1: Anforderungen zerlegen — Sie benötigen sowohl Schutz gegen gleichzeitige Auswirkungen von geplanten Wartungen (Update Domains) als auch gegen physische Hardwarefehler (Fault Domains). Azure bietet diese beiden Konzepte zusammen im Availability Set.

Step 2: Verfügbare Mechanismen prüfen — Availability Sets verteilen VMs über mehrere Fault Domains (für Hardware-Fehler) und Update Domains (für geplante OS- oder Hypervisor-Updates). Availability Zones sind für physische Trennung auf Rechenzentrums-Ebene gedacht, aber nur wenn Sie explizit zonale Ressourcen einsetzen; außerdem bietet eine einzelne Zone keine Update/Fault-Domain-Aufteilung aller drei Instanzen innerhalb derselben Zone. VM-Scale-Sets sind für Skalierung sinnvoll, aber ein Scale-Set allein garantiert nicht automatisch die gewollte Verteilung über Update/Fault Domains, besonders wenn nicht korrekt konfiguriert.

Step 3: Umsetzung und Tradeoffs — Erstellen Sie ein Availability Set (z. B. 3 Fault Domains, mehrere Update Domains) und weisen Sie die VMs dem Set bei der Erstellung zu. Tradeoffs: Availability Sets schützen innerhalb derselben Region und bieten keine Zonenausfall-Sicherheit; wenn Sie Zonen-Resilienz benötigen, müssen Sie mehrere zonale Instanzen oder zonenübergreifende Architekturen einsetzen, was komplexere Netzwerk- und IP-Designs erfordert. Trap: Ein häufiger Irrtum ist anzunehmen, Availability Zones ersetzen Availability Sets. Für Verteilung über Fault- und Update-Domains innerhalb desselben Rechenzentrumsverbunds ist das Availability Set weiterhin die richtige Wahl. Warum die falschen Antworten fehlschlagen: - Bereitstellen in derselben Availability Zone: Eine einzelne Zone verteilt nicht automatisch über Fault/Update Domains wie ein Availability Set; zudem wären alle drei VMs in derselben Zone bei einem Zonenausfall betroffen. - VM-Scale-Set mit Zonenverteilung: Das wäre eine valide Alternative wenn korrekt konfiguriert (mehrere zonale Instanzen), aber die Option beschreibt nicht eindeutig die Sicherstellung von Update/Fault-Domain-Verteilung für genau drei VMs; Scale-Sets sind außerdem für dynamische Skalierung gedacht. - Alle drei VMs auf derselben Host-VM: Das würde keinerlei Verfügbarkeitsvorteil bringen und ist weder eine unterstützte Architektur noch sicherheits- oder ausfallsicherheitskonform. Praxis-Hinweis: Wenn Ihre SLA-Anforderungen nur gegen Hardware- und Wartungsfehler gerichtet sind, verwenden Sie Availability Sets; für Schutz gegen komplette Zonenausfälle kombinieren Sie zonale VMs über mehrere Availability Zones.

Step 1: Zielsetzung und Azure-Prinzipien - Availability Sets ermöglichen, dass mehrere VMs einer Anwendung über Fault Domains (physische Hardware-/Rack-Trennung) und Update Domains (Wartungsfenster) verteilt werden. Um dies in ARM zu erzwingen, müssen Sie eine AvailabilitySet-Ressource definieren und die VM-Ressourcen darauf verweisen. Optional können Sie Plattformwerte für die Anzahl der Fault/Update Domains angeben, damit Azure weiß, wie viele Domänen zu verwenden sind.

Step 2: Konkrete Template-Konfigurationen - Eine AvailabilitySet-Ressource definieren: Im ARM-Template legen Sie einen Typ Microsoft.Compute/availabilitySets an, setzen properties und referenzieren dessen resourceId in der virtualMachines-Ressource (availabilitySet.id). Ohne diese Referenz verteilt Azure die VMs nicht automatisch auf Fault/Update Domains. - Plattform-Festlegung der Domain-Anzahlen: Die AvailabilitySet-Ressource akzeptiert Eigenschaften wie platformFaultDomainCount und platformUpdateDomainCount (bzw. die entsprechenden Felder) um zu bestimmen, in wie viele Domains die VMs verteilt werden. Standardwerte können unterschiedlich sein, daher ist explizite Angabe oft wünschenswert für deterministische Verteilung.

Step 3: Trade-offs und Deployment-Implikationen - Trade-off: Mehr Fault/Update Domains erhöhen Redundanz, können aber bei kleineren Subscription-Limits oder bei begrenztem Capacity-Plan zu Platzierungsproblemen führen. Von Administrationsseite erfordert es außerdem, dass VMs die AvailabilitySet-Referenz beim Erstellungszeitpunkt haben; nachträgliches Verschieben einer VM in ein Availability Set ist nicht direkt möglich. Trap: Häufige Fehlannahmen - Ein häufiger Fehler ist zu glauben, dass Availability Zones oder Proximity Placement Groups dieselbe Funktion erfüllen. Availability Zones sind für zonale Isolation, Proximity Placement Groups für Latenzoptimierung. Proximity Placement Groups kontrollieren nicht Update/Fault Domains. Warum jede falsche Antwort fehlschlägt - Die VMs mit einem availabilityZone-Feld versehen und die gleiche Zone angeben: Dies verteilt VMs nicht über Fault- und Update Domains; außerdem würde die gleiche Zone die Anwendung gegenüber Zone-Ausfällen anfällig machen. Zones sind eine andere Dimension von Isolation (Region → Zone) und ersetzen nicht die Domain-Verteilung innerhalb eines Rechenzentrums. - Für jede VM eine separate Proximity Placement Group anlegen: Proximity Placement Groups dienen dazu, VMs nahe zueinander im Netzwerk/Physik zu platzieren (niedrige Latenz) und haben keinen Einfluss auf Update- oder Fault-Domain-Verteilung. Tatsächlich könnte eine PPG das Availability-Targeting kontraproduktiv beeinflussen. Kontext zu RBAC/Netzwerk/Storage/Identity/Governance - RBAC: Stellen Sie sicher, dass das Service Principal/der User, der das Template deployt, Rechte für Compute-Ressourcen und Availability Sets hat. - Netzwerk: NSGs/Private IPs werden weiterhin pro VM konfiguriert; Health-Probes und Load Balancer sollten so geplant sein, dass sie hinter dem Availability Set funktionieren. - Storage: Betrieb der OS-Disks ist unabhängig vom Availability Set, aber Managed Disks werden empfohlen. - Governance: Deployment-Policies könnten Availability Sets erzwingen oder limitieren; prüfen Sie dies vor Deployment.

Step 1: Auswahl der geeigneten Skalierungs- und Verteilungsmechanismen. Virtual Machine Scale Sets (VMSS) unterstützen zonale Bereitstellung (multi-zone VMSS) und bieten automatische Skalierung, Rolling Upgrades und Integration mit Load Balancer. Alternativ können Sie einzelne VMs in verschiedenen Zonen bereitstellen und diese manuell hinter einem zonenfähigen Load Balancer gruppieren. Beide Ansätze ermöglichen zonale Verteilung; VMSS bietet jedoch bessere Automatisierung.

Step 2: Implementierung und Abwägungen. Option A (VMSS zonal) ist in der Regel die bevorzugte Lösung für automatisches Skalieren mit Zonenunterstützung: Sie definieren die zones-Eigenschaft im VMSS-Template und konfigurieren einen Standard Load Balancer mit Health-Probes; VMSS skaliert Instanzen in den angegebenen Zonen. Tradeoffs: VMSS kann Einschränkungen bei bestimmten VM-Erweiterungen oder spezialisierten Images haben; prüfen Sie Inkompatibilitäten. Option C (manuelle zonale VMs + zonenfähiger Load Balancer) bietet maximale Flexibilität bei Konfigurationen, die nicht im VMSS-Szenario abbildbar sind (z. B. individuell angepasste VM-Konfigurationen). Dieser Ansatz erfordert jedoch mehr Betriebsaufwand (Autoscaling manuell oder via Automation/Logic Apps) und erhöht potenziell die Verwaltungslast.

Step 3: Betrieb, Monitoring und Netzwerkkonfiguration. Verwenden Sie Standard Load Balancer (nicht Basic) mit cross-zone Load Balancing, konfigurieren Sie Health-Probes, passen Sie NSGs an und richten Sie Telemetrie in Azure Monitor ein. Bei VMSS nutzen Sie die integrierten Health-Probes und Aktualisierungsrichtlinien (upgradePolicy) für Rolling-Upgrades; bei manuellen VMs gestalten Sie Autoscaling via Azure Automation oder Azure Monitor Autoscale. Trap: Ein häufiger Fehler ist zu glauben, dass Availability Sets VMs automatisch in verschiedene Zonen verteilen oder dass App Service Plans VM-Instanzen zonal steuern – beides ist nicht korrekt. Availability Sets betreffen Fault/Update Domains in einem Rechenzentrum. App Service ist ein PaaS-Angebot und skaliert nicht automatisch Ihre IaaS-VMs über Availability Zones. Why each wrong answer fails: - Die Option "Ein einzelnes Availability Set mit manueller Skalierung nutzen und für jede VM eine eigene Availability Zone zuweisen": Availability Sets erlauben keine Zonen-Zuweisung; sie sind eine separate Logik für Fault/Update Domains innerhalb eines Rechenzentrums. Sie sind daher ungeeignet, um zonale Ausfallsicherheit zu erreichen. - Die Option "Eine Azure App Service-Plan in einer Region konfigurieren, um zonale Verteilung der VMs sicherzustellen": Azure App Service ist ein PaaS-Dienst (Web Apps) und sorgt nicht dafür, dass Ihre IaaS-VMs zonal verteilt werden; zudem entspricht App Service nicht immer den Anforderungen von IaaS-Workloads. Fazit: Für automatisches Skalieren in Kombination mit zonaler Redundanz ist ein zonales VM Scale Set plus Standard Load Balancer die beste Wahl; wenn spezielle VM-Konfigurationen nötig sind, können manuelle zonale VM-Deployments mit einem zonenfähigen Load Balancer ebenfalls genutzt werden.

Step 1: Anforderungen und passende Funktion identifizieren – Sie benötigen eine granularere Wiederherstellung (einzelne Datei) statt Full‑VM‑Restore. Azure Backup bietet eine eingebaute File‑Level‑Restore‑Funktion für schnelle, gezielte Wiederherstellungen aus einem Wiederherstellungspunkt des VMs (bei Windows meist über VSS konsistent, bei unterstützten Linux‑Workloads analog).

Step 2: Ablauf und administrative Details – Im Recovery Services‑Tresor wählen Sie das Backup Item (die VM), klicken auf Restore und wählen 'Dateien und Ordner' oder vergleichbare Option. Der Dienst stellt typischerweise einen wiederhergestellten Snapshot bereit, den Sie über ein temporäres Dienstkonto mounten oder per Download z.B. über ein SMB‑Share/Script abrufen können. Tradeoffs: File‑Level‑Restore ist wesentlich schneller und weniger störend als ein Full‑VM‑Restore; achten Sie auf RBAC‑Berechtigungen am Tresor und auf mögliche Datenverschlüsselungs‑/Compliance‑Anforderungen beim Export.

Step 3: Sicherheit, Tests und Follow‑up – Nach der Extraktion stellen Sie sicher, dass Datei‑Berechtigungen und Integrität geprüft werden. Protokollieren Sie den Restore‑Vorgang und passen Sie ggf. die Backup‑Policy (Häufigkeit/Aufbewahrung) an, um künftige Vorfälle zu minimieren. Testen Sie File‑Level‑Recovery regelmäßig, um sicherzustellen, dass Wiederherstellungs‑Skripte und Prozesse funktionieren. Trap: Ein häufiger Irrtum ist anzunehmen, dass nur ein kompletter VM‑Restore möglich ist oder dass Snapshots immer die schnellste Lösung sind. Azure Backup bietet ausdrücklich eine Dateiwiederherstellungsfunktion, die viel effizienter ist. Außerdem wird oft ASR mit Backup verwechselt—ASR ist Replikation/Failover, nicht primär für granulare Dateiwiederherstellung gedacht. Why each wrong answer fails: - Die gesamte VM aus Backup wiederherstellen und danach die Datei kopieren: Das funktioniert, ist aber viel zeitaufwändiger und störender (RTO, potenziell IP/Netzwerkauswirkungen, Doppelung in der Umgebung). Für nur eine Datei ist das overkill. - Einen Snapshot der VM‑Festplatte erstellen und die Disk an eine andere VM anhängen: Technisch möglich, aber Snapshots sind nicht der standardisierte bzw. einfachste Weg für file‑level recovery in Azure Backup; dieser Ansatz erfordert manuelle Schritte, Downtime/Unmount/Mount und ist fehleranfälliger als die integrierte Recover‑Files‑Funktion. - Azure Site Recovery Failover durchführen und die Datei aus der replizierten Maschine kopieren: ASR repliziert für DR und ist nicht für ad‑hoc File‑Recovery gedacht; Failover ist eine umfangreiche Operation mit erheblichem Risiko und Aufwand und nicht angemessen für das Wiederherstellen einer einzelnen Datei. Fazit: Nutzen Sie die File‑Level‑Restore‑Funktion im Recovery Services‑Tresor für schnelle, sichere Wiederherstellung einzelner Dateien ohne Full‑VM‑Wiederherstellung; stellen Sie RBAC, Verschlüsselung und Wiederherstellungstests sicher.