AZ-400 är ett prov där utmaningen ofta är bredare än att bara kunna klicka sig runt i Azure DevOps.
Det är en missvisande bild, eftersom provets svårighet i praktiken ligger i att förstå hur DevOps-lösningar designas, säkras, automatiseras och följs upp över både Azure DevOps- och GitHub-ekosystemet.
Är AZ-400 svårt?
AZ-400 kan upplevas svårt, men inte för att provet är otydligt eller kräver ovanliga specialkunskaper. Svårigheten kommer främst från bredden. Kandidaten behöver kunna resonera om källkodshantering, CI/CD, säkerhet, efterlevnad, artefakter, övervakning, feedback och DevOps-strategi som delar av ett sammanhängande leveransflöde.
Microsoft beskriver AZ-400 som provet för rollen Azure DevOps Engineer. Enligt Microsoft Learn mäter provet färdigheter inom bland annat DevOps-strategi, utvecklingsprocesser, kontinuerlig integration och leverans, source control, artefakthantering, säkerhet och feedback. Därför räcker det sällan att bara kunna bygga en pipeline i ett grafiskt gränssnitt; kandidaten behöver förstå varför en lösning är robust, spårbar och säker.
Det finns också en praktisk orsak till att erfarna utvecklare ibland underskattar nivån. Många har djup erfarenhet av antingen kod, drift eller molninfrastruktur, men AZ-400 korsar dessa områden. En utvecklare som kan Git och GitHub Actions kan behöva stärka Azure Policy, Key Vault och release governance. En plattformstekniker som kan Azure DevOps kan behöva öva mer på branching-strategier, package management och feedbackloopar.
Vad provet omfattar enligt Microsoft
Den säkraste utgångspunkten är alltid Microsoft Learn-sidan för Exam AZ-400: Designing and Implementing Microsoft DevOps Solutions och den tillhörande Skills measured-beskrivningen. Microsoft kan ändra innehåll och viktning över tid, så alla förberedelser bör kontrolleras mot den officiella sidan och dokumentets fält för senaste uppdatering innan en studieplan låses.
På en övergripande nivå handlar provet om att designa och implementera DevOps-lösningar, inte om att memorera menyer. Frågor kan vara scenario- och flervalsbaserade, och Microsofts provformat kan variera. Därför bör kandidaten förbereda sig på att tolka krav, välja lämplig lösning och väga av säkerhet, spårbarhet, automation och operativ hållbarhet.
En vanlig missuppfattning är att AZ-400 skulle ha ett särskilt matematiskt avsnitt. Det finns inget stöd i Microsofts officiella provöversikt för att beskriva provet på det sättet. Däremot behöver kandidaten förstå mätetal och feedback, till exempel hur ledtid, deployfrekvens, felgrad och återställningstid används för att förbättra ett leveransflöde.
Varför AZ-400 ofta känns bredare än väntat
AZ-400 har blivit bredare i praktiken eftersom moderna DevOps-miljöer sällan bygger på ett enda verktyg. Microsofts ekosystem omfattar både Azure DevOps och GitHub, och kandidater som bara studerar Azure DevOps-gränssnittet riskerar att missa viktiga delar av hur GitHub, repositories, pull requests, Actions, säkerhetskontroller och paketflöden passar in i arbetet.
Den tekniska bredden märks särskilt i YAML-baserade pipelines. En kandidat behöver förstå hur pipeline som kod fungerar, hur variabler och hemligheter hanteras, hur stages och approvals används, och hur en pipeline bör reagera när ett bygge, ett test eller en säkerhetskontroll misslyckas. Det är ofta här provet blir svårare än förväntat: frågan handlar inte om var knappen finns, utan om vilken design som minskar risk i en verklig leveranskedja.
Säkerhet och styrning är en annan svårighetsdrivare. Branch policies, skyddad main-branch, pull request-krav, service connections, managed identities, Key Vault-integrering, approvals och miljöskydd är inte sidospår. De är centrala för att skapa en leveransmodell där kod kan granskas, byggas, distribueras och återställas utan att teamet tappar kontroll.
Arbetsgivare värderar ofta just denna förmåga högre än ren verktygsmemorering. I praktiken innebär en stark DevOps Engineer att kunna härda pipelines, begränsa behörigheter, separera miljöer, mäta flöde och skapa återkoppling från produktion till utveckling. AZ-400 speglar den typen av arbetsflöden bättre än en studieplan som bara bygger på läsning.
Förkunskaper som gör provet mer hanterbart
AZ-400 passar bäst för personer som redan har arbetat med utveckling, drift, molnplattformar eller DevOps-praktiker. Det innebär inte att varje kandidat måste vara expert på alla delar, men det bör finnas en stabil grund i Git, bygg- och releaseflöden, Azure-tjänster, identitet, säkerhet och applikationslivscykel.
En användbar beslutsregel är att titta på var kunskapsluckorna finns. Den som saknar Azure-grund bör först stärka administration, nätverk, identitet och resurshantering. Den som saknar utvecklingsbakgrund bör lägga tid på Git, branching, pull requests, testautomation och beroendehantering. Den som redan arbetar som DevOps- eller plattformsingenjör kan ofta gå direkt mot AZ-400, men bör fortfarande validera sig mot Skills measured i stället för att förlita sig på yrkestitel.
Readynez nämner AZ-400 i rollen Azure DevOps Engineer, och en strukturerad Microsoft Azure DevOps Engineer-utbildning kan vara relevant när kandidaten vill jämföra sin egen erfarenhet mot provets områden. Det viktiga är ändå att förberedelsen bygger på praktiska moment, inte bara genomgång av teori.
En realistisk studieplan på sex till åtta veckor
En effektiv studieplan bör utgå från Microsofts Skills measured och koppla varje område till praktiska labbar. Metoden är enkel: läs målet, bygg något litet, bryt det avsiktligt, felsök och dokumentera varför lösningen fungerar. Det förbereder kandidaten bättre för scenariofrågor än passiv repetition.
Sex veckor kan räcka för en erfaren kandidat som redan arbetar med Azure DevOps eller GitHub i vardagen. Åtta veckor är mer realistiskt för den som behöver fylla luckor inom säkerhet, governance, YAML eller observability. Planen nedan är därför ett ramverk snarare än ett löfte om exakt tidsåtgång.
| Period |
Fokus |
Praktisk övning |
| Vecka 1 |
Kartlägg Skills measured och nuläge |
Skapa en enkel applikation med repository, branch-strategi och pull request-flöde. |
| Vecka 2 |
Source control och utvecklingsprocesser |
Inför branch policies, kodgranskning och skyddad main-branch. |
| Vecka 3 |
CI med YAML |
Bygg en pipeline som kör build, test och artefaktpublicering, och felsök ett avsiktligt trasigt bygge. |
| Vecka 4 |
CD, miljöer och approvals |
Distribuera till testmiljö med manuella gates, godkännanden och tydlig rollback-plan. |
| Vecka 5 |
Säkerhet och efterlevnad |
Flytta hemligheter från pipelinevariabler till Key Vault och begränsa behörigheter för service connections. |
| Vecka 6 |
Artefakter, paket och beroenden |
Publicera och konsumera paket, lås versioner och granska beroenderisker. |
| Vecka 7 |
Observability och feedback |
Koppla deployment-resultat, incidenter och flödesmätetal till förbättringsåtgärder. |
| Vecka 8 |
Repetition och scenarioträning |
Gå igenom felaktiga svar, bygg om svaga delar och jämför lösningar mot Microsofts målbeskrivning. |
Den viktigaste skillnaden mellan en svag och stark studieplan är hur kandidaten tränar på fel. Ett trasigt bygge, en misslyckad deployment, en felaktigt konfigurerad hemlighet eller en rollback som inte fungerar lär ut mer än en perfekt demo. Scenariofrågor belönar ofta förståelse för konsekvenser, inte bara igenkänning av begrepp.
Hur provmålen syns i verkliga arbetsflöden
DevOps-strategi syns i hur teamet organiserar arbetet, mäter flöde och tar beslut om releasefrekvens, kvalitet och risk. I en verklig organisation betyder det att koppla backlogg, pull requests, pipelines, miljöer och incidentdata till ett förbättringsarbete som går att följa upp.
Source control syns i valet av branching-modell, granskningskrav och skydd mot oavsiktliga ändringar i produktionsnära kod. En kandidat bör kunna förklara varför en skyddad main-branch, obligatoriska granskningar och status checks minskar risken utan att stoppa leveransflödet helt.
CI/CD syns i YAML-pipelines, återanvändbara mallar, stage-indelning, approvals och deployment-strategier. Rollback, feature toggles och stegvis utrullning är praktiska exempel på hur tekniska val påverkar riskhantering. Den som bara kan starta en pipeline manuellt har en svagare förståelse än den som kan designa ett flöde som fungerar när något går fel.
Säkerhet och efterlevnad syns i hur team hanterar hemligheter, identiteter, behörigheter och granskningsspår. Hårdkodade hemligheter, breda servicekonton och manuella undantag är typiska varningssignaler. En bättre lösning använder principen om minsta privilegium, säkra hemlighetslager och tydliga godkännandepunkter.
Vanliga misstag i AZ-400-förberedelser
Ett vanligt misstag är att studera Azure DevOps som ett gränssnitt i stället för som en modell för leverans. Kandidaten klickar igenom builds och releases, men tränar inte på YAML, branching, policies, återanvändbara templates eller säker hantering av variabler och hemligheter.
Ett annat misstag är att ignorera GitHub-delarna. Eftersom många organisationer använder GitHub och Azure parallellt behöver kandidaten förstå när GitHub Actions, Azure Pipelines, repositories, packages och säkerhetsfunktioner är relevanta. Det betyder inte att verktygen är utbytbara i varje situation, men provförberedelsen bör behandla båda ekosystemen seriöst.
Det tredje misstaget är att hoppa över mätetal och feedback. DevOps handlar inte bara om att leverera snabbare; det handlar om att förstå om leveransen är stabil, säker och värdeskapande. Kandidater bör därför öva på hur deploymentdata, incidenter, testresultat och användarfeedback kan leda till förbättringar i processen.
Så bör kandidaten läsa Microsofts källor
Microsoft Learn bör användas som primär källa för provets aktuella omfattning. Särskilt viktigt är att kontrollera provsidan, Skills measured-dokumentet och information om uppdateringar. Om ett blogginlägg, en kurs eller en studieguide säger något som avviker från Microsofts aktuella målbeskrivning bör Microsofts information väga tyngst.
Dokumentation för Azure Pipelines, GitHub Actions och Azure Key Vault är också värdefull när kandidaten vill förstå hur provmålen fungerar i praktiken. Dessa källor bör läsas med ett konkret labb öppet bredvid, eftersom dokumentation utan praktisk tillämpning lätt blir ytlig inför scenariofrågor.
En bra metod är att göra en enkel matris där varje Skills measured-punkt kopplas till ett labb, en svaghet och en verifiering. Om målet gäller hemlighetshantering bör verifieringen vara att en hemlighet kan roteras utan kodändring. Om målet gäller rollback bör verifieringen vara att en misslyckad deployment kan återställas kontrollerat.
När en kurs eller strukturerad träning är rimlig
Självstudier fungerar väl för kandidater som redan har en egen Azure-miljö, vana vid YAML och möjlighet att öva praktiskt. Strukturerad träning blir mer relevant när tiden är begränsad, när flera kunskapsområden saknas eller när kandidaten behöver en tydlig ordning mellan strategi, pipelines, säkerhet och feedback.
Den som planerar flera Microsoft-certifieringar kan även vilja se hur AZ-400 passar in i ett bredare utbildningsspår via Microsoft-utbildningar. På Readynez finns dessutom information om Unlimited Microsoft Training, vilket kan vara relevant för organisationer som behöver planera utbildning över flera roller snarare än ett enskilt prov.
FAQ
Är AZ-400 svårt att klara?
AZ-400 är ofta svårt för kandidater som saknar praktisk erfarenhet av DevOps-flöden i Azure, GitHub eller Azure DevOps. Det blir mer hanterbart när kandidaten kan bygga, säkra, felsöka och förbättra pipelines i en verklig eller labbliknande miljö.
Vilka delar av AZ-400 är vanligtvis mest utmanande?
De mest utmanande delarna är ofta YAML-pipelines, säkerhet, governance, hemlighetshantering, approvals, rollback och feedbackmätetal. Dessa områden kräver att kandidaten förstår konsekvenserna av olika designval, inte bara känner igen terminologi.
Behöver kandidaten kunna både Azure DevOps och GitHub?
Ja, förberedelsen bör täcka båda ekosystemen eftersom Microsofts DevOps-plattform omfattar både Azure DevOps och GitHub. Kandidaten bör förstå skillnaderna mellan exempelvis Azure Pipelines och GitHub Actions samt hur repositories, pull requests, paket och säkerhetskontroller används i praktiken.
Hur lång tid tar det att förbereda sig för AZ-400?
Det beror på bakgrund. En erfaren DevOps- eller plattformsingenjör kan ofta arbeta effektivt med en sexveckorsplan, medan kandidater med luckor inom Azure, YAML eller säkerhet ofta behöver närmare åtta veckor eller mer. Tiden bör styras av Skills measured, inte av ett fast antal studiedagar.
Finns det en godkändsgrad för AZ-400?
Microsoft publicerar inte någon officiell generell godkändsgrad som bör användas som beslutsunderlag. Det är därför bättre att bedöma beredskap genom praktiska labbar, övningsfrågor, genomgång av felaktiga svar och jämförelse mot Microsofts aktuella Skills measured.
Rätt sätt att bedöma svårighetsgraden
AZ-400 är svårt om förberedelsen bygger på läsning, verktygsmemorering och korta demonstrationer. Det blir betydligt mer rimligt när kandidaten tränar på pipeline som kod, säkerhetskontroller, branch policies, hemlighetsrotation, approvals, rollback och mätbar feedback i ett sammanhängande flöde.
Den mest praktiska nästa åtgärden är att öppna Microsofts aktuella Skills measured, markera varje område som starkt eller svagt och bygga en labbplan därefter. Den som vill diskutera lämplig utbildningsväg för AZ-400 kan kontakta Readynez, men själva grunden för att klara provet är fortfarande praktisk erfarenhet kopplad till Microsofts officiella mål.
