Lernen

Die Prüfung auf einen Blick

Microsoft Certified: Azure Administrator Associate (AZ-104) prüft den Betrieb: Identitäten und Berechtigungen vergeben, Speicher und virtuelle Maschinen bereitstellen, Netze verbinden, überwachen und sichern. Es geht nicht um Definitionen, sondern um die richtige Handlung in einem Szenario.

Stand: September 2026, laut Microsoft Learn. Deutsch ist als Prüfungssprache verfügbar; Aktualisierungen erscheinen zuerst auf Englisch und etwa acht Wochen später in den Übersetzungen.

Die fünf Bereiche und ihr Gewicht

Besonderheiten der Prüfung

• Interaktive Aufgaben: AZ-104 enthält gelegentlich Laborfragen im echten Portal. Dort zählt, dass die Aufgabe erledigt ist, nicht der Weg.
• Ja/Nein-Blöcke mit drei Aussagen und Zuordnungsfragen kommen häufig vor. Einmal abgeschickte Blöcke lassen sich nicht zurückholen.
• Wiederkehrende Szenarien: Dieselbe Ausgangslage mit unterschiedlichen Lösungsvorschlägen — jede Variante wird einzeln mit „erfüllt das Ziel: ja/nein“ bewertet.
• Kein Abzug fürs Raten. Keine Frage unbeantwortet lassen.

Denkraster

1. Was ist gefordert? „Geringster Verwaltungsaufwand“, „am kostengünstigsten“, „ohne Ausfallzeit“ — das entscheidet zwischen zwei technisch richtigen Wegen.
2. Auf welcher Ebene? Verwaltungsgruppe, Abonnement, Ressourcengruppe, Ressource — Rollen und Richtlinien wirken nach unten.
3. Gibt es dafür eine fertige Funktion? Azure löst die meisten Aufgaben mit einem eingebauten Schalter; eigene Skripte sind selten die richtige Antwort.
4. Was ist der kleinste Eingriff? Eine Einstellung ändern schlägt „neu erstellen und migrieren“, solange die Anforderung das zulässt.

Lernquellen

• Microsoft Learn: der kostenlose Lernpfad zu AZ-104 mit Übungen im Sandbox-Konto.
• Studienleitfaden („Skills measured“) mit Änderungsdatum — die verbindliche Themenliste.
• Kostenlose Practice Assessment von Microsoft.
• Eigenes Abonnement: Für AZ-104 ersetzt Klicken das Lesen. Vieles bleibt erst hängen, wenn man es einmal selbst eingerichtet hat.
• Generalprobe: Die Simulation hier zieht 50 Fragen nach Gewicht, mit 100-Minuten-Countdown.

Benutzer, Gruppen, Lizenzen

Ein Mandant (Tenant) ist eine Instanz von Microsoft Entra ID: das Verzeichnis mit Benutzern, Gruppen, Geräten und Anwendungen. Gefragt wird nicht das Anlegen, sondern der Lebenszyklus.

• Längere Abwesenheit — Anmeldung blockieren: Konto, Lizenzen und Mitgliedschaften bleiben unverändert. Löschen gibt die Lizenz frei, das Objekt ist 30 Tage wiederherstellbar.
• Lizenzzuweisung scheitert für einzelne Benutzer, obwohl Lizenzen frei sind: Es fehlt der Nutzungsspeicherort — ohne Land ist die regionale Verfügbarkeit der Dienstpläne unklar.
• Gruppenbesitzer pflegen die Mitgliedschaft ihrer eigenen Gruppe ohne Verzeichnisrolle — die Antwort auf „geringste Rechte für eine Gruppe“. Gruppenadministrator gilt für alle Gruppen.

Eine Gruppe ist entweder zugewiesen oder dynamisch; beim Umstellen wird die Mitgliederliste verworfen. Die gruppenbasierte Lizenzzuweisung hängt an derselben Gruppe: dynamische Regel plus Lizenz ergibt Zuweisung beim Eintritt und Entzug beim Austritt. Verteilergruppen und administrative Einheiten sind keine zulässigen Lizenzziele.

Editionen, administrative Einheiten, Kennwortzurücksetzung

Gefragt ist das Minimum — dynamische Gruppen und gruppenbasierte Lizenzen deckt schon P1 ab. Administrative Einheiten begrenzen den Wirkungsbereich einer Entra-Rolle auf einen Ausschnitt des Verzeichnisses: Ein regionales Helpdesk bekommt Helpdeskadministrator innerhalb der Einheit seines Standorts, mandantenweit gälte die Rolle für alle Benutzer.

Die Self-Service-Kennwortzurücksetzung (SSPR) kennt drei Einstellungen: Keine, Ausgewählt (genau eine Sicherheitsgruppe, der übliche Pilot) und Alle. Bedingter Zugriff steuert Anmeldebedingungen und kann SSPR nicht gruppenweise abschalten; für Administratoren ist sie immer aktiv und verlangt zwei Methoden.

Hybride Identität und Geräte

Entra Connect Sync ist der klassische Server-Agent, Entra Cloud Sync der leichtgewichtige Nachfolger mit kleinen Agenten je Gesamtstruktur. Cloud Sync verbindet auch getrennte Gesamtstrukturen, synchronisiert aber keine Geräteobjekte — hybrid join, Passthrough und Verbund bleiben Sache von Connect.

Nahtloses einmaliges Anmelden ergänzt PHS und PTA, ist aber keine Anmeldemethode. Nur das Kennwortrückschreiben bringt ein in der Cloud geändertes Kennwort zurück ins lokale AD — PTA prüft dort zwar, schreibt aber nichts zurück.

• Entra join löst die Domänenbindung ab, Entra hybrid join gibt domänengebundenen Rechnern zusätzlich ein Verzeichnisobjekt (ohne Neuaufsetzen), Entra registered ist die Registrierung privater Geräte über ein Arbeitskonto.
• Wer neue Geräte einbinden darf, steht in den Geräteeinstellungen des Mandanten (Alle, Keine, Ausgewählt mit einer Gruppe) — nicht in einer Rolle. Cloudgeräteadministrator verwaltet vorhandene Geräteobjekte, Lokaler Geräteadministrator macht seine Mitglieder auf jedem eingebundenen Gerät zum lokalen Administrator.

Gastbenutzer und externe Zusammenarbeit

• B2B-Zusammenarbeit ist der Standardweg für Externe: Der Gast authentifiziert sich weiter im Heimatmandanten, im eigenen Verzeichnis entsteht nur ein Gastobjekt für Gruppen und Azure-Rollen — eigene Cloudkonten hießen, fremde Kennwörter zu verwalten.
• Die Einstellungen für externe Zusammenarbeit regeln zweierlei: wie viel Gäste im Verzeichnis lesen dürfen (restriktivste Stufe: nur eigene Objekte) und wer einladen darf.
• Gasteinladender erlaubt ausschließlich Einladungen, unabhängig davon — ohne die weiteren Rechte des Benutzeradministrators. Entra External ID ist ein eigener Mandantentyp für Kundenszenarien, nicht das Mittel für Partnerzugriff.

Mandant, Abonnements, Verwaltungsgruppen

