Automatiserad leverans i Azure innebär att kod, infrastruktur och säkerhetskontroller styrs som en sammanhängande leveranskedja. För svenska utvecklings- och plattformsteam gör detta AZ-400 relevant eftersom provet ligger nära de beslut som redan uppstår i verkliga Azure-miljöer.
AZ-400, Designing and Implementing Microsoft DevOps Solutions, mäter förmågan att designa och implementera DevOps-lösningar med Microsofts verktyg och Azure som central plattform. Det handlar mindre om att memorera produktnamn och mer om att förstå hur versionshantering, CI/CD, säkerhet, infrastruktur som kod, övervakning och samarbete kopplas ihop till en fungerande leveransmodell.
En bra förberedelse behöver därför spegla hur arbetet faktiskt görs. Den som bara klickar sig igenom Azure DevOps-portalen riskerar att missa det som ofta avgör både provfrågor och implementationer: spårbar konfiguration, repeterbara pipelines, tydliga branchpolicys, säkra service connections och mätetal som visar om leveransflödet förbättras.
Vad AZ-400 prövar i praktiken
Microsofts examenssida och skills outline är den primära källan för aktuella provområden, eftersom Microsoft uppdaterar certifieringar när tjänster och arbetssätt förändras. Kandidater bör därför alltid jämföra sin studieplan med den officiella sidan innan de bokar provet, särskilt om de tidigare har läst äldre material om Classic Release pipelines eller äldre säkerhetsmönster.
I praktiken kretsar AZ-400 kring hur ett team går från idé till körande tjänst med kontroll över risk. Det omfattar planering i backloggar, källkod i Git, pull requests, branchregler, bygg- och releaseflöden, pakethantering, testautomatisering, hemlighetshantering, infrastruktur som kod och feedback från drift. Azure DevOps samlar mycket av detta i Azure Boards, Repos, Pipelines, Test Plans och Artifacts, men provet förutsätter också att kandidaten kan resonera om integrationer och arkitekturval.
Det är vanligt att blanda ihop provförberedelse med kortsiktig repetition av gränssnittet. En mer hållbar förberedelse är att bygga ett litet men realistiskt flöde där varje ändring börjar i en work item, går via pull request, testas i en YAML-pipeline, distribueras till en miljö och följs upp med loggar eller mätetal. Då blir de teoretiska områdena lättare att förstå eftersom de syns som beroenden i ett faktiskt leveransflöde.
Azure DevOps, GitHub och valet av plattform
AZ-400 fokuserar på Microsoft DevOps-lösningar, men många organisationer använder en kombination av Azure DevOps och GitHub. Valet bör inte göras utifrån vana eller varumärke, utan utifrån vilka arbetsflöden teamet behöver stödja. Azure DevOps passar ofta väl när organisationen vill ha end-to-end-stöd med Azure Boards, privata agentpooler, etablerade releasekontroller och tät koppling till Azure-miljöer.
GitHub kan vara ett naturligt val när repoekosystem, pull request-kultur, Actions och öppen källkodsflöden väger tyngre. Samtidigt kan krav på efterlevnad, on-prem-konnektivitet, självhostade agenter och detaljerad miljöstyrning göra Azure DevOps mer praktiskt i vissa företagsmiljöer. För AZ-400 är poängen inte att en plattform alltid är rätt, utan att kandidaten kan motivera designval utifrån spårbarhet, säkerhet, automation och driftkrav.
Versionskontroll och branchstrategi
Versionskontroll i AZ-400 handlar om mer än att kunna Git-kommandon. Teamet behöver en strategi som gör det möjligt att integrera ofta utan att tappa kvalitet. Två vanliga mönster är GitFlow och trunk-based development, där trunk-based innebär att utvecklare integrerar små ändringar ofta mot huvudgrenen och skyddar ofärdig funktionalitet med feature flags, alltså funktionsväxlar.
GitFlow kan ge tydliga releasegrenar i organisationer med längre releasecykler, men modellen riskerar att skapa långa sidogrenar och sen integration. Trunk-based development minskar ofta ledtid och merge-risk, men kräver bättre testautomation, tydliga feature flags och disciplin kring små ändringar. I AZ-400-sammanhang är det viktigt att förstå trade-offen: branchstrategin måste stödja både teknisk kvalitet och organisationens leveransrytm.
Branchpolicys är ett konkret sätt att göra strategin verkställbar. I Azure Repos kan ett team kräva pull request-granskning, lyckade build-valideringar, länkning till work items och begränsningar kring vem som får godkänna ändringar i skyddade grenar. Ett vanligt misstag är att dokumentera dessa regler i en wiki men aldrig genomdriva dem i verktyget, vilket leder till undantag och svag spårbarhet när leveranstakten ökar.
CI/CD med YAML: från gränssnitt till versionerad leverans
Azure Pipelines kan byggas via gränssnittet, men moderna implementationer bör i regel beskrivas som YAML och versioneras tillsammans med applikationskoden. Det gör ändringar granskningsbara, återställbara och möjliga att återanvända mellan team. För AZ-400 är detta centralt eftersom pipelines som kod binder ihop källkontroll, test, artefakter, miljöer och säkerhetskontroller.
Följande exempel visar ett förenklat flöde för en webbapplikation som byggs, testas och hämtar hemligheter från Azure Key Vault via en service connection. Syftet är inte att visa varje detalj i en produktionspipeline, utan att illustrera hur säkerhet och leverans kopplas in tidigt i flödet.
Example — YAML-pipeline med Key Vault och byggvalidering
trigger:
branches:
include:
- main
pr:
branches:
include:
- main
pool:
vmImage: ubuntu-latest
variables:
buildConfiguration: Release
stages:
- stage: BuildAndTest
displayName: Build and test
jobs:
- job: dotnet_ci
displayName: Run CI checks
steps:
- task: AzureKeyVault@2
displayName: Load pipeline secrets
inputs:
azureSubscription: sc-azure-prod-readonly
KeyVaultName: kv-app-prod-shared
SecretsFilter: appinsights-connection-string
RunAsPreJob: true
- task: UseDotNet@2
inputs:
packageType: sdk
version: 8.x
- script: dotnet restore src/Contoso.Web/Contoso.Web.csproj
displayName: Restore packages
- script: dotnet build src/Contoso.Web/Contoso.Web.csproj --configuration $(buildConfiguration) --no-restore
displayName: Build application
- script: dotnet test tests/Contoso.Web.Tests/Contoso.Web.Tests.csproj --configuration $(buildConfiguration) --no-build
displayName: Run automated tests
Exemplet visar tre principer som är värda att öva praktiskt inför AZ-400. Pipelinefilen triggas av ändringar i huvudgrenen och pull requests, hemligheter hämtas från Key Vault i stället för att sparas i YAML, och service connection-namnet antyder en begränsad behörighetsmodell. I en verklig miljö bör service connectionen ha just-enough-permissions, vilket betyder minsta behörighet som krävs för uppgiften och inget bredare ägarskap över prenumerationen.
Den vanligaste fallgropen vid pipelineinförande är att behålla för mycket logik i manuella steg eller äldre Classic Release-flöden. Migrering till YAML bör därför ske stegvis: börja med build och test, flytta därefter artefaktpublicering, och lägg till miljödistribution först när rollback, godkännanden och spårbarhet är lösta. På så sätt bevaras kontrollen under övergången i stället för att ett nytt pipelineformat införs som en stor engångsförändring.
DevSecOps i Azure: säkerhet som del av leveransen
DevSecOps betyder att säkerhetskontroller integreras i utvecklings- och leveransflödet i stället för att hanteras som en separat granskning i slutet. I Azure-miljöer innebär det ofta hemlighetshantering i Key Vault, skanning av beroenden och containerbilder, policykontroller för infrastruktur och release-gates som stoppar distribution när kvalitetssignaler inte uppfylls.
För AZ-400 är det viktigt att kunna placera kontroller på rätt ställe. En snabb syntaxkontroll bör köras tidigt i CI eftersom feedbacken behöver komma innan en pull request slås samman. En mer tidskrävande sårbarhetsskanning kan köras som en separat stage, medan en release-gate kan kopplas till testresultat, godkända ändringsärenden eller signaler från Azure Monitor och Log Analytics efter distribution.
Säkerhet i pipelines handlar också om identitet. Service connections bör inte delas brett mellan projekt utan tydligt ägarskap, och agenter bör inte ha mer åtkomst än de behöver. Om en pipeline kan skapa, ändra och radera alla resurser i en prenumeration blir den en attraktiv angreppsyta, särskilt om branchpolicys och godkännanden är svaga.
Infrastruktur som kod och miljöparitet
Infrastructure as Code, ofta förkortat IaC, innebär att infrastruktur definieras i filer som kan granskas, testas och versioneras. Det är en central del av AZ-400 eftersom DevOps i Azure sällan slutar vid applikationsbygget. Nätverk, app services, managed identities, Key Vault, monitoring och policytillämpning behöver kunna skapas på ett repeterbart sätt.
Följande Bicep-exempel visar en liten del av detta: en App Service Plan och en webbapp med managed identity aktiverad. Det är en enkel modell, men den visar hur team kan göra miljöer reproducerbara och samtidigt undvika hårdkodade hemligheter.
Example — Bicep för repeterbar webbappsmiljö
param location string = resourceGroup().location
param appName string
resource plan 'Microsoft.Web/serverfarms@2023-12-01' = {
name: '${appName}-plan'
location: location
sku: {
name: 'B1'
tier: 'Basic'
}
}
resource webapp 'Microsoft.Web/sites@2023-12-01' = {
name: appName
location: location
identity: {
type: 'SystemAssigned'
}
properties: {
serverFarmId: plan.id
httpsOnly: true
}
}
Det viktiga i exemplet är inte resursvalet utan arbetssättet. När infrastrukturen ligger i källkontroll kan ändringar granskas i pull requests, distribueras via pipeline och återställas genom en ny kontrollerad ändring. I ett minisceanrio kan ett team exempelvis skapa test, staging och produktion med samma modul, distribuera en ny version till staging, köra automatiserade tester och därefter släppa till produktion med blue/green eller canary beroende på risknivå.
Blue/green innebär att en ny miljö körs parallellt med den gamla innan trafik växlas över. Canary innebär att en mindre del av användarna får den nya versionen först, så att teamet kan övervaka fel, latens och affärssignaler innan utrullningen breddas. Rollback bör inte vara ett improviserat manuellt steg; den bör beskrivas i releaseprocessen, exempelvis genom att växla trafik tillbaka, distribuera föregående artefakt eller återställa en infrastrukturändring via versionerad kod.
Agentstrategi: Microsoft-hosted eller self-hosted
Build- och releaseagenter blir ofta en flaskhals först när teamet skalar upp. Microsoft-hosted agenter är enkla att komma igång med och passar många standardbyggen eftersom de är tillfälliga, underhålls av Microsoft och ger en ren miljö vid varje körning. Nackdelen är att de kan sakna specialverktyg, ha begränsad cache-effekt och inte alltid nå privata nätverk eller interna beroenden.
Self-hosted agenter behövs ofta när byggen kräver privata nät, stora beroendecachar, licensierade verktyg, specialiserade SDK:er eller när organisationen har striktare kontrollkrav. De kräver i gengäld patchning, härdning, övervakning och tydlig isolering mellan projekt. En self-hosted agent som kör många känsliga pipelines utan segmentering kan snabbt bli en central riskpunkt.
En praktisk tumregel är att börja med Microsoft-hosted agenter för standardiserade workloads och införa self-hosted agenter när kraven är tydliga. Då bör teamet dokumentera vem som äger agentpoolen, vilka verktyg som installeras, hur uppdateringar görs och vilken behörighet agentidentiteten har i Azure. Detta är både bra driftpraxis och relevant för AZ-400, där designbeslut ofta behöver vägas mot säkerhet, kostnad, underhåll och leveranshastighet.
Mätetal som gör DevOps styrbart
DevOps blir lätt ett verktygsprojekt om teamet inte mäter effekten av arbetssättet. DORA-mått används ofta för att förstå leveransförmåga, till exempel hur ofta teamet driftsätter, hur lång tid en ändring tar från commit till produktion, hur ofta ändringar orsakar incidenter och hur snabbt tjänsten återställs efter fel. I Azure kan dessa signaler kopplas ihop från Boards, Pipelines, Azure Monitor och Log Analytics.
Mätning behöver samtidigt ske med omdöme. Om ett team bara premierar fler deployment-tillfällen kan det skapa högre risk utan bättre användarvärde. Om ett team bara mäter incidenter kan utvecklare börja undvika förändring. Ett mer praktiskt angreppssätt är att kombinera leveransmått med felbudgetar, kvalitetsgrindar och produktsignaler, så att snabbare leverans inte sker på bekostnad av stabilitet.
Så bör förberedelserna struktureras
En kandidat som redan arbetar med Azure bör börja med att läsa Microsofts officiella examenssida och jämföra varje område mot den egna erfarenheten. Den som har byggt pipelines men aldrig arbetat med release-gates, branchpolicys eller IaC bör lägga mer tid på praktiska labbar än på teoriläsning. Den som däremot kommer från utveckling men saknar driftperspektiv bör fokusera på övervakning, rollback, identiteter och miljöstrategi.
Ett strukturerat alternativ är Readynez Microsoft Certified DevOps Engineer-utbildning, särskilt när målet är att koppla provområdena till praktiska designval i Azure. En sådan väg ersätter inte egen hands-on-övning, men kan ge ramverk för vad som bör prioriteras och vilka luckor som behöver stängas.
Det är också klokt att använda en lärplattform eller studieyta för att följa framsteg, samla labbanteckningar och återvända till svagare områden. Readynez365 kan fylla den rollen för organisationer som vill samla lärresurser och uppföljning, men den praktiska nyttan kommer först när studierna kopplas till verkliga pipelines, repos och Azure-resurser.
Certifieringsvägen efter AZ-400
AZ-400 är kopplat till rollen som DevOps Engineer Expert och bör förstås i relation till Microsofts bredare certifieringsstruktur. Den officiella sidan för Microsoft Certified: DevOps Engineer Expert beskriver hur certifieringen positioneras och vilka krav som gäller när Microsoft uppdaterar programmet.
För arkitekter och tekniska ledare kan även Azure Solutions Architect Expert vara relevant, eftersom DevOps-beslut ofta påverkar nätverk, identitet, governance och driftsarkitektur. Den bredare katalogen över Microsoft Credentials är den säkraste platsen att kontrollera aktuella certifieringsrelationer, namn och ändringar innan en långsiktig studieplan låses.
FAQ
Vilka färdigheter är viktigast för AZ-400?
De viktigaste färdigheterna är att kunna designa och implementera versionskontroll, CI/CD, säkerhet i leveransflödet, infrastruktur som kod, övervakning och samarbete i Azure-baserade DevOps-miljöer. Praktisk förståelse väger tungt: kandidaten bör kunna förklara varför en pipeline, branchpolicy eller service connection är utformad på ett visst sätt.
Behöver man kunna Azure DevOps före AZ-400?
Ja, praktisk erfarenhet av Azure DevOps eller motsvarande DevOps-arbete är starkt rekommenderad. Det räcker sällan att bara läsa om tjänsterna, eftersom många provfrågor bygger på designval, felsökning och konsekvenser av olika implementationer.
Hur lång tid tar det att förbereda sig för AZ-400?
Förberedelsetiden varierar beroende på tidigare erfarenhet av Azure, Git, pipelines, säkerhet och drift. En erfaren Azure-utvecklare kan behöva fokusera på luckor som IaC och releasekontroller, medan en kandidat utan praktisk pipelineerfarenhet bör räkna med mer labbtid innan provet.
Är Classic Release pipelines fortfarande relevanta?
De kan fortfarande förekomma i äldre miljöer, men ny design bör i många fall utgå från YAML-baserade pipelines och miljöstyrning som kan versioneras. Vid migrering bör teamet flytta funktion stegvis, behålla spårbarhet och säkerställa att godkännanden, rollback och artefakthantering fungerar innan gamla flöden avvecklas.
Hur skiljer sig Azure DevOps från GitHub i AZ-400-sammanhang?
Azure DevOps ger ett samlat stöd för Boards, Repos, Pipelines, Artifacts och Test Plans, medan GitHub ofta används för repository-centrerade arbetsflöden och GitHub Actions. I AZ-400 är det viktigaste att förstå hur verktygsvalet påverkar spårbarhet, säkerhet, automation, agentstrategi och integration med Azure.
Att göra AZ-400 användbart i vardagen
AZ-400 blir mest värdefull när förberedelserna leder till bättre implementationer, inte bara ett avklarat prov. Den praktiska vägen är att bygga små, repeterbara leveransflöden med YAML, IaC, branchpolicys, säkra identiteter och mätning från drift. Då blir certifieringen en bekräftelse på färdigheter som redan går att använda i teamets Azure-miljö.
