AZ-400 är en certifiering för DevOps-arbetet i Azure, men den handlar inte bara om att klicka sig igenom Azure DevOps och bygga en pipeline.
Det leder ofta till fel förberedelse, eftersom provet i praktiken prövar hur en Azure DevOps-ingenjör designar arbetssätt, styrning, säkerhet, återkoppling och leveransflöden som fungerar i riktiga team.
AZ-400, Designing and Implementing Microsoft DevOps Solutions, är provet som tillsammans med rätt förkunskap leder till Microsoft Certified: DevOps Engineer Expert. För att certifieringen ska utfärdas krävs först antingen AZ-104 Microsoft Azure Administrator Associate eller AZ-204 Microsoft Azure Developer Associate. Det är en viktig detalj, eftersom AZ-400 bygger vidare på både Azure-plattformen och utvecklingsnära leveransmetoder.
DevOps-marknaden och molnanvändningen har länge drivit efterfrågan på personer som kan minska friktionen mellan utveckling, drift och säkerhet. Äldre marknadsrapporter, exempelvis från IMARC, och analyser av molnleverantörernas positioner, som denna artikel från The Register, visar varför DevOps har blivit en central kompetens i många IT-organisationer. Samtidigt är provförberedelse inte samma sak som arbetsförmåga; en kandidat behöver kunna visa hur kod, infrastruktur, kvalitet, säkerhet och driftdata hänger ihop.
Vad en Azure DevOps-ingenjör faktiskt gör
En DevOps-ingenjör arbetar i gränslandet mellan utveckling, plattform, drift och säkerhet. Rollen handlar om att göra programvaruleverans mer förutsägbar genom versionshantering, automatiserade byggen, testning, artefakthantering, infrastruktursomkod, release-strategier och kontinuerlig övervakning. I en Azure-miljö betyder det ofta arbete med Azure DevOps, GitHub, Azure-resurser, identitet, hemligheter och telemetri.
Det är därför en snäv verktygsfokus blir riskabel. Microsoft Azure finns beskrivet på Azure-webbplatsen, men en Azure DevOps-ingenjör behöver även förstå hur lösningar kan samexistera med AWS, Google Cloud och tredjepartsverktyg. I praktiken kan samma leveransflöde innehålla GitHub för källkod, Jenkins i en äldre CI-miljö och SonarQube för kodkvalitet, även om målet på sikt är att standardisera och förenkla.
Azure DevOps som tjänst samlar repos, pipelines, boards, artefakter och teststöd i en integrerad verktygskedja, vilket Microsoft beskriver på sidan för Azure DevOps. Intresset för termen kan jämföras över tid i Google Trends, men sådana jämförelser bör ses som signaler snarare än facit. För den som ska klara AZ-400 är det mer relevant att förstå varför YAML-drivna pipelines, GitHub-integrationer, policyer och observability har fått större betydelse än klassiska manuella releaseflöden.
AZ-104 eller AZ-204 före AZ-400
Valet mellan AZ-104 och AZ-204 bör styras av bakgrund, inte av vad som uppfattas som snabbast. Den som arbetar med drift, identitet, nätverk, virtuella maskiner, lagring och Azure Policy får oftast bättre grund av AZ-104. Den som bygger applikationer, arbetar med API:er, containerisering, autentisering i kod och Azure SDK:er får oftast en mer naturlig väg via AZ-204.
| Bakgrund |
Lämpligare förkunskapsväg |
Varför det hjälper inför AZ-400 |
| Systemadministratör, cloud engineer eller plattformsteam |
AZ-104 |
Ger starkare bas i Azure-resurser, identitet, nätverk, styrning och driftansvar. |
| Utvecklare eller integrationsutvecklare |
AZ-204 |
Ger starkare bas i applikationsarkitektur, kodnära säkerhet, API:er och molnbaserad utveckling. |
| Teknisk projektledare eller DevOps-generalist |
Den väg som ligger närmast det dagliga arbetet |
AZ-400 blir lättare när förkunskapen kan kopplas till egna projekt och verkliga beslut. |
Det vanligaste misstaget är att behandla förkunskapsprovet som en administrativ spärr. AZ-400 utgår från att kandidaten redan förstår antingen Azure-drift eller Azure-utveckling tillräckligt väl för att kunna designa ett leveransflöde ovanpå den kunskapen. En svag grund gör att ämnen som service connections, managed identities, RBAC, miljöskydd och deployment approvals blir svårare än de behöver vara.
Vad AZ-400 prövar bortom CI/CD
CI/CD är centralt, men AZ-400 stannar inte vid build- och release-steg. Provet bedömer hur kandidaten hanterar källkod, branching, pull requests, paketering, artefakter, teststrategier, säkerhet, compliance, feedback, SRE-principer och samarbete. Det innebär att en bra studieplan behöver växla mellan teknik och process.
I praktiska projekt blir detta tydligt när en pipeline inte längre är ett isolerat YAML-dokument. Den måste kunna hämta hemligheter från Azure Key Vault, köra på rätt agent, bygga artefakter på ett reproducerbart sätt, distribuera infrastruktur med Bicep eller Terraform, tillämpa godkännanden och skicka driftsignaler till Application Insights eller Log Analytics. Självhostade agenter, brandväggsregler, change management och rollbaserad åtkomst är ofta de detaljer som skiljer ett övningslabb från en miljö som fungerar på arbetet.
En annan förbisedd del är mätning. DevOps handlar inte bara om att släppa oftare, utan om att ge teamet bättre återkoppling. DORA-mått, felbudgetar, incidentdata och applikationstelemetri hjälper ett team att avgöra om leveransflödet faktiskt förbättrar stabilitet och ledtid. Det är också sådant arbetsgivare ofta vill se i praktiska exempel: ADR:er, postmortems, pull requests i IaC-repon och resonemang bakom release-strategier, inte enbart ett certifikat.
En 4–6-veckors studieplan som kopplar provmål till labbar
En realistisk studieplan bör börja med Microsofts officiella AZ-400-sida och dokumentet Skills measured, eftersom provmål och format kan ändras. Den officiella sidan är också rätt plats för aktuell information om bokning, språk, regionbaserad prissättning och eventuella ändringar i provupplevelsen. Hårdkodade uppgifter om antal frågor, pris eller tidslängd blir snabbt inaktuella och bör inte styra planeringen.
| Period |
Fokus |
Praktiskt labb |
| Vecka 1 |
Git, branching, pull requests, work items och samarbetsflöden. |
Skapa ett repo, sätt branch policy, koppla pull request till ett arbetsobjekt och dokumentera beslutet i en enkel ADR. |
| Vecka 2 |
YAML-baserad CI, testning, artefakter och paket. |
Bygg en applikation, kör tester, publicera en artefakt och versionssätt resultatet. |
| Vecka 3 |
IaC, miljöer, service connections, Key Vault och behörigheter. |
Distribuera en Azure-resurs med Bicep eller Terraform och låt pipelinen hämta hemligheter utan att exponera dem i loggar. |
| Vecka 4 |
Release-strategier, approvals, säkerhet, compliance och quality gates. |
Inför miljögodkännande, kodanalys och en release-strategi som går att rulla tillbaka. |
| Vecka 5 |
SRE, monitoring, incidentflöden och kontinuerlig återkoppling. |
Skicka telemetri till Application Insights eller Log Analytics och skapa en enkel rutin för postmortem efter ett simulerat fel. |
| Vecka 6 |
Repetition, scenariofrågor och svaga områden. |
Öva case-baserade frågor, byggstegsordning och beslutsfrågor utan att använda brain-dump-material. |
Den som har arbetat dagligen med pipelines kan ibland korta perioden, medan den som kommer från ren drift eller ren utveckling ofta behöver mer tid för de delar som ligger utanför den egna vardagen. En instruktörsledd variant, till exempel Readynez utbildning för Microsoft Certified Azure DevOps Engineer, kan passa när tiden är begränsad och målet är att få struktur, labbar och provnära genomgång i samma spår.
Ett praktiskt pipeline-scenario att öva på
Ett bra AZ-400-labb bör följa ett helt leveransflöde från källkod till driftåterkoppling. Det behöver inte vara stort, men det måste vara sammanhängande. En enkel webbapp räcker om repot innehåller applikationskod, teststeg, artefaktpublicering, IaC för målmiljön, release till en Azure-miljö och telemetri som kan användas efter driftsättning.
Följande YAML-exempel visar ett kompakt övningsflöde där pipelinen bygger en .NET-applikation, kör tester, publicerar artefakt och förbereder deployment. I ett verkligt labb bör service connection, miljögodkännande, Key Vault-referenser och IaC-steget konfigureras i Azure DevOps eller GitHub på ett sätt som matchar organisationens säkerhetsmodell.
Example — YAML-pipeline för build, test och artefakt
trigger:
branches:
include:
- main
pool:
vmImage: ubuntu-latest
variables:
buildConfiguration: Release
artifactName: webapp-drop
stages:
- stage: BuildAndTest
jobs:
- job: Build
steps:
- task: UseDotNet@2
inputs:
packageType: sdk
version: 8.x
- script: dotnet restore src/Contoso.Web/Contoso.Web.csproj
displayName: Restore dependencies
- 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 tests
- script: dotnet publish src/Contoso.Web/Contoso.Web.csproj --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)
displayName: Publish application
- publish: $(Build.ArtifactStagingDirectory)
artifact: $(artifactName)
Det viktiga i exemplet är inte syntaxen i sig, utan arbetsmönstret. Kandidaten bör kunna förklara varför beroenden återställs, varför test körs före artefaktpublicering, hur artefakten spåras vidare till release och var security scanning, IaC och miljögodkännanden bör placeras. Därifrån kan labbet byggas ut med Bicep eller Terraform, Key Vault-integrering, blue/green- eller canary-release samt Application Insights-data som återkopplas till teamets backlogg.
Vanliga misstag under förberedelsen
Ett vanligt misstag är att träna på för många verktyg ytligt. AZ-400 kräver visserligen kännedom om integrationer, men det är bättre att kunna ett sammanhängande flöde väl än att känna igen många produktnamn utan att förstå besluten bakom dem. Den som kan förklara varför en pipeline använder en viss branching-strategi, hur hemligheter skyddas och hur fel återkopplas till utvecklingsteamet står starkare än den som bara har följt isolerade tutorials.
Ett annat misstag är att öva i fel verktygsyta. Klassiska pipelines och äldre servervarianter förekommer fortfarande i organisationer, men moderna Azure DevOps- och GitHub-flöden är i hög grad YAML-drivna och Git-centrerade. Förberedelsen bör därför prioritera kodgranskning, pipeline-as-code, pull request-policyer, miljöskydd, säkerhetskontroller och automatiserad återkoppling.
Examenshygien spelar också roll. Brain-dump-material bryter mot provets syfte och ger dessutom dålig träning för scenariofrågor. Bättre är att öva lugnt på case, ordning av byggsteg, drag-and-drop-liknande resonemang och frågor där flera svar verkar rimliga men bara ett passar kraven på säkerhet, styrning eller driftsäkerhet.
Inför provdagen
Dagen före provet bör fokus ligga på stabilitet, inte nyinlärning. Kontrollera bokningsinformation, legitimation, tekniska krav för provmiljön och aktuell information på Microsofts officiella AZ-400-sida. Eftersom format och regler kan ändras bör den officiella sidan väga tyngre än blogginlägg, äldre videor och forumtrådar.
- Kontrollera provtid, legitimation, språkval och om provet sker online eller på testcenter.
- Gå igenom Skills measured och markera endast de områden som fortfarande känns osäkra.
- Öva några scenariofrågor långsamt och motivera varför fel svar är fel.
- Stäng av störande program och testa kamera, mikrofon och nätverk om provet skrivs online.
- Undvik att memorera inaktuella siffror om format, pris eller antal frågor; verifiera sådant direkt hos Microsoft.
Under själva provet är det klokt att läsa kraven före svarsalternativen, särskilt i case-frågor. Ord som compliance, least privilege, rollback, auditability, deployment window och business continuity styr ofta vilket svar som är mest korrekt. En tekniskt fungerande lösning är inte alltid rätt om den saknar godkännande, spårbarhet eller säker hemlighetshantering.
Att använda AZ-400-kunskapen efter certifieringen
Certifieringen är mest värdefull när den kopplas till praktiska leveranser. En Azure DevOps-ingenjör som vill visa faktisk förmåga bör kunna peka på ett repo med IaC, en pipeline med tydliga quality gates, ett exempel på förbättrad incidentåterkoppling och dokumenterade arkitekturbeslut. Det ger en mer trovärdig bild än att bara säga att CI/CD har implementerats.
Den mest hållbara vägen till AZ-400 är att studera som om kunskapen ska användas nästa arbetsdag. Bygg en pipeline från början, dokumentera besluten, mät resultatet och repetera mot Microsofts aktuella provmål. Om nästa steg är att strukturera träningen för ett team eller en individuell certifieringsplan går det också att kontakta Readynez för rådgivning om lämplig väg framåt.
