Microsoft AZ-900: Azure Architectuur & Wereldwijde Infrastructuur — Studiegids

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

De wereldwijde architectuur van Azure is ontworpen om veerkrachtige, performante en conforme cloudservices op schaal te leveren. Een goed begrip van de fysieke indeling van geographies, regions en availability zones, samen met de logische hiërarchie van management groups, subscriptions, resource groups en resources, vormt de basis voor een betrouwbaar ontwerp en governance. Het control plane dat wordt geleverd door Azure Resource Manager, in combinatie met declaratieve templates, maakt consistente, herhaalbare implementaties mogelijk die in lijn zijn met het organisatiebeleid en de beveiligingseisen. Ontwerpbeslissingen in dit domein hebben een directe invloed op beschikbaarheidsdoelstellingen, verplichtingen rondom dataresidentie en de wereldwijde gebruikerservaring. Het selecteren van het juiste redundantie-model, het berekenen van samengestelde SLA’s en het kiezen van wereldwijde routeringsdiensten zoals Azure Front Door, Traffic Manager en Azure CDN zijn essentieel voor het behalen van doelstellingen op het gebied van bedrijfscontinuïteit, compliance en prestaties.

Geographies, Regions, Availability Zones en Region Pairs

Azure geographies zijn gedefinieerde sets van regions die de grenzen voor dataresidentie en compliance waarborgen. Voorbeelden zijn United States, Europe, United Kingdom, Australia en Canada, evenals soevereine clouds met afzonderlijke compliance- en connectiviteitsmodellen. Workloads die binnen een bepaalde jurisdictie moeten blijven, moeten worden geïmplementeerd in regions die tot de doel-geography behoren om te voldoen aan regelgeving en dataresidentie. Een region is een set datacenters die binnen een door latency gedefinieerde perimeter zijn geïmplementeerd en verbonden zijn via een toegewijd netwerk met lage latency. Niet alle services of functies zijn in elke region beschikbaar, dus de capaciteit en de beschikbaarheid van functies moeten vroeg in de planningsfase worden gevalideerd. Regions die Availability Zones ondersteunen, bieden drie of meer fysiek gescheiden datacenterzones met onafhankelijke stroomvoorziening, koeling en netwerken. Zone-redundant services (ZRS) en het ontwerpen van architecturen over zones heen bieden bescherming tegen storingen op datacenterniveau, terwijl de toegang met lage latency binnen de region behouden blijft. Elke Azure-region is gekoppeld aan een andere region binnen dezelfde geography om een region pair te vormen (bijvoorbeeld North Europe met West Europe, East US met West US). Region pairs maken herstel met prioriteit mogelijk tijdens grootschalige storingen, gefaseerde platformupdates en datareplicatie voor bepaalde services. De geo-redundante opties van Azure Storage (GRS/GZRS) repliceren data asynchroon naar de gekoppelde region; wanneer leestoegang tot de secundaire region vereist is, gebruik dan RA-GRS of RA-GZRS om leesbewerkingen vanaf het secundaire eindpunt toe te staan tijdens een storing of een geplande failover. Voor bedrijfskritische workloads die zowel hoge beschikbaarheid binnen de region als disaster recovery tussen regions vereisen, combineer je zone-redundantie met replicatie via region pairs. Het balanceren van latency, veerkracht en compliance leidt tot een veelvoorkomend patroon: implementeer actieve workloads over zones in een primaire region en bescherm tegen regionale rampen door data te repliceren en failover-paden naar de gekoppelde region te voorzien. Valideer regelmatig failover-draaiboeken en het gedrag van DNS of front-end routering om ervoor te zorgen dat de hersteldoelstellingen worden gehaald.

• Geography
  • Scope: Grens over meerdere regions
  • Belangrijkste voordeel: Dataresidentie en compliance
  • Typisch gebruik: Naleving van regelgeving (bijv. EU-data)
• Region
  • Scope: Eén metropoolgebied
  • Belangrijkste voordeel: Toegang tot services met lage latency
  • Typisch gebruik: Primaire implementatielocatie
• Availability Zone
  • Scope: Afzonderlijke datacenters binnen een region
  • Belangrijkste voordeel: Foutisolatie op datacenterniveau
  • Typisch gebruik: Hoge beschikbaarheid binnen de region
