Microsoft AZ-900: Speicher & Datenbanken — Lernleitfaden
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.
Azure bietet eine breite Grundlage für die Speicherung von unstrukturierten und strukturierten Daten im globalen Maßstab, mit integrierter Langlebigkeit, Sicherheit und Kostenkontrolle. Das Verständnis der richtigen Speicherprimitive, Redundanzmodelle, Zugriffsebenen und Datenbankdienste ermöglicht zuverlässige, performante Anwendungen – von virtuellen Maschinen bis hin zu global verteilten Web- und mobilen Plattformen.
Azure Storage-Dienste und verwaltete Datenträger
Azure Blob Storage ist der Eckpfeiler für unstrukturierte Daten. Block-Blobs verarbeiten große Objekte mit effizientem Streaming und parallelem Upload, Snapshots, Versionierung und Tiering. Seiten-Blobs (Page Blobs) sind für zufällige Lese-/Schreib-I/O-Vorgänge in 512-Byte-Seiten optimiert und bilden die Grundlage für virtuelle Festplatten (VHDs); sie liegen unter Datenträgern und Szenarien, die konsistente IOPS mit geringer Latenz erfordern. Anfüge-Blobs (Append Blobs) sind auf schreibintensive Anfügeszenarien wie Anwendungsprotokolle zugeschnitten, bei denen neue Blöcke effizient am Ende hinzugefügt werden. Azure Files bietet vollständig verwaltete Dateifreigaben, die über SMB oder NFS mit NTFS-ACLs, Verzeichnisintegrationsoptionen und Azure File Sync zum Zwischenspeichern von „heißen“ Daten (Hot Data) auf Windows Servern zugänglich sind. Queue Storage bietet ein schlankes, langlebiges Anwendungs-Messaging zur Entkopplung von Komponenten mit „At-least-once“-Zustellungssemantik. Table Storage stellt einen schemalosen Schlüssel-Attribut-Speicher für riesige, partitionierte Datensätze bereit, bei dem Sie Partitions- und Zeilenschlüssel zur Skalierung und Kosteneffizienz steuern. Verwaltete Datenträger (Managed Disks) bieten langlebigen, persistenten Blockspeicher für Azure Virtual Machines, ohne dass Speicherkonten oder Seiten-Blobs direkt verwaltet werden müssen. Wählen Sie zwischen Standard HDD für kostenoptimierte Durchsatz-Workloads, Standard SSD für ausgewogene Leistung, Premium SSD und Premium SSD v2 für hohe IOPS bei geringer Latenz und Ultra Disk für die anspruchsvollsten transaktionalen Workloads mit konfigurierbaren IOPS und Durchsatz. Verwaltete Datenträger unterstützen Snapshots, inkrementelle Backups, Datenträgerverschlüsselung und Verfügbarkeitsoptionen, die auf Ihre VM-SLAs abgestimmt sind.
- Blob – Block-Blob
- Datenmodell oder I/O-Muster: Großes Objekt, sequenzielles I/O
- Wichtige Funktionen: Tiering, Snapshots, Versionierung, Lebenszyklusrichtlinien
- Typische Anwendungsfälle: Bilder, Videos, Backups, Big-Data-Landing-Zones
- Wichtige Limits/Hinweise: Einzelner Blob bis zu ~190 TiB; nicht für zufälliges I/O optimiert
- Blob – Seiten-Blob (Page Blob)
- Datenmodell oder I/O-Muster: Zufälliges I/O in 512-Byte-Seiten
- Wichtige Funktionen: Lese-/Schreibvorgänge mit geringer Latenz, Grundlage für VHDs
- Typische Anwendungsfälle: Zugrundeliegender Speicher für Datenträger und Szenarien, die wahlfreien Zugriff erfordern
- Wichtige Limits/Hinweise: Größe von Seiten-Blobs bis zu 8 TiB; wird durch verwaltete Datenträger abstrahiert
- Blob – Anfüge-Blob (Append Blob)
- Datenmodell oder I/O-Muster: Nur-Anfüge-Schreibvorgänge (Append-only)
- Wichtige Funktionen: Effizientes Anhängen an Protokolle, Unveränderlichkeitsoptionen
- Typische Anwendungsfälle: Telemetrie- und Anwendungsprotokolle
- Wichtige Limits/Hinweise: Direkte Aktualisierung (Update-in-place) nicht unterstützt; es gelten Limits für die Blockanzahl
- Azure Files
- Datenmodell oder I/O-Muster: POSIX/SMB/NFS-Dateisemantik
- Wichtige Funktionen: SMB/NFS-Zugriff, NTFS-ACLs, Integration von AD DS/Azure AD DS, File Sync
- Typische Anwendungsfälle: Lift-and-Shift von Dateifreigaben, App-Konfiguration, Benutzer-Home-Verzeichnisse
- Wichtige Limits/Hinweise: Standard- und Premium-Tarife; große Dateifreigaben bis zu 100 TiB
- Queue Storage
- Datenmodell oder I/O-Muster: Nachrichtenwarteschlange
- Wichtige Funktionen: „At-least-once“-Zustellung, Sichtbarkeits-Timeouts, Verarbeitung von „Poison Messages“
- Typische Anwendungsfälle: Hintergrundverarbeitung, entkoppelte Microservices
- Wichtige Limits/Hinweise: Nachrichtengröße bis zu 64 KB (für größere/fortgeschrittene Muster Service Bus verwenden)
- Table Storage
- Datenmodell oder I/O-Muster: Schlüssel-Attribut-NoSQL
- Wichtige Funktionen: Massive Skalierung, Partitionierung nach PartitionKey, niedrige Kosten
- Typische Anwendungsfälle: Telemetrie, Kataloge, Benutzerprofile
- Wichtige Limits/Hinweise: Keine Joins oder sekundären Indizes; Cosmos DB Table API für globale Anforderungen
- Managed disks
- Datenmodell oder I/O-Muster: Blockspeicher für VMs
- Wichtige Funktionen: Standard/Premium/Ultra-SKUs, Snapshots, Skalierung, Datenträgerverschlüsselung
- Typische Anwendungsfälle: Betriebssystem-/Datenträger für VMs, Datenbanken, geschäftskritische Anwendungen (Line-of-Business)
- Wichtige Limits/Hinweise: Bis zu 32 TiB pro Datenträger; ZRS für ausgewählte SKUs verfügbar
Redundanz- und Durabilitätsoptionen
Redundanzmodelle definieren, wo und wie viele synchrone und asynchrone Replikate Azure für Ihre Daten vorhält. Lokal redundanter Speicher (LRS) hält drei Kopien in einem einzigen Rechenzentrum in einer Region vor und schützt so zu den niedrigsten Kosten vor Laufwerks- und Rack-Ausfällen. Zonenredundanter Speicher (ZRS) verteilt drei synchrone Kopien über separate Verfügbarkeitszonen in einer Region und bietet so Resilienz gegenüber einem zonalen Ausfall ohne Anwendungsfailover. Georedundanter Speicher (GRS) erweitert LRS durch die asynchrone Replikation Ihrer Daten in die gekoppelte Region, was zu insgesamt sechs Kopien in zwei Regionen führt. Nachdem Microsoft ein Kontofailover initiiert hat, wird die sekundäre zur neuen primären Region. Georedundanter Speicher mit Lesezugriff (RA‑GRS) fügt einen aktiven, schreibgeschützten sekundären Endpunkt hinzu, sodass Anwendungen auch vor einem Failover aus der sekundären Region lesen können. Dies ermöglicht eine globale Leseverteilung und das Auslagern von Analysen. Geozonenredundanter Speicher (GZRS) kombiniert ZRS in der primären Region mit asynchroner Replikation zu LRS in der gekoppelten Region und schützt so sowohl vor zonalen als auch vor regionalen Ausfällen. Eine Variante mit Lesezugriff (RA‑GZRS) stellt Leseendpunkte in der sekundären Region bereit. Die Auswahl richtet sich nach den Wiederherstellungszielen, den Latenzerwartungen und dem Budget. Innerhalb einer Region schützt ZRS vor Zonenausfällen und hält gleichzeitig die Schreiblatenz niedrig. Regionsübergreifend werden GRS/RA‑GRS und GZRS für Disaster-Recovery- und regionsübergreifende Leseszenarien bevorzugt. Die Datenkonsistenz mit der sekundären Region ist bei den Geo-Optionen designbedingt asynchron, daher sollten Anwendungen Eventual Consistency tolerieren, bis ein Failover abgeschlossen ist.
- LRS
- Replikationslayout: 3 Kopien in einem einzigen Rechenzentrum (Region)
- Lesezugriff auf sekundäre Region: Nein
- Regions-/Zonentoleranz: Schützt vor lokalen Hardware-/Rack-Ausfällen
- Typische Workloads: Entwicklung/Test, kostengünstiger Speicher, unkritische Daten
- ZRS
- Replikationslayout: 3 Kopien synchron über 3 Verfügbarkeitszonen (Region)
- Lesezugriff auf sekundäre Region: Nein
- Regions-/Zonentoleranz: Übersteht zonale Ausfälle ohne Failover auf Anwendungsebene
- Typische Workloads: Produktive Web-/App-Inhalte, die eine hohe regionale Verfügbarkeit erfordern
- GRS
- Replikationslayout: LRS in primärer Region + asynchrones LRS in gekoppelter Region (insgesamt ~6 Kopien)
- Lesezugriff auf sekundäre Region: Nein
- Regions-/Zonentoleranz: Regionales DR über Kontofailover; kein Zonenschutz in der primären Region
- Typische Workloads: Backup/Archivierung mit regionaler DR-Strategie
- RA‑GRS
- Replikationslayout: GRS + Leseendpunkt in der sekundären Region
- Lesezugriff auf sekundäre Region: Ja
- Regions-/Zonentoleranz: Wie bei GRS; ermöglicht globale Leseverteilung
- Typische Workloads: Globale Lesezugriffe auf Inhalte, Auslagerung von Analysen/Berichten auf die sekundäre Region
- GZRS
- Replikationslayout: ZRS in primärer Region + asynchrones LRS in gekoppelter Region
- Lesezugriff auf sekundäre Region: Nein (RA‑GZRS verwenden)
- Regions-/Zonentoleranz: Schützt vor zonalen Ausfällen und regionalen Katastrophen
- Typische Workloads: Geschäftskritische Anwendungen, die Zonen- und Geo-Resilienz erfordern
Zugriffsebenen und Lebenszyklusverwaltung
Blob-Zugriffsebenen stimmen die Speicherkosten auf die Zugriffsmuster ab. Die „Hot“-Ebene ist für häufigen Zugriff optimiert und bietet die niedrigsten Transaktionskosten für Lese- und Schreibvorgänge bei einem höheren Speicherpreis pro GB. Die „Cool“-Ebene senkt den Speicherpreis pro GB und erhöht die Transaktions- sowie die Kosten für vorzeitiges Löschen, wodurch sie sich für Datensätze eignet, auf die selten zugegriffen wird, wie z. B. Monatsberichte oder kurzfristige Backups. Die „Archive“-Ebene bietet die niedrigsten Speicherkosten, erfordert jedoch vor dem Zugriff eine Reaktivierung (Rehydration) und hat die höchsten Zugriffs- und Gebühren für vorzeitiges Löschen; sie ist für Langzeitaufbewahrung und Compliance-Szenarien konzipiert. Richtlinien zur Lebenszyklusverwaltung automatisieren das Tiering und die Aufbewahrung auf Container- oder Kontoebene. Regeln können Blobs zwischen den Ebenen „Hot“, „Cool“ und „Archive“ basierend auf dem Zeitpunkt der letzten Änderung, dem Zeitpunkt des letzten Zugriffs oder Blob-Index-Tags verschieben und Versionen, Snapshots oder Basis-Blobs nach einem definierten Alter löschen. Richtlinien helfen, die Gesamtbetriebskosten (Total Cost of Ownership) zu senken, indem kalte Daten aus dem „Hot“-Speicher verschoben und veraltete Daten ohne manuellen Eingriff entfernt werden. Die Lebenszyklusverwaltung ist für Speicherkonten vom Typ „Universell v2“ und „Blob Storage“ verfügbar und funktioniert mit Block- und Anfüge-Blobs; sie ist nicht auf Premium-Block-Blob-Speicher anwendbar. Die Reaktivierung aus dem Archiv (Archive Rehydration) unterstützt Standard- und Hochprioritätsoptionen, bei denen Kosten gegen Geschwindigkeit abgewogen werden. Planen Sie für die Standard-Reaktivierung Abrufzeitfenster von mehreren Stunden ein, und für die Hochprioritäts-Reaktivierung bei kleineren Objekten Minuten bis Stunden. Für Compliance-Anforderungen kombinieren Sie die „Archive“-Ebene mit Unveränderlichkeitsrichtlinien (zeitbasierte Aufbewahrung oder Legal Hold), um WORM-Garantien (Write-Once, Read-Many) auf Container- oder Blob-Ebene durchzusetzen.
- Hot
- Speicherkosten: Am höchsten
- Zugriffs-/Transaktionskosten: Am niedrigsten
- Mindestaufbewahrungsdauer: Keine
- Abruflatenz: Millisekunden (online)
- Typische Daten: Aktive Inhalte, häufig gelesene/geschriebene Daten
- Cool
- Speicherkosten: Niedriger als „Hot“
- Zugriffs-/Transaktionskosten: Höher als „Hot“; Gebühr für vorzeitiges Löschen fällt an
- Mindestaufbewahrungsdauer: 30 Tage
- Abruflatenz: Millisekunden (online)
- Typische Daten: Selten abgerufene Daten, kurzfristige Backups
- Archive
- Speicherkosten: Am niedrigsten
- Zugriffs-/Transaktionskosten: Am höchsten; Gebühr für vorzeitiges Löschen fällt an
- Mindestaufbewahrungsdauer: 180 Tage
- Abruflatenz: Stunden (Reaktivierung erforderlich)
- Typische Daten: Langzeitaufbewahrung, Compliance-Archive, selten abgerufene Backups
Sicherheit, Verschlüsselung und Zugriffskontrolle
Verschlüsselung im Ruhezustand (at rest) ist standardmäßig über Storage Service Encryption (SSE) aktiviert. Standardmäßig schützen von Microsoft verwaltete Schlüssel die Daten transparent. Für eine strengere Kontrolle und Funktionstrennung können kundenseitig verwaltete Schlüssel (CMK) pro Speicherkonto konfiguriert werden. Dabei werden Schlüssel in Azure Key Vault oder einem Managed HSM verwendet, was die Rotation und den Widerruf von Schlüsseln unterstützt. Für sensible Workloads reduzieren Optionen wie doppelte Verschlüsselung und Confidential Computing die Risiken der Datenexposition weiter. Für die Übertragung (in transit) sollte HTTPS mit TLS für alle Vorgänge auf der Datenebene erzwungen werden. Die Zugriffskontrolle umfasst identitätsbasierte Autorisierung und bereichsbezogene Token. Azure RBAC lässt sich in Microsoft Entra ID integrieren, um Benutzern, Gruppen und verwalteten Identitäten den Zugriff auf die Datenebene nach dem Prinzip der geringsten Rechte (Least Privilege) zu gewähren, z. B. über Rollen wie Storage Blob Data Reader/Contributor. RBAC macht gemeinsam genutzte Geheimnisse überflüssig und unterstützt bedingten Zugriff (Conditional Access), Privileged Identity Management und Auditing. Shared Access Signatures (SAS) delegieren zeitlich begrenzten und auf Berechtigungen beschränkten Zugriff an Clients, die möglicherweise keine Identität haben. SAS können mit Kontoschlüsseln oder per Benutzerdelegation unter Verwendung von Microsoft Entra-Anmeldeinformationen signiert werden, um die Offenlegung von Kontoschlüsseln zu vermeiden. Kombinieren Sie RBAC für den Zugriff zwischen Diensten und den administrativen Zugriff mit SAS für temporäre Client-Zugriffsabläufe. Schützen Sie Kontoschlüssel und rotieren Sie sie regelmäßig. Bevorzugen Sie nach Möglichkeit SAS mit Benutzerdelegation. Netzwerkisolierung mit Private Endpoints oder Dienstendpunkten, Firewall-Regeln und Richtlinien für unveränderlichen Speicher vervollständigen eine tiefengestaffelte Sicherheitsstrategie (Defense-in-Depth) für Speicherkonten.
- Azure RBAC (Microsoft Entra ID)
- Geltungsbereich: Identitätsbasierte Rollen auf der Daten- und Verwaltungsebene des Speichers
- Optimal für: Administratoren, Dienste und Anwendungen mit verwalteten Identitäten
- Wichtige Eigenschaften: Geringste Rechte (Least Privilege), bedingter Zugriff, Überprüfbarkeit, keine gemeinsam genutzten Geheimnisse
- Risikoaspekte: Erfordert Identitätsintegration; Widerruf durch Rollenänderungen
- Shared Access Signature (SAS)
- Geltungsbereich: Zeitlich begrenzte, auf Berechtigungen beschränkte Token für bestimmte Ressourcen
- Optimal für: Delegierung von eingeschränktem Zugriff an Clients/Partner
- Wichtige Eigenschaften: Granulare Berechtigungen, IP-/Zeitbeschränkungen; SAS mit Benutzerdelegation vermeidet Kontoschlüssel
- Risikoaspekte: Ein kompromittiertes Token gewährt Zugriff bis zum Ablauf; Verteilung schützen und kurze Lebensdauern festlegen
Relationales PaaS und global verteilte NoSQL-Datenbanken
Azure SQL Database bietet eine verwaltete relationale Engine mit automatischem Patching, integrierter Hochverfügbarkeit, Backups und Skalierung. Stellen Sie einzelne Datenbanken oder elastische Pools bereit, um variable Workloads zu konsolidieren. Der Dienst unterhält mehrere Replikate innerhalb einer Region und unterstützt Zonenredundanz; Transparent Data Encryption (TDE) ist standardmäßig aktiviert. Automatisierte Backups ermöglichen eine Point-in-Time-Wiederherstellung (PITR) für typischerweise 7–35 Tage, mit optionaler Langzeitaufbewahrung (LTR) von bis zu mehreren Jahren in Azure Storage. Für multiregionale Resilienz und Lesevorgänge mit geringer Latenz verwenden Sie aktive Georeplikation (bis zu vier lesbare sekundäre Replikate) oder Autofailover-Gruppen für eine koordinierte Notfallwiederherstellung (DR) im großen Stil. Azure SQL Managed Instance bietet eine Kompatibilität von nahezu 100 % mit der SQL Server-Engine für Features auf Instanzebene wie SQL Agent, datenbankübergreifende Abfragen, Service Broker und CLR. Dies ermöglicht eine unkomplizierte Modernisierung von lokalen Systemen ohne Refactoring. Sie teilt die gleiche verwaltete HA-Architektur, Online-Patching, automatisierte Backups, standardmäßige TDE und unterstützt Autofailover-Gruppen zwischen Regionen. Netzwerkisolierung mit Private Endpoints und die Skalierung von Rechenleistung/Speicher pro Datenbank oder pro Instanz sorgen für vorhersagbare Leistungsbereiche. Azure Cosmos DB ist eine vollständig verwaltete, multimodale NoSQL-Datenbank mit schlüsselfertiger globaler Verteilung und Schreibvorgängen in mehreren Regionen. Sie garantiert Latenzen im einstelligen Millisekundenbereich für das 99. Perzentil innerhalb einer Region und bietet fünf einstellbare Konsistenzebenen, um Leistung und Korrektheit über Regionen hinweg abzuwägen. Stellen Sie den Durchsatz in RU/s bereit oder nutzen Sie die automatische Skalierung, fügen Sie Regionen ohne Ausfallzeiten hinzu oder entfernen Sie sie und konfigurieren Sie ein automatisches Failover. Die APIs umfassen Core (SQL), MongoDB, Cassandra, Gremlin und Table, was die Migration und Integration in verschiedene Anwendungsstacks vereinfacht.
- Azure SQL Database
- Modell: Relationales PaaS (einzelne DB/elastischer Pool)
- Kompatibilität: Neueste SQL-Features; Kompatibilität auf Anwendungsebene
- HA/DR: Integrierte Replikate, Zonenredundanz; aktive Georeplikation; Autofailover-Gruppen
- Backups/TDE: Automatisches PITR 7–35 Tage; LTR bis zu Jahre; TDE standardmäßig aktiviert
- Geo-Optionen: Lesbare sekundäre Replikate über Regionen hinweg; koordinierte Failover-Gruppen
- Optimal geeignet für: SaaS/mandantenfähige Apps, neue cloud-native relationale Workloads
- Azure SQL Managed Instance
- Modell: Relationales PaaS (Instanz)
- Kompatibilität: Hohe Feature-Parität mit SQL Server, inkl. SQL Agent, Cross-DB
- HA/DR: Integrierte HA; Zonenredundanz; Autofailover-Gruppen
- Backups/TDE: Automatisches PITR 7–35 Tage; LTR; TDE standardmäßig aktiviert; native Wiederherstellungsunterstützung
- Geo-Optionen: Multiregional mit Failover-Gruppen und lesbaren sekundären Replikaten
- Optimal geeignet für: Lift-and-Shift von lokalen SQL-Systemen mit minimalen Änderungen
- Azure Cosmos DB
- Modell: NoSQL, multimodal (Core, MongoDB, Cassandra, Gremlin, Table)
- Kompatibilität: Kompatibilität auf API-Ebene für gängige NoSQL-Stacks
- HA/DR: Multiregionale Schreibvorgänge mit mehreren Mastern; 99,99 % SLAs
- Backups/TDE: Automatisierte und kontinuierliche Backup-Optionen; Verschlüsselung im Ruhezustand
- Geo-Optionen: Regionen live hinzufügen/entfernen; einstellbare Konsistenz; automatisches Failover
- Optimal geeignet für: Globale Anwendungen mit geringer Latenz, IoT, Kataloge, Personalisierung
Praktisches Problem: Tailwind Traders: Bicoastal-Resilienz mit sicheren, kostenoptimierten Datenebenen
Szenario: Tailwind Traders betreibt E-Commerce-Anwendungen mit primären Workloads in East US und einer Disaster-Recovery-Präsenz in West US. Produktbilder und Protokolle werden im Objektspeicher gespeichert, während Bestellungen und Lagerbestand auf einer verwalteten relationalen Datenbank laufen. Bei regionalen Störungen benötigt das Unternehmen Lesezugriff auf Produktmedien aus der sekundären Region, um den Katalog durchsuchbar zu halten. Die Data Governance erfordert eine Verschlüsselung mit kundenseitig verwalteten Schlüsseln und eine zeitbasierte Aufbewahrung von Audit-Protokollen.
Herausforderung: Entwerfen Sie Speicher- und Datenbankdienste, die einen regionsübergreifenden Lesezugriff für Medien, einen automatisierten Lebenszyklus und eine automatisierte Aufbewahrung für Protokolle, eine starke Verschlüsselung und Zugriff nach dem Prinzip der geringsten Rechte (Least Privilege) sowie ein verwaltetes relationales Backend mit integrierter Hochverfügbarkeit und Disaster Recovery bieten.
Empfohlener Ansatz:
- Erstellen Sie ein universelles v2-Speicherkonto in East US mit RA-GRS (oder RA-GZRS, falls auch Zonenresilienz erforderlich ist) für die Container der Produktmedien.
- Aktivieren Sie „Nur HTTPS“, konfigurieren Sie einen privaten Endpunkt zum VNet und integrieren Sie kundenseitig verwaltete Schlüssel aus Azure Key Vault für das Speicherkonto.
- Definieren Sie Lebenszyklusrichtlinien: Verschieben Sie Medien, auf die 30 Tage lang nicht zugegriffen wurde, nach „Cool“ und nach 180 Tagen nach „Archive“; löschen Sie archivierte Medien nach 5 Jahren.
- Verwenden Sie für schreibgeschützte Anwendungsprotokolle (Append-Only) einen Append-Blob-Container mit unveränderlichen (zeitbasierten) Aufbewahrungsrichtlinien und einer separaten Lebenszyklusregel, um ältere Protokolle nach „Archive“ zu überführen.
- Gewähren Sie Anwendungszugriff über Azure RBAC (Storage Blob Data Contributor) für verwaltete Identitäten; stellen Sie kurzlebige User-Delegation-SAS für Partner-Uploads in einen Staging-Container aus.
- Stellen Sie Azure SQL Database (Business Critical oder General Purpose mit Zonenredundanz) für Bestellungen und Lagerbestand bereit; konfigurieren Sie Auto-Failover-Gruppen für die Replikation nach West US.
- Validieren Sie automatische Backups (PITR 7–35 Tage) und aktivieren Sie bei Bedarf die Langzeitaufbewahrung für Compliance-Datenbanken.
- Implementieren Sie Transparent Data Encryption (standardmäßig aktiviert) und bringen Sie bei Bedarf Ihren eigenen Schlüssel (Bring Your Own Key) für die SQL-Server-Ressource mit.
- Aktualisieren Sie die E-Commerce-App, sodass sie bei einer Beeinträchtigung der primären Region Produktmedien über den sekundären RA-Endpunkt liest; setzen Sie transaktionale Schreibvorgänge auf die primäre SQL-Datenbank bis zum Failover fort.
- Führen Sie Failover-Übungen sowohl für den Speicher (Konto-Failover) als auch für SQL (Auto-Failover-Gruppe) durch und dokumentieren Sie RTO/RPO im Abgleich mit den Geschäftszielen.
Azure-Begründung: RA-GRS bietet drei synchrone Replikate in der primären Region sowie eine asynchrone Replikation in die gekoppelte Region und stellt einen schreibgeschützten sekundären Endpunkt bereit. Dies erfüllt die Anforderung, bei einer regionalen Störung Lesezugriffe für den Katalog zu ermöglichen. Lebenszyklusrichtlinien gleichen die Speicherkosten an die Zugriffsmuster an, indem sie selten aufgerufene Medien nach „Cool“ und „Archive“ verschieben (Tiering) und eine zeitbasierte Aufbewahrung für Protokolle mit Unveränderlichkeit erzwingen. Kundenseitig verwaltete Schlüssel und private Endpunkte stärken die Sicherheit und Compliance, während Azure RBAC und User-Delegation-SAS das Prinzip der geringsten Rechte (Least Privilege) und eine sichere Delegierung durchsetzen. Azure SQL Database bietet integrierte Hochverfügbarkeit (HA), TDE und automatisierte Backups; Auto-Failover-Gruppen ermöglichen ein kontrolliertes, getestetes regionsübergreifendes Failover für transaktionale Workloads, um die Servicekontinuität aufrechtzuerhalten.
← Netzwerk · Alle Domänen · Identität →
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →