Microsoft AZ-400: CI/CD Pipelines met Azure Pipelines — Studiegids

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Onderdeel van de Microsoft DevOps Engineer Expert AZ-400 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Azure Pipelines levert end-to-end CI/CD as code, met multi-stage YAML-pipelines die build, test en release verenigen met behoud van enterprise-controles. Beheersing van het schrijven van YAML, triggers, agents, variabelen, templates, deployment jobs, artifacts, caching en service connections is essentieel om schaalbare, veilige en herhaalbare delivery-systemen te bouwen.

Schrijven met YAML en Templates

Een YAML-pipeline is opgebouwd uit stages, jobs en steps. Stages modelleren de grenzen van de levenscyclus, zoals Build, Test en Release; jobs worden uitgevoerd op agents en kunnen parallel draaien; steps zijn taken of scripts die binnen een job worden uitgevoerd. Afhankelijkheden zijn expliciet via dependsOn, wat fijnmazige orkestratie en voorwaardelijke uitvoering mogelijk maakt. Multi-stage YAML consolideert CI en CD, ondersteunt fan-in/fan-out-patronen en koppelt goedkeuringen aan environments in plaats van aan een losstaand release-construct.

Templates maken compositie en hergebruik op verschillende granulariteitsniveaus mogelijk:

Step templates: kapselen een reeks taken in (bijv. tool-setup, restore, build, test) voor hergebruik over verschillende repositories.
Job templates: bundelen steps met een specifieke agent-specificatie en strategie (bijv. een testmatrix-job).
Stage templates: verpakken volledige stages, inclusief goedkeuringen, voorwaarden en environment-targeting, voor consistente promotie-flows.
Extends templates: dwingen pipeline-overerving af. Een extends op het hoogste niveau verwijst naar een centrale template die vereiste stages/jobs/steps en governance voorschrijft. Dit is krachtig voor bedrijfsbrede policies, en zorgt ervoor dat elk team security-scans, compliance-controles en naamgevingsconventies overerft.

Template-evaluatie vindt plaats tijdens compile-time, voorafgaand aan de runtime-executie. Gebruik ${{ }} voor template-expressies om de pipeline-structuur tijdens compile-time te vertakken (bijvoorbeeld om bepaalde jobs alleen voor main op te nemen). Macro-syntax $(var) en runtime-expressies $[ ] worden tijdens runtime omgezet, wat invloed heeft op wanneer secrets en variabelegroepen beschikbaar zijn. Sla gedeelde templates op in een centrale repo en importeer ze via resources repositories; pin ze aan een branch of tag voor deterministische builds.

Triggers, Agents, Variabelen en Expressies

Triggers bepalen de startpunten van automatisering:

CI-triggers starten pipeline-runs wanneer code naar gevolgde branches wordt gepusht. Include- en exclude-padfilters verminderen onnodige runs. Batch maakt het samenvoegen van meerdere pushes mogelijk.
PR-triggers valideren pull requests. Configureer doel-branches en padfilters, en schakel het automatisch annuleren van vervangen runs in.
Scheduled triggers draaien op basis van cron-expressies om nachtelijke builds of periodieke validaties te ondersteunen, met controle over de tijdzone.
Pipeline-triggers worden geactiveerd wanneer een upstream pipeline een nieuwe run of artifact publiceert. Declareer pipeline resources en voeg trigger: true toe met branch-filters om pipelines over repositories of projecten heen te koppelen.

Agents en agent pools bepalen waar jobs worden uitgevoerd:

Microsoft-hosted agents provisioneren tijdelijke VM’s op ubuntu-latest, windows-latest of macOS-images met vooraf geïnstalleerde toolsets. Ze zijn ideaal voor elasticiteit en minimaal onderhoud. Plan voor concurrency door parallelle jobs aan te schaffen en houd rekening met de limieten voor het opwarmen van de cache.
Self-hosted agents draaien op uw eigen infrastructuur voor aangepaste toolchains, toegang tot privénetwerken en voorspelbare prestaties. Hard de host, beperk egress waar nodig en roteer de agent-PAT die wordt gebruikt om de agent te registreren. Gebruik scale sets of gecontaineriseerde agents voor elasticiteit.
Agent pools groeperen agents logisch en worden gebruikt om permissies te delegeren. Geef op projectniveau “Use”-rechten aan pools en isoleer gevoelige workloads met behulp van dedicated pools. Jobs specificeren een pool en optioneel demands om agents met de vereiste capabilities te selecteren.