• Region Pair
  • Scope: Twee regions in dezelfde geography
  • Belangrijkste voordeel: Gecoördineerd herstel en updates
  • Typisch gebruik: Disaster recovery tussen regions

Organisatie en beheer van resources: Management Groups, Subscriptions, Resource Groups en Resources

De beheerhiërarchie van Azure maakt beleid, toegangs- en kostenbeheer op schaal mogelijk. Management groups bevinden zich boven subscriptions en stellen u in staat om Azure Policy en op rollen gebaseerd toegangsbeheer (RBAC) centraal toe te passen, waarbij overerving doorwerkt naar onderliggende management groups en subscriptions. Dit is de juiste constructie voor segmentatie op basis van bedrijfsdivisies, omgevingsniveaus (productie, niet-productie) of regelgevende grenzen, terwijl uniforme ‘guardrails’ (kaders) worden gehandhaafd. Subscriptions vormen de grens voor administratie, facturering en quota. Ze zijn zeer geschikt voor het isoleren van kosten en toegang voor bedrijfsonderdelen, omgevingen of applicaties. Gebruik een consistent subscription-ontwerp om productie van niet-productie te scheiden en om limieten en budgetten af te dwingen. Voor organisaties met meerdere divisies en gedecentraliseerd beheer, wijs aan elke divisie een of meer subscriptions toe en plaats deze onder divisie-specifieke management groups voor een duidelijke overerving van beleid en RBAC. Resource groups zijn logische containers voor resources die een gezamenlijke levenscyclus hebben. Ze maken atomische deployments, consistente tagging en levenscyclusoperaties zoals verwijderen of vergrendelen mogelijk. Groepeer resources die samen worden geïmplementeerd, bijgewerkt en buiten gebruik gesteld, zoals een web-tier en de bijbehorende monitoringcomponenten. Gebruik tags om ‘chargeback/showback’ (kostenverrekening), eigendom, omgeving en compliance-attributen voor resources en groepen te beheren. Locks (ReadOnly, CanNotDelete) bieden bescherming tegen onbedoeld verwijderen op het niveau van een resource of groep. Resources zijn de geïmplementeerde service-instanties (VM’s, App Service plans, storage accounts). RBAC-scopes (management group, subscription, resource group, resource) maken het mogelijk om ’least-privileged access’ (minimale bevoegdheden) precies daar toe te kennen waar het nodig is. Voor implementaties over meerdere divisies heen, behoud één enkele Microsoft Entra ID-tenant, tenzij er een sterke compliance- of autonomie-eis is voor meerdere tenants; subscriptions en management groups bieden doorgaans voldoende scheiding met aanzienlijk minder administratieve overhead.

• Management Group
  • Primaire doel: Organisatiebrede governance
  • Toegepaste controles: RBAC, Policy, Blueprints (via Policy + templates)
  • Veelvoorkomende patronen: Segmentatie per divisie/regelgeving
• Subscription
  • Primaire doel: Grens voor facturering en quota
  • Toegepaste controles: Budgetten, RBAC, Policy
  • Veelvoorkomende patronen: Isolatie per BU of per omgeving
• Resource Group
  • Primaire doel: Levenscyclusgrens
  • Toegepaste controles: Locks, Tags, RBAC
  • Veelvoorkomende patronen: Per applicatie of workload-eenheid
• Resource
  • Primaire doel: Service-instantie
  • Toegepaste controles: RBAC op instantieniveau, Tags
  • Veelvoorkomende patronen: Individuele servicecomponenten

Azure Resource Manager en Templates

Azure Resource Manager (ARM) is het ‘control plane’ voor het implementeren, bijwerken en verwijderen van Azure-resources via een consistente API en een op rollen gebaseerd model. ARM biedt idempotente operaties, afhankelijkheidsbeheer, tagging en beleidshandhaving op het moment van implementatie, waardoor platform-governance in elke wijziging kan worden verankerd. Declaratieve ARM-templates beschrijven de gewenste staat van uw omgeving in JSON en ondersteunen parameters, variabelen, condities en modulaire ’linked templates’. Ze maken herhaalbare, versie-gecontroleerde implementaties mogelijk over verschillende omgevingen en subscriptions heen. Voor een gestroomlijnde ontwikkelervaring biedt Bicep een beknopte syntaxis die wordt ‘getranspiled’ naar ARM-templates, terwijl dezelfde deployment-engine en voordelen behouden blijven. Sla templates op in source control, verpak ze als ’template specs’ om te delen, en integreer ze in CI/CD-pipelines om ‘drift-free’ (afwijkingsvrije), auditeerbare infrastructuurwijzigingen te garanderen. Gevoelige waarden zoals beheerderswachtwoorden of connection strings mogen nooit in templates worden opgenomen. Gebruik secureString/secureObject-parameters met Key Vault-referenties zodat ARM secrets ophaalt tijdens de implementatie zonder ze bloot te stellen in logs. Combineer templates met ‘managed identities’ om hardgecodeerde credentials in automatisering te elimineren. Deze aanpak vermindert het risico terwijl volledige automatisering voor grootschalige implementaties over meerdere subscriptions behouden blijft.

• Idempotente deployments
  • ARM/Template-ondersteuning: Ja
  • Resultaat: Veilige, herhaalbare wijzigingen
• Beleidshandhaving bij deployment
  • ARM/Template-ondersteuning: Ja
  • Resultaat: ‘Guardrails’ (kaders) ingebakken in pipelines
• Modulaire compositie
  • ARM/Template-ondersteuning: Linked modules / Bicep modules
  • Resultaat: Herbruikbaarheid en standaardisatie
• Omgaan met secrets
  • ARM/Template-ondersteuning: Key Vault-referenties
  • Resultaat: Geen secrets in code of logs

Beschikbaarheid, SLA’s, Samengestelde SLA’s en de Levenscyclus van Services

Azure publiceert financieel ondersteunde service-level agreements (SLA’s) voor algemeen beschikbare (GA) services. Voor virtuele machines hangt de beschikbaarheid af van de implementatietopologie: een enkele VM met Premium SSD-opslag heeft een SLA van 99,9%; twee of meer VM’s in een availability set hebben een SLA van 99,95%; en twee of meer VM’s die over availability zones zijn geïmplementeerd, bereiken een SLA van 99,99%. Platformservices (bijvoorbeeld Azure SQL Database of App Service) hebben hun eigen SLA’s, die kunnen variëren per laag of redundantieoptie. Lijn de architectuur uit op de beoogde SLA door het juiste redundantiemodel en de juiste servicelagen te selecteren. Wanneer een oplossing afhankelijk is van meerdere services, is de samengestelde SLA het product van de individuele SLA’s als alle componenten nodig zijn om de app te laten functioneren. Als bijvoorbeeld een web-app (99,95%) afhankelijk is van een database (99,99%), is de samengestelde beschikbaarheid ongeveer 0,9995 × 0,9999 = 99,94%. Het verhogen van de redundantie op elke laag—zoals implementeren over zones, het toevoegen van meerdere instanties achter een load balancer, of het gebruik van geo-redundante datastores—verbetert de effectieve beschikbaarheid. Omgekeerd verlaagt het toevoegen van seriële afhankelijkheden de samengestelde SLA en moet dit worden gerechtvaardigd door duidelijke functionele waarde. De status in de levenscyclus van een service beïnvloedt de betrouwbaarheidsgaranties. Public preview-functies worden aangeboden om feedback te verzamelen en kunnen beperkt zijn tot bepaalde regio’s of functionele hiaten hebben; ze hebben doorgaans geen SLA en worden niet aanbevolen voor productiekritieke paden. GA-functies (general availability) zijn productieklaar en worden gedekt door een SLA. Roadmaps en uitrolschema’s per regio moeten worden gevolgd om onbedoelde afhankelijkheid van preview-functies in productieontwerpen te voorkomen, vooral in compliance-gevoelige omgevingen. Doelstellingen voor noodherstel (disaster recovery), zoals RPO en RTO, vullen SLA’s aan en sturen ontwerpkeuzes zoals replicatie tussen zones of regio’s, back-upfrequentie en failover-orkestratie. Valideer failover-procedures regelmatig om ervoor te zorgen dat de gemeten herstelprestaties overeenkomen met de bedrijfsdoelstellingen en dat DNS, certificaten en identiteitsafhankelijkheden ook zoals verwacht herstellen.

