I praktiska Azure-miljöer prövas AZ-400-kandidater av att laboratorieövningar ofta känns tydliga, medan äldre kodbaser, delade prenumerationer, säkerhetskrav och releasefönster inte går att ignorera.
AZ-400 handlar därför mindre om att känna igen enskilda DevOps-funktioner och mer om att kunna designa ett fungerande leveranssystem. Microsofts studieguide för microsoft.com/en-us/credentials/certifications/resources/study-guides/az-400">AZ-400: Designing and Implementing Microsoft DevOps Solutions beskriver färdigheter inom processer, källkodshantering, CI/CD, säkerhet, efterlevnad och övervakning. I praktiken möts dessa områden i samma pipeline: en ändring ska granskas, byggas, testas, säkras, distribueras, observeras och kunna återställas utan improvisation.
Från provmål till produktionsflöde
En realistisk AZ-400-tolkning börjar med ett team som levererar en webbapplikation till Azure App Service. Koden ligger i Git, arbetsflödet styrs med pull requests, infrastrukturen beskrivs med Bicep eller Terraform och distributionen sker via Azure DevOps eller GitHub Actions. Miljöerna är separerade i utveckling, test och produktion, och produktionssteget kräver godkännande från en ansvarig grupp innan trafiken flyttas.
Det viktiga är inte vilket verktyg som råkar köra pipelinen, utan hur kontrollpunkterna är utformade. Azure DevOps passar ofta väl när organisationen redan använder Boards, Repos, Pipelines och miljögodkännanden i samma arbetsflöde. GitHub Actions passar ofta väl när utvecklingen redan drivs i GitHub och teamet vill ha nära koppling till pull requests, code scanning och beroendegranskning. AZ-400 förväntar sig förståelse för båda sammanhangen, så valet bör göras utifrån befintlig källkodshantering, styrningskrav, säkerhetsmodell och hur teamet vill spåra arbete från idé till drift.
En vanlig miss i verkliga införanden är att bygga en pipeline som fungerar tekniskt men saknar driftbarhet. Hemligheter hamnar i pipelinevariabler, produktionsmiljön saknar godkännanden, brancher är oskyddade och det finns ingen koppling mellan Azure Policy, monitorering och releasebeslut. En sådan lösning kan klara en demonstration men blir svår att försvara när revision, incidenthantering eller flera team kommer in i bilden.
CI/CD som företagsmönster, inte bara automation
Med Azure Pipelines kan team skapa flerstegspipelines där bygg, test, säkerhetskontroller och distribution är separata steg med tydliga beroenden. I företagsmiljö bör YAML inte växa till en enda lång fil som alla kopierar. Ett bättre mönster är att lägga återanvändbara bygg- och distributionssteg i mallar, låta varje applikation ange sina egna parametrar och använda environments för att koppla godkännanden, historik och rättigheter till specifika miljöer.
Hemligheter bör behandlas som driftdata, inte som kod eller vanliga variabler. Azure Key Vault används ofta för anslutningssträngar, certifikat och API-nycklar, medan service connections begränsar vilken pipeline som får distribuera till vilken prenumeration eller resursgrupp. I större miljöer blir även agentvalet en arkitekturfråga. Microsoft-hosted agents minskar driftbördan, medan self-hosted agents kan behövas för privata nätverk, särskilda verktygskedjor eller striktare kontroll över körmiljön.
Nedanstående exempel visar ett förenklat Azure DevOps-mönster där en applikation byggs, en artefakt publiceras och produktion ligger bakom ett environment. Exemplet förutsätter att service connection, Key Vault-behörigheter och miljön redan är skapade i Azure DevOps och Azure.
Example — Multi-stage YAML med environment och artefakt
trigger:
branches:
include:
- main
stages:
- stage: Build
jobs:
- job: BuildWebApp
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 unit tests
- script: dotnet publish src/Contoso.Web/Contoso.Web.csproj --configuration Release --output $(Build.ArtifactStagingDirectory)
displayName: Publish web app
- publish: $(Build.ArtifactStagingDirectory)
artifact: webapp
- stage: Deploy_Production
dependsOn: Build
jobs:
- deployment: DeployWebApp
environment: production
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: webapp
- task: AzureWebApp@1
inputs:
azureSubscription: sc-prod-contoso
appType: webAppLinux
appName: app-contoso-prod
package: $(Pipeline.Workspace)/webapp
Poängen är inte att YAML-filen är färdig för alla organisationer, utan att den visar separationen mellan bygg och produktion. Environment-inställningen gör att godkännanden, behörigheter och distributionshistorik kan hanteras runt produktionssteget i stället för att hårdkodas i skript. Det är nära kopplat till AZ-400-färdigheter inom CI/CD, säkerhet och processdesign.
Infrastruktur som kod och styrning i samma flöde
IaC blir kraftfullt först när det kombineras med policy, granskning och driftupptäckt. Bicep-moduler kan skapa återanvändbara byggblock för App Service, Application Insights och Key Vault. Terraform kan passa när organisationen behöver hantera flera plattformar eller redan har etablerad state-hantering. Oavsett verktyg behöver teamet bestämma var tillstånd lagras, vem som får ändra det och hur ändringar granskas innan de påverkar produktion.
För Terraform i Azure innebär det ofta state i ett lagringskonto, åtkomst styrd via Azure-behörigheter och känsliga värden i Key Vault. För Bicep ligger fokus i stället på modulstruktur, parameterfiler och konsekvent namngivning. Driftupptäckt bör hanteras som en del av arbetssättet: om någon ändrar resurser manuellt i portalen ska nästa planerings- eller valideringssteg visa avvikelsen, och teamet behöver avgöra om den manuella ändringen ska kodifieras eller återställas.
Azure Policy gör styrningen konkret. En policy kan kräva taggar, begränsa regioner eller säkerställa att diagnostikinställningar finns på kritiska resurser. När policyresultat ingår i pipelinen kan en release stoppas innan en icke-kompatibel miljö går vidare till produktion. Detta är ett praktiskt sätt att koppla efterlevnad till leveransflödet i stället för att hantera den som en separat kontroll i efterhand.
Följande Bicep-exempel illustrerar en liten del av detta mönster: en App Service-plan, en webbapp med taggar och Application Insights-instrumentering. Exemplet är avsiktligt begränsat för att visa strukturen utan att dölja resonemanget bakom moduler, policy och miljöparametrar.
Example — Bicep-resurser med taggar och observability
param location string = resourceGroup().location
param appName string = 'app-contoso-prod'
var tags = {
workload: 'contoso-web'
environment: 'prod'
owner: 'platform-team'
}
resource insights 'Microsoft.Insights/components@2020-02-02' = {
name: 'appi-contoso-prod'
location: location
kind: 'web'
tags: tags
properties: {
Application_Type: 'web'
}
}
resource plan 'Microsoft.Web/serverfarms@2022-09-01' = {
name: 'asp-contoso-prod'
location: location
tags: tags
sku: {
name: 'P1v3'
tier: 'PremiumV3'
}
}
resource app 'Microsoft.Web/sites@2022-09-01' = {
name: appName
location: location
tags: tags
properties: {
serverFarmId: plan.id
siteConfig: {
linuxFxVersion: 'DOTNETCORE|8.0'
appSettings: [
{
name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
value: insights.properties.ConnectionString
}
]
}
}
}
Detta skapar inte en fullständig produktionsplattform, men det visar hur IaC kan bära både resursdefinitioner och styrningsmetadata. I en skarp pipeline bör samma mall kompletteras med validering, policykontroll och separata parametrar per miljö. AZ-400-kopplingen ligger i designen av säkra och repeterbara leveransflöden, inte bara i syntaxen.
Säker mjukvaruförsörjningskedja
DevSecOps i AZ-400-sammanhang börjar innan pipelinen körs. Pull request-regler, skyddade brancher och krav på granskning hindrar osedda ändringar från att nå main. Code scanning, beroendegranskning och paketpolicy minskar risken för att sårbar kod eller olämpliga paket går vidare till byggsteget. I mer reglerade miljöer kan SBOM och artefaktssignering behövas för att kunna visa vad som byggdes, av vilken kod och med vilka beroenden.
Azure DevOps och GitHub har olika uttryck för dessa kontroller, men principen är densamma: produktion ska bara ta emot spårbara artefakter från en kontrollerad kedja. Det är också här Azure DevOps Marketplace kan vara relevant, eftersom Azure DevOps Marketplace innehåller tillägg för exempelvis kvalitet, säkerhet och integrationer. Ett tillägg bör dock införas med samma omsorg som annan produktionskod: rättigheter, uppdateringar och beroenden behöver förstås innan det får påverka releaseflödet.
En praktisk säkerhetsgrind består ofta av flera små kontroller i stället för ett enda stort stopp i slutet. Kodgranskning fångar designproblem, statisk analys fångar vissa sårbarhetsmönster, beroendeskanning identifierar kända risker och policykontroller granskar miljön. Om något misslyckas ska pipelinen ge tydlig återkoppling till teamet, inte bara ett rött felmeddelande som kräver felsökning i flera system.
Leveransstrategier, rollback och observability
En pipeline är inte färdig när den kan distribuera. Den behöver också kunna minska risken vid distribution och ge teamet signaler efteråt. För Azure App Service är deployment slots ett vanligt mönster för blue/green-liknande releaser, där en ny version värms upp i en slot innan trafiken växlas. Med Azure Front Door eller liknande trafikstyrning kan mer avancerade mönster användas, till exempel gradvis trafikfördelning. Feature flags via Azure App Configuration kan minska behovet av stora releaseögonblick genom att funktioner aktiveras kontrollerat efter distribution.
Rollback bör planeras innan den behövs. I vissa fall är den snabbaste återställningen att växla tillbaka till föregående slot. I andra fall krävs en ny distribution av en tidigare artefakt, särskilt om databasscheman eller externa integrationer har ändrats. Databasändringar är ofta den svåraste delen av rollback, eftersom de kan vara destruktiva eller påverka data som redan skrivits av användare. Därför bör schemaändringar designas bakåtkompatibelt när det är möjligt.
Observability binder ihop release och drift. Application Insights och Azure Monitor kan visa fel, svarstider, beroenden och användarbeteende efter en release. DORA-mått som deployment frequency, lead time for changes, change failure rate och time to restore service kan hjälpa team att se om leveranssystemet faktiskt blir bättre. De bör användas för förbättringsarbete, inte som isolerade prestationsmått för enskilda utvecklare.
Planering och samarbete utan att tappa tekniken
DevOps-provet behandlar också processer och kommunikation, vilket ibland underskattas av tekniskt starka kandidater. Azure Boards kan koppla arbetsobjekt till commits, pull requests, builds och releaser. Den kopplingen gör incidenter, ändringar och affärsprioriteringar spårbara på ett sätt som är svårt att återskapa i efterhand om arbetet bara diskuteras i chattkanaler.
I praktiken behöver teamet skilja mellan synlighet och administration. En backlog som visar risk, beroenden och releaseomfång hjälper leveransen. En backlog som främst samlar fält för rapportering skapar ofta friktion. AZ-400-perspektivet är att processerna ska stödja kontinuerligt värdeflöde: planering ska påverka hur arbete prioriteras, kod granskas, pipeline körs och driftdata används för nästa förbättring.
Kostnad och skalning i pipeline-drivna team
När fler team börjar använda CI/CD blir kostnad och kapacitet en del av DevOps-designen. Onödiga pipelinekörningar kan uppstå när varje commit triggar fullständiga integrationstester, containrar byggs utan cache eller tillfälliga testmiljöer lämnas kvar efter avslutad validering. Det märks särskilt i organisationer med många mikrotjänster eller flera parallella produktteam.
En mer hållbar modell är att låta pull requests köra snabba kontroller, medan tyngre tester och miljöskapande sker vid merge eller inför release. Cache för beroenden och containerlager kan minska repetitivt arbete, och ephemeral testmiljöer bör ha tydlig livscykel så att de tas bort automatiskt. Budgetar, taggar och kostnadsuppföljning i Azure hjälper plattformsteam att se vilka miljöer och pipelines som driver kostnad utan att behöva stoppa utvecklingsteamens arbete.
Hur AZ-400 bör studeras praktiskt
Den som förbereder sig för AZ-400 bör bygga en liten men realistisk miljö snarare än att enbart läsa om tjänsterna. Ett bra övningsscenario är en enkel webbapp med testprojekt, IaC-mall, Key Vault, Application Insights och en pipeline med minst två miljöer. Därefter kan kandidaten lägga till pull request-policyer, miljögodkännanden, säkerhetsskanning och en rollback-övning.
Detta sätt att studera avslöjar snabbt luckor som annars förblir teoretiska. Det blir tydligt hur service connections får sina rättigheter, hur variabler skiljer sig från hemligheter, hur policyfel presenteras i en pipeline och vad som händer när en release delvis lyckas. En lärarledd AZ-400-utbildning hos Readynez kan vara ett sätt att strukturera den typen av övning, men den praktiska förståelsen byggs framför allt genom att koppla varje provmål till ett fungerande leveransflöde.
Versionsstöd bör kontrolleras nära inpå både studier och implementation. Azure DevOps, GitHub, Bicep, Terraform och Microsofts provmetadata förändras över tid, och officiella Microsoft Learn-sidor är den rimliga källan för aktuell information om provets färdigheter och tjänsternas beteende. Den här artikeln bör därför läsas som ett arkitekturmönster och en praktisk tolkningshjälp, inte som en ersättning för aktuell produktdokumentation.
FAQ
Hur förbättrar Azure DevOps-verktyg produktiviteten i ett utvecklingsteam?
De förbättrar produktiviteten när de binder ihop planering, kod, bygg, test, release och driftdata i samma arbetsflöde. Värdet kommer inte bara från automationen, utan från spårbarheten: ett team kan se vilken ändring som hör till vilket arbetsobjekt, vilken build som skapade artefakten och vilken release som nådde en viss miljö.
Vilken roll spelar Azure Boards i DevOps?
Azure Boards hjälper team att hantera backlog, arbetsobjekt, sprintar och Kanban-flöden. I en DevOps-miljö blir det särskilt användbart när arbetsobjekt kopplas till pull requests, commits och releaser, eftersom tekniska ändringar då kan följas tillbaka till prioriteringar och beslut.
Hur stödjer Azure Pipelines CI/CD i praktiken?
Azure Pipelines kan bygga, testa och distribuera applikationer med YAML-baserade arbetsflöden. I praktiken bör pipelines delas upp i tydliga steg, använda environments för godkännanden och hämta hemligheter från säkra källor som Key Vault i stället för att lagra dem direkt i pipelinekonfigurationen.
Är GitHub Actions eller Azure DevOps bäst för AZ-400?
AZ-400 kräver förståelse för DevOps-lösningar i Microsofts ekosystem, och både GitHub och Azure DevOps är relevanta. Valet i en verklig organisation bör utgå från var koden redan finns, hur säkerhets- och granskningskrav ser ut, hur arbete planeras och vilka integrationer teamet behöver för CI/CD och observability.
Hur används Azure DevOps Marketplace på ett säkert sätt?
Marketplace-tillägg kan utöka Azure DevOps med funktioner för säkerhet, kvalitet, rapportering och integrationer. De bör granskas innan införande, särskilt när de får åtkomst till källkod, artefakter eller service connections, eftersom ett tillägg blir en del av leveranskedjan.
Att göra AZ-400-kunskapen användbar i drift
AZ-400 blir mest värdefullt när provmålen omsätts i ett leveransflöde som klarar verkliga krav: granskad kod, säkra hemligheter, policykontroller, repeterbar infrastruktur, observerbara releaser och en tydlig rollback-plan. Det är dessa samband som gör DevOps-kunskap användbar för teknikledare, plattformsteam, utvecklare och driftorganisationer.
Readynez kan hjälpa till med strukturerad förberedelse inför AZ-400, men den avgörande frågan är om kunskapen kan användas när en release ska godkännas, en policy stoppar en distribution eller en incident kräver snabb återställning. Ett praktiskt nästa steg är att bygga ett litet referensflöde i Azure och låta varje del av det motsvara ett område i AZ-400: planering, källkod, CI/CD, säkerhet, efterlevnad och övervakning.
