Microsoft AZ-700 certificering: examenhandleiding en studieplan voor 2026

• Controleer eerst de officiële AZ-700 examendoelen.
• Plan acht tot tien weken rond hands-on Azure-netwerklabs.
• Besteed extra aandacht aan Private Link, routering, ExpressRoute en application delivery.
• Regel de Belgische examendetails voordat de laatste herhalingsweek begint.

De Microsoft AZ-700 certificering is het examen voor Microsoft Certified: Azure Network Engineer Associate en beoordeelt of een kandidaat Azure-netwerkoplossingen kan ontwerpen, implementeren, beveiligen, bewaken en troubleshooten. Voor Belgische kandidaten vraagt een goede voorbereiding meer dan het doornemen van theorie: het examen beloont begrip van ontwerpkeuzes, foutanalyse en de gevolgen van netwerkconfiguratie in realistische Azure-omgevingen.

Laatst bijgewerkt: januari 2026. Deze versie legt meer nadruk op Private Endpoints en DNS, application delivery-keuzes, ExpressRoute-ontwerp en praktische examendagvoorbereiding. Omdat Microsoft examendoelen, policies, prijzen en beschikbaarheid kan aanpassen, blijft de officiële Microsoft Learn-examenpagina de bron die vóór registratie gecontroleerd moet worden.

Wat AZ-700 werkelijk toetst

AZ-700 gaat over Azure-netwerken op associate-niveau, maar de vragen zijn vaak architecturaal van aard. Een kandidaat moet niet alleen weten waar een instelling staat in de portal, maar ook kunnen uitleggen waarom een ontwerp met VNet-peering, route tables, Azure Firewall, Private Link, VPN Gateway, ExpressRoute, Application Gateway of Azure Front Door in een bepaalde situatie past.

De officiële Microsoft-leerroute voor Designing and Implementing Microsoft Azure Networking Solutions is een logische basis, omdat die de servicegebieden volgt die Microsoft voor AZ-700 verwacht. Daarnaast helpt het om Azure-documentatie te lezen met een architectuurbril: welke afhankelijkheden zijn er, welke SKU of servicelaag wordt bedoeld, hoe verloopt naamresolutie, en welke signalen gebruikt een engineer om te bewijzen dat een netwerkpad werkt.

De domeinen in het examen zijn breed. Kernnetwerkinfrastructuur en connectiviteitsservices krijgen veel aandacht, net als application delivery en netwerkbeveiliging. Privétoegang tot Azure-services heeft een kleiner gewicht, maar veroorzaakt in labs en productie opvallend vaak problemen omdat DNS, routing en endpointconfiguratie samenkomen.

Voorkennis: wanneer AZ-700 haalbaar wordt

Een kandidaat hoeft geen carrier-netwerkspecialist te zijn, maar moet wel comfortabel zijn met IP-adressering, subnetting, routing, DNS, TLS, firewalls, load balancing en hybride connectiviteit. Azure-ervaring is belangrijker dan het kunnen reproduceren van definities. Wie nog moeite heeft met resource groups, VNets, NSG’s, role-based access control en Azure Monitor, zal tijdens AZ-700-studie veel tijd verliezen aan basisnavigatie.

In praktijk werkt AZ-700 het beste na enige ervaring met Azure-administratie of cloudinfrastructuur. Een sysadmin die al VNets, VPN’s of Azure Firewall heeft beheerd, kan meestal sneller schakelen dan iemand die alleen klassieke netwerkapparatuur kent. Omgekeerd heeft een traditionele netwerkengineer vaak voordeel bij routeanalyse en troubleshooting, maar moet die extra tijd voorzien voor Azure-specifieke concepten zoals Private DNS zones, service endpoints, managed identities rond monitoring en platform-SKU’s.

Belgische registratie en praktische examendetails

