Microsoft AZ-104: Azure Databases en Dataservices — Studiegids

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

Onderdeel van de Microsoft Azure Administrator Associate AZ-104 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

De database- en dataservices van Azure omvatten beheerde relationele engines, wereldwijd gedistribueerde NoSQL, in-memory caching, grootschalige analytics en integratie/orkestratie. Als beheerder moet u inzicht hebben in aankoopmodellen, servicelagen (service tiers), netwerk- en beveiligingstopologie, de semantiek van back-up/DR, en hoe u services kunt combineren voor prestaties, kosten en veerkracht. Dit gedeelte richt zich op de operationele keuzes en platformfuncties die u dagelijks configureert: provisioningmodellen (DTU vs vCore), elastic pools, back-up en langetermijnbewaring, geo-replicatie en failover, in VNet geïntegreerde managed instances, Cosmos DB-distributie en -consistentie, open-source relationele HA/read replica’s, Synapse-engines en Data Factory-runtimes.

Azure Relational Databases (SQL Database, Managed Instance, MySQL/PostgreSQL)

Azure SQL Database biedt twee aankoopmodellen. Het DTU-model bundelt CPU, geheugen en IOPS in Database Transaction Units met Basic-, Standard- en Premium-lagen; het is eenvoudig maar ondoorzichtig, en geschikt voor stabiele, voorspelbare workloads en traditionele ‘sizing’. Het vCore-model maakt de CPU-generatie/-aantal en het geheugen zichtbaar, gekoppeld aan opslag- en IOPS-controles. vCore maakt transparantie in ‘sizing’, Azure Hybrid Benefit en kortingen voor Reserved Capacity mogelijk. Binnen vCore komen de servicelagen overeen met workload- en beschikbaarheidspatronen: General Purpose gebruikt externe Premium SSD of Azure Premium-opslag met een standaard beschikbaarheidsarchitectuur; Business Critical plaatst compute en opslag op lokale SSD met meerdere replica’s, lage latentie en geïntegreerde ‘read scale-out’; Hyperscale ontkoppelt compute en opslag met ‘page servers’ voor vrijwel onmiddellijke schaalbaarheid en zeer grote databases. Voor ‘single databases’ schaalt de serverless compute-laag (vCore) de CPU elastisch en kan deze automatisch pauzeren om kosten bij inactiviteit te besparen.

Elastic pools delen compute-resources tussen meerdere databases om piekbelastingen (‘bursty workloads’) die niet gelijktijdig optreden op te vangen tegen lagere totale kosten. Pools zijn beschikbaar in DTU- (eDTU) en vCore-varianten. U stelt per database min/max-limieten in om ’noisy neighbors’ in toom te houden en een maximum voor de pool om de uitgaven te beheersen. Overboeking (‘oversubscription’) is acceptabel wanneer pieken kort en niet-gecorreleerd zijn. De ‘sizing’ van de pool hangt af van het opgetelde gemiddelde verbruik plus extra ruimte (‘headroom’) voor gelijktijdigheid; het monitoren van statistieken per database en van de pool is cruciaal om SLO’s te handhaven.

Back-ups worden automatisch gemaakt. Azure SQL onderhoudt volledige, differentiële en transactielog-back-ups met ‘point-in-time restore’ (PITR) tot op de seconde nauwkeurig binnen de bewaarperiode (doorgaans 7–35 dagen, afhankelijk van de laag en opslagconfiguratie). Langetermijnbewaring (Long-term retention, LTR) bewaart wekelijkse volledige back-ups jarenlang in RA-GRS-opslag; u kunt een LTR-back-up herstellen als een nieuwe database op elke server binnen dezelfde subscription en regio-set, en ‘cross-region restore’ is beschikbaar als geo-redundante back-upopslag is ingeschakeld. Herstelacties maken een nieuwe database aan; ze overschrijven niet de bestaande database.

Opties voor geo-replicatie omvatten actieve geo-replicatie voor ‘single databases’ en pools (tot vier leesbare ‘secondaries’ met asynchrone replicatie) en ‘auto-failover groups’ op het niveau van de logische server. Failover groups bundelen meerdere databases (of een volledige server) met geo-DR, een read-write listener-endpoint, een read-only endpoint voor het ‘offloaden’ van leesbewerkingen, op status gebaseerde automatische failover en op DNS gebaseerde omleiding. Business Critical biedt ook ‘read scale-out’ via een lokale leesbare replica, wat onmiddellijke ‘offload’ van lees-workloads mogelijk maakt zonder de complexiteit van cross-region-verkeer.

