En robust Azure DevOps-pipeline er en CI/CD-arbeidsflyt som leverer endringer raskt, sikkert og forutsigbart uten manuelle snarveier som senere blir teknisk gjeld. AZ-400 er relevant nettopp fordi eksamenen tester hvordan DevOps-praksis utformes og implementeres når kildekode, bygg, sikkerhet, utrulling og drift må fungere som én sammenhengende arbeidsflyt.
AZ-400-eksamenen, Design and Implement Microsoft DevOps Solutions, handler om å designe og gjennomføre DevOps-løsninger i Microsoft-miljøer. Den passer særlig for utviklere, SRE-er, release managers og DevOps-ingeniører som allerede arbeider med Azure, Git, CI/CD, testautomatisering, infrastruktur som kode og operasjonell forbedring.
Det er viktig å avgrense rollen riktig. AZ-400 er ikke en grunnleggende Azure-administratorprøve, og den er heller ikke en ren verktøytest i Azure Pipelines. Den måler evnen til å sette sammen DevOps-praksis på tvers av planlegging, kildekontroll, bygg, release, sikkerhet, samsvar, artefakter, observabilitet og kontinuerlig læring. Microsofts rollebeskrivelse for Azure DevOps Engineer Expert viser også at kandidaten forventes å kunne samarbeide med utvikling, drift, sikkerhet og interessenter, ikke bare skrive pipeline-syntaks.
Hva AZ-400 dekker i praksis
Azure DevOps består av tjenester som dekker store deler av programvareleveransen: Boards for arbeidssporing, Repos for Git-basert kildekontroll, Pipelines for bygg og utrulling, Test Plans for manuell og utforskende testing, og Artifacts for pakker. I en moden DevOps-praksis brukes disse tjenestene ikke som separate moduler, men som koblede deler av samme leveransekjede.
En backlog-item i Boards bør kunne spores til en branch, en pull request, et bygg, et artefakt, en utrulling og til slutt til driftsdata. Når denne sporbarheten mangler, blir det vanskeligere å finne årsaken til feil, prioritere teknisk gjeld og dokumentere endringer ved revisjon. AZ-400 legger derfor vekt på både tekniske mekanismer og samarbeidsformer.
Forberedelse til eksamen bør begynne med Microsofts offisielle ferdighetsoversikt, fordi eksamensinnhold og vektlegging kan bli oppdatert. Kandidater bør bruke den offisielle eksamenssiden for formalia som språk, måleområder, forutsetninger og eventuelle endringer, i stedet for å basere seg på eldre blogginnlegg eller uoffisielle sammendrag.
Fra commit til produksjon: slik bør en Azure Pipeline tenkes
En god Azure Pipeline starter før YAML-filen. Teamet må først avklare hvordan kode flyter gjennom repositoryet, hvilke kvalitetsporter som skal gjelde, og hvilke miljøer som krever manuell eller automatisert godkjenning. Når dette er avklart, blir YAML et uttrykk for leveransemodellen, ikke en samling tilfeldige oppgaver.
Valget mellom trunk-based development og GitFlow bør styres av releasekadense, teamstørrelse og krav til kontroll. Team som deployer ofte og kan bruke feature flags, har vanligvis nytte av trunk-based development med korte feature branches, strenge branch policies og hyppige pull requests. Team med lange releasevinduer, flere vedlikeholdte versjoner eller tung regulatorisk kontroll kan ha behov for GitFlow-lignende struktur, men bør fortsatt bruke branch policies for byggvalidering, obligatorisk kodegjennomgang og beskyttelse av hovedgrenene.
Branch policies i Azure Repos er et praktisk styringspunkt fordi de flytter kvalitet tidligere i arbeidsflyten. En pull request kan kreve vellykket bygg, minst én godkjenning, kobling til work item og oppdatert branch før sammenslåing. Det gir en tydelig kobling mellom samarbeidsmodell og teknisk kontroll, og det er et område AZ-400-kandidater bør kunne forklare med konkrete eksempler.
Når koden er slått sammen, bør pipeline-stegene være repeterbare og lesbare. YAML gir fordelen av at pipeline-definisjonen versjoneres sammen med applikasjonen, kan vurderes i pull requests og kan gjenbrukes gjennom maler. Klassiske pipelines kan fortsatt finnes i eldre miljøer, men YAML er vanligvis et bedre valg for team som vil ha sporbarhet, kodegjennomgang og konsistent praksis på tvers av repositories.
Eksempelet under viser et enkelt mønster for bygg, pakking og utrulling til et Azure DevOps Environment. Det bruker artefakter, cache og Key Vault-integrasjon, mens selve godkjenningen håndteres på miljøet i Azure DevOps i stedet for å hardkode manuelle steg i YAML-filen.
Example — YAML-pipeline med bygg, artefakt og kontrollert utrulling
trigger:
branches:
include:
- main
pool:
vmImage: ubuntu-latest
variables:
buildConfiguration: Release
stages:
- stage: Build
jobs:
- job: BuildAndTest
steps:
- task: Cache@2
inputs:
key: 'nuget | "$(Agent.OS)" | **/packages.lock.json'
restoreKeys: 'nuget | "$(Agent.OS)"'
path: ~/.nuget/packages
- task: DotNetCoreCLI@2
inputs:
command: restore
projects: src/WebApp/WebApp.csproj
- task: DotNetCoreCLI@2
inputs:
command: test
projects: tests/WebApp.Tests/WebApp.Tests.csproj
arguments: '--configuration $(buildConfiguration)'
- task: DotNetCoreCLI@2
inputs:
command: publish
publishWebProjects: false
projects: src/WebApp/WebApp.csproj
arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
- publish: $(Build.ArtifactStagingDirectory)
artifact: webapp
- stage: Deploy
dependsOn: Build
jobs:
- deployment: DeployWebApp
environment: prod-web
strategy:
runOnce:
deploy:
steps:
- task: AzureKeyVault@2
inputs:
azureSubscription: sc-az-prod-webapp
KeyVaultName: kv-prod-webapp
SecretsFilter: AppConfigConnection
- download: current
artifact: webapp
- task: AzureWebApp@1
inputs:
azureSubscription: sc-az-prod-webapp
appType: webAppLinux
appName: app-prod-web
package: $(Pipeline.Workspace)/webapp/**/*.zip
Det viktige læringspunktet er ikke selve syntaksen, men ansvarsdelingen. Pipeline-filen beskriver bygg, test, artefakt og utrulling; Azure DevOps Environment kan håndtere approvals og checks; service connection bør ha minst mulige rettigheter; og hemmeligheter bør hentes fra Key Vault. Etter et slikt eksempel bør kandidaten kunne forklare hvor godkjenninger, tilgangsstyring, hemmeligheter og sporbarhet ligger, ikke bare få YAML til å kjøre.
DevSecOps og governance i Azure DevOps
Sikkerhet i en DevOps-pipeline handler om å redusere risiko uten å gjøre leveranseprosessen treg og uforutsigbar. I praksis betyr det at sikkerhetskontroller må automatiseres, dokumenteres og plasseres der de gir mest verdi. En statisk analyse tidlig i byggesteget har en annen funksjon enn en miljøgodkjenning før produksjon, og begge bør ha en tydelig eier.
Service connections er et vanlig svakt punkt. De bør ikke gis brede rettigheter fordi det er enklest under oppsett. En bedre praksis er å bruke egne service connections per miljø eller arbeidsbelastning, begrense tilgang med minst privilegium og vurdere managed identity der tjenesten og arkitekturen støtter det. Tilgang til produksjonsmiljøer bør i tillegg knyttes til Environments med approvals og checks, slik at utrulling kan kontrolleres uten at passord eller nøkler deles mellom personer.
Hemmeligheter bør ikke ligge som åpne variabler i pipeline-definisjonen. Variable groups kan være nyttige for ikke-sensitive konfigurasjonsverdier, men hemmeligheter bør som hovedregel hentes fra Azure Key Vault eller en tilsvarende hemmelighetsforvalter. Dette gjør rotasjon, revisjon og tilgangskontroll enklere, og det reduserer risikoen for at sensitive verdier havner i logger, YAML-historikk eller lokale utviklermiljøer.
Artefakthåndtering er en annen del av governance som ofte undervurderes. Et bygg bør produsere et identifiserbart artefakt som flyttes gjennom miljøene, i stedet for at hvert miljø bygger på nytt fra en branch. Det gir bedre sporbarhet, enklere feilsøking og tydeligere revisjonsspor når samme pakke er testet og deretter promotert videre.
Infrastruktur som kode, policy og utrullingsmodeller
AZ-400 forventer forståelse av Infrastructure as Code fordi moderne DevOps ikke stopper ved applikasjonskoden. Azure Resource Manager, Bicep og Terraform kan alle inngå i leveransemodellen, men kandidatens viktigste ferdighet er å forstå hvordan infrastrukturendringer valideres, godkjennes og rulles ut på en kontrollert måte.
I produksjonsmiljøer er Terraform remote state i Azure Storage et praktisk eksempel. State-filen må beskyttes med tilgangskontroll, versjonering og låsing, ellers kan parallelle endringer skape uforutsigbar drift. Moduler bør bygges rundt stabile plattformmønstre, som nettverk, App Service, AKS eller observabilitet, slik at team ikke kopierer store kodeblokker mellom prosjekter. Azure Policy eller annen policy-as-code bør brukes for å hindre konfigurasjonsdrift, for eksempel åpne lagringskontoer, manglende tags eller ressurser uten godkjente regioner.
Utrullingsmodeller bør velges etter risiko og brukerimpact. Blågrønn utrulling passer når to parallelle miljøer kan kjøres samtidig og trafikken kan flyttes kontrollert. Kanariutrulling passer når en ny versjon skal eksponeres gradvis for en liten del av trafikken før bred utrulling. I Azure Pipelines kan deployment jobs og Environments brukes sammen med App Service eller AKS for å styre slike mønstre med approvals, checks og tydelig miljøhistorikk.
Feature flags er ofte det som gjør hyppig utrulling realistisk. Ved å bruke Azure App Configuration eller en tilsvarende løsning kan funksjonalitet aktiveres gradvis uten full redeploy. Det gir raskere tilbaketrekking ved feil, og det skiller teknisk utrulling fra forretningsmessig lansering. For AZ-400 er dette et godt eksempel på forskjellen mellom å kunne deploye kode og å kunne drive trygg endringsledelse i produksjon.
Måling, drift og læringssløyfer
DevOps blir svakt hvis pipeline-arbeidet slutter ved produksjonsutrulling. Driftssignaler må tilbake til teamets prioriteringer, ellers blir forbedringsarbeidet basert på antakelser. DORA-metrikker som deployment frequency, lead time for changes, change failure rate og mean time to recovery brukes ofte for å forstå flyt og stabilitet, men de bør tolkes sammen med hendelser, applikasjonslogger og brukeropplevelse.
Application Insights og Log Analytics kan gi telemetri fra applikasjon og plattform, mens Azure Boards kan brukes til å gjøre funnene om til arbeid som prioriteres. Hvis en utrulling gir økt feilrate, bør teamet kunne koble observasjonen til en release, en commit, et arbeidselement og en korrigerende oppgave. Denne læringssløyfen er mer verdifull enn et dashboard som ingen bruker til beslutninger.
Rollback bør også planlegges før feilen oppstår. Noen endringer kan rulles tilbake ved å re-deploye forrige artefakt; andre krever databasekompatibilitet, feature flags eller fremoverrettet feilretting. DevOps-ingeniører som forbereder seg til AZ-400 bør derfor øve på scenarioer der riktig svar avhenger av arkitektur, dataendringer og risiko, ikke bare av hvilken knapp som starter en release.
Slik forbereder DevOps-ingeniører seg effektivt til AZ-400
Effektiv forberedelse starter med å kartlegge egen praksis mot ferdighetene Microsoft beskriver. En kandidat som allerede bygger pipelines, men sjelden arbeider med sikkerhet eller observabilitet, bør bruke mest tid på DevSecOps, environment checks, logging og måling. En utvikler med sterk Git-erfaring, men lite produksjonsansvar, bør øve på deployment strategies, rollback, Key Vault, service connections og artefaktpromotering.
Praktisk øving bør ha et lite, men realistisk scenario: ett repository, én applikasjon, automatiserte tester, et IaC-oppsett, et testmiljø og et produksjonslignende miljø med godkjenning. Deretter kan kandidaten legge til branch policies, pakkehåndtering, sikkerhetsskanning, Key Vault-integrasjon og observabilitet. Dette gir bedre læring enn å lese isolerte dokumentasjonssider uten å se hvordan delene påvirker hverandre.
Strukturert opplæring kan være nyttig når kandidaten trenger en tydelig progresjon gjennom eksamensområdene. Et instruktørledet AZ-400-kurs kan gi ramme rundt stoffet, men bør kombineres med egen bygging i Azure DevOps. En læringsplattform som Readynez365 kan også hjelpe med å samle ressurser og følge progresjon, særlig når kandidaten må prioritere svake områder før eksamen.
Det er også verdt å plassere AZ-400 i en større Microsoft-kontekst. Noen går videre mot Azure DevOps Engineer Expert, mens andre kombinerer DevOps-kompetansen med arkitekturforståelse gjennom Azure Solutions Architect Expert. Kandidater som vurderer flere retninger bør bruke Microsoft Credentials til å sjekke gjeldende krav og sertifiseringsrelasjoner.
Vanlige spørsmål om AZ-400 og Azure DevOps
Hva er hovedfunksjonene i Azure DevOps?
Azure DevOps omfatter Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans og Azure Artifacts. Tjenestene støtter planlegging, kildekontroll, bygg, test, utrulling og pakkehåndtering, og verdien øker når de kobles sammen med sporbarhet fra arbeidselement til produksjonsendring.
Hvor lang tid tar det å forberede seg til AZ-400?
Forberedelsestiden varierer med erfaring. En kandidat som allerede arbeider daglig med Azure Pipelines, Git og produksjonsutrulling vil ofte trenge mest målrettet repetisjon, mens en kandidat uten praktisk Azure DevOps-erfaring bør sette av mer tid til labarbeid og scenarioøving.
Hvilke ferdigheter bør prioriteres før eksamen?
Kandidater bør prioritere YAML-baserte pipelines, branch policies, deployment strategies, service connections, Key Vault, artefakter, IaC, observabilitet og kontinuerlig forbedring. Det er også viktig å kunne forklare hvorfor en løsning passer i et gitt scenario, ikke bare kjenne navnet på tjenesten.
Hvordan kan AZ-400 støtte karriereutvikling?
AZ-400 kan validere praktiske DevOps-ferdigheter for roller som DevOps-ingeniør, SRE, utvikler med plattformansvar og release manager. Sertifiseringen er mest verdifull når den støttes av erfaring med reelle pipelines, produksjonsmiljøer, sikkerhetskontroller og måling av leveranseflyt.
Hvor finner kandidater oppdatert informasjon om eksamen?
Microsoft oppdaterer sertifiseringer og eksamenssider over tid. Kandidater bør derfor bruke den offisielle AZ-400-siden og Microsoft Credentials for gjeldende informasjon om eksamensmål, sertifiseringskrav og eventuelle endringer.
Fra eksamensmål til bedre leveransepraksis
AZ-400 gir mest verdi når forberedelsen knyttes til faktisk arbeid i Azure DevOps. Kandidaten bør kunne forklare hvordan en endring beveger seg fra backlog til kode, pull request, bygg, artefakt, sikkerhetskontroll, utrulling, observabilitet og læring. Det er denne sammenhengen som skiller overflatisk verktøykunnskap fra robust DevOps-praksis.
En praktisk neste handling er å bygge eller forbedre én pipeline med de samme prinsippene eksamenen måler: YAML som kode, branch policies, sikre service connections, Key Vault, miljøgodkjenninger, artefakter, IaC og driftsdata tilbake til backloggen. Readynez kan brukes som støtte for strukturert AZ-400-forberedelse, men den avgjørende læringen kommer når kandidatens egne pipelines tåler både revisjon, feilretting og produksjonsendringer.