Variabelen en parameters zorgen voor configureerbaarheid:

Pipeline-variabelen zijn key/value-paren die beschikbaar zijn voor taken als omgevingsvariabelen en via de $(name)-macro. Secret-variabelen worden gemaskeerd in logs en nooit blootgesteld in compile-time template-expressies. Markeer ze als secret in de Library of in de pipeline.
Variabelegroepen centraliseren gedeelde waarden en secrets in de Library. Koppel aan Azure Key Vault om secrets tijdens runtime op te halen, zodat waarden niet in de pipeline worden opgeslagen. Beheer pipeline-permissies om te beperken welke pipelines een groep mogen gebruiken.
Runtime-parameters definiëren sterk getypeerde input op het moment van queuen (string, number, boolean, object) en worden tijdens compile-time geëvalueerd via ${{ parameters.* }} om de pipeline vorm te geven (bijv. het in- of uitschakelen van stages). Geef de voorkeur aan parameters wanneer u de pipeline-structuur moet aanpassen; geef de voorkeur aan variabelen wanneer u runtime-waarden binnen steps nodig heeft.
Expressies: gebruik ${{ }} voor compile-time template-logica, $(var) voor macro-substitutie, en $[condition()] voor runtime-voorwaarden in properties. Stel variabelen in vanuit taken via logging-commando’s, en propageer outputs tussen jobs met behulp van isOutput-variabelen.

Deployments, Omgevingen, Strategieën en Gates

Deployment jobs bieden eersteklas CD-semantiek. Een deployment job richt zich op een omgeving en wordt uitgevoerd volgens een strategie die rollouts en lifecycle hooks beheert:

Omgevingen (environments) vertegenwoordigen implementatiedoelen (bijv. dev, test, prod) en kunnen resources bevatten zoals Kubernetes-clusters, virtuele machines of generieke ’none’-resources voor platform-agnostische implementaties. Omgevingen verenigen telemetrie, goedkeuringen en checks.
Goedkeuringen (approvals) en checks worden gekoppeld aan omgevingen en service connections. Goedkeuringen vereisen aangewezen fiatteurs voordat de deployment doorgaat. Checks fungeren als gates die voorwaarden evalueren, zoals kantooruren, vereiste werkitems, signalen van Azure Monitor, het aanroepen van REST API’s of Azure Functions, en branch protection. Deze voorkomen promotie als prestatiebaselines of compliancevoorwaarden niet worden gehaald.
Strategieën bepalen hoe updates worden uitgerold:
- runOnce past wijzigingen toe in één enkele golf, met preDeploy- en postDeploy-hooks.
- rolling implementeert in batches over instances, met maxParallel- en faaldrempels voor een veilige voortgang.
- canary verschuift het verkeer geleidelijk in stappen, met routeTraffic- en postRouteTraffic-fases om te valideren vóór de volledige uitrol.
- blue-green (ook wel red/black genoemd) wordt geïmplementeerd door te deployen naar een parallelle omgeving of slot en het verkeer om te schakelen op de load balancer of via een App Service slot swap. Hoewel blue-green geen benoemde YAML-strategie is, wordt het gerealiseerd via omgevingen, routing en swap-taken, en biedt het een snelle rollback door het verkeer terug te draaien.

Codeer de deploymentlogica als een deployment job per omgevingsfase (environment stage). Maak gebruik van environment checks voor robuuste gates, in plaats van ad-hoc polling met scripts. Wanneer secrets nodig zijn, haal ze dan op uit Azure Key Vault via een service connection in plaats van ze in variabelen in te bedden.

Artifacts, Caching en Service Connections

Artifacts en caching verbeteren hergebruik en prestaties:

Pipeline artifacts zijn de native manier om build-outputs te publiceren en te gebruiken. Gebruik PublishPipelineArtifact om benoemde artifacts te publiceren en DownloadPipelineArtifact om ze op te halen uit de huidige of een specifieke run. Ze zijn geoptimaliseerd voor betrouwbaarheid en het delen tussen stages in YAML. Bij gebruik vanuit een andere pipeline, declareer een pipeline resource en gebruik de bijbehorende artifacts resource-naam voor een precieze ophaalactie.
Universal packages bieden versiebeheerde, onveranderlijke binaire distributie via Azure Artifacts voor niet-taalspecifieke assets (bijv. CLI-tools, databestanden). Publiceer en download met de Universal Packages-taken, organiseer via feed views (bijv. prerelease vs. release) en beheer retentie in feeds.
Pipeline caching versnelt het herstellen van dependencies. De Cache-taak gebruikt een key en een path. Keys moeten een hash zijn van lockfiles (package-lock.json, Pipfile.lock, packages.lock.json, go.sum) plus OS- en toolversies voor precieze invalidatie. Restore keys bieden fallback-matches voor gedeeltelijke cache-hits. Vermijd het inbedden van secrets in cache-paden, respecteer de limieten voor cachegrootte en schakel caching uit voor efemere tools wanneer lockfiles instabiel zijn. Gebruik cacheHitVar om het gedrag van taken te vertakken.

Service connections definiëren de identiteit die Azure Pipelines gebruikt om externe systemen te bereiken:

Typen omvatten Azure Resource Manager (voor Azure-abonnementen en resourcegroepen), GitHub (repository lezen/schrijven, statusrapportage) en Docker/Container Registry (Docker Hub, ACR). Er bestaan ook andere voor AWS, GCP, generieke service-eindpunten en package registries.
OIDC-federatie (workload identity federation) elimineert langlevende secrets door een vertrouwensrelatie tot stand te brengen tussen Azure DevOps en cloud identity providers. Configureer voor ARM een Entra ID-applicatie met een federated credential die is gekoppeld aan de Azure DevOps-issuer en repository/pipeline-claims. Tijdens runtime wisselt Azure DevOps een kortlevend token in voor een cloud access token, waardoor service principal secrets worden geëlimineerd en het risico op het lekken van credentials wordt verminderd.
Scoping en governance zijn cruciaal. Beperk de scope van ARM-connections tot het ’least privilege’-principe (idealiter op resourcegroepniveau met custom RBAC). Schakel “Grant access permission to all pipelines” uit en autoriseer in plaats daarvan pipelines expliciet. Koppel goedkeuringen en checks aan service connections om menselijke beoordeling of beleidsvalidatie te vereisen vóór gebruik.

Klassieke vs YAML en Migratie

Klassieke pipelines gebruiken de visuele designer met afzonderlijke concepten voor Build en Release. Ze bieden task-gebaseerd ontwerpen, variabelenbeheer, release-omgevingen en gates. YAML-pipelines bieden pipeline-as-code, unificatie van meerdere stages, templates en robuuste versionering met de repository. Feature-pariteit is grotendeels bereikt: omgevingsgoedkeuringen en -controles (approvals en checks) vervangen release gates; deployment jobs modelleren omgevingen; pipeline artifacts vervangen build artifacts; en templates en extends implementeren centraal beheer (governance) op schaal. De resterende verschillen hebben doorgaans betrekking op UI-gebaseerde handmatige interventies en enkele niche-features van de release designer, die in YAML worden afgedekt via Manual Validation-taken en omgevingscontroles (environment checks).

Een pragmatisch migratiepad is:

Inventariseer klassieke build- en release-definities, taken, variabelen, omgevingen, goedkeuringen (approvals) en gates.
Converteer de build naar YAML met behulp van de assistent of exporteer naar YAML, en refactor dit vervolgens naar templates voor hergebruik en onderhoudbaarheid.
Modelleer elke release-omgeving als een YAML-stage met een deployment job die gericht is op een omgeving. Vertaal release gates naar omgevingsgoedkeuringen en -controles (approvals en checks) (bijv. Azure Monitor query checks, work item query checks).
Externaliseer gedeelde variabelen naar variabelegroepen en koppel Key Vault voor secrets. Vervang service principal secrets door OIDC-ondersteunde service connections.
Vervang release artifact triggers door pipeline resource triggers. Publiceer pipeline artifacts in CI en gebruik ze in CD-stages.
Valideer de pariteit door beide pipelines tijdelijk parallel te draaien, schakel dan over en neem de klassieke definities buiten gebruik, met geschikte rollback-plannen.

