AZ-700 is a practical design and implementation exam for Azure-netwerkingenieurs and cloudbeheerders who must go beyond productkennis to reason through routing, private access, hybrid connectivity and security trade-offs in realistic Azure designs.
AZ-700, officieel gekoppeld aan de Microsoft Certified: Azure Network Engineer Associate-certificering, toetst het ontwerpen, implementeren en beheren van Azure-netwerkoplossingen. Het examen is vooral relevant voor professionals die werken met virtuele netwerken, hybride verbindingen, DNS, private endpoints, firewalls, load balancing en netwerkbewaking.
Deze gids gebruikt consequent “je”, omdat de voorbereiding op AZ-700 praktisch moet blijven. Wie al ervaring heeft met Azure-beheer, bijvoorbeeld op AZ-104-niveau, heeft een goede basis. Het verschil is dat AZ-700 minder draait om losse configuratiestappen en meer om het kiezen van de juiste netwerkarchitectuur onder beperkingen zoals latency, kosten, beheerbaarheid, beveiliging en afhankelijkheden met on-premises netwerken.
Actuele exameninformatie voor AZ-700
Microsoft publiceert de officiële exameneisen, vaardigheidsdomeinen, planning en lokale tariefinformatie op de certificeringspagina voor Azure Network Engineer Associate. Die pagina hoort de bron te zijn voor de meest actuele details, omdat examenblueprints, prijzen en beschikbaarheid per land kunnen wijzigen.
Voor Nederlandse kandidaten is vooral belangrijk dat de planning via Microsofts examenproces verloopt, met opties voor een testcentrum of online proctoring wanneer beschikbaar. De prijs wordt lokaal weergegeven tijdens registratie; daarom is een vaste USD-prijs geen betrouwbare Nederlandse referentie. De slaagscore voor Microsoft-certificeringsexamens zoals AZ-700 wordt weergegeven op een schaal waarbij 700 van 1000 de gebruikelijke grens is, maar de officiële examenpagina blijft leidend voor actuele beleidsdetails zoals herkansingen en registratievoorwaarden.
Bij het lezen van de examengids is het verstandig om niet alleen naar de domeinnamen te kijken. Let vooral op werkwoorden zoals “design”, “implement”, “configure”, “monitor” en “troubleshoot”. Die woorden geven aan dat een kandidaat niet alleen moet weten wat een service doet, maar ook wanneer de service passend is en welke gevolgen een ontwerpkeuze heeft.
Wat AZ-700 werkelijk toetst
AZ-700 bevat scenario’s waarin meerdere oplossingen technisch mogelijk zijn. Een vraag kan bijvoorbeeld gaan over het verbinden van vestigingen met Azure, het afdwingen van inspectie via een firewall, of het bereikbaar maken van een PaaS-service via private endpoints. De juiste keuze hangt dan af van eisen rond routing, beheer, kosten, beveiliging of latency.
Dat maakt blind leren van “best practices” riskant. Een ontwerp dat goed werkt voor een enkele VNet-peering kan ongeschikt zijn voor een omgeving met tientallen subscriptions en gedeelde beveiligingsperimeters. Een private endpoint kan de juiste beveiligingskeuze zijn, maar zonder correcte DNS-resolutie ontstaan time-outs die op netwerkblokkades lijken. Het examen beloont daarom het verklaren van het waarom achter een configuratie.
De kerngebieden zijn hybride connectiviteit, core networking, routing, beveiliging, private access, load balancing en monitoring. Daarbinnen verdienen enkele onderwerpen extra aandacht omdat ze in de praktijk vaak complexer zijn dan ze in korte documentatievoorbeelden lijken: Virtual WAN, Azure Network Manager, Private Link, Private DNS Resolver, NAT Gateway, DDoS Protection, Application Gateway, Front Door en WAF.
Hybride connectiviteit: VPN, ExpressRoute of Virtual WAN
Hybride connectiviteit is een van de belangrijkste onderdelen van AZ-700. VPN Gateway gebruikt IPsec/IKE voor site-to-site- en point-to-siteverbindingen via het publieke internet. ExpressRoute gebruikt een private verbinding via een provider en ondersteunt BGP voor route-uitwisseling. Virtual WAN voegt daar beheerde hubs aan toe voor gecentraliseerde connectiviteit, routing en beleid, met integratie voor site-to-site VPN, ExpressRoute en point-to-site VPN.
Een praktisch besliskader helpt bij examencases. VPN past vaak bij kleinere of tijdelijke verbindingen, of wanneer internetgebaseerde connectiviteit acceptabel is. ExpressRoute past beter wanneer private connectiviteit, voorspelbare prestaties of integratie met bestaande WAN-contracten belangrijk zijn. Virtual WAN wordt interessant wanneer meerdere regio’s, vestigingen of subscriptions centraal moeten worden verbonden en beheerd.
De ontwerptrend in veel Azure-omgevingen is een verschuiving van losse hub-spoke-modellen naar Virtual WAN in combinatie met centraal beheer via Azure Network Manager. Dat verandert hoe netwerkingenieurs nadenken over UDR’s, BGP-routes en beveiligingsperimeters. Waar een klassieke hub-spoke vaak per regio en per hub werd beheerd, vraagt een Virtual WAN-ontwerp meer aandacht voor globale intent, routepropagatie en consistente policy.
Een veelgemaakte fout is het onderschatten van routeprioriteit. Azure gebruikt systeemroutes, door BGP geleerde routes en user-defined routes, waarbij een UDR specifieke verkeersstromen bewust kan overrulen. Dat is krachtig, maar kan ook symmetrische routing breken wanneer verkeer via een firewall-appliance wordt afgedwongen en het retourpad een andere route kiest.
Private Link, DNS en naamomzetting
Private Link en Private Endpoints vormen een belangrijk examenonderwerp omdat ze private toegang tot Azure PaaS-services mogelijk maken. De netwerkregel is echter maar de helft van het ontwerp. Zonder correcte DNS-integratie blijft een client soms de publieke naam of een verkeerd privé-adres gebruiken, waarna de verbinding faalt ondanks ogenschijnlijk correcte NSG’s en route-instellingen.
In praktijkomgevingen is DNS vaak het struikelblok. Een goed ontwerp gebruikt private DNS-zones voor de relevante Azure-service, koppelt die zones aan de juiste VNets en regelt forwarding vanuit on-premises DNS naar Azure, bijvoorbeeld met Private DNS Resolver. Dit is vooral belangrijk in hybride omgevingen waar clients in een datacenter een Azure SQL-database, storage account of andere PaaS-service via een private endpoint moeten bereiken.
Voor AZ-700 is het nuttig om split-horizon DNS te begrijpen: dezelfde servicenaam kan intern naar een privé-adres wijzen en extern naar een publieke endpointresolutie. Kandidaten die alleen controleren of een firewallregel openstaat, missen dan de echte oorzaak. Een goede troubleshootingvolgorde begint met naamresolutie, gaat daarna naar routepad en eindigt pas bij toegangsregels.
Routing, NAT Gateway en schaalbare uitgaande verbindingen
Routing in Azure lijkt eenvoudig zolang verkeer binnen één VNet blijft. De complexiteit ontstaat bij VNet-peering, hybride BGP, forced tunnelling, firewalls, gedeelde services en subnetten met eigen routebehoeften. AZ-700 verwacht dat kandidaten routebeslissingen kunnen verklaren, niet alleen een routetabel kunnen aanmaken.
NAT Gateway verdient speciale aandacht bij schaalbare uitgaande verbindingen. Voor workloads zoals schaalsets en AKS kan SNAT-uitputting optreden wanneer veel instanties via beperkte uitgaande poorten verbinding maken met externe endpoints. NAT Gateway wordt per subnet gekoppeld en biedt een explicieter ontwerp voor outbound connectivity dan afhankelijkheid van impliciete SNAT via andere componenten.
In ontwerpvragen is het verstandig om te letten op de plaats waar outbound verkeer ontstaat. Een subnet met veel pods, VM’s of parallelle verbindingen vraagt een andere uitgaande strategie dan een klein beheersubnet. Daardoor is NAT Gateway niet alleen een configuratie-item, maar een schaal- en betrouwbaarheidsoverweging.
Application Gateway, Front Door en WAF goed onderscheiden
Application Gateway en Azure Front Door worden regelmatig door elkaar gehaald, vooral omdat beide met HTTP(S)-verkeer en WAF kunnen werken. Het onderscheid is belangrijk. Front Door Standard/Premium werkt aan de globale edge en past bij wereldwijde entry points, anycast, caching en verkeer naar meerdere regio’s. Application Gateway is regionaal en past bij regionale webworkloads, integratie met WAF v2 en scenario’s waarin end-to-end TLS en regionale routingcontrole centraal staan.
In veel ontwerpen is de vraag niet welke dienst “beter” is, maar welke laag welk probleem oplost. Front Door kan het globale toegangspunt vormen voor gebruikers, terwijl Application Gateway in een regio fijnmazige verkeerssturing naar workloads verzorgt. WAF-beleid moet dan doelgericht worden geplaatst, zodat inspectie niet dubbel, inconsistent of op de verkeerde laag gebeurt.
DDoS Protection hoort in dezelfde ontwerpredenering thuis. Azure biedt platformbescherming, maar DDoS Network Protection is relevant wanneer publieke IP’s en internetgerichte workloads extra bescherming, telemetrie en mitigatieondersteuning nodig hebben. Voor het examen is vooral belangrijk dat beveiliging niet als los product wordt gezien, maar als onderdeel van het netwerkontwerp.
Hands-on oefenen zonder onnodige complexiteit
Praktijkervaring is de kortste route naar begrip, mits de labs klein blijven en elk lab één ontwerpvraag beantwoordt. Een lab waarin VNet-peering, UDR’s, een firewall, Private Link en DNS tegelijk worden gebouwd, lijkt efficiënt maar maakt troubleshooting onduidelijk. Beter is om één concept per oefening te isoleren en daarna combinaties te maken.
Een sterke voorbereiding bevat in elk geval labs met VNet-peering, route tables, BGP-concepten, VPN Gateway of Virtual WAN, Private Endpoints, Private DNS Resolver, NAT Gateway, Application Gateway of Front Door, en Network Watcher. Gebruik Azure Portal om relaties visueel te begrijpen, maar oefen ook met Azure CLI of PowerShell zodat configuratiepatronen herkenbaar worden.
Onderstaande Azure CLI-oefening laat zien hoe een veelvoorkomende AZ-700-bouwsteen ontstaat: een VNet met een subnet en een expliciete NAT Gateway voor uitgaand verkeer. Dit is nuttig bij workloads die voorspelbaar outbound internetverkeer nodig hebben.
Example — NAT Gateway koppelen aan een subnet
az group create --name rg-az700-networking --location westeurope
az network public-ip create \
--resource-group rg-az700-networking \
--name pip-nat-westeurope-01 \
--sku Standard \
--allocation-method Static
az network nat gateway create \
--resource-group rg-az700-networking \
--name natgw-workloads-westeurope-01 \
--public-ip-addresses pip-nat-westeurope-01 \
--idle-timeout 10
az network vnet create \
--resource-group rg-az700-networking \
--name vnet-workloads-westeurope-01 \
--address-prefixes 10.40.0.0/16 \
--subnet-name snet-app-01 \
--subnet-prefixes 10.40.1.0/24
az network vnet subnet update \
--resource-group rg-az700-networking \
--vnet-name vnet-workloads-westeurope-01 \
--name snet-app-01 \
--nat-gateway natgw-workloads-westeurope-01
Dit lab maakt duidelijk dat NAT Gateway aan een subnet wordt gekoppeld en niet aan een individuele VM. Controleer daarna in de portal welke subnetinstelling is gewijzigd en bedenk hoe het ontwerp verandert wanneer meerdere workloadsubnetten elk eigen uitgaand verkeer nodig hebben.
Een korte praktijkcase: van hub-spoke naar Virtual WAN
Een herkenbaar scenario is een organisatie met meerdere Azure-regio’s, enkele on-premises locaties en een klassiek hub-spoke-ontwerp per regio. In de eerste fase werkt dat goed: elke hub bevat een firewall, VPN- of ExpressRoute-connectiviteit en peering naar spokes. Na verloop van tijd worden route tables, firewallregels en DNS-forwarding per regio verschillend, waardoor wijzigingen trager en foutgevoeliger worden.
Bij een migratie naar Virtual WAN verschuift het ontwerp naar beheerde hubs, centrale route-intentie en consistentere koppeling van vestigingen en Azure-spokes. De trade-off is dat teams minder maatwerk per hub willen toepassen en vooraf beter moeten bepalen welke verkeersstromen centraal worden geïnspecteerd. Het voordeel is eenvoudiger beheer wanneer meerdere locaties, regio’s en verbindingstypen samenkomen.
Voor AZ-700 is deze case nuttig omdat hij laat zien hoe ontwerpkeuzes veranderen bij schaal. Een enkele UDR kan in een kleine omgeving voldoende zijn, terwijl centrale routing en policybeheer logischer worden zodra meerdere regio’s en teams betrokken zijn. De examenvraag zal zelden letterlijk naar een migratieplan vragen, maar vaak wel naar de architectuurkeuze die bij deze omstandigheden past.
Veelgemaakte fouten bij AZ-700-voorbereiding
- Private Endpoints configureren zonder private DNS-zones en conditional forwarding mee te nemen.
- NAT Gateway vergeten bij subnetten met veel uitgaande verbindingen, waardoor SNAT-uitputting pas tijdens belasting zichtbaar wordt.
- UDR’s inzetten zonder het retourpad te controleren, waardoor asymmetrische routing ontstaat.
- Front Door en Application Gateway behandelen alsof ze dezelfde laag in het ontwerp oplossen.
- Examenvragen beantwoorden vanuit een vaste voorkeur in plaats van vanuit eisen zoals latency, beheer, security en kosten.
Deze fouten hebben één gemeenschappelijk patroon: de kandidaat kent de service, maar niet de afhankelijkheden. Daarom moet voorbereiding altijd bestaan uit lezen, bouwen, breken en herstellen. Network Watcher, effectieve routes, DNS-querytests en verbindingsdiagnostiek zijn daarbij net zo belangrijk als de eerste implementatie.
Studieaanpak voor Nederlandse kandidaten
Een realistisch studieplan begint met de officiële Microsoft-examenpagina en de Microsoft Learn-modules, maar eindigt daar niet. De Microsoft-bronnen geven structuur; hands-on labs en scenarioanalyse zorgen voor begrip. Plan de voorbereiding rond ontwerpvragen, bijvoorbeeld: hoe wordt on-premises DNS gekoppeld aan private endpoints, wanneer is ExpressRoute nodig, en waar hoort WAF-inspectie plaats te vinden?
Gestructureerde begeleiding kan helpen wanneer iemand weinig tijd heeft of feedback nodig heeft op ontwerpkeuzes. Een live cursus zoals de AZ-700 training met instructeur kan nuttig zijn als aanvulling op eigen labs, vooral wanneer routing, DNS en hybride connectiviteit nog niet dagelijks werk zijn. De waarde zit dan vooral in het ordenen van onderwerpen en het oefenen met scenario’s, niet in het uit het hoofd leren van productdetails.
Wie meerdere Microsoft-certificeringen wil combineren, kan daarnaast kijken naar een breder leerbudget via Readynez, maar voor AZ-700 blijft de kern hetzelfde: bouw kleine labs, documenteer je ontwerpkeuzes en controleer steeds welk probleem een Azure-netwerkdienst werkelijk oplost.
Laatst bijgewerkt en examengebonden aandachtspunten
Laatst bijgewerkt: 2026. Controleer vóór registratie altijd de officiële Microsoft-pagina voor de actuele examengids, taalbeschikbaarheid, lokale prijs, planning en eventuele wijzigingen in gemeten vaardigheden. Deze gids is bedoeld als praktische voorbereiding en vervangt de officiële exameninformatie niet.
Een eenvoudige changelog voor eigen studie is verstandig. Noteer wanneer Microsoft de skills outline wijzigt, welke nieuwe Azure-netwerkservices in je omgeving relevant worden en welke onderwerpen tijdens oefenvragen terugkerend zwak blijken. Zo blijft voorbereiding gekoppeld aan actuele exameneisen én aan de netwerken die je daadwerkelijk beheert.
Verder bouwen na AZ-700
AZ-700 is waardevol omdat het netwerkdenken in Azure scherper maakt. Na het examen ligt de volgende stap vaak in twee richtingen: dieper specialiseren in cloudnetwerken en security, of breder groeien richting Azure-architectuur. In beide gevallen blijft de praktische basis hetzelfde: routes verklaren, DNS bewijzen, private toegang testen, verkeersstromen inspecteren en ontwerpkeuzes onderbouwen.
De meest effectieve volgende stap is een eigen referentieomgeving onderhouden waarin hybride connectiviteit, Private Link, WAF, NAT Gateway en monitoring samenkomen. Wie deze onderdelen in samenhang kan uitleggen, is beter voorbereid op AZ-700 en beter bruikbaar in echte Azure-netwerkprojecten.
