AZ-400 is geen instapexamen voor iedereen die met DevOps wil beginnen, maar een expertgericht examen binnen de Microsoft Certified: DevOps Engineer Expert-certificering. Het vraagt om aantoonbaar begrip van ontwikkeling, operations, Azure, automatisering en beveiligde softwarelevering.
Laatst bijgewerkt: 28 juli 2026. De meest betrouwbare bron voor actuele examendetails blijft de officiële Microsoft-pagina voor examen AZ-400. Microsoft kan examendoelen, vraagvormen en certificeringsrelaties aanpassen, dus vaste aannames over duur, vraagtypen of wegingen zijn minder nuttig dan werken vanuit de officiële examengids en veel praktijkoefening.
Wat AZ-400 werkelijk toetst
AZ-400 draait om het ontwerpen en implementeren van DevOps-processen met Microsoft-technologieën. Het examen toetst niet alleen of iemand weet waar een knop in Azure DevOps staat, maar vooral of die persoon een betrouwbaar softwareleveringsproces kan inrichten: van source control en branching tot CI/CD, security, compliance, monitoring en feedbackloops.
De certificering waar AZ-400 bij hoort is Microsoft Certified: DevOps Engineer Expert. Dat woord “Expert” is belangrijk. Kandidaten die al ervaring hebben met Azure-beheer of Azure-ontwikkeling hebben doorgaans een realistischer startpunt, zeker wanneer zij eerder richting Azure Administrator Associate of Azure Developer Associate hebben gewerkt.
Dat betekent niet dat AZ-104 of AZ-204 altijd eerst afgerond moet zijn voordat AZ-400 zinvol wordt. Het betekent wel dat een kandidaat de onderliggende werelden moet herkennen: infrastructurele inrichting, identity, deploymentmodellen, repositories, testautomatisering, releasebeheer en operationele monitoring. Wie alleen theoretisch DevOps-jargon kent, loopt snel vast zodra scenario’s vragen om trade-offs.
Gebruik de officiële examengids als ruggengraat, niet als leeslijst
De Microsoft-studiegids voor AZ-400 is het logische vertrekpunt, maar de gids werkt het best als structuur voor labs. Een veelgemaakte fout is de onderwerpen één voor één te lezen en daarna oefenvragen te maken. AZ-400 beloont eerder het vermogen om onderwerpen te combineren, bijvoorbeeld branch policies, approvals, secrets, deployment gates en monitoring in één delivery flow.
Een goede voorbereiding begint daarom met het markeren van de examendomeinen en het koppelen van elk domein aan een tastbaar labartefact. Een onderwerp als “security and compliance” wordt pas examengericht wanneer het zichtbaar wordt in een pipeline met secret management, dependency scanning, toegangsbeheer en traceerbare approvals. Hetzelfde geldt voor monitoring: een dashboard of alertregel leert meer dan een losse definitie van observability.
Communitybronnen kunnen helpen bij nuance en actuele discussies. De Microsoft Tech Community en de Microsoft Learn Community zijn vooral nuttig wanneer kandidaten willen begrijpen hoe anderen bepaalde DevOps-keuzes interpreteren. Ze vervangen de officiële examengids niet, maar kunnen wel helpen om blinde vlekken te ontdekken.
Azure DevOps Pipelines of GitHub Actions: wat oefen je voor AZ-400?
Voor AZ-400 is het minder belangrijk om één platform als winnaar te kiezen dan om de DevOps-principes achter beide platformen te beheersen. Azure DevOps Pipelines en GitHub Actions kunnen allebei builds automatiseren, tests uitvoeren, artefacten publiceren, secrets gebruiken en deployments naar omgevingen sturen. Het examen kijkt vooral of een kandidaat begrijpt waarom een bepaalde inrichting veilig, onderhoudbaar en controleerbaar is.
GitHub Actions ligt vaak voor de hand in teams die dicht bij GitHub-repositories werken, open-sourcecomponenten gebruiken of workflows willen opbouwen rond pull requests en repository events. In multi-cloud- of productteams waar ontwikkelaars al in GitHub leven, sluit Actions vaak natuurlijk aan op de dagelijkse werkwijze. De voorbereiding moet dan wel verder gaan dan eenvoudige workflowbestanden; kandidaten moeten ook oefenen met environments, protected branches, secrets, dependency checks en herbruikbare workflows.
Azure DevOps Pipelines blinkt uit in organisaties die al zwaar leunen op Azure DevOps Boards, Repos, Artifacts en enterprise governance. Het platform voelt vaak sterk in omgevingen waar auditbaarheid, gescheiden verantwoordelijkheden, releasegeschiedenis en integratie met bestaande projectprocessen belangrijk zijn. Voor examendoelen is het verstandig om minimaal één pipeline in Azure DevOps declaratief op te bouwen, omdat YAML, environments, approvals en policies vaak beter blijven hangen wanneer ze samen worden toegepast.
Een praktische keuze voor de voorbereiding is daarom eenvoudig: oefen primair op het platform dat de kandidaat op het werk gebruikt, maar bouw minstens één vergelijkbare workflow op het andere platform om concepten te kunnen vertalen. Wie kan uitleggen hoe een approval, secret, artefact, branch policy en rollbackstrategie in beide werelden werken, bereidt zich sterker voor dan iemand die alleen UI-wizards heeft gevolgd.
Een examengericht CI/CD-lab dat meerdere doelen tegelijk dekt
Een effectief AZ-400-lab hoeft geen groot project te zijn. Het moet vooral de juiste DevOps-beslissingen afdwingen. Een kleine webapplicatie met unit tests, een buildstage, een securitycheck, publicatie van een artefact en deployment naar een test- en productieomgeving is voldoende om meerdere examendomeinen tegelijk te oefenen.
Het onderstaande voorbeeld laat een compacte Azure Pipelines YAML-structuur zien. Het doel is niet om een volledige productiepipeline te leveren, maar om te laten zien hoe stages, quality gates, environments en secrets logisch samenkomen. In een echte omgeving worden service connections, environment approvals en secret values buiten het YAML-bestand beheerd.
Example — multi-stage Azure Pipelines met test, scan en deployment
trigger:
branches:
include:
- main
variables:
buildConfiguration: 'Release'
stages:
- stage: BuildAndTest
displayName: Build and test
jobs:
- job: Build
pool:
vmImage: 'ubuntu-latest'
steps:
- task: UseDotNet@2
inputs:
packageType: 'sdk'
version: '8.x'
- script: dotnet restore
displayName: Restore dependencies
- script: dotnet build --configuration $(buildConfiguration) --no-restore
displayName: Build application
- script: dotnet test --configuration $(buildConfiguration) --no-build --collect "XPlat Code Coverage"
displayName: Run tests with coverage
- script: dotnet list package --vulnerable --include-transitive
displayName: Check vulnerable dependencies
- task: PublishPipelineArtifact@1
inputs:
targetPath: '$(System.DefaultWorkingDirectory)'
artifact: 'webapp-drop'
- stage: DeployTest
displayName: Deploy to test
dependsOn: BuildAndTest
condition: succeeded()
jobs:
- deployment: DeployTestApp
environment: 'az400-test'
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: 'webapp-drop'
- script: echo "Deploying to test with a secured service connection"
displayName: Deploy test release
- stage: DeployProduction
displayName: Deploy to production
dependsOn: DeployTest
condition: succeeded()
jobs:
- deployment: DeployProdApp
environment: 'az400-production'
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: 'webapp-drop'
- script: echo "Deploying after environment approval"
displayName: Deploy production release
Dit voorbeeld dwingt een kandidaat om verder te denken dan “een pipeline die groen wordt”. De teststage levert bewijs over kwaliteit, de dependencycheck raakt security, het artefact maakt de release herhaalbaar en de environments maken approvals en scheiding tussen test en productie bespreekbaar. De kandidaat moet vervolgens in Azure DevOps zelf controleren of de productieomgeving een approval vereist, of secrets niet in YAML staan en of branch policies voorkomen dat onbeoordeelde code rechtstreeks naar main gaat.
Een sterk vervolg op dit lab is het beschrijven van de rollbackstrategie. Bijvoorbeeld: wanneer een deployment naar productie faalt, wordt niet handmatig in de portal gerepareerd, maar teruggegaan naar een eerder artefact of wordt via een gecontroleerde hotfixbranch opnieuw gebouwd. Wie kan uitleggen welke gate faalde, welk bewijs in logs staat en hoe een postmortem tot een verbeteractie leidt, zit dichter bij examengerichte beheersing.
Een realistisch studieplan van twee tot vier weken
De meeste kandidaten halen meer uit een vast studieritme dan uit lange marathons in het weekend. Een bruikbare aanpak is dagelijks 45 tot 60 minuten werken aan één concreet artefact: een YAML-template, een branch policy, een dashboard, een testresultaat, een securityscan of een korte incidentanalyse. Die kleine opbrengsten maken voortgang zichtbaar en zorgen dat kennis toepasbaar blijft.
In de eerste week ligt de nadruk op positionering en source control. De kandidaat leest de officiële examengids, brengt de eigen zwakke plekken in kaart en richt een repository in met branch policies, pull request-validatie en een eenvoudige build. Het doel is niet snelheid, maar controle: elke wijziging moet traceerbaar zijn en door een voorspelbaar proces lopen.
In week twee verschuift de focus naar CI/CD. De kandidaat bouwt een multi-stage pipeline, voegt testcoverage toe, publiceert artefacten en gebruikt environments met approvals. Wie al met GitHub Actions werkt, kan dezelfde applicatie daar laten bouwen en deployen, zodat de onderliggende concepten loskomen van één interface.
Week drie is geschikt voor security, compliance en monitoring. Denk aan secret management, dependency scanning, toegangsmodellen, dashboards, alerts en feedback naar werkitems. De beste voorbereiding ontstaat wanneer deze onderdelen niet los worden geoefend, maar worden gekoppeld aan de pipeline uit week twee.
Een vierde week is vooral waardevol voor herhaling en readiness-checks. De kandidaat maakt oefenvragen, maar onderzoekt vooral waarom een fout antwoord aantrekkelijk leek. Daarna volgt een korte herbouw van de belangrijkste labs zonder stappenplan. Als dat lukt, is de kennis meestal robuuster dan wanneer iemand alleen herkenning uit meerkeuzevragen ervaart.
Veelgemaakte fouten tijdens AZ-400-voorbereiding
De meest hardnekkige fout is te veel oefenen via de gebruikersinterface. UI-wizards zijn handig om mogelijkheden te ontdekken, maar het examen verwacht begrip van declaratieve configuratie, herbruikbare templates, environments, policies en governance. YAML-first oefenen helpt kandidaten om afhankelijkheden, voorwaarden en verantwoordelijkheden expliciet te maken.
- Alleen definities leren. Bouw in plaats daarvan een scenario waarin een definitie zichtbaar wordt, zoals een approval gate voor productie.
- Security pas aan het einde toevoegen. Neem secrets, dependency checks en toegangsbeheer vanaf de eerste pipelineversie mee.
- Oefenvragen als hoofdstrategie gebruiken. Gebruik ze als diagnose, niet als vervanging voor labs.
- Geen fouten simuleren. Breek bewust een test, een secret reference of een deployment condition en onderzoek hoe de pipeline reageert.
Deze aanpak sluit aan op taakgericht leren: scenario’s bouwen, feedback krijgen, kleine verbeteringen doorvoeren en dezelfde handeling later opnieuw uitvoeren zonder volledige instructie. In die context kan een gestructureerde AZ-400-training van Readynez nuttig zijn voor kandidaten die labs, uitleg en examengerichte feedback in één ritme willen combineren.
Wanneer is iemand klaar om AZ-400 te plannen?
Exam readiness is meer dan een score op een oefentoets. Een kandidaat is op de goede weg wanneer hij of zij een branchingstrategie kan verdedigen, branch policies kan afdwingen, een multi-stage pipeline kan bouwen, secrets veilig kan gebruiken en kan uitleggen hoe gates het risico van productie-uitrol verlagen.
Ook operationeel denken telt. Kan de kandidaat na een mislukte release uitleggen welke logs relevant zijn, welke rollbackopties bestaan en hoe een incident-postmortem tot een verbeterde pipeline leidt? Kan hij of zij het verschil uitleggen tussen build-validatie, release approval, environment protection en monitoring-alerts? Dat zijn signalen dat de kennis verder gaat dan herkenning.
Een nuttige self-assessment is om een leeg repository te nemen en binnen een beperkte studietijd een minimale delivery flow op te bouwen: branch policy, build, test, artefact, testdeployment, productieapproval en monitoringnotitie. Wie dat met beperkte naslag kan uitvoeren en de keuzes kan toelichten, heeft een realistischer beeld van de eigen gereedheid.
AZ-400 als bewijs van DevOps-denken
AZ-400 is waardevol wanneer de voorbereiding leidt tot beter werkgedrag: kleinere changes, veiligere pipelines, duidelijkere ownership, betere feedbackloops en releases die te auditen zijn. Het examen is dan geen losstaand doel, maar een manier om DevOps-praktijken te formaliseren en te toetsen aan scenario’s die in echte teams voorkomen.
De meest effectieve volgende stap is de officiële Microsoft-examengids naast een eigen labomgeving leggen en per examendomein één bewijsstuk bouwen. Wie meer structuur nodig heeft, kan daarnaast kijken naar Microsoft-training via Readynez, maar de kern blijft hetzelfde: oefenen met echte pipelines, echte policies en echte beslissingen.
FAQ
Is AZ-400 geschikt als eerste Microsoft-certificering?
Voor de meeste kandidaten is AZ-400 geen logisch instappunt. Het examen hoort bij de DevOps Engineer Expert-certificering en vraagt begrip van zowel Azure-ontwikkeling als Azure-operations. Kandidaten zonder die basis doen er meestal goed aan eerst de relevante Azure-beheer- of ontwikkelvaardigheden op te bouwen.
Moet iemand eerst AZ-104 of AZ-204 halen voordat AZ-400 zinvol is?
Dat hangt af van ervaring en certificeringsdoel. De officiële Microsoft-certificeringspagina’s geven de actuele relatie tussen de certificeringen weer. Inhoudelijk helpt AZ-104 vooral bij beheer, identity, networking en platformoperaties, terwijl AZ-204 sterker aansluit op applicatieontwikkeling, integraties en developer workflows.
Wat is de beste manier om de officiële AZ-400-examendoelen te gebruiken?
Gebruik de examendoelen als kaart voor labs. Zet naast elk onderwerp een praktische opdracht, zoals een branch policy configureren, een YAML-template bouwen, een deployment approval instellen of een alert koppelen aan een incidentproces. Zo wordt de gids een werkplan in plaats van alleen leesmateriaal.
Moet ik voor AZ-400 oefenen met Azure DevOps Pipelines of GitHub Actions?
Beide zijn nuttig, omdat ze dezelfde DevOps-principes vanuit verschillende ecosystemen benaderen. Azure DevOps Pipelines is sterk in enterpriseprocessen en integratie met Boards, Repos en Artifacts. GitHub Actions is logisch wanneer repositories, pull requests en developer workflows centraal staan. Het belangrijkste is dat de kandidaat de concepten kan vertalen.
Hoe controleer ik of ik klaar ben voor het AZ-400-examen?
Een goede readiness-check is het zelfstandig bouwen en uitleggen van een multi-stage pipeline met tests, artefacten, secrets, approvals en monitoring. Daarnaast moet de kandidaat een rollbackstrategie kunnen beschrijven, branch policies kunnen afdwingen en een incident-postmortem kunnen structureren. Als dat lukt zonder volledig stappenplan, is de voorbereiding duidelijk verder dan theorie.