• Enkele VM (Premium SSD)
  • Indicatieve SLA: 99,9%
  • Opmerkingen: Gebruik voor niet-kritieke workloads of tolerante apps
• 2+ VM’s in Availability Set
  • Indicatieve SLA: 99,95%
  • Opmerkingen: Beschermt tegen storingen op rack-/fault domain-niveau
• 2+ VM’s over Availability Zones
  • Indicatieve SLA: 99,99%
  • Opmerkingen: Beschermt tegen storingen op datacenterniveau
• Public Preview-functie
  • Indicatieve SLA: Geen financiële SLA
  • Opmerkingen: Evalueer; vermijd op kritieke paden
• GA-functie (afhankelijk van servicelaag)
  • Indicatieve SLA: Ondersteund door SLA
  • Opmerkingen: Controleer SLA’s die specifiek zijn voor de laag en regio

Wereldwijde Routering en Contentlevering: Azure Front Door, Traffic Manager en Azure CDN

De wereldwijde gebruikerservaring hangt af van intelligente routering, de nabijheid van content en snelle failover. Azure Front Door is een wereldwijde, anycast Layer 7 reverse proxy met Web Application Firewall (WAF), TLS-beëindiging, URL/pad-gebaseerde routering, sessieaffiniteit en health probes vanaf de edge. Het versnelt dynamische content via split-TCP en protocoloptimalisaties en biedt een vrijwel onmiddellijke failover tussen origins. Front Door is ideaal voor actief-actieve of actief-passieve webapplicaties en API’s in meerdere regio’s waar zowel prestaties als gecentraliseerde beveiliging aan de edge vereist zijn. Azure Traffic Manager is een DNS-gebaseerde service voor verkeersdistributie die clients naar het beste eindpunt leidt met behulp van beleidsregels zoals prioriteit, gewogen, prestatie (latentie), geografisch, subnet of multivalue. Omdat het op DNS-niveau werkt, ondersteunt het niet-HTTP-eindpunten (bijv. TCP-services) en hybride scenario’s, maar de failover-snelheid wordt beperkt door de DNS TTL en caching door de client. Traffic Manager fungeert niet als proxy voor verkeer en versnelt geen content; het beantwoordt simpelweg DNS-verzoeken met het gekozen eindpunt. Azure CDN cachet statische content op edge points of presence om de latentie te verminderen en de origins te ontlasten. Het is zeer geschikt voor grote statische assets zoals afbeeldingen, video’s, scripts en downloads. Hoewel CDN round trips voor cachebare content vermindert, is het geen statusbewuste wereldwijde load balancer voor dynamische origins; combineer het met Front Door of Traffic Manager voor failover tussen meerdere origins of voor dynamische routeringslogica. Veel architecturen plaatsen CDN voor het cachen van statische assets en Front Door voor dynamisch verkeer en beveiliging vóór dezelfde applicatie.

• Azure Front Door (Std/Prm)
  • Laag/Mechanisme: Layer 7 anycast proxy
  • Primaire Gebruiksscenario’s: Wereldwijde load balancing, edge-beveiliging, versnelling
  • Routeringsmethoden: Prioriteit, gewogen; pad/host-gebaseerde regels
  • Health Probing: Edge POP-probes
  • Failover-snelheid: Seconden (vrijwel onmiddellijk)
  • Dynamische Versnelling: Ja
  • Statische Caching: Ja (op basis van regels)
  • WAF Beschikbaar: Ja (geïntegreerd)
  • Typisch Patroon: Front Door vóór web-apps/API’s in meerdere regio’s
• Azure Traffic Manager
  • Laag/Mechanisme: DNS-gebaseerd beleid
  • Primaire Gebruiksscenario’s: DNS-routering tussen regio’s; niet-HTTP-eindpunten
  • Routeringsmethoden: Prioriteit, gewogen, prestatie, geografisch, subnet, multivalue
  • Health Probing: Wereldwijde eindpunt-probes
  • Failover-snelheid: TTL-gebonden (tientallen seconden tot minuten)
  • Dynamische Versnelling: Nee
  • Statische Caching: Nee
  • WAF Beschikbaar: N.v.t.
  • Typisch Patroon: DNS-sturing voor HTTP- en niet-HTTP-services
