Microsoft AZ-104: Azure-Abonnements, Governance und Kostenverwaltung — Lernleitfaden

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

Überblick

Azure-Abonnements, Governance und Kostenmanagement definieren, wie Sie Cloud-Ressourcen im großen Stil strukturieren, sichern, standardisieren und bezahlen. Ein fundiertes Design beginnt mit einer Organisationshierarchie (Verwaltungsgruppen und Abonnements), wendet den Zugriff nach dem Prinzip der geringsten Rechte (RBAC) an, setzt Standards und Compliance durch (Policy, Blueprints, Sperren und Tags) und optimiert kontinuierlich die Ausgaben (Cost Management und Advisor). Der Azure Resource Manager (ARM) bildet die Grundlage für Bereitstellungs-, Gruppierungs- und Lebenszyklusvorgänge, sodass Standards und Kontrollen von der Stammverwaltungsgruppe bis hin zu einzelnen Ressourcen konsistent angewendet werden.

Organisationsstruktur und Zugriffskontrolle

Verwaltungsgruppen sind das Konstrukt der obersten Ebene zur Organisation eines oder mehrerer Abonnements unter einer einzigen Stammverwaltungsgruppe. Sie können Verwaltungsgruppen bis zu sechs Ebenen tief verschachteln (die Stammgruppe ausgenommen), um Organisations- oder Umgebungsgrenzen abzubilden (z. B. Corp > Prod/NonProd > Business Units). Sowohl RBAC-Rollenzuweisungen als auch Azure Policy-Zuweisungen, die auf einer Verwaltungsgruppe angewendet werden, werden an alle untergeordneten Verwaltungsgruppen, Abonnements, Ressourcengruppen und Ressourcen vererbt, sofern sie nicht explizit auf einer niedrigeren Ebene überschrieben werden. Diese Vererbung ist zentral für die konsistente Durchsetzung von Standards; beispielsweise gilt eine Richtlinie „Öffentlichen Speicher verweigern“ auf der Produktions-Verwaltungsgruppe für jedes Produktionsabonnement ohne Konfiguration pro Abonnement.

Abonnements sind Isolationsgrenzen für Abrechnung und Bereitstellung. Gängige Typen sind Pay-As-You-Go, Enterprise Agreement (EA), Microsoft Customer Agreement (MCA), CSP und guthabenbasierte Angebote wie Visual Studio-Abonnements. Abonnements trennen Ausgaben, Kontingente und RBAC-Geltungsbereiche und sind die atomare Einheit für Gebühren und Budgets. Das Verschieben von Ressourcen zwischen Abonnements ist während Lebenszyklusübergängen (z. B. vom Entwickler- zum Produktionsmandanten, Reorganisationen) oft notwendig. Die Unterstützung für das Verschieben von Ressourcen ist anbieter- und ressourcenspezifisch; ARM-basierte Ressourcen wie VMs, verwaltete Datenträger, Speicherkonten, virtuelle Netzwerke und sogar Recovery Services-Tresore können in der Regel mit Einschränkungen verschoben werden. Zu den Voraussetzungen gehören, dass sich Quelle und Ziel im selben Azure Active Directory-Mandanten befinden (mandantenübergreifende Verschiebungen sind eingeschränkt), registrierte Ressourcenanbieter in beiden Abonnements, kompatible Regionen/SKUs und keine blockierenden Sperren/Richtlinien. Rechnen Sie während des Verschiebens mit einer vorübergehenden Nichtverfügbarkeit einiger Ressourcen; planen Sie Wartungsfenster für zustandsbehaftete Dienste. Klassische (ASM) Ressourcen können nicht verschoben werden. Überprüfen Sie die Unterstützung immer mithilfe des Vorgangs „Verschieben“ im Portal oder in der Dokumentation des Ressourcenanbieters.

Azure RBAC bietet einen differenzierten Zugriff nach dem Prinzip der geringsten Rechte mithilfe von Rollenzuweisungen in einem bestimmten Geltungsbereich (Scope). Der Geltungsbereich (Scope) kann eine Verwaltungsgruppe, ein Abonnement, eine Ressourcengruppe oder eine einzelne Ressource sein; Zuweisungen werden nach unten vererbt. Die zentralen integrierten Rollen sind:

Besitzer (Owner): vollständiger Zugriff auf alle Ressourcen, einschließlich Rollenzuweisungen.
Mitwirkender (Contributor): vollständige Berechtigungen zum Erstellen/Aktualisieren/Löschen von Ressourcen, jedoch keine Berechtigung zum Zuweisen von Rollen.
Leser (Reader): schreibgeschützter Zugriff. Benutzerdefinierte Rollen ermöglichen es Ihnen, erlaubte Actions und DataActions festzulegen, unter Ausschluss von NotActions und NotDataActions, und werden auf oder über dem beabsichtigten Zuweisungsbereich definiert. Verweigerungszuweisungen (Deny Assignments), die von bestimmten Diensten wie Blueprints oder durch Sperren erstellt werden, haben Vorrang vor Erlaubniszuweisungen (Allow Assignments), was eine versehentliche Ausweitung von Berechtigungen verhindert.

Governance, Compliance und Ressourcenschutz

Azure Policy wertet den Ressourcenstatus zum Zeitpunkt der Erstellung/Aktualisierung und bei regelmäßigen Compliance-Scans aus. Eine Richtliniendefinition drückt eine Regel (mit optionalen Parametern) und eine Auswirkung (Effect) aus. Sie gruppieren zusammengehörige Definitionen in Initiativen, um die Zuweisung in großem Umfang zu vereinfachen. Zuweisungen heften eine Definition oder Initiative an einen Bereich (Verwaltungsgruppe, Abonnement, Ressourcengruppe oder Ressource) mit Parameterwerten und, für bestimmte Effekte, einer verwalteten Identität für die Korrektur. Wichtige Effekte, die Sie beherrschen sollten:

Deny: blockiert nicht konforme Erstellungs-/Aktualisierungsvorgänge zum Zeitpunkt der Anforderung.
Audit: erlaubt den Vorgang, zeichnet aber die Nichtkonformität für das Reporting auf.
DeployIfNotExists: wenn eine zugehörige Ressource oder Einstellung fehlt, wird eine Vorlagenbereitstellung ausgelöst, um das Ziel in einen konformen Zustand zu bringen (z. B. Bereitstellung einer Diagnoseeinstellung oder einer Richtlinienzuweisung). Weitere wichtige Effekte sind Append (fügt beim Schreiben Felder wie Tags hinzu) und Modify (ändert Eigenschaften). Richtlinien können zulässige Standorte, SKU-Einschränkungen, erforderliche Tags, Diagnoseeinstellungen und Verschlüsselungsstandards erzwingen. Beispielsweise stellt die Einschränkung von Azure SQL Server-Standorten sicher, dass Bereitstellungen nur in genehmigten Regionen oder Ressourcengruppen erfolgen.

Azure Blueprints bündeln Governance-as-Code, indem sie Artefakte – Richtlinienzuweisungen, Rollenzuweisungen, ARM-Vorlagen und Ressourcengruppendeklarationen – in einem versionierten Blueprint kombinieren. Weisen Sie Blueprints Abonnements oder Verwaltungsgruppen zu, um Umgebungen konsistent zu prägen. Eine Blueprint-Zuweisung kann Sperren auf Artefaktebene mit Modi wie DoNotDelete oder ReadOnly anwenden, um bereitgestellte Ressourcen vor Abweichungen (Drift) zu schützen. Verwenden Sie Blueprints, um neue Abonnements mit obligatorischen Kontrollen und einer Basisinfrastruktur zu initialisieren.

Ressourcensperren bieten eine letzte Verteidigungslinie gegen versehentliche Änderungen. Wenden Sie CanNotDelete an, um das Löschen zu verhindern, während Aktualisierungen erlaubt bleiben; wenden Sie ReadOnly an, um Schreib- und Löschvorgänge zu blockieren. Sperren werden von übergeordneten Bereichen vererbt, sodass eine ReadOnly-Sperre für eine Ressourcengruppe alle enthaltenen Ressourcen betrifft (z. B. schlägt das Stoppen/Starten einer VM fehl, da diese Vorgänge Schreibzugriffe durchführen). Sperren setzen RBAC-Berechtigungen außer Kraft: Selbst Besitzer (Owner) können eine gesperrte Ressource nicht löschen, ohne zuerst die Sperre zu entfernen.

