AZ-400 vs praktisk DevOps-arbeid: veien til bestått

AZ-400 er en eksamen der praktisk DevOps-arbeid oversettes til korte scenarioer som komprimerer mange valg, avveininger og driftskonsekvenser. Kandidaten må derfor kunne forklare hvorfor en løsning er riktig, ikke bare kjenne igjen en YAML-fil eller et azure-administrator-exam" data-autoinject="link_injection">Azure DevOps-skjermbilde.

Sist oppdatert: 22. juli 2026. Microsoft endrer eksamensmål og sertifiseringskrav jevnlig, så den offisielle siden for Exam AZ-400: Designing and Implementing Microsoft DevOps Solutions bør brukes som primærkilde før eksamen bookes. Denne artikkelen forklarer hvordan innholdet kan omsettes til praktisk trening, med særlig vekt på kildekontroll, CI/CD, sikkerhet, etterlevelse og instrumentering.

AZ-400 er en ekspertrettet DevOps-eksamen

AZ-400 er ikke en nybegynnerinngang til Azure eller DevOps. Eksamenen er knyttet til Microsoft Certified: DevOps Engineer Expert, og den forutsetter at kandidaten forstår både utvikling, drift, skyplattform og teamprosesser. Det betyr ikke at alle må ha lang fartstid i en formell DevOps-rolle, men ren teorilesing er sjelden nok.

En sterk kandidat kan se sammenhengen mellom et depot, en forgreiningsstrategi, en pipeline, en identitetsmodell, en utrulling og en observability-løsning. Hvis en build feiler, bør kandidaten kunne vurdere om problemet ligger i avhengigheter, testmiljø, tilgang til hemmeligheter, tjenestetilkoblinger eller selve applikasjonskoden. Den typen resonnering er mer verdifull enn å memorere enkeltkommandoer.

Microsoft peker ofte på erfaring med Azure-administrasjon eller Azure-utvikling som et godt grunnlag. Kandidater som allerede har arbeidet mot Azure Developer Associate eller Azure Administrator Associate, vil vanligvis kjenne igjen mange av byggesteinene. AZ-400 krever likevel en annen måte å tenke på: leveranseflyten, sikkerhetsstyringen og driften må henge sammen.

Hva eksamenen faktisk måler

Den offisielle studieveiledningen for AZ-400 bør være utgangspunktet for all planlegging. Den beskriver ferdigheter som kildekontroll, bygg- og release-pipelines, sikkerhet og etterlevelse, samt instrumentering. Disse områdene opptrer sjelden isolert i praksis, og eksamensspørsmålene kan derfor kombinere flere temaer i samme scenario.

Kildekontroll handler for eksempel ikke bare om Git-kommandoer. Kandidaten må forstå hvordan trunk-basert utvikling, feature branches, pull requests og branch policies påvirker kvalitet, hastighet og risiko. Et depot med god struktur, tydelige review-regler og sporbarhet mellom arbeidselementer og commits gir et annet operasjonelt utgangspunkt enn et depot der alle endringer går rett til hovedgrenen.

CI/CD-delen må også leses bredt. Det er naturlig å trene på YAML, men mange stryker ikke fordi syntaksen er ukjent. Vanskeligheten ligger ofte i governance og drift: hvem eller hva får deploye, hvordan håndteres hemmeligheter, hvilke miljøer krever godkjenning, hvordan rulles en feil tilbake, og hvilke logger eller måledata brukes for å avgjøre om utrullingen er vellykket.

GitHub Actions vs Azure DevOps i forberedelsene

AZ-400 kan berøre både GitHub og Azure DevOps. Derfor er det risikabelt å forberede seg utelukkende i det verktøyet som tilfeldigvis brukes mest på arbeidsplassen. Samtidig er det heller ikke effektivt å prøve å bli like dyptgående i alt. En praktisk beslutningsramme er å velge hovedplattform etter det teamet faktisk bruker, og deretter bygge de viktigste ferdighetene på nytt i den andre plattformen.

Hvis arbeidsplassen bruker Azure DevOps, bør kandidaten likevel kunne forklare hvordan GitHub Actions håndterer workflows, environments, secrets og approvals. Hvis arbeidsplassen bruker GitHub, bør kandidaten fortsatt forstå Azure Pipelines, service connections, variable groups, environments og release-gates. Målet er ikke å pugge to brukergrensesnitt, men å kjenne igjen de samme DevOps-prinsippene når terminologien og konfigurasjonsmodellen endres.

En fireukers praksisplan som ligner et virkelig prosjekt

Den mest effektive treningen er ofte å bygge ett end-to-end scenario i stedet for å hoppe mellom isolerte øvelser. Scenarioet kan være en enkel webapplikasjon på Azure App Service eller AKS, definert med Bicep eller Terraform, bygget fra Git, testet automatisk, skannet for sikkerhetsproblemer, distribuert via pipeline og overvåket med Azure Monitor og Log Analytics. Det gir kandidaten en konkret kontekst for alle valg som ellers blir abstrakte.

