Microsoft AZ-305: Datenspeicherung und Datenbanklösungen — Lernleitfaden

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

Nicht-relationale und global verteilte Speicher

Azure Cosmos DB ist eine vollständig verwaltete, multimodale, global verteilte Datenbank mit schlüsselfertiger globaler Replikation und Lese- und Schreibvorgängen im einstelligen Millisekundenbereich im 99. Perzentil. Wählen Sie die API basierend auf der Passung zum Ökosystem und dem Datenmodell: Core (SQL) API für Dokumente und SQL-ähnliche Abfragen mit umfassender SDK-Unterstützung; MongoDB API für Kompatibilität mit dem Mongo-Wire-Protokoll; Cassandra API für Wide-Column-Workloads; Gremlin API für Graph-Traversierung; und Table API für Schlüssel/Attribut-Szenarien. Der Durchsatz wird in Anforderungseinheiten (Request Units, RUs) im festen oder automatischen Skalierungsmodus bereitgestellt; entwerfen Sie Partitionen und Indizierung so, dass der RU-Verbrauch minimiert wird.

Partitionierung ist fundamental. Wählen Sie einen Partitionsschlüssel mit hoher Kardinalität, der Speicher und Datenverkehr gleichmäßig verteilt, „heiße“ Partitionen (Hot Partitions) vermeidet und auf Ihre Zugriffsmuster abgestimmt ist (z. B. tenantId oder userId für mandantenfähige Schreibvorgänge oder ein synthetischer zusammengesetzter Schlüssel zum Ausgleich von Lesevorgängen). Logische Partitionen sind in Größe und Durchsatz begrenzt; modellieren Sie so, dass „heiße“ Arbeitsdatensätze (Hot Working Sets) verteilt bleiben. Sie können den Partitionsschlüssel eines Containers nach der Erstellung nicht mehr ändern; Migrationen erfordern neue Container und eine Datenverschiebung.

Die Konsistenz von Cosmos umfasst fünf einstellbare Stufen: Strong (linearisierbar, höchste RU/Latenz), Bounded Staleness (vorhersehbare Verzögerung oder Versionsfenster), Session (clientzentriertes „Reads-Your-Writes“, beliebter Standard), Consistent Prefix (keine Lesevorgänge außerhalb der Reihenfolge) und Eventual (maximale Verfügbarkeit und Leistung mit potenziellen Anomalien). Wählen Sie Standardeinstellungen pro Konto und überschreiben Sie diese bei Bedarf pro Anforderung. Schreibvorgänge in mehreren Regionen ermöglichen echtes Multi-Master für globale Schreibvorgänge mit geringer Latenz und höhere Verfügbarkeit; behandeln Sie die Konfliktlösung über Last-Writer-Wins (auf einer festgelegten Eigenschaft), benutzerdefinierte Richtlinien oder Anwendungslogik mit gespeicherten Prozeduren und dem Konfliktfeed.

Bei der Auswahl des richtigen Datenspeichers sollten Sie die Anforderungen mit den Fähigkeiten abgleichen. Strenge relationale Integrität, komplexe Joins und Transaktionsgarantien sprechen für Azure SQL Database oder Managed Instance. Massive globale Skalierung, flexibles Schema und Geo-Zugriff mit geringer Latenz sprechen für Cosmos DB. Graph-Probleme (soziale Netzwerke, Empfehlungen, Netzwerktopologie) passen zur Cosmos DB Gremlin API oder zu den Graph-Funktionen in Azure SQL, wenn eine relationale Kollokation vorteilhaft ist. Zeitreihen-Telemetrie mit hohem Erfassungsaufkommen, Ad-hoc-Exploration und Analysen in nahezu Echtzeit passen zu Azure Data Explorer. Unstrukturierte Blobs, Medien und große binäre Payloads gehören in Azure Blob Storage oder ADLS Gen2, wobei die Metadaten in einer komplementären Datenbank gespeichert werden.

Objekt- und Analysespeicher

Azure Blob Storage ist die Grundlage für unstrukturierte Daten. Zugriffsebenen (Access Tiers) stimmen die Speicherkosten auf die Zugriffsmuster ab: Hot für häufigen Zugriff, Cool für seltenen Zugriff mit einer Mindestaufbewahrungsdauer von 30 Tagen und Archive für langfristige kalte Speicherung (Cold Storage) mit einer Mindestaufbewahrungsdauer von 180 Tagen und einer Rehydrierung, die Stunden dauern kann. Premium-Block-Blob-Konten auf SSDs ermöglichen Workloads mit geringer Latenz und hohem Transaktionsvolumen, wie z. B. Erfassungspipelines. Richtlinien zur Lebenszyklusverwaltung (Lifecycle Management) automatisieren Übergänge und Löschungen auf der Grundlage von Regeln – Zeitpunkt der letzten Änderung, Blob-Index-Tags oder Präfixe – und senken so die Kosten ohne manuellen Eingriff.

Die Objektreplikation für Block-Blobs spiegelt Objekte und ihre Versionen asynchron zwischen Speicherkonten (in derselben oder in verschiedenen Regionen). Sie erfordert die Blob-Versionierung auf Quell- und Zielkonto und wird richtliniengesteuert pro Container-Paar konfiguriert. Dies unterstützt Compliance und die Verteilung über mehrere Regionen, während die Unabhängigkeit von den Redundanzoptionen auf Kontoebene gewahrt bleibt. Unveränderlichkeit (WORM) ist auf Container- oder Blob-Ebene durch zeitbasierte Aufbewahrungsrichtlinien und rechtliche Aufbewahrungspflichten (Legal Holds) durchsetzbar, mit Optionen wie allowProtectedAppendWrites für reine Anfügeprotokolle (Append-only Logs). Unveränderlichkeit auf Versionsebene schützt frühere Zustände vor Manipulation und Ransomware.

Azure Data Lake Storage Gen2 fügt dem Blob Storage einen hierarchischen Namespace hinzu, der echte Verzeichnisse, atomare Umbenennungen und optimierte Dateioperationen ermöglicht. Feingranulare, POSIX-ähnliche ACLs steuern den Zugriff auf Verzeichnis- und Dateiebene, mit Zugriffs- und Standard-ACLs (Access und Default ACLs), und werden zusammen mit Azure RBAC ausgewertet. Authentifizieren Sie sich mit Azure AD und OAuth2 für geringste Rechtevergabe (Least Privilege) und Überprüfbarkeit. Die Analyse-Integration ist nativ: Azure Synapse Analytics und Azure Databricks greifen über den ABFS-Treiber mit skalierbarem Durchsatz auf ADLS Gen2 zu, während Dienste wie Azure Data Factory, Azure Purview und Azure Machine Learning für Orchestrierung, Governance und Modelltraining integriert sind. Entwerfen Sie Ordnerstrukturen und ACL-Vererbung, um Domänen zu isolieren und die Governance für mehrere Teams zu unterstützen, und nutzen Sie Funktionen wie den Änderungsfeed (Change Feed) und vorläufiges Löschen (Soft Delete) für Datenherkunft (Lineage) und Wiederherstellung.

Caching und Leistungsbeschleunigung

Azure Cache for Redis bietet Datenzugriff im Sub-Millisekunden-Bereich, Pub/Sub und verteilte Sperren (Distributed Locking). Die Tarife (Tiers) entsprechen den Anforderungen an Verfügbarkeit und Skalierung. Basic ist ein einzelner Knoten für Entwicklung/Test. Standard fügt einen Zwei-Knoten-Aufbau mit Primär-/Replikat-Knoten und automatischem Failover hinzu. Premium führt Clustering über Shards, Persistenz (RDB-Snapshots und AOF), VNet-Unterstützung und Geo-Replikation in einer Aktiv-Passiv-Topologie ein. Enterprise und Enterprise Flash (Redis Enterprise) fügen Aktiv-Aktiv-Geo-Replikation mithilfe von CRDTs für Schreibvorgänge in mehreren Regionen, größere Arbeitsspeicher, Multi-Threaded-Leistung und Modulunterstützung hinzu; Flash erweitert DRAM mit NVMe für riesige Caches zu geringeren Kosten.

Wählen Sie die Verdrängungsrichtlinie (Eviction Policy) passend zur Schlüssel-TTL und zum Workload: allkeys-lru/allkeys-random, wenn nicht alle Schlüssel TTLs haben; volatile-lru/volatile-ttl, wenn nur ablaufende Schlüssel verdrängt werden sollen; und noeviction, wenn Schreibfehler anstelle von Verdrängung akzeptabel sind. Persistenz reduziert Datenverluste bei einem Failover auf Kosten von I/O- und Latenz-Overhead; aktivieren Sie sie nur bei Bedarf und passen Sie die Snapshot-Intervalle an.

Integrieren Sie Redis als Cache-Aside für Datenbankabfrageergebnisse, Sitzungszustände und Zähler für Ratenbegrenzungen (Rate-Limit Counters). Stellen Sie eine idempotente Befüllung sicher, wenden Sie geeignete TTLs an und implementieren Sie Circuit Breaker. Sharden Sie bei geclusterten Caches die Schlüssel deterministisch; testen Sie bei Enterprise Aktiv-Aktiv die Semantik der Konfliktlösung.

Sicherheits-, Zugriffs- und Resilienzmuster

Die Zugriffsdelegierung in Azure Storage verwendet SAS-Token und -Richtlinien. Eine Service SAS gewährt bereichsbezogenen Zugriff auf eine bestimmte Ressource (Container, Blob, Dateifreigabe, Warteschlange oder Tabelle). Eine Account SAS erstreckt sich über mehrere Dienste im Konto und ist sehr mächtig; schützen Sie sie sorgfältig. Eine User Delegation SAS (nur für den Blob-Dienst) wird von Azure AD und einem Benutzerdelegierungsschlüssel abgeleitet und ermöglicht eine benutzerspezifische Zugriffskontrolle ohne Kontoschlüssel – ideal für mandantenfähige Anwendungen und kurzlebige Berechtigungen. Gespeicherte Zugriffsrichtlinien (auf Containern, Freigaben, Warteschlangen und Tabellen) binden SAS-Token an eine serverseitige Richtlinie, sodass Sie den Zugriff widerrufen oder verkürzen können, ohne die Kontoschlüssel rotieren zu müssen; eine SAS ohne gespeicherte Zugriffsrichtlinie kann nur durch das Ablaufen des Tokens oder die Rotation der Schlüssel widerrufen werden.

Für die Verschlüsselung verwendet Azure Storage standardmäßig die serverseitige Verschlüsselung. Kundenseitig verwaltete Schlüssel (CMK), die in Azure Key Vault oder Managed HSM gespeichert sind, bieten eine zentralisierte Kontrolle über den Lebenszyklus der Schlüssel und Auditierbarkeit. Verschlüsselungsbereiche (Encryption Scopes) ermöglichen die Verwendung unterschiedlicher CMKs innerhalb desselben Speicherkontos nach Container oder Präfix und unterstützen so eine mandantenbasierte Schlüsselverwaltung. Für die clientseitige Kontrolle pro Blob können kundenseitig bereitgestellte Schlüssel (CPK) bei Anfragen mitgeliefert werden. Kombinieren Sie CMK auf Konto- oder Bereichsebene je nach Bedarf mit CPK, um regulatorische Anforderungen an die Isolation zu erfüllen.

Die Sicherheit und Resilienz von Azure SQL bauen auf den bereits beschriebenen Plattform-Tiers und Replikationsfunktionen auf. Verwenden Sie Auto-Failover-Gruppen für koordinierte regionsübergreifende Failover und gebundene Listener-Endpunkte und aktivieren Sie Zonenredundanz, wo verfügbar, um zonale Ausfälle zu überstehen. Wenden Sie bei sensiblen Daten dynamische Datenmaskierung (Dynamic Data Masking) an, um personenbezogene Daten (PII) in Abfrageergebnissen für nicht privilegierte Benutzer zu verschleiern, und ziehen Sie Always Encrypted mit Secure Enclaves für den clientseitigen Schutz von Spalten in Betracht, wenn Administratoren daran gehindert werden müssen, Klartextdaten einzusehen. Überwachen Sie die RPO/RTO-Ziele im Abgleich mit dem Replikationsverhalten Ihres Tiers und testen Sie Failover routinemäßig.

Vereinheitlichen Sie bei der Planung von End-to-End-Architekturen die Identität (Azure AD für SQL, Storage und Analytics), wenden Sie das Prinzip der geringsten Rechte mit RBAC und ACLs an, verwenden Sie Private Link oder VNet-Integration, um Daten vom öffentlichen Internet fernzuhalten, und implementieren Sie Lebenszyklus-, Unveränderlichkeits- und Replikationsrichtlinien, um die Aufbewahrungs- und DR-Ziele zu erreichen.

Praktisches Problemszenario

Contoso Retail startet eine globale E-Commerce-Plattform mit volatilem Traffic während des Tages, strengen Kontrollen für personenbezogene Daten (PII), Produktmedien im Petabyte-Bereich und Personalisierung nahezu in Echtzeit. Sie benötigen weltweit Lesevorgänge mit geringer Latenz, minimale Ausfallzeiten und eine geregelte Datenanalyse.

Platzieren Sie die transaktionalen Katalog- und Bestelldatenbanken auf Azure SQL Database unter Verwendung des vCore-Modells:

Auswahl des Tiers: Business Critical für Bestellungen (Speicher mit geringer Latenz und schnelles Failover) und General Purpose Serverless für den Katalog (Traffic-Spitzen mit Leerlaufphasen).
Warum: vCore bietet eine vorhersagbare Dimensionierung und den Hybridvorteil; Business Critical erfüllt die Latenz-/HA-Anforderungen für Bestellungen; Serverless minimiert die Computekosten bei geringer Aktivität.

Konfigurieren Sie eine Auto-Failover-Gruppe über Regionspaare für beide Datenbanken und aktivieren Sie die Zonenredundanz:

Warum: Ein einheitlicher Lese-/Schreib-Listener vereinfacht das Anwendungsfailover; Zonenredundanz schützt vor zonalen Ausfällen; regionsübergreifende Replikate erfüllen die DR-Anforderungen und bieten Leseskalierung für das Reporting.

Speichern Sie Produktbilder und -videos in Azure Blob Storage (universell v2) mit Lebenszyklusverwaltung und Objektreplikation:

Richtlinie: Hot für aktive Elemente, Cool nach 30 Tagen, Archive nach 180 Tagen; Replikation in eine sekundäre Region mittels Objektreplikation.
Warum: Minimiert die Speicherkosten im Zeitverlauf und bietet gleichzeitig eine asynchrone regionale Verteilung unabhängig von der Kontoredundanz; erfüllt die Aufbewahrungsanforderungen mit Unveränderlichkeit für rechtlich relevante Assets (zeitbasiertes WORM).

Erstellen Sie den Kundenprofil- und Warenkorb-Dienst auf Azure Cosmos DB (Core API) mit Schreibvorgängen in mehreren Regionen und Sitzungskonsistenz (Session Consistency):

Design: Partitionierung nach userId, um Schreibvorgänge zu verteilen; automatische Skalierung von RUs aktivieren.
Warum: Multi-Master bietet Schreibvorgänge mit geringer Latenz für ein globales Publikum und hohe Verfügbarkeit; Sitzungskonsistenz gewährleistet Read-Your-Writes pro Benutzer mit starken UX-Garantien und effizienter RU-Nutzung.

Führen Sie Azure Cache for Redis Enterprise für den Sitzungszustand, das Caching von Produktdetails und die Ratenbegrenzung ein:

Modus: Clustering mit Active-Active-Geo-Replikation für Schreibvorgänge in mehreren Regionen.
Warum: Zugriff im Sub-Millisekundenbereich und CRDT-basierte Konfliktlösung halten Sitzungen und Zähler über Regionen hinweg konsistent, ohne einen einzelnen Schreib-Master zu benötigen.

Speichern Sie Clickstream- und Betriebsprotokolle in Azure Data Lake Storage Gen2 mit hierarchischen Namespaces und POSIX-ACLs:

Integration: Die Stream-Erfassung schreibt in kuratierte Ordner; Databricks und Synapse lesen über ABFS; Aktivieren Sie den Änderungsfeed (Change Feed) und das vorläufige Löschen (Soft Delete).
Warum: Feingranulare Verzeichnis-/Datei-ACLs unterstützen die Governance für mehrere Teams; der hierarchische Namespace optimiert Dateioperationen; die native Analytics-Integration verkürzt die Time-to-Insight.

Verwenden Sie Azure Database for PostgreSQL Flexible Server für den Empfehlungs-Microservice:

HA: Zonenredundantes synchrones Standby; Bereitstellung von Lesereplikaten für Experimente mit neuen Features.
Warum: Das umfangreiche Ökosystem an Postgres-Erweiterungen und die JSONB-Fähigkeiten passen zum Dienst; die verwaltete Hochverfügbarkeit (HA) hält die RTO niedrig; Replikate entlasten Lesevorgänge.

Sichern Sie den Zugriff mit User Delegation SAS für den temporären Medien-Upload und CMK mit Verschlüsselungsbereichen pro Mandant:

Warum: Eliminiert die Offenlegung von Kontoschlüsseln und ermöglicht eine mandantenbasierte kryptografische Isolierung und Auditierbarkeit.

Migrieren Sie Altdaten zu Bestellungen von einem lokalen SQL Server zu Azure SQL Managed Instance für die Archivverarbeitung und Agent-gesteuerte Aufgaben:

Schritte: Bewertung mit dem Data Migration Assistant; Durchführung der Online-Migration über DMS; Verbindung über ExpressRoute.
Warum: MI erhält SQL Agent-Aufträge und datenbankübergreifende Operationen bei, was die Modernisierung erleichtert und gleichzeitig Archiv-Workloads nahe an den Cloud-Daten hält.

Dieses Design erfüllt die globalen Leistungsanforderungen durch die Multi-Region-Schreibvorgänge von Cosmos DB und Redis Enterprise, setzt Governance mit ADLS Gen2 ACLs und der Unveränderlichkeit von Storage durch, liefert transaktionale Integrität und schnelles Failover mit Azure SQL Tiers und Auto-Failover-Gruppen und optimiert die Kosten durch Serverless-Compute und Lebenszyklusrichtlinien.

← Identität · Alle Domänen · Compute- und Anwendungsarchitektur →

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