Tags sind Schlüssel-Wert-Paare für Ressourcengruppen und Ressourcen zur Kategorisierung von Workloads (Abteilung, Umgebung, Kostenstelle). Die Vererbung von Tags erfolgt nicht automatisch; um Tags für jede Ressource zu garantieren, verwenden Sie Azure Policy (Append/Modify), um Tags von der Ressourcengruppe zum Zeitpunkt der Erstellung/Aktualisierung zu erzwingen oder zu erben. Tags steuern die Tag-basierte Kostenberichterstattung in Cost Management, sodass Abteilungen eine genaue Kostenverrechnung erhalten. Um einzelne Ressourcen wie virtuelle Maschinen Abteilungen zuzuordnen, wenden Sie Tags direkt auf jede VM an.

Kostenverwaltung und -optimierung

Azure Cost Management + Billing bietet Ihnen Budgets, Kostenanalysen, Exporte und Warnungen. Budgets werden für einen Bereich (Abonnement oder Ressourcengruppe) definiert und können nach Ressourcengruppe, Dienst oder Tag filtern. Konfigurieren Sie Schwellenwerte (z. B. 50 %, 80 %, 100 %), um Warnungen über Aktionsgruppen (Action Groups) zu senden und optional Automatisierungen (Logic App, Function) auszulösen, um nicht kritische Workloads herunterzuskalieren oder abzuschalten; Budgets selbst erzwingen keine Ausgaben. Die Kostenanalyse ermöglicht es Ihnen, Daten nach Zeit, Ressource, Verbrauchseinheit (Meter), Ressourcengruppe, Abonnement und Tag aufzuschlüsseln, um Kostentreiber und Trends zu verstehen; planen Sie Exporte in den Speicher zur Aufnahme in BI-Tools. Ausgabenlimits sind für guthabenbasierte Angebote verfügbar (z. B. kostenlose Testversion, Visual Studio) und versetzen das Abonnement bei Erreichen in einen deaktivierten Zustand, um weitere Kosten zu verhindern. Ausgabenlimits werden bei Pay-As-You-Go oder den meisten EA/MCA-Angeboten nicht unterstützt; verwenden Sie stattdessen Budgets und Automatisierung.

Azure Advisor wertet Ihre Ressourcen kontinuierlich aus und erstellt umsetzbare Empfehlungen in den Bereichen Kosten, Sicherheit, Zuverlässigkeit, Leistung und Operational Excellence. Kostenempfehlungen umfassen die Größenanpassung/das Herunterfahren von nicht ausgelasteten VMs, den Kauf von Reservierungen oder Sparplänen und die Beseitigung von ungenutzten öffentlichen IPs oder Datenträgern. Zuverlässigkeit umfasst Verfügbarkeitsgruppen/-zonen und Backup-Konfigurationen; Leistung deckt Compute-/Speicheroptimierungen ab; Sicherheit ist in Defender for Cloud integriert; Operational Excellence hebt Best-Practice-Konfigurationen hervor. Verwenden Sie den Advisor Score, um den Fortschritt zu verfolgen, und integrieren Sie Empfehlungen gegebenenfalls in das Backlog oder in die automatisierte Korrektur.

Bereitstellung und Lebenszyklus mit dem Azure Resource Manager

ARM ist die Steuerungsebene für Azure und ermöglicht deklarative, idempotente Bereitstellungen und eine konsistente Verwaltung. Ressourcengruppen sind logische Container für Lebenszyklus- und RBAC-Grenzen; gruppieren Sie Ressourcen, die einen gemeinsamen Lebenszyklus, Berechtigungen und Standortabhängigkeiten haben. RBAC- und Richtlinienzuweisungen auf Ebene der Ressourcengruppe steuern alle enthaltenen Ressourcen, und Sperren und Tags auf Gruppenebene werden vererbt, es sei denn, sie werden durch Richtlinien oder Vorgänge auf Ressourcenebene überschrieben.

ARM-Vorlagen (und Bicep als übergeordnete Sprache) definieren Ressourcen, Parameter, Variablen, Ausgaben und Abhängigkeiten. Sie ermöglichen wiederholbare Bereitstellungen und stellen sicher, dass Governance-Artefakte (z. B. Richtlinien, Rollenzuweisungen) und Workloads gemeinsam angewendet werden. Verwenden Sie Vorlagenspezifikationen (Template Specs), um Vorlagen zu versionieren und innerhalb der Organisation zu teilen. Bereitstellungsmodi sind wichtig:

Inkrementell (Incremental): Erstellt/aktualisiert Ressourcen in der Vorlage; entfernt keine vorhandenen Ressourcen, die nicht in der Vorlage enthalten sind.
Vollständig (Complete): Löscht nach der Bereitstellung Ressourcen im Zielbereich, die nicht in der Vorlage definiert sind – mit Vorsicht verwenden, um einen strikten Soll-Zustand innerhalb der Ressourcengruppe zu erzwingen. Der Bereitstellungsverlauf ist auf Ressourcengruppen-, Abonnement- oder Verwaltungsgruppenebene beschränkt. Wenn mehrere Ressourcen durch eine einzige Vorlage bereitgestellt werden, sehen Sie sich die Bereitstellung und ihre Vorlage über das Blade „Bereitstellungen“ des Zielbereichs – üblicherweise die Ressourcengruppe – an, um Änderungen zu prüfen und Fehler zu beheben.

Praktisches Problemszenario

Starbucks übernimmt eine regionale Kette und muss drei neue Abonnements integrieren. Dabei sollen globale Sicherheitsrichtlinien durchgesetzt, eine Kostenverrechnung auf Abteilungsebene ermöglicht und mehrere gemeinsam genutzte Dienste ohne Dienstunterbrechung in ein konsolidiertes „Corp-IT“-Abonnement migriert werden.

Aufbau der Verwaltungsgruppenhierarchie

Aktion: Erstellen Sie eine an der Stammverwaltungsgruppe ausgerichtete Hierarchie: Starbucks > Prod/NonProd > BusinessUnits (Retail, SupplyChain, CorpIT).
Warum: Verwaltungsgruppen ermöglichen eine hierarchische Vererbung von RBAC und Richtlinien, sodass globale Kontrollen (z. B. Sicherheitsbaselines) automatisch auf jedes neue Abonnement angewendet werden.

Basiszugriff mit RBAC festlegen

Aktion: Weisen Sie auf der Ebene der BusinessUnits die Rolle „Leser“ (Reader) dem Auditing-Team, „Besitzer“ (Owner) dem zentralen Plattformteam in CorpIT und „Mitwirkender“ (Contributor) den delegierten BU-Admins in ihren jeweiligen Bereichen zu. Erstellen Sie eine benutzerdefinierte Rolle „Tag-Editor“, die

undefined

erlaubt.

Warum: Das Prinzip der geringsten Rechte (Least Privilege) im korrekten Geltungsbereich verhindert zu weitreichende Berechtigungen und ermöglicht gleichzeitig die Autonomie der BUs; eine benutzerdefinierte Rolle vermeidet die Gewährung voller Schreibrechte nur für die Tag-Verwaltung.

Governance mit Policy und Blueprints durchsetzen

Aktion: Erstellen Sie eine Initiative, die Richtlinien für erlaubte Standorte, erforderliche Tags (CostCenter, Department, Environment), Diagnoseeinstellungen für wichtige Dienste und „Öffentlichen Zugriff verweigern“ für Speicher enthält. Verpacken Sie dies in einem Azure Blueprint mit Artefakten: der Zuweisung der Initiative, RBAC-Rollenzuweisungen, ARM-Vorlagen für einen gemeinsamen Log Analytics-Arbeitsbereich und einen DDoS-Plan sowie einem Standard-Layout für Ressourcengruppen. Weisen Sie den Blueprint jedem neuen Abonnement mit DoNotDelete-Sperren für die Basisressourcen zu.
Warum: Blueprints liefern eine versionierte, wiederholbare Landing Zone mit Sperren, um versehentliches Löschen zu verhindern; Policy stellt sicher, dass jede Ressource bei der Erstellung konform ist und Abweichungen über DeployIfNotExists korrigiert.

Tags anwenden und Vererbung garantieren

Aktion: Verwenden Sie eine Modify-Richtlinie, um Tags von Ressourcengruppen zu erben, und eine Append-Richtlinie, um fehlende Tags beim Erstellen/Aktualisieren von Ressourcen hinzuzufügen. Fordern Sie CostCenter-Werte, die dem Finanzsystem von Starbucks entsprechen.
Warum: Die native Vererbung ist nicht automatisch; Policy stellt sicher, dass alle Ressourcen die Metadaten tragen, die für die kostenbasierte Berichterstattung mittels Tags erforderlich sind.

Cost Management und Benachrichtigungen einrichten

Aktion: Erstellen Sie Budgets auf Ebene jedes Abonnements und kritischer Ressourcengruppen, bei Bedarf nach Tags gefiltert, mit Benachrichtigungen bei 50/80/100 % an eine Aktionsgruppe, die eine Logic App auslöst. Diese benachrichtigt die BU-Leiter und skaliert optional Dev/Test-Ressourcen herunter. Konfigurieren Sie Cost Analysis-Dashboards nach Tags und exportieren Sie die Daten täglich in einen Speicher.
Warum: Budgets und Benachrichtigungen bieten eine frühzeitige Warnung und lösen nahezu in Echtzeit Korrekturmaßnahmen aus; die Auswertung nach Tags ermöglicht eine genaue Kostenverrechnung.

Gemeinsam genutzte Dienste sicher zwischen Abonnements migrieren

Aktion: Überprüfen Sie die Unterstützung für die Verschiebung der Zielressourcen (VMs, verwaltete Datenträger, VNets, Speicher, Recovery Services-Tresore). Entfernen Sie blockierende Sperren, stellen Sie sicher, dass die Ressourcenanbieter in Quelle und Ziel registriert sind, bestätigen Sie die Kompatibilität von Region/SKU und planen Sie ein Wartungsfenster. Verwenden Sie den Vorgang „Verschieben“ (Move) auf Ebene der Ressourcengruppe, um die Ressourcen in das Corp-IT-Abonnement zu verschieben; validieren Sie nach der Verschiebung erneut die Diagnoseeinstellungen und Richtlinien.
Warum: Das Verschieben auf Ebene der Ressourcengruppe erhält Abhängigkeiten und minimiert Ausfallzeiten; Vorabprüfungen vermeiden fehlgeschlagene Verschiebungen aufgrund von Richtlinien- oder Anbieter-Inkompatibilitäten.

Kritische Ressourcen mit Sperren schützen

Aktion: Wenden Sie CanNotDelete auf grundlegende Netzwerk- und Überwachungsressourcen an; wenden Sie ReadOnly auf eine Ressourcengruppe mit einem Golden Image an.
Warum: Sperren setzen RBAC außer Kraft, um versehentliches Löschen oder Ändern von Basis-Assets zu verhindern, während normale Vorgänge an anderer Stelle weiterhin erlaubt sind.

Kontinuierliche Optimierung mit Advisor

Aktion: Überprüfen Sie wöchentlich die Empfehlungen von Advisor; akzeptieren Sie Kostenvorschläge zur Größenanpassung (Rightsizing) von nicht ausgelasteten VMs und zum Kauf von Reservierungen für stabile Workloads; verfolgen Sie den Fortschritt mit dem Advisor Score.
Warum: Advisor operationalisiert die laufende Optimierung in den Bereichen Kosten, Sicherheit, Zuverlässigkeit, Leistung und operative Exzellenz und erhält die Governance über die ursprüngliche Bereitstellung hinaus aufrecht.

← Azure Active Directory und Identitätsverwaltung · Alle Domänen · Azure Virtual Machines und Compute →

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