Benefits of AZ-400: Styrk dine DevOps-kompetencer i praksis

• AZ-400 er relevant for Azure-professionelle, der vil designe og implementere DevOps-processer på tværs af kode, pipelines, sikkerhed, drift og feedback.
• Certificeringsvejen kræver enten AZ-104 eller AZ-204 som forudsætning, før AZ-400 giver credentialen Microsoft Certified: DevOps Engineer Expert.
• Den stærkeste forberedelse kombinerer Microsoft Learn, praktisk pipeline-arbejde, målinger, governance og øveeksamener.

AZ-400 er en eksamen i at omsætte DevOps-praksis til driftssikre arbejdsgange i Azure-miljøer. Den tester, om kandidaten kan forbinde kildekontrol, CI/CD, sikkerhed, compliance, observability, release governance og Site Reliability Engineering til en arbejdsform, der kan fungere i en rigtig organisation.

Denne artikel er opdateret med fokus på 2026-relevant forberedelse. Microsoft kan ændre eksamensformat, skills measured, varighed, sprog og politikker, så den officielle Microsoft Learn-side for AZ-400 bør altid kontrolleres umiddelbart før booking. Det samme gælder forudsætningsvejene AZ-104 og AZ-204, hvor rollebeskrivelsen og målte færdigheder afgør, hvilken vej der passer bedst til kandidatens baggrund.

Hvad AZ-400 måler i praksis

AZ-400, Designing and Implementing Microsoft DevOps Solutions, er rettet mod kandidater, der arbejder med både udvikling og drift i Azure-miljøer. Rollen ligger typisk mellem udviklere, platformsteams, sikkerhedsfunktioner og operations, og derfor kræver eksamen mere end kendskab til et enkelt værktøj.

I praksis betyder det, at en kandidat skal kunne designe en leverancekæde fra commit til produktion. Koden skal versionsstyres, builds skal være reproducerbare, tests skal automatiseres, secrets skal håndteres sikkert, og deployments skal kunne kontrolleres med approvals, environments og rollback-tankegang. Når løsningen er i drift, skal telemetry fra Azure Monitor og Log Analytics bruges til at forstå fejl, performance og brugeroplevelse.

DevOps-markedet og cloud-adoption omtales ofte med store væksttal, eksempelvis i analyser fra IMARC Group og cloudmarkedsdækning hos The Register. Sådanne tal bør læses som baggrund, ikke som eksamensgrundlag. For AZ-400 er det vigtigere at kunne omsætte DevOps-principper til robuste processer i Microsoft Azure, også når virksomheden samtidig bruger AWS, Google Cloud eller andre platforme.

Azure DevOps, GitHub og værktøjsvalget i eksamen

Azure DevOps er en Microsoft-tjeneste til boards, repositories, pipelines, test plans og artifacts. Den optræder ofte i AZ-400-forberedelse, fordi Azure Pipelines, environments, service connections og release governance illustrerer mange af de færdigheder, eksamen måler.

Det betyder dog ikke, at kandidaten bør lære Azure DevOps isoleret fra resten af økosystemet. Mange organisationer kombinerer Azure DevOps med GitHub, bruger Jenkins i ældre CI-miljøer eller integrerer kodekvalitet med SonarQube. Google Trends-sammenligninger som Azure DevOps versus AWS DevOps kan sige noget om søgeadfærd, men de siger ikke, hvilke færdigheder en DevOps Engineer skal beherske.

En praktisk eksamensstrategi er derfor at lære begreberne før værktøjsdetaljerne. Hvis kandidaten forstår branch policies, pull request reviews, artifact versionering, deployment gates, secret management og telemetry, bliver det lettere at genkende samme mønster på tværs af Azure Pipelines, GitHub Actions og tredjepartsværktøjer. Den fejl, mange gør, er at øve sig på klikveje i portalen uden at kunne forklare, hvorfor en approval, en service connection eller en Key Vault-integration er nødvendig.

Vælg den rigtige forudsætning: AZ-104 eller AZ-204