Kandidaten in België registreren zich via de officiële Microsoft Learn-examenpagina, waarna de boeking doorgaans via de examenleverancier wordt afgehandeld. Tijdens die flow wordt het land, de beschikbare taal, de examenvorm en de prijs in EUR getoond. De prijs kan wijzigen en btw-behandeling kan afhangen van de registratiecontext, dus het bedrag moet vlak vóór betaling worden gecontroleerd in plaats van uit een studiegids te worden overgenomen.

Online-proctored examens zijn handig voor kandidaten die thuis of op kantoor een rustige ruimte kunnen garanderen. Het vraagt wel voorbereiding: een stabiele internetverbinding, een werkende webcam, een schoon bureau, geen tweede scherm tenzij toegestaan in de check-in flow, en een identiteitsbewijs waarvan de naam overeenkomt met het Microsoft-profiel. Een testcenter is vaak eenvoudiger voor wie thuis geen afgesloten ruimte heeft of risico’s wil vermijden rond netwerkblokkades, bedrijfsapparaten of camera-permissies.

Taalkeuze verdient aandacht. Engels is voor Azure-netwerkterminologie vaak het meest eenduidig, zeker bij termen zoals private peering, route propagation, health probe, backend pool en WAF policy. Als een andere taal beschikbaar is, blijft het verstandig om Engelse productnamen en portalbegrippen te leren, omdat documentatie, foutmeldingen en praktijklabs meestal in het Engels verschijnen.

Een studieplan van acht tot tien weken

Een realistisch plan combineert lezen, bouwen, breken en herstellen. Alleen video’s bekijken of documentatie markeren geeft te weinig bewijs dat de kandidaat scenario’s kan oplossen. Het doel is elke week een ontwerpbeslissing te koppelen aan een werkende configuratie en vervolgens te controleren wat er gebeurt wanneer DNS, routes, probes of policies verkeerd staan.

De laatste twee weken zijn geen buffer om nieuwe onderwerpen voor het eerst te leren. Ze zijn bedoeld om scenariofouten uit te halen: waarom resolveert een storage account nog publiek, waarom werkt een health probe niet, waarom kiest verkeer de verkeerde route, of waarom verbreekt een UDR een pad dat eerder via peering werkte. Wie begeleide labs en structuur wil, kan een AZ-700 training bij Readynez gebruiken als aanvulling op de officiële leerroute, maar de kern blijft actief oefenen in een eigen Azure-omgeving.

Private Endpoints: de DNS-valkuil die veel studieplannen onderschatten

Private Endpoints lijken eenvoudig: een Azure-service krijgt een privé-IP-adres in een subnet en verkeer blijft binnen het privénetwerk. De moeilijkheid zit meestal in naamresolutie. Als de juiste private DNS zone niet aan de juiste VNets is gekoppeld, kan een client nog steeds naar een publiek endpoint resolveen of helemaal geen bruikbaar adres terugkrijgen.

In hub-spoke ontwerpen wordt deze fout snel subtiel. De private endpoint staat bijvoorbeeld in een spoke, de DNS-resolver of forwarder in de hub, en workloads in een andere spoke. Dan moet worden nagedacht over zone-linking, forwarding, split-horizon DNS en de correcte privatelink-recordset. Een UDR die alle verkeer naar een firewall stuurt, kan bovendien onverwachte effecten hebben als niet duidelijk is welke stromen naar de private endpoint NIC lopen en welke naar DNS-infrastructuur.

Gebruik dit soort lab niet als een portal-oefening, maar als een diagnose-oefening. Maak eerst de endpoint, controleer de A-record in de private DNS zone, valideer vanaf een VM in elke relevante spoke, en bekijk daarna wat er gebeurt als de zone-link ontbreekt. Dat leert meer dan een foutloze build, omdat AZ-700-scenario’s vaak toetsen welk onderdeel in de keten ontbreekt.

De volgende Azure CLI-opdracht past bij een lab waarin een private DNS zone voor Azure Storage al bestaat en een spoke-VNet expliciet aan die zone moet worden gekoppeld. Dit is nuttig wanneer een workload in een spoke een storage account via Private Link moet bereiken en naamresolutie nog niet naar het privé-adres wijst.

Example — Private DNS zone koppelen aan een spoke-VNet

az network private-dns link vnet create \
  --resource-group rg-network-prod \
  --zone-name privatelink.blob.core.windows.net \
  --name link-vnet-spoke-app-prod \
  --virtual-network vnet-spoke-app-prod \
  --registration-enabled false

Na deze wijziging moet een DNS-query vanuit het spoke-VNet naar de storage-accountnaam een privé-IP-adres teruggeven. Controleer niet alleen de record in Azure, maar ook de resolver die de VM gebruikt; bij aangepaste DNS-servers moet forwarding naar Azure of naar een centrale resolver correct zijn ingericht.

ExpressRoute, VPN-failover en asymmetrische routing

ExpressRoute-vragen draaien zelden alleen om het aanmaken van een circuit. Kandidaten moeten kunnen onderscheiden wanneer private peering nodig is voor privé-adressen in VNets, wanneer Microsoft peering relevant is voor Microsoft-diensten, en hoe route filters bepalen welke prefixes worden geadverteerd. Global Reach voegt daar een extra ontwerpkeuze aan toe wanneer on-premises locaties via het Microsoft-netwerk met elkaar moeten communiceren.

Een robuust ontwerp gebruikt vaak VPN als failoverpad naast ExpressRoute. Dat klinkt eenvoudig, maar de valkuil is asymmetrische routing: verkeer heen loopt via ExpressRoute, verkeer terug via VPN of een firewallpad, waardoor sessies kunnen breken. Het ontwerp moet daarom routevoorkeuren, BGP-advertenties, lokale firewallroutes en eventuele forced tunneling samen bekijken. In een lab is het nuttig om effective routes op VM-niveau te vergelijken vóór en na het toevoegen van een VPN-pad.

Microsoft beschrijft zelf hoe software en wereldwijde netwerkarchitectuur bijdragen aan betrouwbaarheid in Azure; de bredere context staat in deze Azure-blog over global network reliability. Voor AZ-700 is het belangrijk om zulke architectuurinformatie te vertalen naar concrete keuzes: welk pad is primair, welk pad is secundair, welke routes worden geadverteerd, en hoe wordt failover gemeten.

Application delivery: Front Door, Application Gateway of Traffic Manager

Application delivery is een examendomein waarin productnamen gemakkelijk door elkaar lopen. Azure Front Door Standard en Premium passen vooral bij globale HTTP- en HTTPS-toepassingen waar anycast, wereldwijde WAF, edge-routing en latency-gebaseerde toegang belangrijk zijn. Application Gateway v2 past beter wanneer layer 7-inspectie dicht bij de workload nodig is, bijvoorbeeld met end-to-end TLS, mTLS-scenario’s, URL-routing binnen een regio en integratie met private backends.

Traffic Manager werkt anders, omdat het DNS-gebaseerd is. Het stuurt clients naar endpoints op basis van DNS-antwoorden, waardoor het geschikt kan zijn voor eenvoudige failover of geografische distributie, maar niet voor request-level inspectie of WAF-functionaliteit. Die DNS-basis betekent ook dat TTL, clientresolvergedrag en caching invloed hebben op hoe snel failover zichtbaar wordt.

Latency hoort bij deze keuze. De Azure-documentatie over Azure network latency helpt om te begrijpen waarom afstand, routingpad en serviceplaatsing belangrijk blijven, zelfs wanneer platformdiensten veel complexiteit wegnemen. In examencases is de juiste vraag vaak niet welke dienst krachtiger is, maar waar inspectie, failoverbeslissing en sessie-affiniteit moeten plaatsvinden.

Monitoring en troubleshooting die examenkennis bruikbaar maken

