Ett designprov för Azure-arkitekter, AZ-305 bedömer förmågan att designa Microsoft azure-solutions-architect" data-autoinject="link_injection">Azure-infrastrukturlösningar för identitet, styrning, data, affärskontinuitet, nätverk och beräkningsplattformar.
Provet hör till certifieringen Microsoft Certified: Azure Solutions Architect Expert och riktar sig till personer som redan arbetar nära Azure-miljöer på en mer strategisk nivå. Det handlar mindre om att klicka sig igenom en enskild konfiguration och mer om att välja rätt arkitektur när kraven drar åt olika håll: kostnad mot motståndskraft, latens mot säkerhet, standardisering mot teamens behov av autonomi.
Senast uppdaterad: juli 2026. Microsoft kan ändra provets innehåll, frågeformat och logistiska detaljer över tid, så den officiella skills outline för AZ-305 bör alltid vara den primära källan när förberedelserna planeras.
Vad AZ-305 egentligen mäter
AZ-305 mäter designförmåga. Kandidaten förväntas kunna översätta affärskrav och tekniska begränsningar till en genomtänkt Azure-arkitektur, inte bara känna igen produktnamn. Det innebär att provet ofta testar resonemang kring varför en viss lösning passar bättre än ett alternativ i ett givet scenario.
De centrala områdena omfattar identitet, styrning, övervakning, datalagring, affärskontinuitet och infrastruktur. I praktiken innebär det exempelvis att kunna designa en identitetsmodell med Microsoft Entra ID, välja rätt nätverksmönster för en hybridmiljö, planera backup och återställning med rätt mål för RTO och RPO samt införa styrning med Azure Policy, RBAC, taggar och budgetar innan arbetslaster börjar växa okontrollerat.
En viktig skillnad jämfört med mer driftorienterade prov är att AZ-305 ofta börjar med ett problem snarare än en uppgift. En administratör kan få frågan hur en resurs konfigureras. En arkitekt måste avgöra vilka begränsningar som spelar störst roll, vilka risker som behöver reduceras och vilken lösning som ger rimlig balans mellan säkerhet, kostnad, prestanda och driftbarhet.
När AZ-305 är rätt nästa steg
Det finns inga formella krav på att först klara andra Azure-prov innan AZ-305. Samtidigt rekommenderar Microsoft avancerad erfarenhet av Azure-administration, utveckling och DevOps, vilket gör tidigare rollbaserad erfarenhet mycket viktig. En praktisk beslutsram är att välja AZ-305 när arbetet redan omfattar design och granskning av lösningar, särskilt inom governance, nätverk, identitet, säkerhet och kontinuitet.
Den som främst arbetar med daglig drift, incidenthantering och resurskonfiguration kan ofta vinna på att först bygga en stabil administrativ grund genom Azure Administrator Associate. Den som kommer från applikationsutveckling och arbetar med API:er, tjänsteintegration, identitet i applikationer och distributionsflöden kan i stället ha större nytta av Azure Developer Associate innan arkitektnivån blir aktuell.
Azure Fundamentals kan vara relevant för den som behöver ett gemensamt språk för molnbegrepp, tjänstemodeller och grundläggande Azure-koncept. För en erfaren Azure-specialist är AZ-900 däremot sällan den största flaskhalsen. Den verkliga frågan är om personen kan väga designalternativ mot varandra utan att fastna i isolerade tjänstefunktioner.
Från provområden till verkliga Azure-arkitekturer
AZ-305 blir lättare att förstå när provområdena kopplas till konkreta arkitekturmönster. En modern Azure-miljö börjar ofta med en landing zone: prenumerationsstruktur, namngivning, taggning, policyer, roller, loggning, säkerhetsbaslinjer och kostnadskontroll. Det kan verka administrativt, men det är arkitekturarbete eftersom besluten styr hur säkert och skalbart organisationen kan bygga senare.
Ett vanligt exempel är en hub-spoke-design. Hubben innehåller gemensamma nätverkstjänster som anslutning mot lokala datacenter, brandvägg, DNS och delade säkerhetskomponenter. Spokes används för separata arbetslaster eller team. Mönstret ger tydlig separation och central kontroll, men kräver genomtänkt routing, namnuppslagning och hantering av private endpoints. Hybridnätverk underskattas ofta i studierna inför AZ-305, särskilt när asymmetrisk routing, DNS-design och faktisk latens påverkar både användarupplevelse och felsökning.
Styrning är ett annat område där provet speglar verkligheten. Azure Policy, RBAC, management groups och budgetar bör inte behandlas som efterarbete. En liten sandbox där dessa delar etableras före arbetslasten ger bättre träning än en miljö där virtuella maskiner, databaser och nätverk skapas först och styrningen läggs på i efterhand. Det tränar samma tänk som behövs i designfrågor: vilka beslut måste standardiseras centralt, och vilka kan lämnas till applikationsteam?
Microsofts Well-Architected Framework är användbart som referensram eftersom det tvingar fram frågor om tillförlitlighet, säkerhet, kostnadsoptimering, operativ excellens och prestanda. I AZ-305-sammanhang är ramverket mest värdefullt när det används för att analysera kompromisser. En lösning med högre redundans kan förbättra tillgänglighet men öka kostnad och komplexitet. En strikt nätverksmodell kan stärka säkerheten men skapa friktion för utvecklingsteam om den inte kombineras med tydliga plattformstjänster.
Vanliga fallgropar vid förberedelser
Den vanligaste fallgropen är att studera AZ-305 som en katalog över Azure-tjänster. Kandidater kan då känna igen namn som Azure Site Recovery, Azure Backup, Azure Firewall, Azure Policy och Microsoft Entra ID, men ändå missa poängen i scenariobaserade frågor. Provet belönar resonemang: varför en viss återställningsstrategi passar ett RPO-krav, varför en tenant-gräns påverkar identitetsdesign eller varför ett nätverksval förändrar både drift och säkerhet.
En annan svag punkt är att inte koppla kontinuitetskrav till konkreta designval. RTO och RPO bör inte behandlas som teoretiska begrepp. De påverkar val av backupfrekvens, replikeringsmodell, databasarkitektur, regionstrategi och testning av återställning. På samma sätt kräver hybridanslutning mer än att känna till skillnaden mellan VPN och ExpressRoute; designen behöver ta hänsyn till routing, DNS, segmentering, beroenden och vad som händer när en länk degraderas snarare än faller bort helt.
Det är också lätt att lägga för lite tid på governance. Azure Policy och tidigare begrepp som Blueprints dyker ofta upp i diskussioner om standardisering, men den praktiska frågan är hur organisationen inför kontroller utan att stoppa leveransflödet. En arkitekt behöver kunna förklara vilka regler som ska vara blockerande, vilka som bör vara audit-baserade och hur avvikelser hanteras när affärskrav kräver undantag.
En praktisk förberedelseplan
En effektiv förberedelse börjar med Microsofts officiella skills outline och fortsätter med praktisk designträning. Målet är att kunna läsa ett scenario, identifiera krav och begränsningar, föreslå en lösning och motivera bortvalen. Det räcker inte att lösningen fungerar tekniskt; den måste passa organisationens mål.
- Läs den officiella skills outline och markera områden där erfarenheten främst är teoretisk.
- Bygg en liten landing zone i en sandbox med management groups, RBAC, Azure Policy, taggar, budgetar och central loggning.
- Designa en enkel hub-spoke-miljö och dokumentera val för DNS, routing, private endpoints och anslutning till lokala nät.
- Välj en arbetslast och skriv ett kort designbeslut för backup, återställning, övervakning, identitet och kostnadskontroll.
- Jämför designen mot Well-Architected Framework och justera där riskerna är tydligast.
- Öva på Microsofts provdemo för att förstå frågeformatet innan skarp provdag.
Deklarativ infrastruktur är särskilt användbar i förberedelserna. Genom att beskriva miljön med Bicep eller ARM-mallar blir det tydligare vilka beslut som är arkitekturbeslut och vilka som är engångskonfigurationer. Ett README eller en kort ADR per designval tränar dessutom förmågan att motivera arkitektur, vilket är närmare AZ-305 än ren syntaxträning.
Den som vill ha strukturerat stöd kan använda en utbildningsleverantör som Readynez som komplement till Microsoft Learn, labbar och egen sandbox-träning. Värdet ligger då främst i att få scenarier, repetition och praktiska övningar samlade, inte i att ersätta den egna designträningen.
Provdag och format
AZ-305 kan innehålla flera frågetyper, däribland flervalsfrågor, fallstudier och scenariobaserade moment. Microsoft tillhandahåller en exam sandbox där kandidater kan bekanta sig med gränssnittet och frågetyperna utan att det påverkar något resultat.
| Område |
Vad kandidaten bör tänka på |
| Tid |
Källtexten anger 140 minuter inklusive instruktioner, granskning och valfri feedback, men kontrollera alltid aktuell information hos Microsoft. |
| Paus |
Provet kan innehålla ett schemalagt uppehåll, och tiden kan fortsätta att räknas under pausen enligt den information som gäller vid bokning. |
| Frågeformat |
Fallstudier kräver ofta att kandidaten läser krav noggrant och skiljer absoluta krav från önskemål. |
| Resultat |
Score-rapporten bör användas för att identifiera svaga kompetensområden, särskilt om provet behöver göras om. |
Detaljer om format, bokning, tillgänglighet och eventuella ändringar bör kontrolleras på Microsofts officiella certifieringssidor före provdagen. Sådana uppgifter kan ändras snabbare än en artikel hinner uppdateras.
Att använda AZ-305-kunskapen i arbetet
Den praktiska nyttan av AZ-305 visar sig när arkitekturvalen blir spårbara och begripliga för andra. En Azure-lösningsarkitekt behöver kunna förklara varför en arbetslast placeras i en viss region, varför identitetsmodellen ser ut som den gör, varför vissa policyer är centrala och hur återställning faktiskt ska testas. Det är samma typ av resonemang som ofta avgör kvaliteten i verkliga designgranskningar.
En väl förberedd kandidat bör kunna diskutera både officiella krav och fältpraxis. Officiella krav kommer från Microsofts provmål och dokumentation. Fältpraxis handlar om hur arkitekturbeslut fungerar när flera team, budgetramar, revisionskrav, äldre system och hybridberoenden möts. AZ-305 blir mest värdefullt när båda perspektiven hålls isär men används tillsammans.
Vägen vidare för Azure-arkitekter
AZ-305 passar bäst för personer som redan rör sig från implementation mot designansvar. Certifieringen kan vara ett tydligt mål, men den verkliga utvecklingen sker när kandidaten tränar på att formulera krav, jämföra alternativ och dokumentera beslut på ett sätt som andra kan förstå och förvalta.
Den mest användbara nästa åtgärden är att välja en befintlig eller tänkt arbetslast och designa den från grunden: identitet, nätverk, governance, data, kontinuitet, övervakning och kostnad. När lösningen sedan granskas mot Microsofts skills outline och Well-Architected Framework blir AZ-305-förberedelsen samtidigt en övning i praktisk Azure-arkitektur.
FAQ
Vilka färdigheter mäts i AZ-305-provet?
AZ-305 mäter förmågan att designa lösningar för identitet, styrning, övervakning, datalagring, affärskontinuitet och Azure-infrastruktur. Kandidaten behöver kunna tolka krav och föreslå arkitekturer som balanserar säkerhet, kostnad, prestanda, tillgänglighet och driftbarhet.
Måste man ha AZ-104 eller AZ-204 före AZ-305?
Nej, de är inte formella krav för AZ-305. Däremot kan AZ-104 vara en stark grund för den som kommer från drift och administration, medan AZ-204 kan vara relevant för den som kommer från utveckling och applikationsintegration. Valet bör styras av faktisk erfarenhet och vilka luckor som behöver fyllas före arkitektnivån.
Hur hjälper AZ-305-kunskap med affärskontinuitet?
AZ-305 tränar kandidaten att koppla kontinuitetskrav till designval. Det omfattar exempelvis backupstrategi, återställning, hög tillgänglighet, regionval, testning och hur RTO och RPO påverkar arkitekturen. Nyttan ligger i att kunna designa lösningar som fortsätter fungera eller kan återställas på ett kontrollerat sätt när incidenter inträffar.
Vad är examensformatet för AZ-305?
Provet kan innehålla flervalsfrågor, fallstudier och scenariobaserade frågor. Microsofts exam sandbox är ett bra sätt att bekanta sig med gränssnittet och frågetyperna före provdagen, men aktuella detaljer bör alltid kontrolleras hos Microsoft.
Vilka praktiska övningar är mest användbara inför AZ-305?
De mest värdefulla övningarna är sådana som tvingar fram designbeslut. Bygg en liten landing zone, skapa en hub-spoke-modell, konfigurera policyer och roller, planera backup och återställning för en arbetslast och dokumentera varför varje val gjordes. Det ger bättre förberedelse än att enbart läsa tjänstebeskrivningar.