• Azure CDN
  • Laag/Mechanisme: Edge caching-netwerk
  • Primaire Gebruiksscenario’s: Ontlasten van statische content en latentiereductie
  • Routeringsmethoden: N.v.t. (cache-regels)
  • Health Probing: N.v.t. (optionele failover van origin-groep)
  • Failover-snelheid: N.v.t. (cache-gebaseerd)
  • Dynamische Versnelling: Nee (buiten de cache)
  • Statische Caching: Ja
  • WAF Beschikbaar: Via Front Door Premium of een aparte WAF
  • Typisch Patroon: CDN voor assets + Front Door/Traffic Manager voor origins

Praktijkprobleem: Het ontwerpen van een hoog beschikbaar, compliant en wereldwijd performant webplatform voor IronPeak Manufacturing

Scenario: IronPeak Manufacturing is actief in Europa en Noord-Amerika en consolideert klant- en partnerportals op Azure. Het platform moet 99,99% beschikbaarheid voor de weblaag bereiken, EU-klantgegevens binnen de EU houden, snelle failover tussen regio’s bieden en wereldwijd snelle laadtijden van pagina’s leveren. Het team wil volledig geautomatiseerde implementaties zonder platte tekstgeheimen in code of logs.

Uitdaging: Het realiseren van hoge beschikbaarheid binnen de regio en disaster recovery tussen regio’s met dataresidentie in de EU, wereldwijde acceleratie en failover voor dynamisch verkeer, en herhaalbare, veilige implementaties over verschillende subscriptions.

Aanbevolen aanpak:

1. Selecteer de Europe-geografie en implementeer de primaire workload in een regio met Availability Zones (bijvoorbeeld West Europe) met behulp van twee of meer VM scale set-instances of App Service-instances die over de zones zijn verdeeld.
2. Activeer cross-region disaster recovery naar de gekoppelde regio (North Europe) met behulp van de native replicatie van de services: gebruik RA-GZRS voor Storage en geo-replicatie voor databases waar beschikbaar; configureer geautomatiseerde failover-runbooks.
3. Plaats Azure Front Door Standard/Premium voor de applicatie voor wereldwijde HTTPS-terminatie, WAF, edge health probes, op prioriteit gebaseerde failover tussen West Europe (primair) en North Europe (secundair), en regels voor path-based routing.
4. Cache statische assets (afbeeldingen, scripts, downloads) met Azure CDN, geïntegreerd met dezelfde origins, om de latentie te verminderen en verkeer te ontlasten; valideer cache-regels en TTL’s.
5. Definieer management groups voor de EU- en NA-divisies; plaats productie- en niet-productie-subscriptions onder elke groep en pas Azure Policy toe voor dataresidentie, tagging en toegestane locaties.
6. Implementeer ARM/Bicep-templates die zijn opgeslagen in source control en gepubliceerd als template specs; parametriseer regio’s, SKU’s en schaalvergroting; refereer aan geheimen uit Azure Key Vault met behulp van managed identities voor implementaties.
7. Stel SLA’s in en test de samengestelde beschikbaarheid: twee over zones verdeelde instances achter Front Door streven naar 99,99% voor de app-laag; valideer elk kwartaal end-to-end failover-oefeningen, DNS, certificaten en afhankelijkheden van identiteiten.
8. Instrumenteer het platform met Application Insights en Azure Monitor; configureer Front Door health probes en alarmering; stem het autoscale- en caching-beleid af op basis van telemetrie.

Azure Rationale: Dit ontwerp houdt EU-data binnen de Europe-geografie en biedt tegelijkertijd foutisolatie binnen de regio via Availability Zones en cross-region disaster recovery naar de gekoppelde regio. Azure Front Door levert wereldwijde acceleratie en health-aware failover voor dynamisch verkeer, terwijl Azure CDN statische content ontlast voor betere prestaties. ARM/Bicep-templates met Key Vault-referenties zorgen voor herhaalbare, veilige implementaties over verschillende subscriptions en regio’s. De gekozen topologieën sluiten aan bij de gepubliceerde SLA’s om het doel van 99,99% voor de weblaag te halen, en beleid op het niveau van de management group en subscription dwingt governance af met minimale operationele overhead.

← Cloudconcepten · Alle domeinen · Compute →

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

Blader door Microsoft →