Ein Mandant kann vielen Abonnements zugeordnet sein, ein Abonnement gehört zu genau einem Mandanten. Das Abonnement ist Abrechnungsgrenze und Ebene der Kontingente — getrennte Rechnungen und eigene Limits je Abteilung bedeuten getrennte Abonnements, nicht Ressourcengruppen oder Tags.

• Abrechnungsbesitz übertragen ändert nur, wer zahlt. Ein Verzeichniswechsel ist der harte Fall: Azure-Rollenzuweisungen und mandantengebundene verwaltete Identitäten gehen verloren.
• Verwaltungsgruppen bündeln Abonnements unter einer unveränderlichen Stammverwaltungsgruppe, bis zu sechs Ebenen tief. Rollen und Richtlinien wirken auf alle untergeordneten Abonnements, auch auf später hinzugekommene — eine Zuweisung oben schlägt zwölf unten.
• Damit neue Abonnements nicht unter der Stammgruppe landen, legt man in den Einstellungen der Hierarchie eine Standardverwaltungsgruppe fest; manuelles Verschieben lässt ein Zeitfenster ohne Richtlinienabdeckung offen.
• Budgets in Microsoft Cost Management vergleichen laufende oder prognostizierte Kosten mit einem Schwellenwert und benachrichtigen Empfänger oder eine Aktionsgruppe. Ein Budget stoppt keine Ausgaben, und Metrikwarnungen in Azure Monitor kennen keine Kosten.

Azure RBAC

Zwei getrennte Systeme: Entra-Rollen verwalten Verzeichnisobjekte, Azure-RBAC-Rollen verwalten Ressourcen. Ein Globaler Administrator hat ohne eigene Azure-Rollenzuweisung keinen Zugriff auf virtuelle Maschinen — die Lösung ist Mitwirkender im Abonnement, keine weitere Entra-Rolle.

Zuweisungen gelten auf Verwaltungsgruppe, Abonnement, Ressourcengruppe oder Ressource, werden nach unten vererbt und sind additiv: Leser im Abonnement plus Mitwirkender in einer Ressourcengruppe ergibt dort Schreibrechte — die höhere Ebene hat keinen Vorrang. Nur eine Verweigerungszuweisung (Deny assignment) nimmt Rechte weg; sie entsteht durch Azure selbst, etwa bei verwalteten Anwendungen, und schlägt jede Rollenzuweisung.

Benutzerdefinierte Rollen sind nötig, sobald keine integrierte passt — integrierte lassen sich nicht bearbeiten. Die Definition braucht die Vorgänge in Actions (etwa Microsoft.Compute/virtualMachines/restart/action) und mindestens einen Eintrag in AssignableScopes, der festlegt, wo sie zuweisbar ist. DataActions betreffen die Daten innerhalb einer Ressource: Deshalb reicht Leser nicht zum Lesen von Blobs, dafür braucht es Storage Blob Data Reader.

• Verwaltete Identitäten: Die systemseitig zugewiesene lebt und stirbt mit ihrer Ressource, die benutzerseitig zugewiesene ist eine eigene Azure-Ressource für mehrere Ressourcen — und damit die Antwort, wenn VMs ständig neu entstehen und die Berechtigung nur einmal vergeben werden soll. Azure rotiert die Anmeldeinformationen selbst, beide Typen sind kombinierbar.
• Privileged Identity Management (P2) macht aus dauerhaften Zuweisungen berechtigte: Aktivierung auf Zeit, optional mit Genehmigung und MFA, jede Aktivierung protokolliert.

Policy, Sperren, Tags und Verwaltungswege

Azure Policy bewertet Ressourcen gegen Regeln und vergibt keine Berechtigungen. Der Effekt entscheidet über die richtige Antwort:

• modify und deployIfNotExists verändern Ressourcen und brauchen an der Zuweisung eine verwaltete Identität mit passenden Azure-Rollen im Zielbereich; Bestehendes wird über eine Korrekturaufgabe (Remediation task) nachgezogen.
• Eine Initiative bündelt viele Definitionen zu einer Zuweisung mit gemeinsamer Konformitätsauswertung — auf der Verwaltungsgruppe deckt sie alle Abonnements darunter ab.
• Ausnahme vs. ausgeschlossener Bereich: Die Richtlinienausnahme trifft einzelne Richtlinien einer Initiative, ist befristbar und erscheint als „Ausgenommen“ in der Konformitätsansicht. Ein ausgeschlossener Bereich nimmt den Bereich ganz aus der Zuweisung und kennt keine Frist.

Ressourcensperren wirken unabhängig von Rollen, auch für Besitzer: CanNotDelete erlaubt Ändern und verbietet Löschen, ReadOnly verbietet beides. Sie werden nach unten vererbt, bei mehreren gilt die restriktivste, und verwalten dürfen sie nur Besitzer und Benutzerzugriffsadministrator. Eine Sperre ist die häufigste Ursache, wenn das Verschieben einer Ressource trotz Besitzerrechten scheitert; sie gilt nur innerhalb von Azure Resource Manager, nie für Verzeichnisobjekte.

Tags werden nicht von Ressourcengruppe oder Abonnement vererbt — wer Vererbung will, nimmt eine Richtlinie mit dem Effekt modify. Ein Tagname ist je Ressource eindeutig, Tags überleben das Verschieben, und die Kostenanalyse gruppiert nach Tag erst ab dem Zeitpunkt der Vergabe.

Verwaltungswege: Portal, Azure Cloud Shell mit Azure CLI oder Azure PowerShell, dazu ARM-Vorlagen (JSON) und Bicep, das nach ARM übersetzt wird. Beide sind deklarativ und idempotent; Modus Inkrementell ist Standard, Vollständig löscht Ressourcen der Gruppe, die nicht in der Vorlage stehen. Alles läuft über den Azure Resource Manager — Rollen, Richtlinien und Sperren greifen unabhängig vom Werkzeug.

Stand September 2026: Azure AD heißt durchgängig Microsoft Entra ID. Azure Blueprints läuft aus; Governance-Pakete entstehen über Initiativen, Vorlagenspezifikationen und Bereitstellungsstapel. Die Liste der integrierten Azure-Rollen wächst laufend, Prüfungsfragen bleiben bei den klassischen vier.

Speicherkonten: Typ, Leistung, Redundanz

Kontotyp, Leistungsstufe und Region stehen beim Erstellen fest — ein Wechsel von Standard auf Premium bedeutet neues Konto und Datenmigration.

Die Redundanz ist im Betrieb umstellbar: LRS auf GRS oder RA-GRS ist eine Einstellung am Konto, Endpunkte und Schlüssel bleiben unverändert; ein Wechsel der Zonenart (LRS ↔ ZRS, GRS ↔ GZRS) läuft als Konvertierung. Kontofailover: Die sekundäre Region wird zur neuen primären; da die Georeplikation asynchron arbeitet, gehen Schreibvorgänge nach der zuletzt gemeldeten Synchronisierungszeit verloren. Endpunktnamen und Schlüssel bleiben gleich, das Konto ist danach lokal redundant, die Georedundanz muss neu eingerichtet werden.

Blobs: Typen, Zugriffsebenen, Lebenszyklus

• Blockblob — Dateien, Sicherungen, Medien; nur dieser Typ kennt Zugriffsebenen.
• Anfügeblob — Schreiben nur ans Ende, gedacht für Protokolle.
• Seitenblob — wahlfreier Zugriff, Grundlage nicht verwalteter VM-Datenträger. Der Blobtyp steht beim Anlegen fest und ist später nicht umstellbar.