Uke én: Opprett depot, velg forgreiningsstrategi, sett branch policies og koble arbeidselementer til commits og pull requests.

Uke to: Bygg CI for applikasjonen med enhetstester, avhengighetscache og publisering av artefakter i både GitHub Actions og Azure Pipelines.

Uke tre: Legg til infrastruktur som kode, hemmelighetshåndtering, miljøer, godkjenningsporter og utrulling til test og produksjonslignende miljø.

Uke fire: Innfør sikkerhetsskanning, rollback-strategi, varsler, dashboards og feilsøking basert på logger og måledata.

Planen fungerer best når kandidaten dokumenterer valgene underveis. Hvorfor ble canary valgt fremfor blue-green, eller omvendt? Hvorfor ligger hemmeligheten i Key Vault og ikke i pipeline-variabler? Hvilke logger brukes for å skille mellom applikasjonsfeil, konfigurasjonsfeil og infrastrukturfeil? Slike svar bygger den typen resonnering som AZ-400 ofte tester.

Eksempelet under viser en liten GitHub Actions-workflow som bygger en .NET-applikasjon, kjører tester og gjør en utrulling til et miljø som kan ha godkjenning konfigurert i GitHub. Den er ikke ment som en komplett produksjonsmal, men som et utgangspunkt for å forstå koblingen mellom bygg, test, identitet og miljø.

Eksempel — GitHub Actions med miljøstyrt utrulling

name: build-test-deploy

on:
  pull_request:
    branches: [ main ]
  push:
    branches: [ main ]

permissions:
  id-token: write
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'
      - run: dotnet restore src/Contoso.Web/Contoso.Web.csproj
      - run: dotnet test src/Contoso.Web.Tests/Contoso.Web.Tests.csproj --configuration Release
      - run: dotnet publish src/Contoso.Web/Contoso.Web.csproj --configuration Release --output ./publish
      - uses: actions/upload-artifact@v4
        with:
          name: contoso-web
          path: ./publish

  deploy-test:
    needs: build
    runs-on: ubuntu-latest
    environment: test
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: contoso-web
          path: ./publish
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - uses: azure/webapps-deploy@v3
        with:
          app-name: app-contoso-test
          package: ./publish

Workflowen bruker OpenID Connect-støttet innlogging i stedet for et passord i klartekst. I en lab bør kandidaten kontrollere at miljøet har riktige godkjenninger, at hemmelighetene ikke eksponeres i logger, og at utrullingen kan feilsøkes hvis App Service ikke starter. Den samme applikasjonen bør deretter bygges i Azure Pipelines for å se hvordan service connections, stages og environments løser tilsvarende behov.

Fallgruvene som ikke ser vanskelige ut på papiret

Identitet og tilgang er en vanlig kilde til feil i både prosjekter og eksamensscenarioer. En pipeline bør få akkurat den tilgangen den trenger, og ikke mer. Kandidaten bør forstå forskjellen mellom en bredt tildelt tjenesteidentitet, en federert identitet for GitHub Actions, en service connection i Azure DevOps og en administrert identitet brukt av selve applikasjonen.

Hemmelighetshåndtering er et annet område der en løsning kan se riktig ut helt til den driftes. Secrets i GitHub eller variabler i Azure DevOps kan være nyttige, men sensitive verdier bør ofte forvaltes i Azure Key Vault med tydelige tilgangspolicyer eller rollebasert tilgangskontroll. Eksamenen kan derfor teste både hvor hemmeligheten bør lagres, hvordan pipeline får tilgang, og hvordan eksponering i logger unngås.

Miljøstrategi skaper også flere praktiske avveininger enn mange forventer. Et testmiljø uten realistiske konfigurasjoner gir svak validering, mens et produksjonsnært miljø uten godkjenningsporter og sporbarhet øker risiko. Kandidaten bør kunne forklare når man bruker manuell godkjenning, automatiserte kvalitetsporter, deployment slots, canary, blue-green eller ringbasert utrulling.

Testflakiness blir ofte undervurdert. En pipeline som feiler tilfeldig, lærer teamet å ignorere røde bygg, og da mister CI/CD mye av verdien. I AZ-400-sammenheng bør kandidaten kunne skille mellom en feil som krever kodeendring, en ustabil integrasjonstest, et manglende testdataoppsett eller en tidsavhengig feil i miljøet.

Observability er en del av leveransen

AZ-400 handler ikke bare om å få kode ut i et miljø. En DevOps-løsning må også gjøre det mulig å se om leveransen fungerer. Instrumentering, logging, varsling og dashboards er derfor ikke pynt rundt pipelinen; de avgjør om teamet kan oppdage feil tidlig, tolke konsekvensene og reagere før brukerne merker store problemer.

En god lab bør derfor avsluttes med feilsøking. Kandidaten kan med vilje introdusere en konfigurasjonsfeil, en feil connection string eller en mislykket health check, og deretter bruke Azure Monitor, Application Insights eller Log Analytics til å finne årsaken. Denne øvelsen knytter eksamensmålene om instrumentering til det som faktisk skjer etter deploy.

Ressurser som støtter læringen

Microsoft Learn bør brukes som den autoritative kilden for eksamensmål, produktendringer og øvingsressurser. I tillegg kan Microsoft Tech Community og Microsoft Learn Community være nyttige når kandidaten trenger diskusjoner om konkrete produktvalg, endringer i verktøy eller vanlige tolkninger av dokumentasjonen.

Strukturert opplæring kan være nyttig når kandidaten har praktisk erfaring, men mangler en ryddig vei gjennom eksamensmålene. Et instruktørledet AZ-400-løp hos Readynez kan for eksempel gi ramme, progresjon og labtid, men det bør fortsatt kombineres med egen bygging av pipelines og feilsøking i et reelt Azure-miljø.

Selvsjekk før eksamen bookes

En kandidat som er klar for AZ-400, bør kunne svare presist på praktiske spørsmål uten å slå opp hvert begrep. Kan løsningen forklare hvorfor et team velger trunk-basert utvikling fremfor langlivede feature branches? Kan kandidaten vise hvordan hemmeligheter beskyttes gjennom hele leveranseflyten? Kan en feilet utrulling analyseres gjennom logger, metrics og pipeline-historikk?

• Forklar forskjellen mellom blue-green, canary og tradisjonell rolling deployment med risiko, rollback og observability.
• Bygg samme enkle pipeline i GitHub Actions og Azure DevOps, og pek ut forskjeller i secrets, miljøer, godkjenninger og identitet.
• Vis hvordan en applikasjon får hemmeligheter fra Key Vault uten at verdiene skrives til logger eller lagres i depotet.
• Feilsøk en mislykket utrulling ved å bruke pipeline-logger, applikasjonslogger og relevante måledata fra Azure.

Hvis disse punktene fortsatt føles uklare, er det bedre å bruke noen ekstra dager i lab enn å booke eksamen for tidlig. Det er særlig viktig for kandidater som har lest mye, men ikke har satt sammen kildekontroll, pipeline, sikkerhet og drift i samme scenario.

En realistisk vei til bestått

AZ-400 belønner kandidater som forstår DevOps som en sammenhengende leveransemodell. Kunnskap om YAML, Git og Azure er nødvendig, men eksamenen går lenger: den spør hvordan teamet styrer kvalitet, sikkerhet, tilgang, utrulling og læring fra produksjon.

Den mest praktiske veien videre er å bruke Microsofts offisielle eksamensside som kart, bygge ett end-to-end scenario som treningsarena og bruke fellesskap eller strukturert undervisning når hullene blir tydelige. Readynez kan støtte den strukturen for kandidater som ønsker et styrt AZ-400-forløp, men selve ferdigheten bygges først når kandidaten designer, implementerer, bryter og reparerer en DevOps-løsning fra kode til drift.

FAQ

Er AZ-400 en god første Microsoft-sertifisering?

AZ-400 er vanligvis ikke det beste første steget hvis kandidaten mangler erfaring med Azure, utvikling eller drift. Eksamenen ligger på ekspertnivå og passer bedre når man allerede forstår grunnleggende Azure-ressurser, Git, CI/CD og driftsprinsipper. For mange er Azure Developer Associate eller Azure Administrator Associate et mer naturlig grunnlag.

Må man kunne både GitHub Actions og Azure DevOps?

Man bør kunne prinsippene og de viktigste forskjellene i begge. Det er fornuftig å velge én hovedplattform for dyp trening, men kandidaten bør bygge et mindre scenario i den andre plattformen for å forstå YAML-struktur, secrets, miljøer, approvals og identitet.

Hva er den viktigste feilen å unngå i forberedelsene?

Den vanligste feilen er å lese eksamensmålene som separate temaer. I praksis henger kildekontroll, pipelines, sikkerhet, etterlevelse og observability sammen. En kandidat som bare øver på syntaks, men ikke på tilgangsstyring, Key Vault, miljøstrategi og feilsøking, får et svakt grunnlag.

Hvor lang tid bør man bruke på å forberede seg?

Det avhenger av erfaringen kandidaten allerede har. En erfaren Azure- og DevOps-praktiker kan ofte strukturere forberedelsene rundt hull i kunnskapen, mens en kandidat med mindre praktisk erfaring bør bruke mer tid på labber. En fireukers plan med jevn praktisk trening er et realistisk minimum for mange som allerede har grunnlaget på plass.

Hvordan vet man at man er klar for AZ-400?

Man er nær eksamensklar når man kan designe og forklare en ende-til-ende leveranseflyt: depot, forgreining, pull requests, CI, tester, sikkerhetsskanning, hemmelighetshåndtering, utrulling, godkjenninger, rollback og monitorering. Hvis man også kan feilsøke en mislykket deploy med logger og metrics, er grunnlaget betydelig sterkere.