AZ-500 is een certificeringsexamen voor professionals die Azure-beveiliging niet alleen willen begrijpen, maar ook aantoonbaar moeten kunnen toepassen in echte cloudomgevingen. Het examen is meegegroeid met Microsoft Entra ID, Defender for Cloud, hybride identiteiten, private connectiviteit en de manier waarop organisaties security operations in Azure inrichten.
Microsoft AZ-500 is het examen voor de rol Azure Security Engineer Associate en toetst of iemand beveiligingscontroles in Microsoft Azure kan implementeren, beheren en bewaken. Het gaat daarbij minder om losse definities dan om de samenhang tussen identiteit, netwerkbeveiliging, data protection en operationele monitoring.
Wie zich op AZ-500 voorbereidt, merkt al snel dat Azure-beveiliging geen afzonderlijk product is. Een veilige omgeving ontstaat uit keuzes in Microsoft Entra ID, role-based access control, netwerksegmentatie, Private Endpoints, Key Vault, Defender for Cloud en logging naar Log Analytics. Het examen weerspiegelt die werkelijkheid: kandidaten moeten kunnen redeneren over configuraties, risico’s en herstelstappen, niet alleen over namen van functies.
Wat AZ-500 werkelijk toetst
AZ-500 richt zich op de technische uitvoering van beveiliging in Azure. De kandidaat hoeft geen volledige enterprise-architectuur te ontwerpen zoals bij een architectuurcertificering, maar moet wel begrijpen hoe ontwerpkeuzes doorwerken in beleid, toegang, netwerkpaden en incidentrespons. Een security engineer moet bijvoorbeeld kunnen verklaren waarom een workload geen publieke toegang nodig heeft, hoe een beheerde identiteit toegang krijgt tot Key Vault en welke logs nodig zijn om een incident achteraf te reconstrueren.
De actuele exameneisen, vraagvormen, registratie-informatie, beschikbare talen en eventuele wijzigingen staan op de officiële Microsoft Learn-examenpagina voor AZ-500. Die pagina hoort leidend te zijn voor de laatste examendetails, omdat Microsoft examendoelen kan aanpassen wanneer Azure-services veranderen. Voor voorbereiding is het verstandig om de skills outline van Microsoft als bron te gebruiken en daar vervolgens eigen labs aan te koppelen.
In de praktijk vallen de getoetste vaardigheden uiteen in vier gebieden. Identiteit en toegang vormen vaak het beginpunt, omdat vrijwel elke Azure-beveiligingsbeslissing afhankelijk is van wie of wat toegang krijgt. Daarna volgen netwerkcontroles, bescherming van compute en data, en security operations. Die volgorde is ook logisch in dagelijkse werkzaamheden: zonder goede toegangsbasis worden netwerk- en datacontroles vaak omzeild door te ruime rechten.
Identiteit: Microsoft Entra ID, RBAC en PIM
Microsoft Entra ID, voorheen Azure Active Directory, vormt de identiteitslaag voor Azure. AZ-500 verwacht dat kandidaten het verschil begrijpen tussen authenticatie, autorisatie en governance. Authenticatie bepaalt of een identiteit is wie die beweert te zijn; autorisatie bepaalt wat die identiteit mag doen; governance bewaakt of die rechten nog steeds passend zijn.
Een veelgemaakte productiefout is het te breed toekennen van de Owner-rol op subscriptionniveau. Dat lijkt handig bij projectdruk, maar vergroot het risico op ongecontroleerde wijzigingen, privilege escalation en onduidelijke verantwoordelijkheid. In volwassen Azure-omgevingen worden brede permanente rechten vervangen door minimale RBAC-rollen, Privileged Identity Management voor tijdelijke activatie en Conditional Access-beleid dat rekening houdt met apparaatstatus, locatie, risico en hybride toegangspatronen.
In de Azure Portal komt dit samen bij Access control (IAM), Microsoft Entra Privileged Identity Management en Conditional Access. Een kandidaat moet niet alleen weten waar deze onderdelen staan, maar ook kunnen redeneren over gevolgen. Een roltoewijzing op management group-niveau werkt bijvoorbeeld door naar onderliggende subscriptions, terwijl een rol op resource group-niveau veel gerichter is. Dat verschil is in het examen belangrijk, maar in productie nog belangrijker.
Onderstaande Azure CLI-opdracht laat zien hoe een beheerde identiteit alleen leesrechten krijgt op één resourcegroep. Dit is een veiligere denkwijze dan een service principal of menselijk account brede subscriptionrechten geven.
Example — beperkte RBAC-toewijzing aan een managed identity
az role assignment create \
--assignee 8f4b7f2a-6c2b-4e67-9f31-1a2b3c4d5e6f \
--role "Reader" \
--scope "/subscriptions/11111111-2222-3333-4444-555555555555/resourceGroups/rg-secure-workload-prod"
De opdracht maakt een roltoewijzing op een beperkte scope. In een echte wijziging moet de object-id vooraf worden gecontroleerd en hoort er een rollbackplan te zijn, bijvoorbeeld door de role assignment-id vast te leggen. Een bekende valkuil is dat teams de juiste rol kiezen maar de scope te hoog leggen, waardoor het praktische effect alsnog te ruim is.
Netwerkbeveiliging: NSG, Azure Firewall en Private Endpoints
Azure-netwerkbeveiliging werkt in lagen. Network Security Groups filteren verkeer op subnet- of netwerkinterfaceniveau en zijn geschikt voor eenvoudige segmentatie binnen virtuele netwerken. Azure Firewall is bedoeld voor centraal beleid, filtering, DNAT, egresscontrole en logging op netwerkniveau. Private Endpoints halen PaaS-diensten zoals Storage en SQL via een privé-IP-adres naar het virtuele netwerk, zodat publieke toegang kan worden beperkt of uitgeschakeld.
Deze controles vervangen elkaar niet. Een NSG kan oost-westverkeer tussen workloads beperken, Azure Firewall kan internetuitgaand verkeer centraliseren en een Private Endpoint kan voorkomen dat een storage account via een publiek endpoint wordt gebruikt. Problemen ontstaan wanneer routes, firewallregels en DNS niet als één geheel worden ontworpen. Asymmetrische flows, verkeerde private DNS-zones en black holes in user-defined routes komen vaker voor dan verkeerd gespelde firewallregels.
In de Portal zou een engineer bij een storage account bijvoorbeeld Public network access beoordelen, Private endpoint connections controleren en de gekoppelde private DNS-zone valideren. Tegelijk hoort dezelfde workload een subnetontwerp te hebben waarin NSG-regels niet onbedoeld beheerverkeer blokkeren. AZ-500 toetst dit soort samenhang vaak indirect: een vraag beschrijft een connectiviteits- of toegangsprobleem, waarna de kandidaat de juiste controle moet herkennen.
Deze Azure CLI-opdracht maakt een Private Endpoint voor een storage account. De opdracht is bewust beperkt tot het aanmaken van de endpointverbinding; in productie moet daarna DNS-resolutie worden getest, omdat veel Private Endpoint-problemen uiteindelijk DNS-problemen zijn.
Example — Private Endpoint voor Azure Storage
az network private-endpoint create \
--name pe-stproddata-blob \
--resource-group rg-secure-network-prod \
--vnet-name vnet-prod-spoke-01 \
--subnet snet-private-endpoints \
--private-connection-resource-id "/subscriptions/11111111-2222-3333-4444-555555555555/resourceGroups/rg-data-prod/providers/Microsoft.Storage/storageAccounts/stproddata01" \
--group-id blob \
--connection-name peconn-stproddata-blob
Na het uitvoeren moet worden gecontroleerd of de private endpoint network interface een privé-IP-adres heeft en of de naam van de blobservice naar dat privé-adres resolveert vanuit het juiste virtuele netwerk. Als de workload nog steeds het publieke endpoint gebruikt, is de private connectiviteit technisch aanwezig maar beveiligingstechnisch niet effectief.
Data protection: Key Vault, opslag en databases
Databeveiliging in AZ-500 draait om toegang, netwerkisolatie, encryptiesleutels en bewaking. Key Vault is daarbij een kernservice, omdat certificaten, sleutels en geheimen vaak de toegang tot andere systemen bepalen. Een veilige Key Vault-configuratie gebruikt RBAC of access policies bewust, beperkt netwerktoegang waar mogelijk en maakt logging verplicht.
Een veelvoorkomende fout is dat teams Key Vault als veilige opslag beschouwen zonder de toegangslaag te ontwerpen. Als te veel gebruikers Secrets Officer-rechten hebben, als publieke netwerktoegang open blijft of als secret-rotatie ontbreekt, ontstaat alsnog een kwetsbaar beheerproces. AZ-500 verwacht dat kandidaten begrijpen hoe Key Vault-firewalls, managed identities, soft-delete, purge protection en RBAC samen bijdragen aan bescherming.
Voor Azure SQL Database en Storage is hetzelfde patroon zichtbaar. Private toegang en firewallregels beperken het netwerkpad, maar identity-based access en logging bepalen wie wijzigingen kan uitvoeren en hoe incidenten zichtbaar worden. In veel organisaties is de technische hardening minder lastig dan het consistent toepassen ervan over subscriptions en omgevingen heen.
Security operations: Defender for Cloud en logging
Microsoft Defender for Cloud helpt bij het beoordelen van beveiligingshouding, aanbevelingen, workloadbescherming en compliance-inzichten binnen Azure. Het moet niet worden verward met Defender for Endpoint, dat zich richt op endpointdetectie en -respons. Voor AZ-500 is vooral belangrijk dat kandidaten begrijpen hoe Defender for Cloud aanbevelingen oplevert en hoe die signalen worden vertaald naar uitvoerbare verbeteringen.
Een praktisch probleem bij Defender for Cloud is beleidsruis. Wanneer alle aanbevelingen op elke scope tegelijk zichtbaar worden, verliezen teams het onderscheid tussen kritieke risico’s en achterstallige configuratiehygiëne. Betere resultaten ontstaan door scope bewust te kiezen, uitzonderingen te documenteren, initiatieven per omgeving te beoordelen en aanbevelingen te koppelen aan de Log Analytics-werkruimten waar securityteams werkelijk mee werken.
Logging hoort vóór hardening te komen, niet erna. Zonder Diagnostic Settings naar Log Analytics of een gekoppelde Microsoft Sentinel-werkruimte ontbreekt de basis voor incidentrespons, trendanalyse en auditsporen. Ook in het examen komen logs terug in scenario’s waarin moet worden bepaald waar een gebeurtenis zichtbaar is of welke configuratie nodig is om onderzoek mogelijk te maken.
Onderstaande PowerShell-opdracht schakelt diagnostische logging in voor een Key Vault richting Log Analytics. Dit voorbeeld gebruikt de Az PowerShell-module en gaat ervan uit dat de beheerder al is aangemeld met een account dat voldoende rechten heeft.
Example — Diagnostic Settings voor Key Vault naar Log Analytics
$keyVaultId = "/subscriptions/11111111-2222-3333-4444-555555555555/resourceGroups/rg-security-prod/providers/Microsoft.KeyVault/vaults/kv-prod-app-01"
$workspaceId = "/subscriptions/11111111-2222-3333-4444-555555555555/resourceGroups/rg-monitoring-prod/providers/Microsoft.OperationalInsights/workspaces/law-security-prod"
New-AzDiagnosticSetting `
-Name "send-keyvault-logs-to-law" `
-ResourceId $keyVaultId `
-WorkspaceId $workspaceId `
-Enabled $true `
-Category "AuditEvent"
Na configuratie moet worden gecontroleerd of Key Vault-auditgebeurtenissen in de werkruimte verschijnen. In productie hoort dit onderdeel van een standaard landing zone- of policy-aanpak te zijn, omdat handmatige loggingconfiguratie per resource snel inconsistent wordt.
Hoe AZ-500-vaardigheden terugkomen in dagelijks werk
Een realistische Azure-omgeving bestaat zelden uit één losstaande resource. Denk aan een applicatie met een weblaag, een database, opslag, geheimen in Key Vault, CI/CD-toegang en monitoring. AZ-500-kennis komt dan terug in ontwerp- en beheermomenten: welke identiteit gebruikt de applicatie, welke netwerkpaden zijn toegestaan, waar staan de sleutels, welke aanbevelingen zijn relevant en welke logs zijn nodig bij een incident?
Een security engineer begint in zo’n scenario vaak bij identiteit. Menselijke beheerders krijgen minimale permanente rechten en gebruiken PIM voor tijdelijke verhoging. Workloads gebruiken managed identities in plaats van opgeslagen geheimen. Conditional Access wordt getest op beheerdersaccounts, break-glassaccounts worden apart beheerd en externe identiteiten krijgen geen bredere toegang dan noodzakelijk.
Daarna volgt het netwerk. De workload wordt geplaatst in subnetten met duidelijke NSG-regels, egress kan via Azure Firewall lopen en PaaS-diensten krijgen Private Endpoints waar publieke toegang niet nodig is. Bij elke wijziging moet connectiviteit worden getest vanuit het perspectief van de workload, omdat een regel die logisch lijkt in een diagram alsnog verkeer kan blokkeren door routing, DNS of firewallvolgorde.
Ten slotte worden data en operations ingericht. Key Vault-logboeken, SQL-auditing, storage logging en Defender for Cloud-aanbevelingen gaan naar een centrale werkruimte. Pas wanneer monitoring werkt, is het zinvol om hardening verder aan te scherpen. Anders kan een wijziging productie verstoren zonder dat duidelijk is welke controle de verstoring veroorzaakte.
AZ-500, SC-200 of SC-100 kiezen
De keuze tussen AZ-500, SC-200 en SC-100 hangt af van het soort werk dat iemand wil aantonen. AZ-500 past bij de Azure Security Engineer Associate-rol en draait om het implementeren van beveiligingscontroles in Azure. SC-200 past beter bij een Security Operations Analyst die detectie, onderzoek en respons uitvoert met onder meer Microsoft Sentinel. SC-100 hoort bij de Cybersecurity Architect-rol, waar organisatiebrede ontwerpbeslissingen en securitystrategie zwaarder wegen.
| Pad |
Waar de nadruk ligt |
Passende focus |
| AZ-500 |
Azure-beveiligingsimplementatie |
RBAC, netwerkbeveiliging, Key Vault, Defender for Cloud en logging |
| SC-200 |
Security operations |
Detectie, incidentonderzoek, respons en Sentinel-workflows |
| SC-100 |
Cybersecurityarchitectuur |
Architectuurbeslissingen, governance, strategie en end-to-end securitydesign |
Een praktische vuistregel is dat AZ-500 geschikt is wanneer iemand zelf Azure-controles configureert of beheert. Wie vooral alerts onderzoekt en incidenten afhandelt, vindt waarschijnlijk meer aansluiting bij Microsoft security-trainingen rond operations. Wie beveiligingsprincipes vertaalt naar enterprise-architectuur en besluitvorming, schuift eerder richting architectuurgerichte certificering.
Effectief voorbereiden zonder alleen voor de test te leren
Een goed studieplan begint met de officiële examengids van Microsoft Learn, maar blijft daar niet bij. Kandidaten halen meer uit voorbereiding wanneer elk examendomein wordt gekoppeld aan een echte taak: een RBAC-rol toewijzen, PIM activeren, een Key Vault afsluiten voor publiek verkeer, een Private Endpoint testen, Defender for Cloud-aanbevelingen triëren en Diagnostic Settings inschakelen. Oefenvragen helpen vooral wanneer ze controleren of de workflow begrepen is.
- Lees de actuele Microsoft Learn-skills outline en markeer per onderwerp welke Azure-service erbij hoort.
- Bouw een kleine labomgeving met een resourcegroep, virtueel netwerk, storage account, Key Vault en Log Analytics-werkruimte.
- Voer per onderwerp een wijziging uit via de Portal en herhaal dezelfde taak waar mogelijk met CLI of PowerShell.
- Controleer na elke wijziging de impact op toegang, logging en netwerkconnectiviteit.
- Gebruik oefenvragen pas daarna om scenarioherkenning en examendiscipline te trainen.
De grootste studiefout is het onthouden van acroniemen zonder operationele context. Wie weet dat PIM staat voor Privileged Identity Management, maar nooit een eligible assignment heeft beoordeeld, mist de vaardigheid die in een scenario nodig is. Hetzelfde geldt voor Private Endpoints, Key Vault-firewalls en Defender for Cloud: de examenvraag gaat zelden alleen over de naam van de service, maar over het juiste gebruik ervan.
Gestructureerde begeleiding kan nuttig zijn wanneer iemand beperkte labtijd heeft of de examendoelen wil oefenen in een begeleide volgorde. De Azure Security Engineer-training kan dan dienen als kader voor labs, scenario’s en examengerichte verdieping, zonder dat eigen hands-on oefening overbodig wordt.
Veelgestelde vragen over AZ-500
Is AZ-500 meer gericht op engineering dan op security operations?
Ja. AZ-500 gaat vooral over het implementeren en beheren van beveiligingscontroles in Azure. Security operations komt wel terug via Defender for Cloud, logging en responsinformatie, maar wie primair met detectie en incidentonderzoek werkt, zal vaak ook naar SC-200 kijken.
Moet iemand eerst Azure-beheerervaring hebben voor AZ-500?
Azure-beheerervaring helpt sterk, omdat veel beveiligingskeuzes voortbouwen op subscriptions, resourcegroepen, netwerken, identities en monitoring. Zonder basiskennis van Azure-beheer wordt AZ-500 snel abstract. Een kandidaat hoeft niet elk Azure-product te kennen, maar moet wel comfortabel zijn met Portal, RBAC, networking en logging.
Hoe blijft de certificering actueel?
Microsoft publiceert actuele certificerings- en verlengingsinformatie via Microsoft Learn. Omdat certificeringsregels en renewal-processen kunnen wijzigen, is de officiële Microsoft-pagina de juiste bron voor de laatste status en voorwaarden.
Zijn oefenexamens voldoende voorbereiding?
Oefenexamens zijn nuttig om vraagstijl en timing te oefenen, maar ze vervangen geen configuratie-ervaring. Sterke voorbereiding combineert scenario-oefeningen met hands-on taken zoals roltoewijzing, key-rotatie, Conditional Access-evaluatie, Private Endpoint-validatie en logging naar Log Analytics.
Waar AZ-500-kennis waarde krijgt
AZ-500 is waardevol wanneer de voorbereiding verder gaat dan examengerichte herkenning. De vaardigheden worden pas echt bruikbaar wanneer een professional kan uitleggen waarom een rol te ruim is, waarom een Private Endpoint geen DNS-probleem oplost zonder juiste zonekoppeling, waarom Defender for Cloud-aanbevelingen moeten worden getrieerd en waarom logging vóór hardening komt.
De meest effectieve volgende stap is een kleine Azure-omgeving opzetten en elke beveiligingscontrole koppelen aan een zichtbaar resultaat: toegang toegestaan of geweigerd, netwerkverkeer bereikbaar of geblokkeerd, geheim wel of niet opvraagbaar, log wel of niet vindbaar. Wie daarna meer structuur wil in Microsoft-voorbereiding kan Microsoft-training via een onbeperkt traject bekijken of contact opnemen met Readynez voor advies over een passend leerpad.