Praktisch Probleemscenario

Starbucks standaardiseert de delivery voor een microservices-platform en moet migreren van klassieke releases naar YAML, terwijl performance gates worden afgedwongen, het risico van credentials wordt verminderd en builds worden versneld.

Schrijf multi-stage YAML met extends templates

Aanpak: Creëer een centraal extends template op organisatieniveau dat gemeenschappelijke stages injecteert voor statische analyse, SCA en security checks, plus standaard notificaties. Elke service-pipeline extend deze template en definieert servicespecifieke build- en deploy-stages.
Reden: Extends dwingt governance uniform af en houdt service-pipelines slank, terwijl de vereiste compliancestappen gegarandeerd worden.

Implementeer CI-, PR-, schedule- en pipeline-triggers

Aanpak: Configureer CI- en PR-triggers met path filters voor elke service; voeg een nachtelijk schedule toe voor langdurige integratietests; keten een packaging-pipeline om een deployment-pipeline te triggeren via pipeline resources.
Reden: Zorgt voor snelle feedback op codewijzigingen, periodieke health checks en deterministische promotie van bekende artifacts.

Gebruik een gemengde agent-strategie met agent pools

Aanpak: Build jobs op Microsoft-hosted ubuntu-latest voor elasticiteit; deploy jobs op self-hosted agents binnen het Starbucks VNet met toegang tot interne clusters. Isoleer agents per omgeving in pools en beperk het gebruik van de pools.
Reden: Hosted agents minimaliseren het onderhoud voor CI; self-hosted agents bieden een veilige netwerktoegang voor CD. Pool scoping dwingt het ’least privilege’-principe af.

Beheer variabelen met variabelegroepen en runtime parameters

Aanpak: Plaats gedeelde, niet-geheime waarden in variabelegroepen, haal secrets op uit Azure Key Vault via gekoppelde variabelegroepen, en stel een booleaanse parameter enablePerfGate beschikbaar om performance gates in niet-productie branches aan of uit te zetten.
Reden: Gecentraliseerde configuratie voorkomt duplicatie; Key Vault beschermt secrets; parameters sturen keuzes in de structuur tijdens de compile-time.

Definieer deployment jobs met environments, approvals en checks

Aanpak: Modelleer dev, staging en prod als environments. Voeg approvals toe voor staging en prod. Voeg checks toe: kantooruren (business hours) voor prod, en een Azure Monitor query check die promotie blokkeert als de latency in staging de baseline overschrijdt.
Reden: Goedkeuringen en controles (approvals en checks) op omgevingsniveau implementeren gecontroleerde promotie en dwingen SLO’s af vóór de productie-deployment.

Pas canary- en vervolgens blue-green-strategieën toe

Aanpak: Gebruik een canary-strategie in staging om incrementele wijzigingen te valideren. In productie, deploy naar een parallelle slot/omgeving en wissel het verkeer (blue-green/red-black) met een directe rollback-mogelijkheid.
Reden: Canary vermindert het risico tijdens validatie; blue-green minimaliseert de deploymenttijd en biedt de snelste rollback.

Optimaliseer met pipeline artifacts en caching

Aanpak: Publiceer build-outputs als pipeline artifacts; gebruik ze in deployment-stages. Cache het herstellen van dependencies met behulp van op lockfile-gehashte keys met restoreKeys als fallback.
Reden: Artifacts zorgen voor onveranderlijke, traceerbare promotie; caching verkort de buildtijden aanzienlijk zonder in te boeten aan correctheid.

Beveilig service connections met OIDC en gescoopte permissies

Aanpak: Maak ARM service connections aan met workload identity federation, gescoped op resourcegroepen. Vereis goedkeuringen en controles (approvals en checks) voor de service connection en schakel “Grant access to all pipelines” uit.
Reden: Verwijdert langlevende secrets en dwingt het ’least privilege’-principe af met auditeerbare goedkeuringen.

Dit end-to-end ontwerp brengt YAML-as-code governance in lijn met enterprise-grade approvals en checks, versnelt de delivery door caching en artifacts, en versterkt de beveiliging via OIDC en gescoopte service connections.

← Broncodebeheer en Repositorybeheer · Alle domeinen · Infrastructuur als Code en Configuratiebeheer →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →