AZ-305 är arkitektprovet för att bedöma om Azure-lösningar kan utformas med rätt balans mellan designbeslut, styrning, säkerhet, kostnad, prestanda och driftbarhet, snarare än enbart tjänstekännedom till.
AZ-305 är provet bakom microsoft.com/en-us/credentials/certifications/azure-solutions-architect/">Microsoft Certified: Azure Solutions Architect Expert, och det testar hur väl en kandidat kan designa Azure-lösningar utifrån affärskrav och tekniska begränsningar. Den som förbereder sig behöver därför förstå mer än enskilda Azure-tjänster. Provet handlar om arkitektur: identitet, styrning, övervakning, data, affärskontinuitet och infrastruktur i scenarier där flera svar kan verka rimliga.
Uppdaterad: 2026. Microsoft kan ändra provets domäner och innehåll över tid, så den officiella AZ-305 skills outline bör alltid kontrolleras nära inpå bokning. Den praktiska kärnan är ändå stabil: en Azure Solutions Architect måste kunna översätta krav till en design som går att säkra, drifta, återställa och kostnadsstyra.
Vad AZ-305 faktiskt mäter
En vanlig missuppfattning är att AZ-305 främst belönar den som kan flest tjänstenamn. I praktiken premieras förmågan att välja rätt mönster för en given situation. En kandidat kan exempelvis behöva avgöra om en applikation bör exponeras via Application Gateway, Front Door eller en privat åtkomstmodell, och samtidigt beakta identitet, loggning, redundans, kostnadsansvar och operativa rutiner.
Microsofts officiella provguide beskriver domänerna som designområden snarare än produktkapitel. Det gör provet mer likt arkitektarbete i verkligheten: kraven är sällan isolerade. Ett beslut om datalagring påverkar återställningstid, nätverksdesign, kryptering, åtkomstmodell och kostnad. Ett beslut om regioner påverkar latens, efterlevnad, backup, failover och driftsättning.
Ett användbart sätt att närma sig varje AZ-305-scenario är att först sortera kraven, därefter identifiera designmönstret, sedan välja tjänster och sist beskriva hur lösningen ska övervakas och styras. För identitet kan mönstret vara Zero Trust med villkorad åtkomst och minst privilegium. För nätverk kan det vara privat åtkomst med segmentering och Private Endpoints. För dataskydd kan det vara geo-replikering, backup och testad återställning enligt definierade RTO- och RPO-krav.
Domän för domän: färdigheter och designval
Den första centrala domänen rör identitet, styrning och övervakning. Här behöver kandidaten kunna designa åtkomst med Microsoft Entra ID, roller, grupper, privilegierade administrativa flöden och samarbete mellan organisationer. I moderna miljöer dyker hybrididentitet, flera tenants, B2B-samarbete och Azure Arc oftare upp som arkitekturfrågor. Det räcker därför inte att veta var en inställning finns; kandidaten behöver förstå hur identitetsflöden, åtkomstgränser och ansvarsfördelning påverkar helheten.
Governance-delen bedömer indirekt om arkitekten tänker på styrning från början. Taggstrategi, budgetar, Azure Policy, resurshierarki, hanteringsgrupper och kostnadsuppföljning bör designas in i modellen, inte läggas till efter att miljön redan vuxit. FinOps har blivit en mer praktisk del av arkitektrollen, eftersom många organisationer vill att molndesign ska koppla tekniska val till kostnadsägarskap och förutsägbar drift.
Övervakning handlar inte bara om att slå på loggar. Arkitekten behöver avgöra vilka signaler som krävs för drift, säkerhet och efterlevnad, hur larm ska prioriteras och hur loggar ska skyddas och behållas. En design som använder Azure Monitor, Log Analytics, Application Insights och Microsoft Defender for Cloud behöver samtidigt ta hänsyn till kostnad, datavolymer, incidentrutiner och åtkomst till driftdata.
Datalagringsdomänen testar valet mellan relationsdatabaser, NoSQL, objektlagring, filer, analyslager och integrationsmönster. Ett scenario kan beskriva global åtkomst, låg latens, regulatoriska krav och behov av transaktionell konsistens. Då behöver kandidaten väga tillgänglighet, partitionering, replikering, kryptering, backup och nätverksåtkomst mot varandra. En vanlig fallgrop är att välja en datatjänst utifrån prestanda men glömma återställningskrav eller privat anslutning.
Affärskontinuitet är en av de tydligaste skiljelinjerna mellan administratörs- och arkitektnivå. AZ-305 förväntar sig att kandidaten kan resonera kring RTO, RPO, regionpar, zonredundans, geo-redundans, backup och disaster recovery. Många förberedelser blir svaga här eftersom kandidater läser om Azure Backup och Site Recovery men inte tränar på att matcha återställningsmål mot tjänstval och kostnad. PaaS-tjänster behöver också backup- eller återställningsstrategi; det är ett vanligt misstag att behandla dem som om plattformen automatiskt löser alla dataskyddskrav.
Infrastrukturdomänen omfattar compute, nätverk, containrar, integration och plattformsval. Här ingår beslut om virtuella nätverk, hub-spoke, routing, brandväggar, lastbalansering, privata slutpunkter, Kubernetes, App Service, Functions och virtuella maskiner. Det viktigaste är inte att memorera varje SKU, utan att kunna motivera varför en arbetslast ska köras på en viss plattform, hur den isoleras, hur den skalas och hur den uppdateras utan onödig risk.
Scenarier som visar hur provet tänker
Anta att ett företag ska migrera en intern affärsapplikation till Azure. Applikationen hanterar känsliga kunddata, ska bara nås från företagsnätet och behöver kunna återställas snabbt efter ett regionalt avbrott. Ett ytligt svar fokuserar på databasen eller den virtuella maskinen. Ett arkitektursvar börjar med åtkomstmodellen, nätverksisoleringen, regionstrategin, identitetsflödet, krypteringen, backupen och hur återställning ska testas.
I ett sådant scenario kan en privat åtkomstmodell med Private Endpoints, segmenterade virtuella nätverk och centraliserad inspektion vara rimlig, men den måste vägas mot operativ komplexitet. Om RTO är kort och RPO nära noll kan geo-replikering eller aktiv-passiv design krävas, vilket påverkar kostnaden. Om organisationen saknar etablerad driftmodell kan en tekniskt elegant lösning bli svår att förvalta. AZ-305 tenderar att belöna den lösning som bäst matchar kraven, inte den som använder flest avancerade tjänster.
Ett annat exempel är en organisation som vill standardisera nya Azure-prenumerationer för flera team. Det provlika problemet handlar då mindre om en enskild workload och mer om landing zones, policy, nätverk, identitet och kostnadsstyrning. En genomtänkt design använder hanteringsgrupper, Azure Policy, rollbaserad åtkomst, namngivnings- och taggningsprinciper, samt en modell för budgetar och rekommendationer från Advisor. Det visar också varför styrning bör byggas före expansionen, inte städas upp i efterhand.
Det tredje scenariot kan handla om ett globalt SaaS-system med användare i flera regioner. Kandidaten behöver väga latens mot dataplacering, global lastbalansering mot privat åtkomst, och cache- eller replikeringsteknik mot konsistenskrav. Om scenariot nämner efterlevnad eller dataintegritet blir svaret sällan bara ”lägg till fler regioner”. Arkitekten måste beskriva var data får ligga, hur nycklar och åtkomst hanteras, hur incidenter upptäcks och hur failover återställs till normalläge.
Provliknande frågor med resonemang
Följande frågor är inte hämtade från Microsofts prov och ska inte ses som svarsdumpar. De är konstruerade för att träna samma typ av resonemang som AZ-305 ofta kräver: att väga flera krav och välja en design som passar helheten.
Scenario 1: En intern applikation i Azure SQL Database ska endast nås från företagets privata nätverk. Säkerhetsteamet vill minimera offentlig exponering, medan driftteamet behöver tydlig övervakning och felsökning. Det mest rimliga resonemanget är att börja med nätverksåtkomsten, exempelvis privat anslutning och DNS-design, och därefter säkerställa loggning, åtkomstkontroll och backup. Ett svar som bara föreslår brandväggsregler kan missa kravet på minimerad exponering.
Scenario 2: En affärskritisk tjänst har ett uttalat krav på kort återställningstid och mycket liten dataförlust vid regional störning. Här måste RTO och RPO styra designen. Kandidaten bör jämföra zonredundans, geo-replikering, aktiv-passiv eller aktiv-aktiv design och kostnadseffekten av varje val. En enkel nattlig backup kan vara otillräcklig om återställningsmålen är strikta.
Scenario 3: Ett företag låter flera produktteam skapa Azure-resurser men vill undvika ostandardiserade namn, saknade taggar och öppna nätverksregler. Det arkitektoniska svaret ligger i governance: hanteringsgrupper, Azure Policy, rollmodeller, budgetar och kontinuerlig uppföljning. Att manuellt granska varje prenumeration skalar dåligt och ger svagare kontroll än en policybaserad modell.
Så byggs en praktisk studieplan
En stark studieplan börjar med den officiella guiden för Exam AZ-305 och jämför den med den egna erfarenheten. Kandidater som redan arbetat med Azure-administration kan ofta hantera resursgrupper, nätverk och identitet, men behöver lägga mer tid på arkitekturavvägningar. Den som kommer från utveckling kan behöva förstärka governance, nätverk och affärskontinuitet.
För den som saknar grundläggande Azure-kunskap kan Azure Fundamentals ge terminologin, medan Azure Administrator Associate ger en mer praktisk administrativ bas. Microsofts egen inlärningsväg för Azure-arkitektförutsättningar är också relevant när kandidaten behöver fylla luckor före AZ-305. En utbildningsleverantör som Readynez kan användas som struktur runt detta, men värdet kommer främst när teori kopplas till scenarier och praktiska designövningar.
Den praktiska delen bör innehålla en liten enterprise landing zone i ett testabonnemang. Bygg den med Bicep eller Terraform, använd Azure Policy för att kräva taggar och begränsa riskabla konfigurationer, separera nätverk för delade tjänster och arbetslaster, och testa privat åtkomst till minst en PaaS-tjänst. Det behöver inte vara stort. Poängen är att se hur identitet, nätverk, policy, kostnad och loggning hänger ihop när de faktiskt deployas.
En bra övning är att dokumentera varje större designval som en kort Architecture Decision Record. Skriv kravet, alternativen, beslutet och konsekvenserna. Det tränar exakt den typ av resonemang som provet kräver och motverkar en vanlig förberedelsefälla: att memorera tjänstelistor utan att kunna förklara varför en lösning passar ett visst krav.
Azure Well-Architected Framework bör användas som kalibrering, särskilt för driftsäkerhet, säkerhet, kostnadsoptimering, operativ excellens och prestanda. Efter att en labbmiljö byggts kan kandidaten göra en Well-Architected Review och jämföra resultatet med egna antaganden. Det blottar ofta luckor som inte syns i läsning, till exempel saknad backup för PaaS-data, otydliga larm, för breda behörigheter eller nätverksvägar som kringgår avsedd segmentering.
Vanliga misstag i AZ-305-förberedelser
Det första misstaget är att läsa provguiden som en katalog över Azure-tjänster. AZ-305 kräver visserligen produktkunskap, men tjänsterna testas i kontext. Om ett scenario nämner regulatoriska krav, driftansvar, flera regioner eller hybrida miljöer förändras den bästa designen. Därför bör varje studietillfälle innehålla frågan: vilket krav styr beslutet?
Det andra misstaget är att behandla RTO och RPO som teoribegrepp. I praktiken avgör de om backup räcker, om replikering krävs, om failover måste automatiseras och hur ofta återställning ska testas. Kandidater som inte övar på dessa avvägningar riskerar att välja lösningar som är tekniskt möjliga men fel för verksamhetens tolerans mot avbrott och dataförlust.
Det tredje misstaget är att underskatta nätverksisolering och privata slutpunkter. Många verkliga Azure-arkitekturer misslyckas inte för att compute-valet var fel, utan för att åtkomstvägar, DNS, brandväggsregler och identitetsgränser blev otydliga. För AZ-305 är det därför viktigt att kunna resonera om hur trafik rör sig, vem som får initiera anslutningar och var inspektion och loggning sker.
Hur färdigheterna används efter provet
AZ-305 är relevant eftersom det ligger nära vad organisationer förväntar sig av en molnarkitekt. Rollen bedöms allt oftare på kvaliteten i designbeslut: hur landing zones byggs, hur policy efterlevs, hur kostnader kopplas till ägarskap, hur hybrida miljöer hanteras och hur Zero Trust-principer omsätts i åtkomstflöden. Det är en annan kompetens än att enbart kunna administrera resurser.
I arbetslivet behöver en Azure Solutions Architect också kunna kommunicera kompromisser. En säkrare design kan öka komplexiteten. En högre tillgänglighetsnivå kan öka kostnaden. En snabbare leverans kan skapa teknisk skuld om governance saknas. Den som kan förklara dessa avvägningar tydligt blir mer användbar än den som bara presenterar en lista med tjänster.
FAQ
Vilka förkunskaper behövs för AZ-305?
Kandidater bör ha praktisk erfarenhet av Azure-administration, identitet, nätverk, säkerhet, dataplattformar och drift. Det är också värdefullt att förstå DevOps och infrastruktur som kod, även om AZ-305 främst testar design snarare än daglig implementation.
Behöver man ta AZ-104 före AZ-305?
Microsofts certifieringskrav och förutsättningar bör kontrolleras på den officiella certifieringssidan, eftersom regler kan ändras. Ur ett kunskapsperspektiv är AZ-104-innehåll mycket användbart eftersom arkitekturfrågor ofta bygger på att kandidaten förstår hur Azure-resurser faktiskt administreras.
Hur lång tid tar det att förbereda sig?
Det beror på tidigare erfarenhet. En senior Azure-administratör kan ofta fokusera på design, Well-Architected-principer och affärskontinuitet, medan en kandidat med mindre Azure-erfarenhet behöver mer tid i labbmiljö. Det viktigaste är att mäta förberedelsen mot scenarier, inte mot antal lästa sidor.
Vilka resurser är viktigast?
Den officiella AZ-305-studieguiden, Microsoft Learn, Azure Well-Architected Framework och praktiska labbar bör utgöra grunden. Komplettera gärna med egna arkitekturanteckningar, ADR:er och scenariobaserade övningsfrågor där varje svar motiveras med krav och kompromisser.
Är AZ-305 mest relevant för arkitekter eller administratörer?
Provet är designat för lösningsarkitekter, men seniora administratörer kan ha en stark utgångspunkt om de redan arbetar med identitet, nätverk, governance och drift. Skillnaden är att AZ-305 kräver ett bredare designperspektiv där tekniska beslut kopplas till verksamhetskrav.
Att omsätta AZ-305-kunskapen i en hållbar arkitekturpraktik
Den mest effektiva vägen till AZ-305 är att kombinera Microsofts officiella skills outline med praktisk designträning. Bygg små lösningar, dokumentera beslut, testa återställning, kör en Well-Architected Review och granska hur policy, kostnad, identitet och nätverk fungerar tillsammans.
Readynez kan vara ett stöd för kandidater som vill ha en tydligare struktur, men provets verkliga värde ligger i arbetssättet det tränar fram. Den som kan läsa ett scenario, identifiera kraven och förklara en balanserad Azure-design har byggt färdigheter som är användbara långt efter certifieringsdagen.
