- AZ-400 toetst of een kandidaat DevOps-processen, CI/CD, bronbeheer, beveiliging, compliance, infrastructuur als code en feedbackmechanismen kan ontwerpen en implementeren.
- Het examen hoort bij Microsoft Certified: DevOps Engineer Expert, samen met een geldige associate-certificering zoals Azure Administrator Associate of Azure Developer Associate.
- Goede voorbereiding vraagt meer dan YAML oefenen: governance, service connections, approvals, secrets en monitoring maken het verschil in echte projecten.
Laatst bijgewerkt: juli 2026. AZ-400 is het Microsoft-examen voor DevOps-professionals die oplossingen voor ontwerp, implementatie, beveiliging, governance en feedback in Azure-omgevingen moeten kunnen verbinden. Deze versie is afgestemd op de publieke Microsoft Learn-pagina’s voor Exam AZ-400, de certificeringspagina voor Microsoft Certified: DevOps Engineer Expert en de algemene Microsoft Credentials-informatie zoals geraadpleegd in juli 2026. De belangrijkste redactionele update is een scherpere nadruk op multi-stage YAML, security gates, governance rond service connections en continuous feedback, omdat deze onderwerpen sterker aansluiten bij hoe DevOps in Azure-projecten wordt uitgevoerd.
AZ-400, officieel Designing and Implementing Microsoft DevOps Solutions, is gericht op professionals die softwarelevering betrouwbaarder willen maken door samenwerking, automatisering en controle in één werkproces te brengen. Het examen gaat niet over één tool afzonderlijk, maar over de samenhang tussen planning, source control, build- en releaseautomatisering, beveiliging, infrastructuur als code en feedback uit productie.
Waar AZ-400 binnen het Microsoft-certificeringspad past
AZ-400 is het examen dat de DevOps-kant van het Microsoft Azure-certificeringspad valideert. Wie de Microsoft Certified: DevOps Engineer Expert-certificering wil behalen, moet slagen voor AZ-400 en daarnaast beschikken over een associate-certificering: Azure Administrator Associate via AZ-104 of Azure Developer Associate via AZ-204. Dat onderscheid is belangrijk, omdat de beste voorbereiding afhangt van de achtergrond van de kandidaat.
Een operations- of infrastructuurprofiel heeft meestal al ervaring met identity, networking, compute, monitoring en governance in Azure. Voor zo iemand vormt AZ-104 vaak de meest logische opstap, waarna AZ-400 de stap maakt naar pipelines, deploymentstrategieën en samenwerking met ontwikkelteams. Een developerprofiel vertrekt eerder vanuit code, API’s, Git en applicatiearchitectuur; voor dat profiel sluit AZ-204 doorgaans beter aan voordat de focus verschuift naar end-to-end delivery.
De officiële Microsoft-pagina’s blijven de plaats voor actuele examendetails, omdat examendoelen en vereisten kunnen wijzigen. Voor de inhoudelijke voorbereiding is vooral de skills measured-sectie van Exam AZ-400 nuttig: die laat zien dat de nadruk ligt op ontwerpen en implementeren, niet alleen op het herkennen van Azure DevOps-menu’s.
Azure DevOps als praktijkomgeving voor AZ-400
Azure DevOps bundelt services voor werkbeheer, versiebeheer, CI/CD, testbeheer en artifactmanagement. In AZ-400 komt die suite vaak terug via scenario’s waarin teams code moeten plannen, bouwen, testen, beveiligen en implementeren met voldoende traceerbaarheid. Azure Boards, Repos, Pipelines, Test Plans en Artifacts zijn daarbij geen losse onderdelen; ze ondersteunen samen het bewijs dat een wijziging gepland, gereviewd, getest, goedgekeurd en gemonitord is.
In echte projecten ligt de complexiteit zelden in het aanmaken van een pipeline alleen. De lastigere vragen gaan over de keuzes eromheen: welke branch-strategie past bij het releasemodel, waar worden secrets beheerd, wie mag naar productie deployen, hoe worden artifacts hergebruikt en welke feedback uit productie bepaalt of een release geslaagd is. Dat is ook waarom AZ-400 meer vraagt dan basiskennis van Azure Pipelines.
Van examendoelen naar dagelijkse DevOps-praktijk
Een belangrijk deel van AZ-400 draait rond het ontwerpen van een DevOps-strategie. Dat begint bij werkprocessen en teamafspraken, maar wordt pas concreet wanneer die afspraken zichtbaar worden in repositories, policies, pipelines en dashboards. Een goede strategie beschrijft bijvoorbeeld hoe pull requests worden beoordeeld, welke tests verplicht zijn, welke omgevingen bestaan en wanneer een release mag doorgaan.
Bronbeheer is daarbij een terugkerend keuzepunt. Trunk-based development met korte featurebranches werkt in veel Azure Pipelines-omgevingen beter dan een strikt GitFlow-model, omdat teams minder merge debt opbouwen en sneller feedback krijgen uit CI. GitFlow kan nog steeds zinvol zijn wanneer producten met lange releasecycli, onderhoudsbranches of parallelle versielijnen werken, maar het vraagt strakke discipline om integratieproblemen te vermijden.
Ook reusable pipeline templates en variabelegroepen verdienen aandacht. In kleinere projecten kan één YAML-bestand voldoende lijken, maar enterprises hebben al snel meerdere teams, applicaties en omgevingen. Templates verlagen dan de onderhoudslast, zorgen voor consistente security- en buildstappen en maken het eenvoudiger om centrale wijzigingen door te voeren zonder elke pipeline afzonderlijk te herschrijven.
Governance is een vaak onderschatte factor. Service connections moeten met least privilege worden ingericht, environment approvals en checks moeten aansluiten bij het risico van de omgeving, en naamgeving voor environments en variabelen moet consequent blijven. Kandidaten die alleen oefenen met een werkende build missen daardoor een belangrijk deel van zowel het examen als de praktijk: bij audits telt niet alleen of de deployment werkt, maar ook wie toegang had, welke controles afgedwongen werden en of de wijziging herleidbaar is.
Een compacte multi-stage pipeline in YAML
Azure Pipelines YAML is een kernvaardigheid voor AZ-400, omdat pipelines als code beheerd, gereviewd en hergebruikt kunnen worden. Het volgende voorbeeld toont een eenvoudige multi-stage pipeline waarin build, test en deployment gescheiden zijn. Het voorbeeld is bewust compact gehouden, zodat de structuur zichtbaar blijft.
Example — multi-stage Azure Pipelines YAML
trigger:
branches:
include:
- main
variables:
buildConfiguration: 'Release'
stages:
- stage: Build
displayName: Build application
jobs:
- job: BuildJob
pool:
vmImage: 'ubuntu-latest'
steps:
- task: DotNetCoreCLI@2
displayName: Restore packages
inputs:
command: 'restore'
projects: 'src/Contoso.Api/Contoso.Api.csproj'
- task: DotNetCoreCLI@2
displayName: Build project
inputs:
command: 'build'
projects: 'src/Contoso.Api/Contoso.Api.csproj'
arguments: '--configuration $(buildConfiguration) --no-restore'
- publish: '$(Build.SourcesDirectory)/src/Contoso.Api'
artifact: drop
- stage: Deploy_Test
displayName: Deploy to test
dependsOn: Build
jobs:
- deployment: DeployTest
environment: 'contoso-test'
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
- script: echo "Deploying Contoso API to test"
displayName: Deploy application
Deze pipeline laat zien hoe stages, jobs, artifacts en deployment jobs samenhangen. In een productiecontext zou de deploystap worden vervangen door een concrete deploymenttaak voor de gebruikte hostingkeuze, bijvoorbeeld Azure App Service, containers of Kubernetes. Voor AZ-400 is vooral belangrijk dat een kandidaat begrijpt waarom stages apart worden beheerd en hoe approvals of checks aan een environment gekoppeld worden.
Approvals en checks staan meestal niet volledig in hetzelfde YAML-bestand, omdat ze op environmentniveau in Azure DevOps worden beheerd. Dat is een belangrijk ontwerpdetail: YAML beschrijft het technische deploymentpad, terwijl environment governance bepaalt wie of wat een release mag vrijgeven. In projecten voorkomt die scheiding dat ontwikkelaars per ongeluk productiecontroles omzeilen door alleen een pipelinebestand aan te passen.
DevSecOps: secrets, scanning en quality gates
DevSecOps in AZ-400 betekent dat beveiliging vroeg en herhaalbaar in de deliveryflow zit. Secrets horen niet in variabelen in platte tekst of in repositorybestanden, maar in een gecontroleerde secret store zoals Azure Key Vault, gekoppeld via geschikte permissies. Security scanning, dependency checks en quality gates moeten vóór productie plaatsvinden, zodat het team fouten vindt voordat ze operationele risico’s worden.
Het volgende voorbeeld toont hoe een pipeline een variabelegroep gebruikt die Key Vault-secrets kan refereren en een statische analyse-stap opneemt. De exacte inrichting van de variabelegroep en Key Vault-koppeling gebeurt in Azure DevOps en Azure, maar de YAML maakt zichtbaar waar de waarden in de pipeline worden gebruikt.
Example — secrets and security scanning in a pipeline
trigger:
branches:
include:
- main
variables:
- group: contoso-shared-secure-vars
stages:
- stage: SecurityValidation
displayName: Security validation
jobs:
- job: Analyze
pool:
vmImage: 'ubuntu-latest'
steps:
- checkout: self
- task: UseDotNet@2
displayName: Use .NET SDK
inputs:
packageType: 'sdk'
version: '8.x'
- script: dotnet restore src/Contoso.Api/Contoso.Api.csproj
displayName: Restore dependencies
- script: dotnet build src/Contoso.Api/Contoso.Api.csproj --configuration Release --no-restore
displayName: Build for analysis
- script: echo "Run approved static analysis and dependency checks here"
displayName: Security checks
- script: echo "Using database endpoint $(databaseEndpoint) without printing secrets"
displayName: Validate secure configuration
Het leerpunt is dat secretbeheer, toegangsrechten en scanning samen ontworpen moeten worden. Een pipeline die wel een scan uitvoert maar tegelijk brede permissies op een service connection gebruikt, blijft zwak. Microsoft Learn verwijst in de AZ-400-context naar vaardigheden rond beveiliging, compliance en dependency management; in de praktijk komen die samen in dit soort end-to-end controles.
Continuous feedback en SRE-denken
AZ-400 behandelt ook continuous feedback. Dat onderwerp wordt soms te beperkt geïnterpreteerd als dashboards of notificaties, terwijl het in moderne DevOps- en SRE-praktijken gaat over de vraag of een release aantoonbaar gezond is. Application Insights, log analytics en Kusto-query’s kunnen releasecriteria ondersteunen, bijvoorbeeld door foutpercentages, latency of availability-signalen na een deployment te controleren.
Een sterk DevOps-proces koppelt releasebeslissingen aan meetbare signalen. Een team kan bijvoorbeeld afspreken dat een canary-release wordt teruggedraaid wanneer kritieke exceptions stijgen of wanneer een synthetische transactie faalt. Daarmee wordt monitoring geen activiteit achteraf, maar een onderdeel van het deploymentmodel.
Voorbereiden op AZ-400 zonder de praktijk uit het oog te verliezen
Een effectieve voorbereiding begint met de officiële skills measured-lijst en vertaalt elk domein naar een praktisch scenario. Wie CI/CD bestudeert, bouwt dus een pipeline met artifacts en stages. Wie beveiliging bestudeert, richt service connections, Key Vault-integratie en approvals in. Wie continuous feedback bestudeert, koppelt een release aan monitoring en incidentrespons.
Een veelgemaakte fout is dat kandidaten zich te lang op toolnavigatie richten. De examenvragen draaien vaak om ontwerpkeuzes: wanneer een template nuttig is, waarom een environment approval nodig is, hoe permissies op een service connection beperkt worden of hoe YAML-pipelines verschillen van oudere classic pipelines. In hands-on leertrajecten, zoals de Readynez Microsoft Certified DevOps Engineer Course, komen die beslissingen vooral tot leven wanneer de kandidaat een volledige flow bouwt in plaats van losse schermen te memoriseren.
Oefenen met case-achtige scenario’s helpt om de verschillende domeinen te verbinden. Een kandidaat kan bijvoorbeeld één repository gebruiken om branching policies, build validation, package publishing, deployment naar test, approval naar productie en monitoringfeedback te combineren. Dat soort oefening lijkt meer op de realiteit van een Azure-team dan afzonderlijke labs zonder samenhang.
Naast training blijft zelfstandig naslagwerk belangrijk. Microsoft Learn is de primaire bron voor examendoelen en productdocumentatie, terwijl een platform zoals Readynez365 kan helpen om leeractiviteiten, voortgang en herhaling te structureren zonder de officiële Microsoft-informatie te vervangen.
Wat na AZ-400?
Na AZ-400 ligt de waarde vooral in toepassing binnen projecten. Een DevOps Engineer Expert wordt niet alleen beoordeeld op het kunnen bouwen van pipelines, maar op het vermogen om teams te helpen betrouwbaarder te leveren. Dat betekent dat vaardigheden rond governance, security, observability, incidentrespons en platformstandaarden minstens zo belangrijk worden als de pipeline zelf.
Wie verder wil groeien, kan zich verdiepen in platform engineering, SRE-praktijken, infrastructuur als code met Bicep of Terraform, containerplatformen en enterprise governance in Azure. Voor professionals die meer architecturaal willen werken, kan Azure Solutions Architect Expert later relevant zijn, vooral wanneer DevOps-keuzes gekoppeld worden aan bredere cloudarchitectuur, netwerkontwerp, identity en resiliency.
De meest praktische vervolgstap is een bestaand project kritisch bekijken: zijn pipelines herbruikbaar, zijn secrets correct beheerd, zijn service connections beperkt, bestaan er duidelijke approvals, en wordt releasesucces gemeten met operationele signalen? Wie daarop kan antwoorden met werkende configuratie en traceerbaar bewijs, gebruikt AZ-400-kennis op het niveau waarvoor ze bedoeld is.
FAQ
Wat toetst het AZ-400-examen?
AZ-400 toetst het ontwerpen en implementeren van Microsoft DevOps-oplossingen. De onderwerpen omvatten onder meer DevOps-processen, bronbeheer, CI/CD, dependency management, security en compliance, infrastructuur als code en continuous feedback. De actuele verdeling en formulering staan op de officiële Microsoft Learn-examenpagina.
Is AZ-400 voldoende voor Microsoft Certified: DevOps Engineer Expert?
Nee. Voor Microsoft Certified: DevOps Engineer Expert is AZ-400 vereist, maar de kandidaat moet ook een geldige associate-certificering hebben: Azure Administrator Associate of Azure Developer Associate. De officiële certificeringspagina van Microsoft blijft leidend voor de actuele vereisten.
Hoe lang duurt voorbereiding op AZ-400?
Dat hangt af van ervaring met Azure, Git, CI/CD, scripting, security en operations. Kandidaten met dagelijkse DevOps-ervaring hebben doorgaans minder conceptuele achterstand, maar moeten nog steeds examengericht oefenen met Microsoft-terminologie en scenario’s. Wie vooral uit development of operations komt, doet er goed aan de ontbrekende helft van het werkveld praktisch te oefenen.
Welke tools zijn nuttig om AZ-400-vaardigheden te oefenen?
Azure Repos, Azure Pipelines, Azure Boards, Azure Artifacts en Azure Test Plans vormen een logische oefenomgeving voor veel examendoelen. Daarnaast zijn Azure Key Vault, Azure Policy, Application Insights, Log Analytics, Bicep en Terraform relevant om security, governance, observability en infrastructuur als code realistisch te oefenen.
Moet een kandidaat YAML-pipelines kennen voor AZ-400?
Ja, YAML-pipelines zijn belangrijk omdat ze CI/CD-configuratie als code behandelen. Kandidaten moeten begrijpen hoe stages, jobs, tasks, artifacts, variabelen, templates, environments en deployment jobs samenwerken. Classic pipelines kunnen nog voorkomen in bestaande omgevingen, maar YAML is de logische focus voor moderne Azure DevOps-praktijk.
Waar staan actuele updates over AZ-400?
Microsoft publiceert actuele examendetails, certificeringsvereisten en wijzigingen via Microsoft Learn en Microsoft Credentials. Het is verstandig om de officiële pagina’s kort voor het plannen van het examen opnieuw te controleren, omdat examendoelen en productfunctionaliteit kunnen wijzigen.