Vorzeitiges Löschen oder Umstufen kostet eine Gebühr für die Restzeit. Hot, Cool und Cold sind auch Standardebene des Kontos, Archive nur je Blob. Rehydrierung geht auf zwei Wegen: die Zugriffsebene auf eine Onlinestufe ändern, oder das Blob in ein neues Blob einer Onlinestufe kopieren — das Original bleibt archiviert. Priorität Standard braucht bis zu rund 15 Stunden, Priorität Hoch unter einer Stunde; ein Direktdownload aus dem Archiv geht nicht.

Die Lebenszyklusverwaltung erledigt Umstufen und Löschen ohne eigenen Code: Filter auf Container, Präfix oder Blobindex-Tag, Bedingungen wie „seit N Tagen nicht geändert“, „seit Erstellung“ oder „seit letztem Zugriff“ (dafür Zugriffszeitverfolgung aktivieren), Aktionen für Stufenwechsel und Löschung, auch für Momentaufnahmen und frühere Versionen. Die Regeln laufen einmal täglich; ein Automation-Runbook ist hier nie die aufwandsärmere Antwort. Statisches Websitehosting ist eine Kontofunktion: Einschalten legt den Container $web an und liefert ihn über einen eigenen Webendpunkt mit Indexdokument und Fehlerseite aus — ein anonym lesbarer Container kann das nicht.

Daten schützen: Löschschutz, Versionen, WORM

Beim unveränderlichen Speicher gilt WORM: Ist eine zeitbasierte Richtlinie gesperrt und die Frist nicht abgelaufen, kann niemand — auch kein Kontobesitzer — die Blobs überschreiben oder löschen; die Frist lässt sich nur verlängern, im Entwurfszustand ist sie frei änderbar und damit kein Nachweis. Eine Ressourcensperre wirkt dagegen nur auf der Steuerungsebene und verhindert keine Datenänderung über den Blobdienst. Objektreplikation kopiert neu geschriebene Blockblobs asynchron in einen Container eines anderen Kontos — freie Zielregion, jederzeit lesbar; sie setzt Versionierung in beiden Konten und den Änderungsfeed im Quellkonto voraus und nimmt bestehende Blobs nicht mit.

Verschlüsselung ruhender Daten (SSE, 256-Bit AES) ist immer aktiv und nicht abschaltbar; standardmäßig verwaltet Microsoft den Schlüssel. Bei kundenseitig verwalteten Schlüsseln liegt er in Key Vault oder Managed HSM — dafür braucht das Konto eine verwaltete Identität mit Zugriff auf den Schlüssel, und im Tresor müssen vorläufiges Löschen und Bereinigungsschutz aktiv sein, eine gemeinsame Ressourcengruppe dagegen nicht. Die Infrastrukturverschlüsselung legt eine zweite Schicht darunter, nur beim Erstellen des Kontos aktivierbar.

Zugriff steuern: Schlüssel, SAS, Entra

Ein Speicherkonto hat zwei gleichwertige Zugriffsschlüssel, die vollen Zugriff auf alle Daten gewähren. Für den Austausch ohne Ausfall werden die Anwendungen erst auf den zweiten Schlüssel umgestellt und danach der erste neu generiert — nie umgekehrt.

Widerruf ist eigenes Prüfungsthema: Sonst läuft ein Token erst mit seiner Ablaufzeit aus. Sofort ungültig wird es, wenn der signierende Kontoschlüssel neu generiert wird (das trifft alle damit ausgestellten Token), wenn der Entra-Delegierungsschlüssel widerrufen wird, oder wenn das Token an eine gespeicherte Zugriffsrichtlinie des Containers gebunden ist und diese geändert oder gelöscht wird. Nur sie erlaubt es, Berechtigungen und Ablauf verteilter Token nachträglich zu ändern; je Container sind bis zu fünf möglich.

Datenrollen: Verwaltungsrollen wie Owner, Contributor oder Storage Account Contributor verwalten das Konto, erteilen aber keinen Datenzugriff über Entra ID — wohl aber das Auslesen der Kontoschlüssel. Daten brauchen Storage Blob Data Reader / Contributor / Owner, Storage Queue Data Contributor oder Storage File Data SMB Share Reader / Contributor / Elevated Contributor. Soll nur noch Entra ID gelten, wird zusätzlich die Shared-Key-Autorisierung deaktiviert — damit sind Kontoschlüssel und alle damit signierten SAS-Token wirkungslos. Anonymer Zugriff hat zwei Schalter: die Kontoeigenschaft „anonymen Blobzugriff zulassen“ und je Container die Ebene Privat, Blob oder Container.

Stand September 2026: Bei neu erstellten Speicherkonten ist der anonyme Blobzugriff standardmäßig unterbunden — ein öffentlich lesbarer Container erfordert zwei bewusste Schritte.

Netzwerkzugriff

Der öffentliche Netzwerkzugriff steht auf „alle Netzwerke“, „ausgewählte Netzwerke“ oder „deaktiviert“; bei ausgewählten Netzwerken filtert die Firewall nach IP-Bereichen und Subnetzregeln.

Azure Files und Azure File Sync

• SMB läuft über Port 445 und gibt es in Standard- wie Premium-Freigaben; NFS 4.1 nur in Premium-Freigaben eines FileStorage-Kontos und ausschließlich über ein virtuelles Netzwerk, da NFS weder Kontoschlüssel noch Transportverschlüsselung nutzt.
• Kontingent: Standardfreigaben fassen mit großen Dateifreigaben bis 100 TiB, sonst 5 TiB; Premium-Freigaben werden nach bereitgestellter Größe abgerechnet, mehr Kapazität heißt dort zugleich mehr IOPS und Durchsatz.
• Momentaufnahmen der Freigabe sind schreibgeschützte, inkrementelle Abbilder; daraus lassen sich einzelne Dateien oder die ganze Freigabe zurückholen. Blob-Versionierung greift hier nicht.
• Identitätsbasierter Zugriff statt Kontoschlüssel: AD DS, Entra Domain Services oder Entra Kerberos aktivieren; danach gilt die Freigabeberechtigung über eine RBAC-Rolle (etwa Storage File Data SMB Share Contributor) und darunter die NTFS-Berechtigung.

Azure File Sync macht einen Windows-Server zum Zwischenspeicher einer Azure-Dateifreigabe:

1. Speichersynchronisierungsdienst anlegen.
2. Agent installieren und den Server beim Dienst registrieren.
3. Synchronisierungsgruppe erstellen, die Dateifreigabe als Cloudendpunkt hinterlegen.
4. Den lokalen Pfad als Serverendpunkt aufnehmen — erst jetzt beginnt der Abgleich.
5. Optional Cloudtiering: Selten benutzte Dateien bleiben als Platzhalter auf dem Server, geregelt über freien Speicherplatz oder Alter — keine Sicherung, es bleiben keine früheren Stände erhalten.

Daten bewegen und Werkzeuge

AzCopy autorisiert über ein Entra-Token — azcopy login für einen Benutzer oder eine verwaltete Identität mit Datenrolle — oder über ein SAS-Token an der Ziel-URL; ein Kontoschlüssel lässt sich nicht direkt übergeben.

Virtuelle Maschinen: Größe, Zustand, Kosten

Die Größe bestimmt CPU, Arbeitsspeicher, Anzahl der Datenträger und Netzwerkkarten. Die Familien: B burstfähig (Test und Entwicklung), D Allzweck, E und M arbeitsspeicheroptimiert (Datenbanken), F computeoptimiert, L speicheroptimiert mit lokalen NVMe-Datenträgern, N mit GPU, H für HPC.

Größe ändern: Liegt die Zielgröße in derselben Hardwarefamilie des aktuellen Clusters, genügt ein Neustart; sonst muss die Zuordnung aufgehoben werden, erst dann erscheint die Größe in der Liste. Datenträger und private IP-Adresse bleiben erhalten.

Preismodelle: nutzungsbasiert als Standard, Reservierungen über ein oder drei Jahre nur bei dauerhaftem Betrieb. Azure-Spot-VMs nutzen freie Kapazität sehr günstig, haben kein SLA und werden jederzeit entfernt — mit einer Entfernungsrichtlinie, die die Zuordnung aufhebt oder die VM löscht. Das ist die Antwort für unterbrechbare Batchlasten ohne Termindruck.

Verfügbarkeit innerhalb einer Region

Daraus folgen die SLA-Stufen: eine einzelne VM erreicht 99,9 % nur mit Premium SSD oder Ultra für alle Datenträger, eine Verfügbarkeitsgruppe mit zwei Instanzen 99,95 %, zwei Instanzen über zwei Zonen 99,99 %.

Datenträger, Images und Sicherung

Jede VM hat einen Betriebssystemdatenträger, optional Datenträger für Anwendungsdaten und meist einen temporären Datenträger (D: bzw. /dev/sdb). Der temporäre liegt lokal am Host, kostet nichts extra und verliert seinen Inhalt bei Größenwechsel und Aufheben der Zuordnung — dorthin gehören nur Auslagerungsdatei und Caches. Die Typen: Standard HDD für Archive, Standard SSD für geringe Last, Premium SSD für Produktion und als Voraussetzung des 99,9-%-SLA, Premium SSD v2 und Ultra mit getrennt einstellbaren IOPS und Durchsatz.

• Größe und Cache: Datenträger lassen sich erweitern, aber nie verkleinern. Die Hostzwischenspeicherung steht beim Betriebssystemdatenträger auf „Lesen/Schreiben“, bei Datenträgern auf „Keine“; für Datenbanken gilt Datendatenträger „Schreibgeschützt“, Protokolldatenträger „Keine“, weil Protokollschreibvorgänge sofort auf dem Datenträger landen müssen.
• Freigegebene Datenträger (Shared Disks): Über die Eigenschaft maxShares hängt ein Premium-SSD- oder Ultra-Datenträger gleichzeitig an mehreren VMs — Voraussetzung für Windows-Failoverclusterinstanzen; Standard HDD kann das nicht.
• Eigener Schlüssel: Ein Datenträgerverschlüsselungssatz (Disk Encryption Set) zeigt auf einen Schlüssel in Azure Key Vault und wird den Datenträgern zugewiesen. Ein Schlüssel, der nur als Geheimnis im Tresor liegt, wird nie verwendet.
• Momentaufnahmen (Snapshots): Inkrementelle Momentaufnahmen speichern nur die seit der letzten Aufnahme geänderten Blöcke, bleiben aber einzeln wiederherstellbar — die Wahl für häufige Point-in-Time-Kopien.
• Vorlagen für neue VMs: Ein verwaltetes Image aus einer generalisierten VM (sysprep unter Windows, waagent -deprovision+user unter Linux) ist regional gebunden und kennt keine Versionen. Die Azure Compute Gallery bietet Imageversionen mit automatischer Replikation in mehrere Regionen — die Antwort, sobald „mehrere Regionen“ oder „versioniert“ in der Frage steht.
• Azure Backup braucht einen Recovery Services-Tresor in derselben Region wie die VMs und eine Sicherungsrichtlinie mit Zeitplan und Aufbewahrung. Wiederhergestellt wird als neue VM, durch Ersetzen vorhandener Datenträger, als reine Datenträgerwiederherstellung oder dateiweise; der MARS-Agent sichert dagegen nur Dateien und Ordner, nie eine komplette VM.
• Regionsübergreifende Wiederherstellung setzt georedundanten Speicher im Tresor voraus und erlaubt jederzeit den Zugriff auf die sekundäre Region, ohne dass Microsoft ein Failover ausruft; Soft Delete schützt nur vor versehentlichem Löschen. Azure Site Recovery ist keine Sicherung, sondern Notfallwiederherstellung: laufende Replikation in eine Zielregion, Wiederherstellungspläne und Testfailover ohne Auswirkung auf den Betrieb.

Bereitstellen, anpassen, zugreifen

ARM-Vorlagen und Bicep beschreiben Infrastruktur deklarativ. az bicep build kompiliert Bicep nach ARM-JSON, az bicep decompile wandelt vorhandene JSON-Vorlagen in Bicep um — ein Ausgangspunkt, der nachgearbeitet wird.

• Bereitstellungsmodi: Incremental (Standard) lässt Ressourcen, die nicht in der Vorlage stehen, unverändert; Complete löscht sie aus der Ressourcengruppe.
• What-If (az deployment group what-if) simuliert gegen den Ist-Zustand und listet erstellte, geänderte, gelöschte und unveränderte Ressourcen auf, ohne etwas anzufassen.
• Vorlagenspezifikation (Template Spec): eigene Azure-Ressource, versioniert, über Azure RBAC freigegeben — kein Blobcontainer mit SAS-Token nötig.
• Geheimnisse: Parameter als securestring deklarieren und in der Parameterdatei per Key Vault-Verweis (Tresor-ID plus Geheimnisname) holen; im Tresor muss enabledForTemplateDeployment aktiviert sein.

VM-Erweiterungen führt der Azure-VM-Agent nach der Bereitstellung im Gastbetriebssystem aus. Die Custom Script Extension lädt ein Skript aus einem Speicherkonto oder von einer URL und führt es aus; in eine Vorlage aufgenommen, konfiguriert sie 50 VMs ohne manuellen Schritt. Benutzerdefinierte Daten und cloud-init wirken schon beim ersten Start und richten unter Linux Pakete, Benutzer und Dateien ein. Run Command führt Skripte über den VM-Agent aus, auch ohne Netzwerkverbindung zur VM — etwa nach einer falschen Firewallregel im Gastbetriebssystem; eine vorinstallierte Erweiterung ist dafür nicht nötig.

• Azure Bastion stellt RDP und SSH über TLS im Portal bereit. Voraussetzung ist ein Subnetz mit exakt dem Namen AzureBastionSubnet und dem Präfix /26 oder größer. Die VMs brauchen weder öffentliche IP-Adressen noch offene Ports 3389 und 22; wer sich verbindet, braucht Lesezugriff auf VM, Netzwerkschnittstelle und Bastion-Ressource.
• Just-in-Time-Zugriff aus Microsoft Defender for Cloud öffnet Verwaltungsports auf Antrag für ein begrenztes Zeitfenster und eine begrenzte Quell-IP und schließt die Netzwerksicherheitsgruppe danach wieder.

VM-Skalierungsgruppen

Eine Skalierungsgruppe betreibt viele identische VMs aus einem gemeinsamen Image. Die flexible Orchestrierung — heute die Vorgabe — verteilt einzeln adressierbare VMs über Fehlerdomänen oder Zonen, die einheitliche verwaltet die Instanzen als Block für sehr große zustandslose Lasten.

• Skalierungsbedingungen bündeln Regeln. Neben metrikbasierten Regeln (Metrik, Operator, Schwellenwert, Zeitraum, Abkühlzeit) gibt es zeitplanbasierte Profile mit Wiederholung, die zu festen Zeiten eine feste Instanzanzahl erzwingen. Steht „werktags 08:00 bis 18:00“ in der Frage, ist das Zeitplanprofil die Antwort — eine CPU-Regel stellt die Instanzen nicht pünktlich bereit.
• Hochskalieren (Scale up) heißt größere Instanz, Aufskalieren (Scale out) mehr Instanzen. Ein Engpass innerhalb einer einzelnen Anforderung wird nur durch Hochskalieren gelöst.
• Upgraderichtlinie: Bei Manuell muss jede Instanz ausdrücklich neu abgebildet werden. Mit Automatisch und automatischen Betriebssystem-Imageupgrades erkennt die Skalierungsgruppe neue Imageversionen aus der Compute Gallery und rollt sie batchweise mit Integritätsprüfung aus.

Azure App Service

Der App Service-Plan ist die gemietete Hardware: Betriebssystem, Region, Instanzgröße, Instanzanzahl. Alle Apps eines Plans teilen sich dessen CPU und Arbeitsspeicher — eine App mit dauerhaft hoher Last stört alle anderen, und die Lösung ist ein eigener Plan, nicht ein weiterer Slot. Hochskalieren ändert den Tarif, Aufskalieren die Instanzanzahl.

• Bereitstellungsslots: neue Version in den Stagingslot, dort testen, dann mit der Produktion tauschen. Die Instanzen werden vorgewärmt, es entsteht keine Ausfallzeit, und ein erneuter Tausch bringt die alte Version sofort zurück.
• Slot-Einstellungen: App-Einstellungen und Verbindungszeichenfolgen wandern beim Tausch mit. Was am Slot bleiben soll, wird in beiden Slots als Bereitstellungsslot-Einstellung markiert; Werte in der Konfigurationsdatei gehören zum Anwendungsinhalt und wandern immer mit.
• Benutzerdefinierte Domäne: Unterdomänen per CNAME auf den Standardhostnamen zeigen und in App Service überprüfen. Das von App Service verwaltete Zertifikat ist kostenlos und verlängert sich automatisch; selbstsignierte Zertifikate sind nie die Antwort.
• Always On verhindert, dass die App nach einer Zeit ohne Anforderungen entladen wird — Voraussetzung für dauerhaft laufende WebJobs. Die ARR-Affinität bindet nur Sitzungen an eine Instanz. Sicherungen werden in der App konfiguriert und landen in einem Speicherkonto, nicht in einem Tresor.

Container: ACI, Container Apps, AKS und ACR

• AKS-Knotenpools: Der Systemknotenpool trägt die Clusterkomponenten und bleibt immer Linux. Windows-Container laufen ausschließlich in Benutzerknotenpools mit Windows Server, und die setzen das Netzwerk-Plug-In Azure CNI voraus.
• Skalierung und Upgrade: Die horizontale Podautoskalierung erhöht nur die Podanzahl; bleiben Pods im Status Pending, ist der Clusterautoskalierer mit minimaler und maximaler Knotenanzahl die Antwort. Steuerungsebene und Knotenpools werden getrennt aktualisiert — jeder Knotenpool muss ausdrücklich auf dieselbe Kubernetes-Version gehoben werden; ein Knotenimageupgrade erneuert nur das Betriebssystemimage.
• Azure Container Registry: Nur der Tarif Premium bietet Georeplikation (ein Anmeldeserver, ein Imagepfad, regionale Replikate), private Endpunkte und das Deaktivieren des öffentlichen Netzwerkzugriffs. Für Pulls aus AKS erhält die Kubelet-Identität des Clusters die Rolle AcrPull — der Weg ohne gespeicherte Anmeldeinformationen, den auch az aks update --attach-acr einrichtet.

Stand September 2026: Das Administratorkonto einer Container Registry gilt als Altlast und ist nie die sichere Antwort; verwaltete Identitäten mit Azure RBAC lösen es ab.

Virtuelle Netzwerke und Subnetze

Ein virtuelles Netzwerk (VNet) gehört zu genau einer Region und einem Abonnement und besitzt einen oder mehrere Adressräume in privater Notation. Darin werden Subnetze geschnitten; ihre Präfixe dürfen sich nicht überschneiden und müssen vollständig in einem Adressraum des VNets liegen. Zwei VNets mit überlappenden Adressräumen lassen sich weder peeren noch per VPN verbinden.

• Fünf Adressen je Subnetz sind reserviert: die Netzadresse, drei Adressen für Standardgateway und Azure-DNS-Zuordnung sowie die Broadcastadresse. Ein /24 hat also 251 nutzbare Adressen, ein /29 nur drei. /29 ist das kleinste mögliche Subnetz.
• Ein Subnetz erweitern heißt in Azure: das Adresspräfix ändern, im laufenden Betrieb, solange der neue Bereich frei ist. Ein zusätzlicher Adressraum oder ein neues VNet ist erst nötig, wenn kein passender Bereich mehr frei ist — beides erzwingt Umzüge und ist der größere Aufwand.
• Reservierte Subnetznamen: GatewaySubnet für VPN- und ExpressRoute-Gateways (mindestens /29, praxisnah /27), AzureFirewallSubnet (mindestens /26), AzureBastionSubnet (mindestens /26). Fehlt das Subnetz oder stimmt der Name nicht exakt, bricht die Bereitstellung ab.
• Private IP-Adressen gehören zur IP-Konfiguration der Netzwerkschnittstelle, nicht zum Gastbetriebssystem. Nur die Umstellung von dynamisch auf statisch hält die Adresse über „Beenden (Zuordnung aufheben)“ hinweg fest. Eine im Gastsystem eingetragene Adresse kennt Azure nicht und sie bricht die Verbindung; DHCP-Reservierungen gibt es in Azure nicht.

Netzwerksicherheitsgruppen

Eine Netzwerksicherheitsgruppe (NSG) filtert nach Richtung, Quelle, Ziel, Protokoll und Port. Regeln haben eine Priorität von 100 bis 4096; ausgewertet wird aufsteigend, und die erste zutreffende Regel entscheidet — danach wird nicht weitergeprüft. Eine niedrigere Zahl bedeutet also höhere Priorität.