For at opnå Microsoft Certified: DevOps Engineer Expert skal kandidaten have enten Azure Administrator Associate via AZ-104 eller Azure Developer Associate via AZ-204 og derefter bestå AZ-400. Valget bør ikke kun handle om, hvilken eksamen der virker lettest. Det bør tage udgangspunkt i den måde kandidaten allerede arbejder med Azure på.

En operations-profil bør især være opmærksom på, at AZ-400 kræver komfort med repositories, branching, YAML og testautomatisering. En udvikler bør omvendt bruge tid på Azure governance, identities, Key Vault, monitoring og release approvals. I virksomheder med skalerede builds bliver Service Connections, RBAC og artifact/cache-strategier ofte de steder, hvor DevOps-design møder driftens realiteter.

Opdaterede eksamensfakta og hvad der bør verificeres

Microsoft offentliggør de gældende eksamensoplysninger på Microsoft Learn, herunder skills measured, registreringsmuligheder, sprog, pris, eksamensvarighed og eventuelle ændringer. Den mest stabile regel er, at Microsoft-certificeringseksamener typisk vurderes på en skaleret score, hvor 700 er den angivne beståelsesgrænse på en skala til 1000. Det betyder ikke, at 70 procent af spørgsmålene nødvendigvis skal være korrekte, fordi scoringen kan vægtes.

Gamle artikler nævner ofte faste tal for antal spørgsmål eller eksakt varighed. Det er risikabelt at bruge sådanne oplysninger som planlægningsgrundlag, fordi formatet kan ændre sig, og enkelte spørgsmålstyper kan variere. Kandidaten bør i stedet bruge Microsoft Learn som primær kilde og se skills measured-dokumentet som den egentlige pensumliste.

AZ-400-spørgsmål tester ofte beslutninger snarere end ren syntaks. En kandidat kan eksempelvis blive bedt om at vælge en sikker metode til at hente secrets i en pipeline, designe en deployment-strategi med approvals eller identificere, hvilke målinger der hjælper et team med at forbedre release-stabilitet. Derfor bør forberedelsen kombinere dokumentation med praktiske øvelser.

Hvordan AZ-400-domænerne ser ud i en rigtig pipeline

Et godt studieprojekt er en lille applikation, der bygges og deployes gennem en multi-stage pipeline. Projektet behøver ikke være stort. Det skal blot være realistisk nok til at indeholde kildekontrol, build, test, artifact, deployment til et testmiljø, en manuel approval før produktion, sikker secret-håndtering og basale driftsmålinger.

I første fase bør repositoryet have en branching-strategi, branch policies og pull request-validering. I anden fase bygger pipelinen applikationen, kører tests og publicerer et artifact. I tredje fase deployes til et Azure-miljø, hvor secrets hentes via Azure Key Vault i stedet for at ligge som plain text i YAML. I fjerde fase bruges approvals på et environment, så en release ikke går i produktion uden kontrol. Efter deployment bør Azure Monitor og Log Analytics give signaler om fejl, latency og tilgængelighed.

Dette er den type sammenhæng, der gør AZ-400 mere praktisk end mange forventer. Instrumentering handler ikke kun om dashboards. SRE handler ikke kun om oppetid. Sikkerhed handler ikke kun om scanning. De tre områder hænger sammen, fordi et team skal kunne opdage fejl hurtigt, begrænse risikoen ved ændringer og lære af incidents uden at stoppe leverancehastigheden.

Følgende eksempel viser en enkel YAML-struktur, der kan bruges til at tænke i stages, test og miljøgodkendelser. Den er ikke en fuld produktionspipeline, men den illustrerer de byggesten, kandidaten bør kunne forklare til AZ-400.

Example — multi-stage Azure Pipelines med test og miljø

trigger:
  branches:
    include:
      - main

stages:
- stage: Build
  jobs:
  - job: BuildAndTest
    pool:
      vmImage: ubuntu-latest
    steps:
    - task: UseDotNet@2
      inputs:
        packageType: sdk
        version: 8.x
    - script: dotnet test src/Contoso.Web.Tests/Contoso.Web.Tests.csproj --configuration Release
      displayName: Run automated tests
    - publish: $(Build.SourcesDirectory)/src
      artifact: application

- stage: Deploy_Test
  dependsOn: Build
  jobs:
  - deployment: DeployToTest
    environment: contoso-test
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: application
          - script: echo "Deploy application artifact to test environment"
            displayName: Deploy to test

Eksemplet viser, at et deployment job kan knyttes til et environment. I Azure DevOps kan environments bruges sammen med approvals and checks, så governance flyttes ind i leveranceflowet i stedet for at ligge som en uformel besked i en chatkanal. Til eksamen er pointen ikke at huske hvert felt i YAML, men at forstå, hvilken kontrol hvert led giver.

Secrets bør håndteres med samme disciplin. Azure Pipelines kan integrere med Azure Key Vault, så pipeline-variabler kan hentes sikkert, og adgang kan styres med identiteter og RBAC. En almindelig fejl i forberedelsen er at lære variable groups uden at forstå, hvem der må læse hemmelighederne, hvordan service connection er sikret, og hvordan adgangen auditeres.

Example — hent secrets fra Azure Key Vault i en pipeline

variables:
- group: contoso-shared-settings

steps:
- task: AzureKeyVault@2
  inputs:
    azureSubscription: contoso-platform-service-connection
    KeyVaultName: kv-contoso-prod
    SecretsFilter: app-insights-connection-string
    RunAsPreJob: true

- script: dotnet publish src/Contoso.Web/Contoso.Web.csproj --configuration Release
  displayName: Build application package

Her henter pipelinen en navngivet secret via en service connection, før build- eller deployment-trin bruger den. Det vigtigste læringspunkt er rettighedsmodellen: service connection, Key Vault access policy eller RBAC, pipeline permissions og audit logs skal passe sammen. I større organisationer er det ofte her, implementeringen bliver sværere end selve YAML-syntaksen.

En realistisk studieplan frem mod AZ-400

En effektiv studieplan bør veksle mellem læsning, hands-on arbejde og kontrol af forståelse. Kandidaten bør begynde med Microsoft Learn og skills measured for AZ-400, men hurtigt omsætte hvert område til en lille løsning. Hvis studiet kun består af videoer og noter, bliver governance, telemetry og incident response for abstrakt.

I de første uger bør fokus ligge på certificeringsvejen, grundbegreberne og værktøjskæden. Kandidaten bør kontrollere, om AZ-104 eller AZ-204 allerede er opfyldt, og derefter gennemgå de officielle AZ-400-domæner. Samtidig kan et lille repository oprettes med en simpel applikation, testprojekt og en indledende YAML-pipeline.

Næste fase bør handle om CI, artifacts og afhængigheder. Her giver det mening at bygge og teste ved hvert commit, gemme artifacts, introducere kodekvalitetskontrol og arbejde med branch policies. Kandidaten bør ikke nøjes med at se, at pipelinen bliver grøn. Der bør også eksperimenteres med fejlende tests, manglende dependencies og konflikter i pull requests, fordi disse situationer ligner de beslutninger, der optræder i scenariebaserede spørgsmål.

Derefter bør studiet flytte sig til delivery, environments, approvals og sikkerhed. Det er her, mange undervurderer AZ-400. En pipeline uden approvals, rollback-overvejelse, secret governance og adgangsstyring ligner en demo mere end et DevOps-design. Kandidaten bør derfor oprette mindst ét testmiljø og ét produktionslignende miljø, konfigurere en approval og sikre secrets med Key Vault i stedet for variable values i klartekst.

Den sidste fase bør fokusere på observability, SRE og eksamenstræning. Azure Monitor, Log Analytics og basale KQL-forespørgsler bør bruges til at finde fejl og forstå driftssignaler. Samtidig bør kandidaten tage øveeksamener og markere spørgsmål, hvor begrundelsen er uklar. Hvis de svage områder samler sig omkring KQL, environments, approvals eller sikker secret-håndtering, bør de prioriteres højere end endnu en gennemgang af simple build tasks.

Et struktureret kursus kan være nyttigt, når tiden er knap, eller når kandidaten har brug for at få koblet Microsofts eksamensmål til praktiske øvelser. Readynez omtaler AZ-400 i en Microsoft DevOps Engineer-sammenhæng på AZ-400-kurssiden, men uanset læringsform bør kandidaten selv kunne bygge, fejlfinde og forklare en pipeline fra commit til drift.

Typiske faldgruber i AZ-400-forberedelsen

Den første faldgrube er at forberede sig værktøjs-first. Kandidaten kan godt kende Azure Pipelines-menuer uden at forstå, hvordan branch policies, environments, approvals, service connections og Key Vault tilsammen reducerer risiko. AZ-400 belønner den sammenhængende beslutning, ikke kun navnet på en task.

Den anden faldgrube er at springe fra classic releases til YAML uden migreringsplan. Mange virksomheder har stadig ældre release pipelines, manuelle gates eller delvist dokumenterede deployment-processer. En praktisk DevOps Engineer bør kunne oversætte disse til YAML gradvist, bevare sporbarhed og undgå at miste governance under migreringen.

Den tredje faldgrube er at overse målinger. KQL, Azure Monitor, Application Insights, alerts og incident-ritualer føles ofte mindre eksamensvenlige end CI/CD, men de er centrale for instrumentering og SRE. Efter en release bør teamet kunne se, om ændringen forbedrede eller forværrede stabilitet, og det kræver data frem for mavefornemmelse.

Den fjerde faldgrube er at behandle DevOps som automatisering alene. I virkelige organisationer skal ændringer forankres i arbejdsgange: pull request reviews, change windows, incident reviews, post-incident learning, dependency management og sikkerhedsansvar. DORA-metrics som deployment frequency, lead time for changes, change failure rate og time to restore service kan være nyttige, fordi de giver et fælles sprog for både udvikling og drift.

Efter certificeringen: fra eksamensviden til driftbar praksis

Værdien af AZ-400 viser sig først, når færdighederne bruges til at forbedre softwareleverancen. I en organisation kan det begynde med at flytte en manuel releaseproces til en versioneret YAML-pipeline, indføre approvals på kritiske miljøer eller standardisere service connections og RBAC, så teams ikke deler for brede rettigheder.

Et næste skridt kan være at forbinde deployment-data med driftssignaler. Når releases, incidents og telemetry kan ses i sammenhæng, bliver det lettere at vurdere, om teamets ændringer faktisk reducerer risiko. Det er også her SRE-praksis får praktisk betydning: målsætninger for pålidelighed, klare incident-roller og læring efter fejl bør indgå i DevOps-arbejdet, ikke ligge som et separat driftsprojekt.

Certificeringen kan også hjælpe med rolleafklaring. En DevOps Engineer er sjældent den eneste person, der ejer hele leverancekæden. Rollen fungerer bedst, når den skaber rammer, skabeloner og standarder, som udviklere og operations kan bruge sikkert. Det kræver teknisk forståelse, men også evnen til at designe processer, der kan efterleves i en travl hverdag.

Det næste skridt mod AZ-400

Den mest holdbare vej til AZ-400 er at bygge en lille, realistisk pipeline og bruge den som studieplatform for hvert eksamensdomæne. Når kandidaten kan forklare, hvordan kode bliver bygget, testet, frigivet, overvåget og forbedret med de rigtige kontroller undervejs, bliver eksamensforberedelsen langt mere konkret.

Readynez kan hjælpe teams og individuelle kandidater, der ønsker en mere struktureret forberedelse til Microsoft Certified: DevOps Engineer Expert. Hvis organisationen har brug for at afklare kompetencebehov, certificeringsvej eller planlægning, kan næste skridt være at kontakte Readynez for en dialog om den rette læringsvej.