Microsoft Azure Administrator Associate
Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der AZ-104-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Die Mitgliedschaft in Sicherheitsgruppen basierend auf Benutzerattributen (z. B. Abteilung) automatisch verwalten.
Eine Microsoft Entra ID-Sicherheitsgruppe mit dem Mitgliedschaftstyp "Dynamischer Benutzer" konfigurieren und eine attributbasierte Regel definieren.
Warum: Attributbasierte Regeln eliminieren die fortlaufende manuelle Verwaltung bei Änderungen des Benutzerlebenszyklus. Erfordert Entra ID P1/P2.
Konsistente Governance (Richtlinien, RBAC) über mehrere Abonnements hinweg von einem einzigen Verwaltungspunkt aus anwenden.
Eine Verwaltungsgruppe erstellen, Abonnements darin platzieren und Richtlinien oder RBAC-Rollen im Bereich der Verwaltungsgruppe zuweisen.
Warum: Richtlinien und Rollenzuweisungen werden von allen untergeordneten Abonnements geerbt, was eine zentralisierte und konsistente Governance ermöglicht.
Die Bereitstellung von Ressourcen in nicht autorisierten Azure-Regionen über ein gesamtes Abonnement hinweg verhindern.
Die integrierte Azure Policy "Zulässige Standorte" mit einem `Deny`-Effekt auf Abonnementebene zuweisen.
Warum: Policy bietet präventive Governance. RBAC steuert Aktionen, nicht Bereitstellungsorte. Ressourcensperren verhindern Änderungen/Löschungen, nicht neue Bereitstellungen.
Berechtigungen zur Verwaltung von VMs erteilen, aber nicht für das zugrunde liegende virtuelle Netzwerk oder den Benutzerzugriff.
Die integrierte Rolle "Virtual Machine Contributor" auf Ressourcen- oder VM-Ebene zuweisen.
Warum: Diese Rolle bietet spezifische VM-Verwaltungsberechtigungen (Starten, Stoppen, Neuabbildung), ohne umfassende Contributor- oder Owner-Rechte zu gewähren.
MFA anfordern, wenn Benutzer von außerhalb des Unternehmensnetzwerks auf bestimmte Cloud-Apps (z. B. Azure-Portal) zugreifen.
Eine Conditional Access-Richtlinie mit einem "Benannten Standort" für Unternehmens-IPs als Ausschlussbedingung erstellen und MFA als Gewährungskontrolle anfordern.
Warum: Der Ausschluss eines vertrauenswürdigen Standorts ist der Schlüssel, um MFA im Unternehmensnetzwerk zu umgehen, während es überall sonst erzwungen wird.
Das Löschen kritischer Ressourcen verhindern, selbst durch Administratoren mit Owner-Rollen.
Eine `CanNotDelete`- oder `ReadOnly`-Ressourcensperre auf die Ressource oder ihre Ressourcengruppe anwenden.
Warum: Ressourcensperren gelten für alle Benutzer, unabhängig von ihrer RBAC-Rolle, und bieten den stärksten Schutz gegen versehentliches Löschen.
Bestehende, nicht konforme Ressourcen, die von einer Azure Policy identifiziert wurden (z. B. Hinzufügen eines fehlenden Tags), automatisch korrigieren.
Für Richtlinien mit `Modify`- oder `DeployIfNotExists`-Effekten eine Korrekturaufgabe für die Richtlinienzuweisung erstellen.
Warum: Korrekturaufgaben lösen die korrigierende Aktion der Richtlinie für alle bestehenden nicht konformen Ressourcen aus und automatisieren den Prozess, eine Umgebung konform zu machen.
Azure-Kosten nach Abteilung, Projekt oder Geschäftseinheit aufschlüsseln und berichten.
Ein konsistentes Tag (z. B. "CostCenter") auf alle Ressourcen anwenden. Azure Cost Management verwenden, um Kosten nach diesem Tag zu filtern und zu gruppieren.
Warum: Tags sind der primäre Mechanismus für die benutzerdefinierte Kostenverteilung und Berichterstellung über verschiedene Ressourcengruppen und Abonnements hinweg.
Administratoren privilegierte Rollen nur bei Bedarf, für einen begrenzten Zeitraum und mit einem Genehmigungsworkflow gewähren.
Microsoft Entra Privileged Identity Management (PIM) verwenden. Benutzer für Rollen berechtigen und Aktivierungsanforderungen konfigurieren.
Warum: PIM erzwingt Just-In-Time (JIT)-Zugriff, reduziert die Exposition permanenter privilegierter Konten und bietet eine vollständige Audit-Trail.
Externen Partnern Zugriff auf Azure-Ressourcen unter Verwendung ihrer eigenen Unternehmensanmeldeinformationen gewähren.
Microsoft Entra B2B-Zusammenarbeit verwenden, um Partner als Gastbenutzer zu Ihrem Tenant einzuladen.
Warum: B2B vermeidet das Erstellen und Verwalten neuer Anmeldeinformationen in Ihrem Tenant; Partner verwenden ihren bestehenden Identitätsanbieter zur Authentifizierung.
Speicherkosten für langfristige Daten (z. B. Compliance-Archive), die selten abgerufen werden, aber aufbewahrt werden müssen, minimieren.
Eine Blob-Lifecycle-Management-Richtlinie verwenden, um Blobs automatisch von Hot/Cool in die Archive-Stufe zu überführen.
Warum: Die Archive-Stufe hat die niedrigsten Speicherkosten. Lebenszyklusregeln automatisieren den Tiering-Prozess basierend auf dem Alter des Blobs oder der letzten Zugriffszeit.
Lesezugriff auf Speicherdaten aus einer sekundären Region während eines Ausfalls der primären Region sicherstellen.
Das Speicherkonto mit Read-Access Geo-Redundant Storage (RA-GRS) oder RA-GZRS konfigurieren.
Warum: Standard GRS/GZRS repliziert Daten, erlaubt aber erst nach einem Failover den Lesezugriff auf die sekundäre. Das Präfix "RA" ist für kontinuierlichen Lesezugriff erforderlich.
Die Möglichkeit, einen Satz von Shared Access Signature (SAS)-Tokens für einen bestimmten Container sofort zu widerrufen.
SAS-Tokens basierend auf einer gespeicherten Zugriffsrichtlinie für den Container erstellen. Zum Widerrufen die Richtlinie ändern oder löschen.
Warum: Das Ändern der gespeicherten Zugriffsrichtlinie macht sofort alle damit verbundenen SAS-Tokens ungültig und bietet einen zentralisierten Widerrufsmechanismus.
Einen lokalen Dateiserver mit einer Azure-Dateifreigabe synchronisieren und gleichzeitig den lokalen Festplattenspeicherverbrauch minimieren.
Azure File Sync bereitstellen und Cloud Tiering auf dem Server-Endpunkt aktivieren.
Warum: Cloud Tiering speichert nur häufig aufgerufene ("heiße") Dateien lokal zwischen, während weniger genutzte Dateien an Azure ausgelagert werden und als Stubs auf dem lokalen Server erscheinen.
Den Netzwerkzugriff auf ein Speicherkonto auf bestimmte VNet-Subnetze und öffentliche IP-Adressen beschränken.
Die Speicherkonto-Firewall aktivieren. Virtuelle Netzwerkregeln für die Subnetze und IP-Adressregeln für die öffentlichen IPs hinzufügen.
Warum: Die Speicher-Firewall bietet Netzwerk-Zugriffskontrolle direkt am öffentlichen Endpunkt des Speicherkontos und blockiert den gesamten anderen Datenverkehr.
Blobs vor versehentlichem Löschen schützen, indem die Wiederherstellung für einen bestimmten Zeitraum ermöglicht wird.
Blob Soft Delete im Speicherkonto aktivieren und den Aufbewahrungszeitraum konfigurieren (z. B. 14 Tage).
Warum: Soft Delete behält gelöschte Blobs für den konfigurierten Zeitraum bei und ermöglicht ein einfaches Wiederherstellen. Dies ist die erste Verteidigungslinie gegen versehentlichen Datenverlust.
Compliance-Anforderungen erfüllen, um Daten für einen festen Zeitraum in einem nicht löschbaren, nicht änderbaren (WORM)-Zustand zu speichern.
Eine zeitbasierte Aufbewahrungsrichtlinie für einen Blob-Container konfigurieren und die Richtlinie sperren.
Warum: Eine gesperrte zeitbasierte Aufbewahrungsrichtlinie macht Blobs unveränderlich und verhindert das Löschen oder Ändern durch jedermann (einschließlich Administratoren), bis der Aufbewahrungszeitraum abläuft.
Einen sehr großen Datensatz (z. B. 50+ TB) in Azure Blob Storage migrieren, wenn die Netzwerkbandbreite begrenzt ist.
Das physische Gerät Azure Data Box für eine Offline-Übertragung verwenden.
Warum: Für große Datensätze ist der Versand eines physischen Geräts erheblich schneller als die Datenübertragung über eine langsame oder überlastete Netzwerkverbindung.
Eine 99,99%ige SLA für VMs erreichen und eine Anwendung gegen einen Ausfall eines einzelnen Rechenzentrums innerhalb einer Region schützen.
Mehrere VM-Instanzen über verschiedene Availability Zones innerhalb derselben Region bereitstellen.
Warum: Availability Zones sind physisch getrennte Rechenzentren. Availability Sets schützen nur vor Rack-Level-Ausfällen innerhalb eines einzelnen Rechenzentrums (99,95% SLA).
Eine neue Anwendungsversion mit Live-Produktions-Traffic bereitstellen und testen, bevor eine vollständige Veröffentlichung erfolgt, und das ohne Ausfallzeit.
Einen App Service-Bereitstellungsslot verwenden. Im Slot bereitstellen, testen und dann einen Swap durchführen. Optional Traffic Routing für Canary-Tests verwenden.
Warum: Slots bieten eine vollständige Staging-Umgebung. Die Swap-Operation ist eine nahezu sofortige Umleitung des Traffics, die keine Ausfallzeiten gewährleistet.
Einen kurzlebigen, containerisierten Batch-Job nach Zeitplan ausführen, mit minimalen Kosten und ohne Infrastrukturverwaltung.
Azure Container Instances (ACI) verwenden.
Warum: ACI bietet Sekundentakt-Abrechnung und keinen Cluster-Verwaltungsaufwand, was es zur kostengünstigsten Option für sporadische oder kurzlebige Container-Workloads macht.
Eine Workload mit vorhersehbaren täglichen Spitzen (z. B. Geschäftszeiten) automatisch skalieren und gleichzeitig unerwartete Spitzen bewältigen.
VM Scale Set-Autoskalierung mit sowohl zeitplanbasierten als auch metrikbasierten Regeln konfigurieren.
Warum: Die Kombination aus proaktiver (zeitplanbasierter) und reaktiver (metrikbasierter) Skalierung bietet die beste Balance zwischen Leistung (bereit vor der Spitze) und Kosteneffizienz (skaliert bei Inaktivität herunter).
Container-Images für einen Azure Kubernetes Service (AKS)-Cluster sicher in einem privaten Registry mit Schwachstellenscans speichern.
Azure Container Registry (ACR) Premium SKU verwenden und mit AKS über eine verwaltete Identität integrieren.
Warum: ACR bietet ein privates Registry, das in Azure co-lokalisiert ist. Die Premium SKU beinhaltet Schwachstellenscans. Managed Identity bietet eine sichere, passwortlose Authentifizierung von AKS zu ACR.
Ein OS- oder Anwendungsupdate auf allen VMSS-Instanzen durchführen, ohne Anwendungs-Ausfallzeiten zu verursachen.
Das VMSS-Modell aktualisieren (z. B. neue Image-Version) und eine Rolling Upgrade-Richtlinie verwenden.
Warum: Die Rolling-Richtlinie aktualisiert Instanzen in konfigurierbaren Batches und stellt sicher, dass eine Untermenge der Instanzen während des gesamten Update-Prozesses immer für den Datenverkehr verfügbar ist.
Eine Multi-Container-Anwendung (z. B. App + Logging-Sidecar) bereitstellen, die Netzwerk und Speicher gemeinsam nutzen muss, ohne einen vollständigen Orchestrator.
Die Container in einer einzigen Azure Container Instances (ACI)-Containergruppe bereitstellen.
Warum: Eine Containergruppe ko-lokalisiert mehrere Container, die ein Localhost-Netzwerk und Volumes gemeinsam nutzen, perfekt für Sidecar-Muster ohne die Komplexität von Kubernetes.
Die Größe der OS- oder Datenfestplatte einer VM nach der Bereitstellung erhöhen.
Die VM deallozieren, die Disk-Ressource in Azure neu dimensionieren, die VM starten und dann die Partition im Gast-OS erweitern.
Warum: Die Größenänderung der Azure-Diskalloziiert nur mehr Speicherplatz. Das Gast-OS muss angewiesen werden, diesen neuen Speicherplatz durch Erweiterung seiner Dateisystempartition zu nutzen.
Einem App Service erlauben, Geheimnisse sicher aus Azure Key Vault abzurufen, ohne Anmeldeinformationen in der Anwendung zu speichern.
Eine systemseitig zugewiesene Managed Identity für den App Service aktivieren und dieser Identität `Get`- und `List`-Berechtigungen für die Key Vault-Geheimnisse gewähren.
Warum: Managed Identity bietet einen anmeldeinformationenlosen Authentifizierungsmechanismus. Die Anwendung kann automatisch ein Zugriffstoken für Key Vault erwerben, wodurch die Geheimnisverwaltung entfällt.
Eine große, komplexe Infrastructure-as-Code-Bereitstellung in kleinere, wiederverwendbare und wartbare Komponenten organisieren.
Die Bereitstellung in Bicep-Module refaktorisieren, wobei jedes Modul eine logische Einheit (z. B. Netzwerk, Compute) darstellt und diese von einer Haupt-Bicep-Datei aus orchestrieren.
Warum: Module fördern die Code-Wiederverwendung, verbessern die Lesbarkeit und vereinfachen die Verwaltung komplexer Infrastruktur-Bereitstellungen.
Anwendungs-Tiers (Web, App, Daten) innerhalb eines VNet isolieren und die direkte Kommunikation zwischen nicht benachbarten Tiers verhindern.
Ein separates Subnetz für jede Stufe verwenden und Network Security Groups (NSGs) auf jedes Subnetz anwenden, um den Datenverkehr zu steuern.
Warum: NSGs ermöglichen eine feingranulare, zustandsbehaftete Filterung basierend auf Quell-/Ziel-IP-Bereichen (Subnetzen), Ports und Protokollen, was eine Netzwerk-Mikro-Segmentierung ermöglicht.
Zwei VNets in verschiedenen Azure-Regionen privat über das Microsoft Backbone-Netzwerk verbinden.
Global VNet Peering zwischen den beiden VNets konfigurieren.
Warum: Global Peering ist einfacher, hat eine geringere Latenz und eine höhere Bandbreite als eine VNet-zu-VNet-VPN-Verbindung. Der Datenverkehr bleibt im privaten Microsoft-Netzwerk.
VNet-A ist mit Hub-VNet gepeert, und Spoke-VNet ist ebenfalls mit Hub-VNet gepeert. VMs in VNet-A können VMs in Spoke-VNet nicht erreichen.
Die Ursache ist, dass VNet Peering nicht-transitiv ist. Um die Kommunikation zu ermöglichen, VNet-A und Spoke-VNet direkt peeren oder eine NVA im Hub verwenden.
Warum: Peering erzeugt keine Reihenschaltung. Jedes VNet muss direkt verbunden sein, um zu kommunizieren, es sei denn, das Routing über eine Network Virtual Appliance ist konfiguriert.
Einen persistenten, verschlüsselten IPsec-Tunnel von einem lokalen Netzwerk zu einem Azure VNet über das öffentliche Internet aufbauen.
Ein Azure VPN Gateway im VNet bereitstellen und eine Site-to-Site (S2S)-Verbindung konfigurieren.
Warum: Dies ist die standardmäßige, sichere und zuverlässige Lösung für hybride Konnektivität zwischen einem einzelnen lokalen Standort und einem Azure VNet.
Ein Azure Load Balancer sendet weiterhin Datenverkehr an eine fehlerhafte Backend-VM, was zu Anwendungs-Timeouts führt.
Eine Health Probe auf dem Load Balancer konfigurieren, die den Zustand der Anwendung auf den Backend-VMs genau überprüft.
Warum: Der Load Balancer verlässt sich vollständig auf Health Probes, um fehlerhafte Instanzen zu erkennen. Ohne eine korrekt konfigurierte Probe kann er ausgefallene VMs nicht aus der Datenverkehrsrotation entfernen.
HTTP/S-Datenverkehr basierend auf dem URL-Pfad (z. B. /images/* vs /api/*) an verschiedene Backend-Serverpools weiterleiten.
Azure Application Gateway mit pfadbasierten Routing-Regeln verwenden.
Warum: Application Gateway ist ein Layer-7-Load Balancer, der HTTP-Anfragen inspiziert und Routing-Entscheidungen basierend auf URL-Pfaden treffen kann. Ein standardmäßiger Azure Load Balancer ist Layer 4 und kann dies nicht.
VMs in einem VNet mit einem benutzerdefinierten DNS-Server können Hostnamen in einer Azure Private DNS Zone nicht auflösen.
Den benutzerdefinierten DNS-Server so konfigurieren, dass er Abfragen für die private Zone bedingt an die von Azure bereitgestellte DNS-Resolver-IP (168.63.129.16) weiterleitet.
Warum: Wenn ein benutzerdefinierter DNS-Server verwendet wird, umgeht er den internen DNS von Azure. Der benutzerdefinierte Server muss lernen, wie Azure-spezifische Zonen aufgelöst werden, indem Anfragen an Azure DNS weitergeleitet werden.
Den gesamten Internet-gebundenen Datenverkehr von Spoke-VNets zwingen, von einer zentralen Azure Firewall im Hub-VNet inspiziert zu werden.
Eine Routentabelle mit einer User-Defined Route (UDR) auf die Spoke-Subnetze anwenden. Die UDR ist eine Standardroute (0.0.0.0/0), die auf die private IP der Firewall verweist.
Warum: Eine UDR überschreibt die standardmäßige Systemroute von Azure ins Internet, wodurch Sie den ausgehenden Datenverkehr für Sicherheitsüberprüfungen steuern und zentralisieren können.
Sicheren RDP/SSH-Zugriff auf VMs bereitstellen, die keine öffentlichen IP-Adressen haben, ohne ein VPN zu konfigurieren.
Azure Bastion in einem dedizierten Subnetz (AzureBastionSubnet) im VNet bereitstellen.
Warum: Bastion bietet einen verwalteten Jump-Box-Dienst, der sicheren administrativen Zugriff über das Azure-Portal über TLS ermöglicht und die Exposition öffentlicher IPs auf VMs eliminiert.
Sicherstellen, dass der Datenverkehr zwischen einer VM und einem PaaS-Dienst (z. B. Azure SQL) im privaten Netzwerk bleibt und der PaaS-Dienst nicht öffentlich zugänglich ist.
Einen Private Endpoint für den PaaS-Dienst im VNet der VM erstellen und den öffentlichen Netzwerkzugriff auf dem PaaS-Dienst deaktivieren.
Warum: Ein Private Endpoint weist dem PaaS-Dienst eine private IP innerhalb Ihres VNet zu, während die Deaktivierung des öffentlichen Zugriffs sicherstellt, dass er nur über diese private IP erreichbar ist.
Globale Benutzer zum nächstgelegenen regionalen Anwendungs-Endpunkt leiten, um die geringstmögliche Latenz zu gewährleisten.
Azure Traffic Manager mit der Routing-Methode "Performance" verwenden.
Warum: Die Performance-Routing-Methode verwendet DNS, um Clients zum Endpunkt mit der geringsten Netzwerklatenz von ihrem Standort aus zu leiten.
Eine Benachrichtigung (E-Mail, SMS, Webhook) senden, wenn eine Ressourcenmetrik (z. B. VM-CPU-Prozentsatz) einen Schwellenwert für eine festgelegte Dauer überschreitet.
Eine Metric Alert-Regel in Azure Monitor erstellen und sie mit einer Action Group verknüpfen, die die Benachrichtigungsaktion definiert.
Warum: Dies ist das Standardmuster. Die Warnregel definiert die Bedingung (was/wann), und die Aktionsgruppe definiert die resultierende Benachrichtigung (wer/wie).
Feststellen, ob der Datenverkehr zwischen zwei VMs durch eine spezifische Network Security Group (NSG)-Regel blockiert wird.
Das IP Flow Verify-Tool in Azure Network Watcher verwenden.
Warum: IP Flow Verify simuliert einen Paketfluss und meldet explizit, welche NSG und Regel den Datenverkehr zulässt oder verweigert, was es zum definitiven Tool zur Behebung von NSG-Konflikten macht.
Geplante, richtlinienbasierte Backups für Azure VMs mit Anwendungskonsistenz und langfristiger Aufbewahrung konfigurieren.
Einen Recovery Services-Tresor erstellen, eine Backup-Richtlinie definieren (Zeitplan, Aufbewahrung) und das Backup für die Ziel-VMs aktivieren.
Warum: Der Recovery Services-Tresor ist die zentrale Verwaltungseinheit für Azure Backup. Er speichert Backup-Daten sicher und verwaltet alle Backup- und Wiederherstellungsvorgänge.
Ein zentralisiertes Dashboard zur Überwachung der Leistung (CPU, Arbeitsspeicher, Festplatte, Netzwerk) von VMs über mehrere Abonnements hinweg erstellen.
Einen zentralen Log Analytics-Arbeitsbereich bereitstellen und VM Insights für alle Ziel-VMs aktivieren, indem sie auf den Arbeitsbereich verweisen.
Warum: VM Insights sammelt und aggregiert Leistungsdaten und bietet vorgefertigte Arbeitsmappen sowie eine konsolidierte "at-scale" Leistungsübersicht über Abonnements hinweg.
Proaktiv ungenutzte Azure-Ressourcen und Möglichkeiten zur Kostenersparnis (z. B. VM-Right-Sizing) identifizieren.
Regelmäßig die Kostenempfehlungen im Azure Advisor überprüfen.
Warum: Azure Advisor analysiert automatisch die Ressourcennutzung und liefert umsetzbare, personalisierte Empfehlungen zur Kostenersparnis ohne zusätzliche Konfiguration.
Azure VMs von einer primären Region in eine sekundäre Region replizieren, um Disaster-Recovery-Funktionen bereitzustellen.
Azure Site Recovery verwenden. Einen Recovery Services-Tresor erstellen und die Replikation für die VMs in die Zielregion aktivieren.
Warum: ASR ist der native Azure-Dienst zur Orchestrierung von VM-Replikation, Failover-Tests sowie Failover/Failback zwischen Azure-Regionen.
Verschiedene Datenaufbewahrungszeiträume für Sicherheits-Logs vs. Performance-Logs innerhalb eines einzelnen Log Analytics-Arbeitsbereichs festlegen, um Kosten zu optimieren.
Eine Standardaufbewahrung auf Arbeitsbereichsebene festlegen und dann einen längeren Aufbewahrungszeitraum auf individueller Tabellenebene konfigurieren (z. B. für die Tabelle SecurityEvent).
Warum: Die Aufbewahrung pro Tabelle ermöglicht es Ihnen, langfristige Compliance-Anforderungen für bestimmte Daten zu erfüllen, während die Speicherkosten für weniger kritische, große Datenmengen minimiert werden.