• Standardregeln lassen sich nicht bearbeiten, nur überstimmen. Soll eine einzelne Quelle von einer bestehenden Allow-Regel ausgenommen werden, braucht die Deny-Regel eine kleinere Zahl als die Allow-Regel — eine größere greift nie.
• Diensttags wie VirtualNetwork, Internet, AzureLoadBalancer, Storage oder Sql ersetzen gepflegte Adresslisten; Microsoft aktualisiert die enthaltenen Präfixe automatisch.
• Anwendungssicherheitsgruppen (ASG) bündeln Netzwerkschnittstellen unabhängig von Subnetz und IP-Adresse. Eine Regel „von asg-web nach asg-db“ bleibt unverändert, wenn Server dazukommen oder wegfallen — die richtige Antwort, sobald sich Server häufig ändern oder im selben Subnetz fremde Workloads liegen. Das Diensttag VirtualNetwork wäre dort zu grob.
• Zuordnung: eine NSG kann am Subnetz, an der Netzwerkschnittstelle oder an beidem hängen; eingehend wird zuerst die Subnetz-NSG geprüft, ausgehend umgekehrt, und der Verkehr muss alle beteiligten NSGs passieren. Was daraus tatsächlich gilt, zeigt die Ansicht Effektive Sicherheitsregeln für die Netzwerkschnittstelle — sie führt NIC-NSG, Subnetz-NSG und Standardregeln zu einer Liste zusammen.

Öffentliche Adressen, DNS und private Endpunkte

• Öffentliche IP-Adresse, SKU Standard: immer statisch, standardmäßig gesperrt bis eine NSG sie öffnet, wahlweise zonenredundant oder fest einer Zone zugeordnet. Zonenredundant übersteht den Ausfall einer Zone; eine auf Zone 1 festgelegte Adresse nicht.
• Azure DNS, öffentliche Zone: Sie wird erst autoritativ, wenn beim Registrar die Namenserver der Domäne auf die von Azure zugewiesenen Namenserver zeigen. Ohne diese Delegierung bleiben alle Einträge wirkungslos; eine Verknüpfung mit einem VNet gibt es hier nicht.
• Private DNS-Zone: wird mit einem oder mehreren VNets verknüpft. Mit automatischer Registrierung legt Azure die A-Einträge der virtuellen Computer selbst an und entfernt sie wieder — je VNet ist genau eine Verknüpfung mit Autoregistrierung möglich. Die von Azure bereitgestellte Namensauflösung gilt nur innerhalb eines VNets: Über ein Peering hinweg lösen sich Hostnamen erst auf, wenn eine private Zone mit beiden VNets verknüpft ist.
• Dienstendpunkt — der Verkehr eines Subnetzes zu einem PaaS-Dienst läuft über das Azure-Backbone und trägt die Subnetzidentität. Gesperrt wird erst durch die Netzwerkregel in der Firewall des Dienstes mit Standardaktion Verweigern. Die Zieladresse bleibt die öffentliche Adresse des Dienstes.
• Privater Endpunkt — der Dienst bekommt eine private IP-Adresse im Subnetz. Damit der gewohnte Name darauf zeigt, muss die passende Zone (etwa privatelink.database.windows.net) angelegt und mit dem VNet verknüpft sein; ohne sie zeigt der Name weiter auf die öffentliche Adresse.

Netze verbinden

VNet-Peering verbindet zwei virtuelle Netzwerke direkt über das Microsoft-Backbone, ohne Gateway, ohne öffentliche Adressen und ohne laufende Verwaltung, auch über Regionsgrenzen hinweg (globales Peering) — bei „möglichst wenig verwalten“ fast immer die richtige Wahl gegenüber zwei VPN-Gateways. Zwei Eigenschaften sind Prüfungsstoff:

1. Peering ist nicht transitiv. A–B und B–C bedeutet nicht A–C. Abhilfe: ein direktes Peering A–C, oder ein virtuelles Netzwerkgerät in B, für das in beiden Peerings „weitergeleiteten Datenverkehr zulassen“ aktiviert und in A und C passende benutzerdefinierte Routen gesetzt sind.
2. Gatewaytransit wird immer auf der Seite aktiviert, die das Gateway besitzt — im Hub also „Gatewaytransit zulassen“, im Spoke „Remotegateways verwenden“. Vertauscht lässt sich das Peering nicht speichern. Gatewaytransit betrifft nur den Weg über ein VPN- oder ExpressRoute-Gateway und schafft keinen Transit zwischen gepeerten Netzen.

VPN-Gateways gibt es in den SKUs VpnGw1 bis VpnGw5, jeweils auch als zonenredundante AZ-Variante; Durchsatz und Tunnelzahl steigen mit der SKU. Für Hochverfügbarkeit läuft das Gateway aktiv/aktiv mit zwei Instanzen, je eigener öffentlicher IP-Adresse und zwei Tunneln zum lokalen Gerät. Die Erstellung dauert typischerweise 20 bis 45 Minuten.

Datenverkehr verteilen

Der Load Balancer besteht aus Front-End-IP, Back-End-Pool, Integritätstest und Regeln. Eine Lastenausgleichsregel verteilt einen Port auf den ganzen Pool, eine Eingangs-NAT-Regel leitet einen Port auf eine Instanz — typisch RDP oder SSH. Ein HTTP-Test auf einen Statuspfad erkennt eine hängende Anwendung, die auf TCP-Ebene noch antwortet. Zonenredundanz verlangt beides: zonenredundantes Front-End und über Zonen verteilte Instanzen.

Verwechslungspaare: Pfadbasierte Verteilung auf mehrere Pools kann nur das Application Gateway über eine URL-Pfadzuordnung mit Standardpool — der Load Balancer sieht den Pfad nie. Schutz vor SQL-Injection und Cross-Site-Scripting leistet nur die Web Application Firewall: SKU WAF_v2 plus WAF-Richtlinie mit verwaltetem Regelsatz im Präventionsmodus, denn der Erkennungsmodus protokolliert nur. Zwischenspeichern und TLS am Edge kann Front Door, nicht Traffic Manager — der arbeitet auf DNS-Ebene und sieht den Datenverkehr nie. Umgekehrt ist Traffic Manager die einzige Wahl, wenn neben HTTPS auch Protokolle wie SMTP verteilt werden sollen.

Stand September 2026: Die SKU Basic für öffentliche IP-Adressen und für den Load Balancer ist zurückgezogen; Neubereitstellungen erfolgen mit Standard. Basic kennt weder Verfügbarkeitszonen noch zonenredundante Front-Ends und ist in Prüfungsfragen nie die richtige Antwort.

Routing, Firewall und ausgehende Verbindungen

• Systemrouten legt Azure selbst an: innerhalb des VNets, über Peerings, zu Gateways und 0.0.0.0/0 ins Internet. Eine Routentabelle mit benutzerdefinierten Routen überschreibt sie; zugeordnet wird sie einem Subnetz.
• Verkehr über eine virtuelle Appliance braucht zwei Dinge: eine Route mit dem nächsten Hoptyp Virtuelles Gerät und der privaten IP-Adresse des Geräts und aktivierte IP-Weiterleitung auf dessen Netzwerkschnittstelle. Ohne IP-Weiterleitung verwirft Azure jedes Paket, dessen Zieladresse nicht die des Geräts ist. Es gewinnt die längste passende Route, bei gleicher Länge benutzerdefiniert vor BGP vor Systemroute.
• Azure Firewall filtert zentral im Hub. Netzwerkregeln arbeiten nach Adresse, Port und Protokoll, Anwendungsregeln nach FQDN, und DNAT-Regeln veröffentlichen einen internen Dienst: Ziel ist die öffentliche Firewall-Adresse mit ihrem Port, übersetzt wird auf private Adresse und Port des Servers. Eine reine Netzwerkregel leistet keine Adressübersetzung.
• Firewallrichtlinien lassen sich im Azure Firewall Manager vererben: Regeln der übergeordneten Richtlinie gelten in jeder abgeleiteten Richtlinie und werden vor deren lokalen Regeln ausgewertet. Kopierte oder per Skript synchronisierte Regelsätze laufen auseinander und sind nie die Antwort auf „geringster Verwaltungsaufwand“.
• NAT Gateway regelt ausgehende Verbindungen: dem Subnetz zugeordnet, mit statischer öffentlicher Adresse oder Präfix und vielen SNAT-Ports, damit ohne Portausschöpfung. Es hat Vorrang vor ausgehenden Regeln des Lastenausgleichs; eingehende Verbindungen nimmt es nicht an.

Stand September 2026: Der implizite ausgehende Internetzugang für neue virtuelle Computer ohne eigene öffentliche Adresse ist entfallen. Ausgehende Konnektivität wird ausdrücklich eingerichtet — bevorzugt über ein NAT Gateway, sonst über ausgehende Regeln eines Standard Load Balancers.

Netzwerkprobleme untersuchen

Azure Monitor als Dach

Azure Monitor ist nicht ein Dienst, sondern die Klammer um alles, was Azure an Betriebsdaten sammelt. Prüfungsentscheidend ist der Unterschied zwischen den beiden Datenarten, weil er festlegt, welche Art von Warnung überhaupt möglich ist.

Daten einsammeln: Agent und Diagnoseeinstellungen

Azure kommt aus eigener Kraft nur bis zur Ressourcengrenze. Alles innerhalb des Gastbetriebssystems — Ereignisprotokolle, Syslog, Leistungsindikatoren, Textprotokolle einer Anwendung — braucht den Azure Monitor Agent. Was der Agent sammelt und wohin er es schickt, steht nicht im Agenten, sondern in einer Datensammlungsregel (Data Collection Rule, DCR): eine eigene Azure-Ressource mit Datenquelle, Filter und Ziel. Eine Regel lässt sich vielen VMs zuweisen, eine VM kann mehrere Regeln tragen.

1. Azure Monitor Agent als Erweiterung auf der VM oder dem Arc-fähigen Server bereitstellen.
2. Datensammlungsregel anlegen: Datenquelle wählen (z. B. Windows-Ereignisprotokoll, Sicherheitsereignisse, Leistungsindikatoren) und den Log Analytics-Arbeitsbereich als Ziel setzen.
3. Regel zuweisen — über Ressource, Ressourcengruppe oder per Richtlinie im Großen.

Diagnoseeinstellungen sind der andere Weg und betreffen die Plattformseite: Sie leiten Ressourcenprotokolle und Plattformmetriken einer Ressource an bis zu drei Zielarten weiter und erreichen das Gastbetriebssystem nie.

Mehrere Ziele lassen sich in derselben Einstellung aktivieren — die typische Antwort auf „KQL und billige Aufbewahrung“ ist Arbeitsbereich plus Speicherkonto, nicht zwei getrennte Einstellungen.

Stand September 2026: Der Log Analytics-Agent (Microsoft Monitoring Agent, MMA) wurde 2024 eingestellt. Der Azure Monitor Agent mit Datensammlungsregel ist der einzige aktuelle Erfassungsweg; Antwortoptionen mit dem alten Agenten oder der Diagnoseerweiterung sind in neuen Szenarien falsch.

Log Analytics und KQL

Der Arbeitsbereich ist die Datenbank hinter den Protokollen: eine eigene Ressource in einer Region, mit Aufbewahrungsdauer, Tageskontingent und Zugriffssteuerung. Daten kommen aus Datensammlungsregeln, Diagnoseeinstellungen und Lösungen wie VM Insights hinein; jede Zeile trägt TimeGenerated. KQL liest sich von links nach rechts, Tabelle zuerst, dann Operatoren durch Pipe getrennt. Vier Operatoren reichen für die Prüfung:

• where — filtert Zeilen, meist zuerst auf den Zeitraum: TimeGenerated > ago(24h).
• summarize — aggregiert und gruppiert: summarize count() by Computer liefert je Computer eine Zeile mit der Anzahl.
• project — wählt nur Spalten aus, aggregiert nichts; die Zeilenzahl bleibt gleich.
• order by (oder sort by) — sortiert, top n by schneidet die ersten Zeilen ab.
• Wichtige Tabellen: Heartbeat (meldet sich der Agent noch?), Event und Syslog (Gastprotokolle), Perf und InsightsMetrics (Leistungsdaten), AzureActivity (Aktivitätsprotokoll), AzureDiagnostics (Ressourcenprotokolle).

Warnungen und Aktionsgruppen

Jede Warnungsregel besteht aus drei Teilen: Bereich (welche Ressource), Bedingung (Signal, Schwellenwert, Zeitraum) und Aktionen (welche Aktionsgruppe). Dazu kommt ein Schweregrad von Sev 0 (kritisch) bis Sev 4 (ausführlich). Die Regelart ergibt sich aus dem Signal:

Dynamische Schwellenwerte ersparen das Raten fester Grenzen: Azure lernt den normalen Verlauf einer Metrik über Tages- und Wochenrhythmus und schlägt bei Abweichung an — die richtige Antwort bei „unterschiedliche Grundlast je VM“ oder „kein bekannter Schwellenwert“. Eine Regel kann mehrere Ressourcen desselben Typs in einer Region gemeinsam überwachen, statt sie je VM anzulegen.

Eine Aktionsgruppe bündelt Empfänger und Reaktionen: E-Mail, SMS, Push, Sprachanruf, Webhook, Logic App, Azure Function, Automation-Runbook, ITSM-Connector. Sie wird einmal erstellt und von beliebig vielen Regeln referenziert — die Standardantwort auf „geringster Verwaltungsaufwand“ bei vielen Regeln mit denselben Empfängern. Eine Gruppe aus Microsoft Entra ID lässt sich in einer Regel nicht als Ziel angeben; Empfänger stehen ausschließlich in Aktionsgruppen.

Für Wartungsfenster gibt es die Warnungsverarbeitungsregel (Alert Processing Rule): Sie unterdrückt Benachrichtigungen für einen Bereich nach Zeitplan, während die Warnungsregeln unverändert weiterlaufen und weiter Warnungen erzeugen. Regeln zu deaktivieren löst dasselbe Problem, verändert aber die Regeln und muss danach manuell zurückgenommen werden.

Fertige Sichten, Zustand und Wartung

• VM Insights — Leistung, Prozesse und Abhängigkeitskarte von VMs und Skalierungsgruppen, aktiviert über Agent und Datensammlungsregel; Container Insights tut dasselbe für AKS.
• Application Insights — Anfragen, Abhängigkeiten und Ausnahmen einer Anwendung, dazu Verfügbarkeitstests, die eine öffentliche URL planmäßig von mehreren Microsoft-Standorten aus aufrufen. Das ist die Antwort auf „weltweit prüfen, ob die Seite erreichbar ist und wie schnell sie antwortet“.
• Aktivitätsprotokoll — jede Aktion der Steuerungsebene mit Aufrufer, Zeitpunkt und Ergebnis, standardmäßig 90 Tage aufbewahrt. Für längere Aufbewahrung und KQL braucht es eine Diagnoseeinstellung in einen Arbeitsbereich. Anmeldeprotokolle von Microsoft Entra ID belegen nur Authentifizierungen, nicht Ressourcenänderungen.
• Azure Service Health — Störungen, geplante Wartung und Integritätshinweise von Microsoft für die genutzten Abonnements, Dienste und Regionen; Resource Health zeigt den Zustand der einzelnen eigenen Ressource und kündigt keine Wartung an.
• Azure Advisor — Empfehlungen in fünf Kategorien (Zuverlässigkeit, Sicherheit, Leistung, Kosten, betriebliche Exzellenz). Gering ausgelastete VMs samt Vorschlag zur Größenanpassung oder Abschaltung stehen in der Kategorie Kosten, ohne eigene Abfragen. Budgets in Cost Management überwachen dagegen nur Ausgabengrenzen.
• Network Watcher — der Verbindungsmonitor (Connection Monitor) prüft Pfade zwischen eigenen Endpunkten dauerhaft auf Erreichbarkeit, Latenz und Paketverlust; die Paketerfassung zeichnet Pakete einer VM zeitlich begrenzt in ein Speicherkonto auf; IP-Flussüberprüfung und Verbindungsproblembehandlung beantworten Einzelfragen, liefern aber keine Paketdaten.
• Azure Update Manager — geplantes Patchen ohne Automation-Konto. Nötig sind zwei Dinge: eine Wartungskonfiguration für Gastupdates mit Zeitplan, der die VMs zugewiesen sind, und die Patchorchestrierung dieser VMs auf kundenseitig verwaltete Zeitpläne. Fehlt Letzteres, greift der Zeitplan nicht.

Sichern: Recovery Services-Tresor und Richtlinien

Azure Backup sichert in einen Recovery Services-Tresor (Azure-VMs, Azure Files, SQL und SAP HANA in VMs, lokale Server über Agenten) oder einen Sicherungstresor (Backup Vault) für neuere Workloads wie Azure Disks, Blobs, PostgreSQL und Kubernetes. Der Tresor liegt in einer Region und schützt Elemente derselben Region.

• Sicherungsrichtlinie — Zeitplan plus Aufbewahrung (täglich, wöchentlich, monatlich, jährlich). Sie gilt für alle ihr zugewiesenen Elemente: Wird die Aufbewahrung dort geändert, übernehmen alle geschützten VMs die Vorgabe sofort — der Weg mit dem geringsten Verwaltungsaufwand, niemals Neuregistrierung jeder einzelnen VM.
• Speicherredundanz des Tresors — LRS, GRS oder ZRS, nur vor der ersten Sicherung umstellbar. Sie betrifft die Ablage der Kopien, nicht die Aufbewahrungsdauer.
• MARS-Agent (Microsoft Azure Recovery Services) — sichert Dateien, Ordner und den Systemzustand eines Windows-Servers direkt in den Tresor, ohne zusätzliche Infrastruktur. Azure Backup Server (MABS) und DPM können mehr (Anwendungsschutz, kurze Intervalle), setzen aber einen eigenen Server mit Datenträgerpool voraus. Azure Files wird über Momentaufnahmen der Freigabe gesichert, gesteuert durch dieselbe Art Richtlinie.

Beim Wiederherstellen einer Azure-VM ist die Frage, wie viel zurück soll:

Wiederherstellen: Azure Site Recovery

Backup schützt Daten, Azure Site Recovery schützt den Betrieb: Es repliziert ganze VMs laufend in eine zweite Region (oder aus dem eigenen Rechenzentrum nach Azure) und schaltet bei Bedarf dorthin um. In der Zielregion entstehen erst beim Failover echte VMs, bis dahin fallen nur Speicher- und Lizenzkosten an. RPO (wie viel Datenverlust) ergibt sich aus der Replikation, RTO (wie lange bis zum Betrieb) aus dem Failover.

• Replikationsrichtlinie — Aufbewahrung der Wiederherstellungspunkte und Häufigkeit anwendungskonsistenter Momentaufnahmen.
• Wiederherstellungsplan — Reihenfolge der Gruppen beim Umschalten, mit Skripten und manuellen Schritten dazwischen: erst Datenbank, dann Anwendung, dann Web.
• Testfailover — Kopien in einem isolierten Netz, während Produktion und Replikation unverändert weiterlaufen; danach Bereinigung. Der einzige Weg, die Wiederherstellung regelmäßig zu prüfen.
• Geplantes Failover — ohne Datenverlust, aber mit Unterbrechung; ungeplantes Failover nach einem Ausfall. Commit legt den Wiederherstellungspunkt endgültig fest.
• Reprotect — kehrt nach einem committeten Failover die Replikationsrichtung um; erst danach schaltet ein weiteres Failover den Betrieb zurück (Failback).

Verwechslungspaare

Bilder, die hängen bleiben

• Vererbung fließt nach unten: Verwaltungsgruppe → Abonnement → Ressourcengruppe → Ressource. Rollen sind additiv wie Wasser, das sich sammelt; Sperren und Policy-Verweigerungen sind Steine, die auch von oben nicht weggespült werden.
• Fünf Adressen sind weg: In jedem Subnetz reserviert Azure die ersten vier und die letzte Adresse. Ein /29 hat also drei nutzbare Adressen, nicht acht.
• NSG-Regeln sind eine Warteschlange: Die niedrigste Priorität gewinnt, und nach dem ersten Treffer wird nicht weitergelesen.
• Peering ist keine Brücke über drei Ufer: A–B und B–C heißt nicht A–C. Ohne Gatewaytransit oder eine Appliance in B ist Schluss.
• Kalte Blobs sind im Keller: Je kälter die Ebene, desto billiger die Lagerung und desto teurer und langsamer das Herausholen — Archive muss erst rehydriert werden.
• Der Slottausch ist ein Wohnungstausch: Beide Seiten stehen danach woanders; die alte Fassung wartet im Staging und kann zurückgetauscht werden.
• Die Datensammlungsregel ist der Auftragszettel: Der Agent allein sammelt nichts — erst die Regel sagt ihm, was er wohin schickt.

Listen zum Auswendiglernen

• Vier integrierte Rollen, die immer drankommen: Besitzer (alles + Rechte), Mitwirkender (alles außer Rechte), Leser (nur sehen), Benutzerzugriffsadministrator (nur Rechte).
• Policy-Effekte: Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists, Disabled. Modify und DeployIfNotExists brauchen eine verwaltete Identität und eine Korrekturaufgabe für vorhandene Ressourcen.
• Sperrtypen: CanNotDelete und ReadOnly — mehr gibt es nicht.
• Zugriffsebenen für Blobs mit Mindesthaltedauer: Hot (keine), Cool (30 Tage), Cold (90 Tage), Archive (180 Tage).
• Bestandteile einer Warnung: Signal, Bedingung (Schwellenwert und Zeitfenster), Aktionsgruppe. Fehlt die Aktionsgruppe, feuert die Warnung ins Leere.
• Ziele einer Diagnoseeinstellung: Log Analytics-Arbeitsbereich (abfragen), Speicherkonto (lange aufbewahren), Event Hub (weiterreichen).
• Skalierungsgruppe, zwei Modi: einheitlich (identische Instanzen, klassisch) und flexibel (Standard für Neues, VMs bleiben einzeln sichtbar).

Signalwörter in der Fragestellung