Azure SQL Managed Instance (MI) levert bijna 100% compatibiliteit met de SQL Server-engine, inclusief SQL Agent, cross-database queries, CLR, linked servers, Service Broker en native back-up/herstel van .bak-bestanden vanuit Azure Blob Storage. MI wordt in een VNet geïnjecteerd: u implementeert het in een toegewezen, gedelegeerd subnet met privé-IP’s en NSG/UDR-controles; plan de subnetgrootte en adresruimte vooraf, omdat het later aanpassen van subnets complex is. Migratiepaden omvatten de Azure Database Migration Service (online/offline ‘cutovers’), native back-up/herstel naar URL in MI, en transactionele replicatie van on-premises SQL Server naar MI. Kies voor MI wanneer u pariteit van de ‘surface area’ of op de instance gerichte functies nodig hebt die ‘single databases’ niet bieden.

Azure Database for MySQL en Azure Database for PostgreSQL (Flexible Server) bieden beheerde OSS-engines met controle over onderhoudsvensters, stop/start voor kostenbesparingen, ‘burstable’ en ‘general-purpose’ compute, automatische groei van opslag (‘auto-grow’) en VNet-integratie. Flexible Server biedt hoge beschikbaarheid (high availability) met synchrone replicatie; u kunt kiezen voor zone-redundante HA verspreid over Availability Zones voor sterkere foutisolatie, of ‘same-zone’ HA voor een lagere schrijflatentie. Read replica’s zijn beschikbaar voor ‘scale-out’ van leesbewerkingen en kunnen binnen of tussen regio’s worden geprovisioneerd; ze gebruiken asynchrone replicatie en zijn ideaal voor analytics, rapportage of microservices met veel leesbewerkingen. Promoveer een replica voor failover of regionale uitbreiding wanneer dat nodig is, en houd daarbij rekening met mogelijke replicatievertraging (’lag’).

Gedistribueerde Data en Caching (Cosmos DB en Azure Cache for Redis)

Azure Cosmos DB is een wereldwijd gedistribueerde, multi-model database die API’s biedt voor Core (SQL), MongoDB, Cassandra, Gremlin (graph) en Table. De keuze van de API bepaalt de compatibiliteit van de client driver en de semantiek van het datamodel; operationeel beheer je de doorvoer (ingerichte RU’s of autoscale) en partities, ongeacht de API. Data wordt horizontaal gepartitioneerd door een partitiesleutel die een hoge cardinaliteit en een gelijkmatige toegangsverdeling moet hebben om ‘hot partitions’ te vermijden; vermijd monotoon oplopende sleutels en overweeg hiërarchische partitiesleutels waar samengestelde toegangspatronen bestaan. Queries over meerdere partities (cross-partition queries) worden ondersteund, maar verbruiken meer RU’s; plaats gerelateerde data waar mogelijk samen op basis van de partitiesleutel.

Consistentieniveaus zijn instelbaar per account, database of request: Strong garandeert lineariseerbaarheid; Bounded Staleness beperkt de veroudering (staleness) op basis van tijd of versie; Session (standaard) biedt ‘read-your-writes’ voor een sessie; Consistent Prefix garandeert de volgorde zonder volledige consistentie; Eventual maximaliseert de beschikbaarheid en prestaties. Kies voor multi-region writes een passend beleid voor conflictoplossing (LastWriterWins of aangepast via stored procedures) en definieer failover-prioriteiten. Met globale distributie voeg je regio’s toe met een klik; de service regelt replicatie, failover en voor latency geoptimaliseerde routing met SLA’s op doorvoer, latency, beschikbaarheid en consistentie.

Azure Cache for Redis biedt een latency van minder dan een milliseconde, ondersteund door Redis. De Tiers bieden oplopende functionaliteit: Basic (enkele node, dev/test), Standard (gerepliceerde twee-node primary/replica met SLA), Premium (grotere formaten, clustering, persistentie, VNet-injectie, geo-replicatie en Redis-modules zoals Bloom), Enterprise en Enterprise Flash (gebaseerd op Redis Enterprise met geavanceerde clustering, actieve geo-replicatie voor multi-primary writes en grotere caches ondersteund door Flash). Eviction policies bepalen het gedrag onder geheugendruk: noeviction (fouten bij schrijven), allkeys-lru/lfu/random (houdt rekening met alle sleutels), en volatile-lru/lfu/ttl/random (houdt alleen rekening met sleutels met een TTL). Gebruik voor sessie-caching de Premium-tier of hoger voor persistentie als je geen sessieverlies kunt veroorloven, schakel TTL’s voor sleutels in om de groei te beperken, en overweeg clustering voor doorvoer en schaalbaarheid. Plaats de cache in dezelfde regio en hetzelfde virtuele netwerk als de app-servers om de latency te minimaliseren; gebruik Managed Identity of toegangssleutels en dwing netwerkisolatie af via Private Link of VNet-injectie.

Analytics en Integratie (Synapse Analytics en Data Factory)

Azure Synapse Analytics verenigt data warehousing, big data en data-integratie. De dedicated SQL pool (voorheen SQL DW) is een MPP-engine met hash/round-robin-distributies, gerepliceerde tabellen en result-set caching. Je schaalt compute op of neer om te voldoen aan SLA-vensters en kunt deze pauzeren om alleen voor opslag te betalen. Workload-isolatie kan worden bereikt met workload groups en importance-instellingen om kritieke queries te beschermen. De serverless SQL pool biedt on-demand T-SQL over data in Azure Data Lake Storage Gen2 zonder provisioning; je betaalt per gescande TB en kunt schema’s externaliseren met behulp van views voor semantische lagen. Spark pools brengen Apache Spark naar Synapse met autoscale en on-demand clusters, wat notebooks, Delta Lake en machine learning mogelijk maakt met geïntegreerde beveiliging en data lineage; je kunt lakehouse-data delen tussen Spark- en SQL-engines.

Azure Data Factory (ADF) orkestreert dataverplaatsing en -transformatie. Pipelines coördineren activiteiten zoals Copy, Data Flow (op Spark gebaseerde mapping flows) en externe compute (Databricks, Synapse, Functions). Datasets definiëren de vorm en locatie van data, terwijl linked services de verbindingsdetails (authenticatie, endpoints) naar bronnen/doelen inkapselen. Integration runtimes (IR’s) bieden het compute- en netwerkvlak: Azure IR voor cloud-native verplaatsing en transformatie, Self-hosted IR voor on-premises of private netwerkbronnen via uitgaand HTTPS, en Azure-SSIS IR voor de lift-and-shift van SSIS-pakketten. Triggers (schedule, tumbling window, event-based) maken herhaalbare orkestratie mogelijk; een managed virtual network en private endpoints kunnen worden ingeschakeld voor bescherming tegen data-exfiltratie en conforme connectiviteit. Parametrisering en Key Vault-integratie ondersteunen herbruikbare, veilige patronen voor de promotie tussen omgevingen (dev/test/prod).

Bedrijfscontinuïteit, Geo-functies en Elastic Pools

Back-up- en herstelstrategieën verschillen per service, maar hebben belangrijke thema’s gemeen: automatiseer, test hersteloperaties regelmatig en maak onderscheid tussen PITR (operationele fouten) en LTR (compliance). Gebruik in Azure SQL PITR voor onbedoelde drops of slechte implementaties; sla wekelijkse volledige LTR-back-ups op in RA-GRS voor wettelijke retentie en voor herstel bij cross-region disaster recovery. Voor MySQL/PostgreSQL Flexible Server, schakel geautomatiseerde back-ups in met geo-redundante opslag waar ondersteund, stel retentie in volgens beleid en valideer point-in-time restores naar alternatieve servers. Cosmos DB-accounts met meerdere regio’s maken automatische failover mogelijk; combineer dit met multi-region writes wanneer de RPO nul moet zijn en de applicatie conflicten deterministisch kan oplossen.

Geo-replicatie en auto-failovergroepen in Azure SQL bieden DR en read offload. Gebruik actieve geo-replicatie voor een enkele database/pool wanneer u secondaries expliciet wilt beheren; gebruik auto-failovergroepen om veel databases te groeperen en DNS-gebaseerde listeners plus automatische failover te krijgen. Waar low-latency reads belangrijk zijn maar DR niet het doel is, gebruik dan Business Critical read scale-out of Hyperscale named replicas om analytics en rapportage van de primary af te houden. Monitor de replicatielag en de health-signalen voor failover, en voer failoveroefeningen uit om RTO/RPO te valideren.

Elastic pools zijn een hefboom voor kostenoptimalisatie voor multi-tenant SaaS en verzamelingen van kleine databases. In op DTU gebaseerde pools, wijs eDTU’s toe met limieten per database; in vCore-pools, wijs vCores, geheugen en IO-doorvoer toe met maximale vCores per database en IO-governance. Bepaal de juiste omvang door het 95e percentiel van het gebruik per database te meten en de poolcapaciteit af te stemmen op concurrency-patronen; verhoog de limieten per database voor tenants met hogere SLO’s en overweeg pools op te splitsen per workloadklasse (bijv. zware versus lichte tenants). Gebruik alerts op de limieten van de pool en per database om verzadiging vroegtijdig te detecteren. Wanneer een handvol databases consequent de maximale limieten bereiken, verplaats ze dan naar dedicated compute of een aparte pool om de voorspelbaarheid te behouden.

Praktijkscenario

Starbucks moet zijn wereldwijde loyaliteitsplatform moderniseren om piekverkeer tijdens promoties aan te kunnen, de operationele overhead te verminderen en analytics te ondersteunen zonder de wereldwijde winkeloperaties te verstoren.

Partitioneer de operationele datastore:

Kies Azure Cosmos DB (Core SQL API) voor klantinteracties en beloningsevents om wereldwijde distributie met lage latentie te bereiken. Configureer multi-region writes in regio’s dicht bij grote klantpopulaties en stel de consistentie in op Session om een balans te vinden tussen ‘read-your-writes’ en prestaties. Selecteer een partitiesleutel met hoge kardinaliteit, zoals customerId of een samengestelde hiërarchische sleutel (customerId, eventMonth), om de doorvoer te verdelen en veelvoorkomende querypatronen te ondersteunen.

Implementeer transactionele account- en catalogusdata:

Implementeer Azure SQL Managed Instance voor rekeningsaldi, inwisselingen en SKU/catalogus, omdat bijna 100% compatibiliteit met SQL Server nodig is voor bestaande stored procedures en cross-database logica. Plaats de MI in een dedicated, gedelegeerd subnet met NSG’s en route tables zoals vereist door VNet-injectie, wat private toegang mogelijk maakt vanaf app-subnets en ExpressRoute.

Zorg voor wereldwijde leesschaal en DR voor relationele workloads:

Gebruik voor nieuwe microservices die Azure SQL Database gebruiken de vCore Business Critical-laag voor lage latentie en read scale-out. Maak een auto-failovergroep naar een gekoppelde regio met read-only listener-eindpunten voor gelokaliseerde reads en automatische failover om aan de DR-doelstellingen te voldoen.

Voeg low-latency sessiebeheer toe:

Implementeer Azure Cache for Redis Premium met clustering en datapersistentie voor web- en mobiele sessietokens. Stel een allkeys-lfu eviction policy in om veelgebruikte sessies in het geheugen te houden. Integreer de cache binnen hetzelfde VNet en dezelfde regio als de app-laag om de latentie te minimaliseren.

Orkestreer dataverplaatsing en bouw analytics:

Gebruik Azure Data Factory om operationele data (Cosmos DB change feed en SQL MI) te kopiëren naar Azure Data Lake Storage Gen2. Gebruik een Managed VNet IR met private endpoints om data-exfiltratie te voorkomen. Parametriseer pipelines en gebruik tumbling window triggers om een geordende verwerking te garanderen.

Maak enterprise analytics mogelijk met elastische kostenbeheersing:

Gebruik in Azure Synapse Analytics een serverless SQL pool voor ad-hocverkenning van parquet-data en een dedicated SQL pool voor gecureerde BI-modellen met hoge concurrency en voorspelbare prestaties. Maak Spark-pools voor feature engineering op loyaliteitsgedrag en schrijf Delta-tabellen naar de lake voor interoperabiliteit tussen Spark en SQL.

Governance, back-ups en retentie:

Configureer de prioriteiten voor automatische failover van Cosmos DB en monitor conflicten met LastWriterWins en een timestamp-veld. Verifieer voor Azure SQL Database en MI de PITR-vensters en schakel LTR in om te voldoen aan de retentievereisten voor compliance. Voor Flexible Server-instanties die ondersteunende OSS-services draaien (bijv. regionale winkeltelmetrie in PostgreSQL), schakel zone-redundante HA in en configureer read replicas voor rapportage.

Waarom deze services: De wereldwijde distributie en afstelbare consistentie van Cosmos DB zijn geschikt voor wereldwijde, latency-gevoelige interacties; MI behoudt complexe SQL Server-functies en biedt tegelijkertijd beheerde operaties; Business Critical-databases leveren lokale leesschaal zonder cross-region latentie; Redis garandeert sub-milliseconde toegang tot sessies tijdens verkeerspieken; ADF zorgt voor veilige, beheerste dataverplaatsing vanuit private netwerken; Synapse combineert on-demand en geprovisioneerde analytics voor kosteneffectieve, schaalbare inzichten. Deze samenstelling voldoet aan de prestatie-SLO’s tijdens promoties, vermindert de administratieve last door beheerde PaaS en dwingt duidelijke RTO/RPO- en compliance-grenzen af.

← Azure App Service en PaaS Compute · Alle domeinen · Azure Monitor →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →