Microsoft AZ-900: Opslag & Databases — Studiegids
Onderdeel van de Microsoft Azure AZ-900 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.
Azure biedt een brede basis voor het opslaan van ongestructureerde en gestructureerde data op wereldwijde schaal, met geïntegreerde duurzaamheid, beveiliging en kostenbeheersing. Het begrijpen van de juiste opslagprimitieve, redundantie-model, access tier en databaseservice maakt betrouwbare, performante applicaties mogelijk, van virtuele machines tot wereldwijd gedistribueerde web- en mobiele platforms.
Azure Storage-services en managed disks
Azure Blob Storage is de hoeksteen voor ongestructureerde data. Block blobs verwerken grote objecten met efficiënte streaming en parallelle uploads, snapshots, versioning en tiering. Page blobs zijn geoptimaliseerd voor willekeurige lees/schrijf-I/O in pagina’s van 512 bytes en vormen de basis voor virtuele harde schijven; ze bevinden zich onder schijven en scenario’s die consistente low-latency IOPS vereisen. Append blobs zijn toegespitst op schrijfintensieve ‘append’-scenario’s zoals applicatielogs, waarbij nieuwe blokken efficiënt aan het einde worden toegevoegd. Azure Files biedt volledig beheerde file shares die toegankelijk zijn via SMB of NFS met NTFS ACL’s, directory-integratieopties en Azure File Sync om ‘hot data’ te cachen op Windows Servers. Queue Storage levert lichtgewicht, duurzame applicatie-messaging om componenten te ontkoppelen met ‘at-least-once delivery’-semantiek. Table Storage levert een schemaloze key/attribute store voor omvangrijke, gepartitioneerde datasets waarbij u de partitie- en rij-sleutels beheert voor schaalbaarheid en kostenefficiëntie. Managed disks bieden duurzame, persistente block storage voor Azure Virtual Machines zonder dat u storage accounts of page blobs direct hoeft te beheren. Kies uit Standard HDD voor op kosten geoptimaliseerde doorvoer-workloads, Standard SSD voor gebalanceerde prestaties, Premium SSD en Premium SSD v2 voor low-latency hoge IOPS, en Ultra Disk voor de meest veeleisende transactionele workloads met configureerbare IOPS en doorvoer. Managed disks ondersteunen snapshots, incrementele back-ups, schijfversleuteling en beschikbaarheidsopties die zijn afgestemd op uw VM-SLA’s.
- Blob – Block blob
- Datamodel of IO-patroon: Groot object, sequentiële IO
- Belangrijkste mogelijkheden: Tiering, snapshots, versioning, lifecycle-beleid
- Typische use cases: Afbeeldingen, video, back-ups, big data landing zones
- Opmerkelijke limieten/notities: Eén blob tot ~190 TiB; niet geoptimaliseerd voor willekeurige IO
- Blob – Page blob
- Datamodel of IO-patroon: Willekeurige IO in pagina’s van 512 bytes
- Belangrijkste mogelijkheden: Low-latency lees/schrijf-operaties, VHD-ondersteuning
- Typische use cases: Onderliggende opslag voor schijven en scenario’s die willekeurige toegang vereisen
- Opmerkelijke limieten/notities: Page blob-grootte tot 8 TiB; managed disks abstraheren dit
- Blob – Append blob
- Datamodel of IO-patroon: Alleen-toevoegen (append-only) schrijfacties
- Belangrijkste mogelijkheden: Efficiënte log-toevoegingen, onveranderlijkheidsopties
- Typische use cases: Telemetrie en applicatielogs
- Opmerkelijke limieten/notities: ‘Update in place’ niet ondersteund; limieten voor het aantal blokken zijn van toepassing
- Azure Files
- Datamodel of IO-patroon: POSIX/SMB/NFS-bestandssemantiek
- Belangrijkste mogelijkheden: SMB/NFS-toegang, NTFS ACL’s, AD DS/Azure AD DS-integratie, File Sync
- Typische use cases: Lift-and-shift file shares, app-configuratie, home-directories voor gebruikers
- Opmerkelijke limieten/notities: Standard en Premium tiers; ’large file shares’ tot 100 TiB
- Queue Storage
- Datamodel of IO-patroon: Berichtenwachtrij (message queue)
- Belangrijkste mogelijkheden: ‘At-least-once delivery’, ‘visibility timeouts’, verwerking van ‘poison messages’
- Typische use cases: Achtergrondverwerking, ontkoppelde microservices
- Opmerkelijke limieten/notities: Berichtgrootte tot 64 KB (gebruik Service Bus voor grotere/geavanceerde patronen)
- Table Storage
- Datamodel of IO-patroon: Key/attribute NoSQL
- Belangrijkste mogelijkheden: Enorme schaalbaarheid, partitionering op PartitionKey, lage kosten
- Typische use cases: Telemetrie, catalogi, gebruikersprofielen
- Opmerkelijke limieten/notities: Geen joins of secundaire indexen; Cosmos DB Table API voor wereldwijde behoeften
- Managed disks
- Datamodel of IO-patroon: Block storage voor VM’s
- Belangrijkste mogelijkheden: Standard/Premium/Ultra SKU’s, snapshots, schalen, schijfversleuteling
- Typische use cases: OS/data-schijven voor VM’s, DB’s, line-of-business apps
- Opmerkelijke limieten/notities: Tot 32 TiB per schijf; ZRS beschikbaar voor geselecteerde SKU’s
Redundantie- en duurzaamheidsopties
Redundantiemodellen bepalen waar en hoeveel synchrone en asynchrone replica’s Azure van uw gegevens onderhoudt. Locally redundant storage (LRS) bewaart drie kopieën binnen één datacenter in één regio, en biedt tegen de laagste kosten bescherming tegen schijf- en rackstoringen. Zone-redundant storage (ZRS) verspreidt drie synchrone kopieën over afzonderlijke availability zones in een regio, wat veerkracht biedt tegen een zonale storing zonder dat een failover van de applicatie nodig is. Geo-redundant storage (GRS) breidt LRS uit door uw gegevens asynchroon te repliceren naar de gekoppelde regio, wat resulteert in zes kopieën in totaal over twee regio’s; nadat Microsoft een account-failover initieert, wordt de secundaire de nieuwe primaire. Read-access geo-redundant storage (RA-GRS) voegt een live, alleen-lezen secundair eindpunt toe, zodat applicaties zelfs vóór een failover vanuit de secundaire regio kunnen lezen, wat wereldwijde leesdistributie en het offloaden van analyses mogelijk maakt. Geo-zone-redundant storage (GZRS) combineert ZRS in de primaire regio met asynchrone replicatie naar LRS in de gekoppelde regio, en biedt bescherming tegen zowel zonale als regionale storingen; een read-access variant (RA-GZRS) biedt leeseindpunten op de secundaire. De keuze wordt bepaald door hersteldoelstellingen, latency-verwachtingen en budget. Binnen een regio beschermt ZRS tegen zone-storingen terwijl de schrijflatency laag blijft. Over regio’s heen hebben GRS/RA-GRS en GZRS de voorkeur voor disaster recovery en scenario’s met cross-regionale leesbewerkingen. De dataconsistentie met de secundaire regio is bij de geo-opties per definitie asynchroon, dus applicaties moeten ’eventual consistency’ kunnen verdragen totdat een failover is voltooid.
- LRS
- Replicatie-indeling: 3 kopieën in één datacenter (regio)
- Leestoegang tot secundaire: Nee
- Regionale/zonale tolerantie: Beschermt tegen lokale hardware-/rackstoringen
- Typische workloads: Dev/test, goedkope opslag, niet-kritieke data
- ZRS
- Replicatie-indeling: 3 kopieën synchroon over 3 availability zones (regio)
- Leestoegang tot secundaire: Nee
- Regionale/zonale tolerantie: Overleeft zonale storingen zonder failover op applicatieniveau
- Typische workloads: Productie web/app-content die hoge regionale beschikbaarheid vereist
- GRS
- Replicatie-indeling: LRS in primaire + asynchrone LRS in gekoppelde regio (totaal ~6 kopieën)
- Leestoegang tot secundaire: Nee
- Regionale/zonale tolerantie: Regionale DR via account-failover; geen zonale bescherming in primaire
- Typische workloads: Back-up/archivering met een regionale DR-strategie
- RA-GRS
- Replicatie-indeling: GRS + leeseindpunt op secundaire regio
- Leestoegang tot secundaire: Ja
- Regionale/zonale tolerantie: Gelijk aan GRS; maakt wereldwijde leesdistributie mogelijk
- Typische workloads: Wereldwijde leesbewerkingen van content, analyses/rapportage via de secundaire
- GZRS
- Replicatie-indeling: ZRS in primaire + asynchrone LRS in gekoppelde regio
- Leestoegang tot secundaire: Nee (gebruik RA-GZRS)
- Regionale/zonale tolerantie: Beschermt tegen zonale storingen en regionale rampen
- Typische workloads: Missiekritieke apps die zowel zonale als geo-veerkracht vereisen
Toegangslagen en lifecycle management
Blob-toegangslagen stemmen de opslagkosten af op toegangspatronen. De Hot-laag is geoptimaliseerd voor frequente toegang met de laagste transactiekosten voor lezen en schrijven, tegen een hogere opslagprijs per GB. De Cool-laag verlaagt de opslagprijs per GB en verhoogt de transactie- en ’early deletion’-kosten, waardoor deze geschikt is voor datasets die niet vaak worden benaderd, zoals maandelijkse rapporten of kortetermijnback-ups. De Archive-laag biedt de laagste opslagkosten maar vereist ‘rehydration’ vóór toegang, met de hoogste toegangs- en ’early deletion’-kosten; deze is ontworpen voor langetermijnbewaring en compliancescenario’s. Lifecycle management-beleidsregels automatiseren de overgang tussen lagen (tiering) en retentie op container- of accountniveau. Regels kunnen blobs verplaatsen tussen Hot, Cool en Archive op basis van de laatste wijzigingstijd, laatste toegangstijd of blob-indextags; en versies, snapshots of basis-blobs verwijderen na een bepaalde leeftijd. Beleidsregels helpen de totale eigendomskosten (TCO) te verlagen door koude data uit Hot-opslag te verplaatsen en verouderde data zonder handmatige tussenkomst te verwijderen. Lifecycle management is beschikbaar voor general-purpose v2 en Blob storage-accounts en werkt op block- en append-blobs; het is niet van toepassing op premium block blob storage. Archive rehydration ondersteunt standaard- en hoge-prioriteitsopties, waarbij kosten worden ingeruild voor snelheid. Houd rekening met ophaaltijden van uren voor standaard rehydration en minuten tot uren voor hoge prioriteit bij kleinere objecten. Voor compliance, combineer Archive met onveranderbaarheidsbeleid (tijdgebaseerde retentie of ’legal hold’) om WORM-garanties (write-once, read-many) af te dwingen op container- of blobniveau.
- Hot
- Opslagkosten: Hoogst
- Toegangs-/transactiekosten: Laagst
- Minimale retentie: Geen
- Ophaallatency: Milliseconden (online)
- Typische data: Actieve content, frequent gelezen/geschreven data
- Cool
- Opslagkosten: Lager dan Hot
- Toegangs-/transactiekosten: Hoger dan Hot; ’early deletion fee’ van toepassing
- Minimale retentie: 30 dagen
- Ophaallatency: Milliseconden (online)
- Typische data: Niet-frequent benaderde data, kortetermijnback-ups
- Archive
- Opslagkosten: Laagst
- Toegangs-/transactiekosten: Hoogst; ’early deletion fee’ van toepassing
- Minimale retentie: 180 dagen
- Ophaallatency: Uren (‘rehydration’ vereist)
- Typische data: Langetermijnbewaring, compliance-archieven, zelden benaderde back-ups
Beveiliging, versleuteling en toegangsbeheer
Versleuteling ‘at rest’ is standaard ingeschakeld via Storage Service Encryption (SSE). Standaard beveiligen door Microsoft beheerde sleutels de data op een transparante manier. Voor striktere controle en scheiding van taken kunnen door de klant beheerde sleutels (CMK) per opslagaccount worden geconfigureerd met sleutels in Azure Key Vault of een Managed HSM, wat workflows voor sleutelrotatie en -intrekking ondersteunt. Voor gevoelige workloads verminderen dubbele versleuteling en ‘confidential computing’-opties de risico’s op blootstelling van data verder. Voor data ‘in transit’ dwingt u HTTPS met TLS af voor alle ‘data-plane’-operaties. Toegangsbeheer omvat op identiteit gebaseerde autorisatie en tokens met een beperkte scope. Azure RBAC integreert met Microsoft Entra ID om ’least-privilege’ toegang tot het ‘data-plane’ te verlenen, zoals de rollen Storage Blob Data Reader/Contributor, aan gebruikers, groepen en beheerde identiteiten. RBAC elimineert gedeelde geheimen en ondersteunt voorwaardelijke toegang (conditional access), Privileged Identity Management en auditing. Shared Access Signatures (SAS) delegeren in tijd beperkte, op permissies gebaseerde toegang aan clients die mogelijk geen identiteit hebben; een SAS kan worden ondertekend met accountsleutels of met gebruikersdelegatie via Microsoft Entra-credentials om te voorkomen dat accountsleutels worden blootgesteld. Combineer RBAC voor service-naar-service en administratieve toegang met SAS voor tijdelijke client-toegangsflows. Bescherm accountsleutels en roteer ze regelmatig; geef waar mogelijk de voorkeur aan SAS met gebruikersdelegatie. Netwerkisolatie met Private Endpoints of service-eindpunten, firewallregels en beleid voor onveranderbare opslag (immutable storage) completeren een ‘defense-in-depth’-strategie voor opslagaccounts.
- Azure RBAC (Microsoft Entra ID)
- Scope: Op identiteit gebaseerde rollen op het ‘data plane’ en ‘management plane’ van de opslag
- Beste voor: Beheerders, services en apps met beheerde identiteiten
- Belangrijkste eigenschappen: ‘Least privilege’, voorwaardelijke toegang (conditional access), auditeerbaarheid, geen gedeelde geheimen
- Risico-overwegingen: Vereist identiteitsintegratie; intrekken via rolwijzigingen
- Shared Access Signature (SAS)
- Scope: In tijd beperkte, op permissies gebaseerde tokens voor specifieke resources
- Beste voor: Delegeren van beperkte toegang aan clients/partners
- Belangrijkste eigenschappen: Granulaire permissies, IP-/tijdsbeperkingen; SAS met gebruikersdelegatie vermijdt accountsleutels
- Risico-overwegingen: Lekkage van een token geeft toegang tot de vervaldatum; bescherm de distributie en stel korte levensduren in
Relationele PaaS en wereldwijd gedistribueerde NoSQL
Azure SQL Database levert een beheerde relationele engine met automatische patching, ingebouwde hoge beschikbaarheid (high availability), back-ups en schaalbaarheid. Implementeer enkele databases of ’elastic pools’ om variabele workloads te consolideren. De service onderhoudt meerdere replica’s binnen een regio en ondersteunt zoneredundantie; Transparent Data Encryption (TDE) is standaard ingeschakeld. Geautomatiseerde back-ups maken ‘point-in-time restore’ mogelijk, doorgaans voor 7–35 dagen, met optionele langetermijnbewaring (long-term retention) tot jaren in Azure-opslag. Voor veerkracht over meerdere regio’s en ’low-latency reads’ gebruikt u actieve geo-replicatie (tot vier leesbare secondaries) of Auto‑failover groups voor gecoördineerde DR op schaal. Azure SQL Managed Instance biedt bijna 100% compatibiliteit met de SQL Server-engine voor features op instantieniveau zoals SQL Agent, cross-database queries, Service Broker en CLR, wat een eenvoudige modernisering van on-premises omgevingen mogelijk maakt zonder refactoring. Het deelt dezelfde beheerde HA-architectuur, online patching, geautomatiseerde back-ups, TDE standaard ingeschakeld, en ondersteunt auto‑failover groups tussen regio’s. Netwerkisolatie met private endpoints en schaalbaarheid van compute/opslag per database of per instantie zorgen voor voorspelbare prestatie-enveloppen. Azure Cosmos DB biedt een volledig beheerde, multi-model NoSQL-database met kant-en-klare wereldwijde distributie en ‘multi-region writes’. Het garandeert latenties van enkele milliseconden op het 99e percentiel binnen een regio en biedt vijf afstembare consistentieniveaus om prestaties en correctheid over regio’s heen in evenwicht te brengen. Provisioneer doorvoer in RU/s of gebruik ‘autoscale’, voeg regio’s toe of verwijder ze zonder downtime, en configureer automatische failover. API’s omvatten Core (SQL), MongoDB, Cassandra, Gremlin en Table, wat migratie en integratie met diverse applicatiestacks vereenvoudigt.
- Azure SQL Database
- Model: Relationele PaaS (enkele DB/elastic pool)
- Compatibiliteit: Nieuwste SQL-features; compatibiliteit op app-niveau
- HA/DR: Ingebouwde replica’s, zoneredundantie; actieve geo-replicatie; Auto‑failover groups
- Back-ups/TDE: Automatische PITR 7–35 dagen; LTR tot jaren; TDE standaard ingeschakeld
- Geo-opties: Leesbare secondaries over regio’s; gecoördineerde failover-groepen
- Meest geschikt voor: SaaS/multi-tenant apps, nieuwe cloud-native relationele workloads
- Azure SQL Managed Instance
- Model: Relationele PaaS (instantie)
- Compatibiliteit: Hoge pariteit met SQL Server-features, incl. SQL Agent, cross-DB
- HA/DR: Ingebouwde HA; zoneredundantie; Auto‑failover groups
- Back-ups/TDE: Automatische PITR 7–35 dagen; LTR; TDE standaard ingeschakeld; ondersteuning voor native restore
- Geo-opties: Multi-regio met failover-groepen en leesbare secondaries
- Meest geschikt voor: ‘Lift-and-shift’ van on-prem SQL met minimale wijzigingen
- Azure Cosmos DB
- Model: NoSQL, multi‑model (Core, MongoDB, Cassandra, Gremlin, Table)
- Compatibiliteit: Compatibiliteit op API-niveau voor populaire NoSQL-stacks
- HA/DR: Multi-regio, multi-master writes; 99,99% SLA’s
- Back-ups/TDE: Geautomatiseerde en continue back-upopties; versleuteling ‘at rest’
- Geo-opties: Live regio’s toevoegen/verwijderen; afstembare consistentie; automatische failover
- Meest geschikt voor: Wereldwijde apps met lage latentie, IoT, catalogi, personalisatie
← Netwerken · Alle domeinen · Identiteit →
Oefen deze vragen → · Getimede oefening op 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.
Slaag voor je examen →