Microsoft AZ-900: Governance & Compliance — Lernleitfaden

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Teil des Microsoft Azure AZ-900 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Organisation und Standards: Verwaltungsgruppen, Abonnements, Ressourcengruppen, Benennung und Tags

Die Verwaltungshierarchie von Azure ermöglicht eine skalierbare Governance. Verwaltungsgruppen (Management Groups) stehen über den Abonnements und bieten einen Ort, um Richtlinien und RBAC anzuwenden, die an alle untergeordneten Abonnements vererbt werden. Abonnements definieren die Abrechnung, Dienstkontingente und eine Sicherheitsgrenze für die meisten Kontrollen. Ressourcengruppen enthalten Ressourcen mit einem abgestimmten Lebenszyklus, Berechtigungen und Bereitstellungslogik; jede Ressource gehört zu genau einer Ressourcengruppe und einem Abonnement. Namens- und Tagging-Standards setzen Governance-Absichten in operative Klarheit um. Namen sollten Abkürzungen für den Ressourcentyp, den Workload, die Umgebung und die Region (z. B. kv-payroll-prod-eus2) innerhalb der Dienstgrenzen kodieren. Tags fügen ressourcenübergreifend geschäftlichen Kontext für Kostenverteilung, Zuständigkeit, Datenklassifizierung und Automatisierungsschlüssel hinzu (z. B. costCenter=FIN, owner=ops-team@contoso.com, dataSensitivity=Confidential). Azure Policy mit den Effekten „Modify“ und „Append“ erzwingt das Vorhandensein von Tags und deren Wertemuster und kann Tags von Ressourcengruppen an Ressourcen vererben. Konsistenz in diesem Bereich führt zu zuverlässigen Kostenberichten, Zugriffsüberprüfungen und zur Automatisierung des Lebenszyklus.

• Management Group
  • Zweck: Skalierbare Governance über Abonnements hinweg
  • Gängige Anwendungsfälle: Anwenden von Richtlinien, RBAC und Initiativen auf Geschäftsbereiche oder Umgebungen
  • Kann enthalten: Untergeordnete Verwaltungsgruppen und Abonnements
  • Wichtige Hinweise: Bis zu 6 Ebenen tief (ohne Root); Vererbung erfolgt nach unten
• Subscription
  • Zweck: Abrechnungs- und Dienstgrenze
  • Gängige Anwendungsfälle: Workload-Isolierung, Kostentrennung, Kontingentverwaltung
  • Kann enthalten: Ressourcengruppen und Ressourcen
  • Wichtige Hinweise: Richtlinien-/RBAC-Zuweisungen hier wirken sich auf alle enthaltenen Ressourcengruppen aus
• Resource Group
  • Zweck: Lebenszyklus- und Berechtigungsgrenze für Ressourcen
  • Gängige Anwendungsfälle: Gemeinsames Bereitstellen, Aktualisieren und Löschen zusammengehöriger Ressourcen
  • Kann enthalten: Ressourcen
  • Wichtige Hinweise: Eine Ressource kann nur in einer RG existieren; Verschiebungen zwischen RGs/Abonnements unterliegen dienstspezifischen Einschränkungen

Ressourcensperren und Schutz vor versehentlichem Löschen

Ressourcensperren (Resource Locks) bieten eine letzte Verteidigungslinie gegen unbeabsichtigte Änderungen. Sperren werden auf Abonnement-, Ressourcengruppen- oder Ressourcenebene angewendet und nach unten vererbt. Es gibt zwei Arten von Sperren: CanNotDelete verhindert das Löschen, erlaubt aber Lese- und Schreibvorgänge, und ReadOnly schränkt alle Schreib- und Löschvorgänge ein (erlaubt also effektiv nur Leseoperationen). Sperren schützen vor Aktionen aus dem Portal, der CLI, PowerShell, ARM/Bicep und IaC-Tools von Drittanbietern. Verwenden Sie CanNotDelete für gemeinsam genutzte oder kritische Infrastruktur – virtuelle Netzwerke, Routingtabellen, DNS-Zonen, produktive Key Vaults –, damit Wartungsarbeiten fortgesetzt werden können, während Löschvorgänge blockiert sind. Verwenden Sie ReadOnly sparsam für Artefakte, die vollständig statisch bleiben müssen, wie z. B. archivierte Speicherkonten oder Container für regulatorische Nachweise; viele Dienste benötigen für den normalen Betrieb Schreibzugriffe und schlagen unter ReadOnly fehl. Nur Prinzipale mit ausreichenden Berechtigungen (z. B. Owner mit Microsoft.Authorization/locks/*) können eine Sperre entfernen, und das Entfernen einer Sperre ist selbst ein prüfbarer Vorgang im Activity Log.

• CanNotDelete
  • Lesen: Erlaubt
  • Schreiben/Aktualisieren: Erlaubt
  • Löschen: Blockiert
  • Typische Anwendungsfälle: Schutz von VNets, Routingtabellen, produktiven Key Vaults, kritischen RGs
  • Überlegungen: Erlaubt Konfigurationsänderungen; Löschvorgänge schlagen fehl, bis die Sperre entfernt wird
• ReadOnly
  • Lesen: Erlaubt
  • Schreiben/Aktualisieren: Blockiert
  • Löschen: Blockiert
  • Typische Anwendungsfälle: Bewahrung von Nachweisspeichern, Archivspeicher, unveränderlichen Konfigurationen
  • Überlegungen: Viele Dienste funktionieren unter ReadOnly nicht; Aktualisierungen und Skalierungen sind blockiert

Auditing, Inventarisierung und Einhaltung von Vorschriften: Resource Graph, Activity Log, Defender for Cloud und Microsoft Purview

Azure Resource Graph ermöglicht schnelle, skalierbare Inventarisierungs- und Statusabfragen über Abonnements und Verwaltungsgruppen hinweg mithilfe der Kusto Query Language (KQL). Er ermöglicht die Beantwortung von Fragen wie, welche Speicherkonten keine Verschlüsselung aufweisen, welche VNets öffentliche IPs verfügbar machen und welche Ressourcen nicht richtlinienkonform sind. Die Ergebnisse fließen in Dashboards, die CMDB-Synchronisierung und Pipelines zur Problembehebung ein. Resource Graph kann in Kombination mit Cost Management-Daten auch den Status der Richtlinienkonformität, Tag-Verteilungen und Dimensionen der Kostenzuordnung aufzeigen. Das Azure Activity Log zeichnet Vorgänge auf der Steuerungsebene für Ressourcen auf, einschließlich wer was wann getan hat, mit einer standardmäßigen Aufbewahrungsfrist von 90 Tagen. Leiten Sie das Activity Log an Log Analytics, Azure Storage oder Event Hubs weiter, um eine langfristige Aufbewahrung, Korrelation und SIEM-Ingestion zu ermöglichen. Die Analyse des Änderungsverlaufs identifiziert Konfigurationsabweichungen, unterstützt die Reaktion auf Vorfälle und liefert Nachweise für Audits. Microsoft Defender for Cloud übersetzt den technischen Status in regulatorische Ansichten, indem es Bewertungen Standards wie Azure Security Benchmark, ISO/IEC 27001, NIST SP 800-53, PCI DSS und CIS zuordnet. Das Dashboard für die Einhaltung von Vorschriften zeigt bestandene/nicht bestandene Kontrollen, betroffene Ressourcen und Anleitungen zur Problembehebung. Die Aktivierung der automatischen Bereitstellung integriert bei Bedarf Agenten und Richtlinien, und der Secure Score bietet eine Priorisierungsperspektive. Microsoft Purview entdeckt, klassifiziert und katalogisiert Daten über Azure-, Multicloud- und lokale Quellen hinweg. Scans identifizieren sensible Daten (z. B. Finanzdaten, personenbezogene Daten (PII), Gesundheitsdaten) in Azure Storage, SQL, Synapse, Power BI und vielen weiteren Diensten und wenden dabei integrierte oder benutzerdefinierte Klassifikatoren an. Die Purview Data Map und der Catalog bieten Datenherkunft (Lineage), Eigentümerschaft und Sensitivitätskennzeichnungen, die sich mit Microsoft Information Protection integrieren lassen und so die Verhinderung von Datenverlust und Entscheidungen über Zugriffsrichtlinien ermöglichen, die auf regulatorische Verpflichtungen abgestimmt sind.

• Hauptfunktion
  • Azure Resource Graph: Inventarisierung und Statusabfragen im großen Maßstab
  • Activity Log: Audit-Trail der Vorgänge auf der Steuerungsebene
  • Defender for Cloud (Regulatory): Zuordnung des Status zu Standards und Priorisierung von Korrekturen
  • Microsoft Purview: Datenermittlung, -klassifizierung, -katalogisierung, -herkunft (Lineage)
• Geltungsbereich
  • Azure Resource Graph: Über MGs/Abonnements hinweg
  • Activity Log: Pro Mandant mit Weiterleitung an LA/Storage/Event Hub
  • Defender for Cloud (Regulatory): Pro Abonnement/Mandant mit Initiativenzuweisungen
  • Microsoft Purview: Über Datenquellen hinweg (Azure, M365, lokal, Multicloud)
• Typische Ergebnisse
  • Azure Resource Graph: KQL-Abfrageergebnisse, Dashboards, Exporte
  • Activity Log: Wer/was/wann, Status, Fehlercodes
  • Defender for Cloud (Regulatory): Konformitätsstatus von Kontrollen, Secure Score, Empfehlungen
  • Microsoft Purview: Daten-Assets, Sensitivitätskennzeichnungen, Schema, Herkunftsgraphen (Lineage)

Praxisbeispiel: Standardisierung konformer Landing Zones bei der Fabrikam Retail Group

Szenario: Die Fabrikam Retail Group ist in Nordamerika und der EU tätig und unterliegt strengen Anforderungen an die Datenresidenz sowie PCI-DSS-Verpflichtungen. Mehrere Anwendungsteams stellen monatlich Workloads bereit. Frühere Ad-hoc-Bereitstellungen führten zu inkonsistenter Tag-Vergabe, Ressourcen in nicht genehmigten Regionen und gelegentlichem Löschen von gemeinsam genutzten Netzwerkressourcen. Die Unternehmensführung fordert standardisierte, konforme Landing Zones, einen kontinuierlichen Nachweis der Wirksamkeit von Kontrollmechanismen und die Ermittlung sensibler Daten über Speicher- und Analyseplattformen hinweg.

Herausforderung: Entwerfen und implementieren Sie einen Azure-Governance-Ansatz, der Regionenbeschränkungen durchsetzt, Bereitstellungen mit Richtlinien und RBAC standardisiert, das versehentliche Löschen von Kerninfrastruktur verhindert, einen Bestands- und Änderungsverlauf pflegt, Berichte gemäß ISO 27001 und PCI DSS erstellt und sensible Daten ermittelt/klassifiziert.

Empfohlene Vorgehensweise:

1. Erstellen Sie eine Verwaltungsgruppenhierarchie: /Fabrikam als Stamm (Root); darunter die untergeordneten Gruppen /Corp (gemeinsam genutzte Dienste), /NA und /EU; fügen Sie unter jeder dieser Gruppen /Prod und /NonProd hinzu. Verschieben Sie die Subscriptions in die entsprechenden Verwaltungsgruppen.
2. Erstellen Sie Richtlinieninitiativen auf Ebene der Verwaltungsgruppen: (a) Zulässige Standorte pro geografischem Raum, (b) Erforderliche Tags (costCenter, owner, dataSensitivity) mit Modify/Append, (c) Erzwingen von Diagnoseeinstellungen für die Übermittlung an Log Analytics für Kerndienste, (d) Einschränkungen für SKUs und öffentliche Netzwerke für PaaS-Dienste. Weisen Sie die Initiativen den Gruppen /NA und /EU mit regionalspezifischen Parametern zu und schließen Sie Notfall-Subscriptions (Break-Glass) über notScopes aus.
3. Paketieren Sie einen Blueprint für die Standard-Landing-Zone: Die Artefakte umfassen die Erstellung von Hub- und App-Ressourcengruppen, RBAC-Zuweisungen (Network Contributor für das Plattformteam, Reader für die Revision), Richtlinienzuweisungen für Diagnose und Tags sowie ARM-Vorlagen zur Bereitstellung von vNETs, Peering, Key Vault und Log Analytics. Versionieren Sie den Blueprint und weisen Sie ihn allen Prod- und NonProd-Subscriptions zu.
4. Wenden Sie Ressourcensperren an: CanNotDelete für Hub-VNets, Routingtabellen, gemeinsam genutzte DNS-Zonen und Log Analytics-Arbeitsbereiche; ReadOnly für ein Archiv-Speicherkonto für regulatorische Exporte. Stellen Sie sicher, dass Owner von Subscriptions für gemeinsam genutzte Dienste die Sperren bei geplanten Änderungen mit eigenen Genehmigungen aufheben können.
5. Aktivieren Sie den Export des Aktivitätsprotokolls aus allen Subscriptions in einen zentralen Log Analytics-Arbeitsbereich und archivieren Sie es in einem Speicherkonto mit unveränderlicher (zeitbasierter) Aufbewahrung für sieben Jahre. Erstellen Sie Resource Graph-Dashboards, die nicht konforme Ressourcen, fehlende Tags und Assets nach Region und dem Tag dataSensitivity auflisten.
6. Aktivieren Sie Microsoft Defender for Cloud für den gesamten Tenant. Wählen Sie ISO/IEC 27001 und PCI DSS als regulatorische Standards aus, schalten Sie die automatische Bereitstellung (Auto-Provisioning) ein und überprüfen Sie die Empfehlungen. Erstellen Sie Arbeitselemente (Work Items) aus Ergebnissen mit hohem Schweregrad und verfolgen Sie die Verbesserung des Secure Score pro Subscription.
7. Stellen Sie Microsoft Purview in der Subscription für gemeinsam genutzte Dienste (/Corp) bereit. Registrieren Sie Azure SQL, Storage, Synapse und Power BI als Datenquellen. Konfigurieren Sie geplante Scans mit integrierten Typen vertraulicher Informationen und klassifizieren Sie die Datensätze. Veröffentlichen Sie den Datenkatalog und weisen Sie Data Owner zu. Exportieren Sie die erkannten Vertraulichkeitsbezeichnungen (Sensitivity Labels), um diese für Conditional Access und DLP zu nutzen.

Azure-Lösungsbegründung: Dieser Ansatz beginnt mit der Geltungsbereichsdefinition durch Verwaltungsgruppen, sodass Richtlinien und RBAC vorhersehbar vererbt werden. Anschließend werden zentrale Kontrollen mit Azure Policy und Initiativen durchgesetzt, um Nichtkonformität bereits zum Zeitpunkt der Bereitstellung zu verhindern. Der Blueprint bündelt Richtlinien, RBAC, Ressourcengruppen und Infrastrukturvorlagen, um konsistente Landing Zones auszuprägen, und ermöglicht gleichzeitig eine Parametrisierung nach Region und Umgebung. Ressourcensperren schützen kritische, gemeinsam genutzte Dienste vor versehentlichem Löschen, ohne die tägliche Konfiguration unnötig zu behindern. Die zentrale Aufbewahrung des Aktivitätsprotokolls und Resource Graph liefern einen zuverlässigen Inventar- und Änderungsnachweis. Defender for Cloud bietet eine Live-Übersicht über regulatorische Kontrollen und priorisierte Behebungsmaßnahmen, während Microsoft Purview sensible Daten ermittelt und klassifiziert, um die PCI-DSS- und Datenresidenz-Kontrollen in der gesamten Analyse-Landschaft von Fabrikam zu unterstützen.

← Kostenmanagement · Alle Domänen · Überwachung →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Microsoft durchsuchen →