AZ-700-kandidaten moeten monitoring niet behandelen als een apart hoofdstuk aan het einde. Het is de manier waarop een engineer bewijst dat een ontwerp werkt. Connection Monitor v2 is nuttig om end-to-end bereikbaarheid en latency over tijd te volgen. NSG Flow Logs v2 naar Log Analytics helpen bij patroononderzoek en historische analyse. Packet Capture is geschikt wanneer pakketten op een VM-niveau bekeken moeten worden. Test-IPFlow geeft snel antwoord op de vraag of NSG-regels een specifiek pad toestaan of blokkeren.

Een sterke troubleshooting-aanpak begint met de laag waar het signaal het meest precies is. Bij een vermoedelijke NSG-blokkade is Test-IPFlow sneller dan algemene metriek. Bij klachten over wisselende prestaties is Connection Monitor waardevoller. Bij onduidelijke applicatiefouten achter Application Gateway zijn backend health, probe-instellingen en TLS-configuratie betere eerste controles dan willekeurig regels aanpassen.

De volgende opdracht is geschikt wanneer een engineer wil controleren of een inkomende HTTPS-stroom naar een VM door NSG-regels wordt toegestaan. Gebruik dit vóór het aanpassen van regels, zodat de wijziging op bewijs is gebaseerd.

Example — NSG-beslissing controleren met Test-IPFlow

az network watcher test-ip-flow \
  --resource-group rg-network-prod \
  --vm appvm-prod-01 \
  --direction Inbound \
  --protocol TCP \
  --local 10.20.1.4 \
  --local-port 443 \
  --remote 10.10.4.20 \
  --remote-port 52000

De uitkomst toont of verkeer wordt toegestaan of geweigerd en welke regel daarvoor verantwoordelijk is. Dat is precies het soort bewijs dat in een lab en in een productie-incident nodig is: eerst vaststellen waar de blokkade zit, daarna pas routes, NSG’s of firewallpolicies aanpassen.

Examendag: minder risico door voorbereiding

De dag van het examen draait om rust en voorspelbaarheid. Bij een online examen moet de kandidaat ruim vóór de starttijd de systeemcheck uitvoeren, bedrijfs-VPN’s of beveiligingssoftware vermijden als die de proctoringtool blokkeren, en zorgen dat het identiteitsbewijs geldig en leesbaar is. Bij een testcenter is het verstandig de route, parkeertijd of openbaar vervoer vooraf te controleren en geen onnodige persoonlijke spullen mee te nemen.

Herplannen, annuleren en herkansen vallen onder Microsoft- en examenleverancierbeleid en kunnen voorwaarden of wachttijden hebben. Die regels moeten vóór boeking worden gelezen, vooral wanneer het examen rond projectdeadlines of verlof wordt gepland. Na afloop is het scorerapport nuttig als diagnose-instrument: het is geen volledige uitleg van gemiste vragen, maar het geeft richting aan de domeinen die bij een herkansing of verdere studie extra aandacht vragen.

Van examenvoorbereiding naar netwerkvaardigheid

De waarde van AZ-700 zit in het vermogen om Azure-netwerkkeuzes te onderbouwen. Een kandidaat die kan uitleggen waarom een Private DNS zone-link ontbreekt, waarom een ExpressRoute-failoverpad asymmetrisch wordt, of waarom Front Door beter past dan Application Gateway in een globale WAF-case, bouwt kennis op die verder gaat dan examengerichte herkenning.

Een praktische volgende stap is een eigen labomgeving behouden tot na het examen en daarin elke zwakke score uit het scorerapport opnieuw bouwen. Readynez kan daarbij structuur bieden voor kandidaten die begeleiding willen, maar de doorslaggevende voorbereiding blijft hetzelfde: officiële examendoelen volgen, scenario’s hands-on oefenen en elke netwerkbeslissing kunnen bewijzen met routing-, DNS- en monitoringdata.