AZ-305 handler om å designe azure-administrator-exam-az-104-i-2026" data-autoinject="link_injection">Azure-infrastruktur for norske virksomheter som skal flytte en kritisk fagsystemplattform, samtidig som enkelte databaser må stå lokalt en periode og sensitive data må behandles innenfor tydelige regulatoriske rammer. Arkitekten må ikke bare velge tjenester, men forklare hvorfor nettverk, identitet, lagring, sikkerhet, beredskap og kost henger sammen.
AZ-305 handler om nettopp denne typen designarbeid. Eksamenen måler evnen til å utforme Microsoft Azure-infrastrukturløsninger som svarer på forretningskrav, tekniske begrensninger og reelle avveiinger i sky- og hybridmiljøer.
Hva AZ-305 faktisk dekker
Microsofts offisielle AZ-305-studieveiledning beskriver eksamenen som en vurdering av designkompetanse, ikke ren administrasjon. Kandidaten forventes å kunne anbefale løsninger for identitet, styring, overvåking, datalagring, forretningskontinuitet og infrastruktur som støtter arbeidsbelastninger i Azure.
Det betyr at AZ-305 skiller seg fra mange mer operasjonelle eksamener. En administrator kan bli spurt om hvordan en ressurs konfigureres, mens en løsningsarkitekt oftere må velge mellom flere mulige design og begrunne valget ut fra krav til sikkerhet, tilgjengelighet, kostnad, ytelse og drift.
Eksamenen er knyttet til Microsoft Certified: Azure Solutions Architect Expert. Sertifiseringen passer best for fagpersoner som allerede har praktisk Azure-erfaring og som jobber i skjæringspunktet mellom teknisk design, interessenthåndtering og langsiktig plattformstyring.
Bør kandidaten ta AZ-104 først, eller gå rett til AZ-305?
Det finnes ikke et formelt krav om at en kandidat må ha en bestemt tidligere sertifisering før AZ-305. Likevel er rekkefølgen viktig i praksis, fordi eksamenen forutsetter at grunnleggende Azure-begreper, driftserfaring og tjenesteforståelse allerede sitter.
Azure Fundamentals kan være nyttig for dem som trenger et felles språk for skybegreper, men AZ-305 ligger langt over introduksjonsnivå. For kandidater som jobber mye med drift, tilgangsstyring, nettverk, virtuelle maskiner, lagring og overvåking, er Azure Administrator Associate ofte en bedre mellomstasjon enn å hoppe rett til arkitektnivå.
En enkel beslutningsramme er å se på arbeidsoppgavene, ikke bare sertifiseringsstigen. Den som primært bygger og drifter Azure-ressurser, bør normalt styrke administratorferdighetene først. Den som allerede deltar i designmøter, skriver arkitekturbeslutninger, vurderer risiko og avklarer krav med sikkerhet, nettverk og forretning, kan være klar for AZ-305 selv uten en lang sertifiseringsrekke bak seg. Utviklere med tung Azure-erfaring kan også ha nytte av Azure Developer Associate, særlig dersom de designer applikasjonsplattformer, integrasjoner og distribusjonsmønstre.
Eksamenslogistikk uten tall som raskt blir utdaterte
Registrering, tilgjengelige språk, eksamensleverandør, hjelpemidler, identitetskontroll og regler for nye forsøk bør alltid sjekkes på Microsofts offisielle sertifiseringssider før bestilling. Slike detaljer kan endres, og det er mer presist å kontrollere dem i Microsoft-kontoen ved registrering enn å basere seg på gamle blogginnlegg.
Spørsmålstypene kan omfatte vanlige flervalgsoppgaver, scenariobaserte spørsmål og caser der kravene må leses nøye før et designvalg tas. Microsofts eksamenssandkasse er nyttig fordi den viser hvordan grensesnittet fungerer, slik at kandidaten ikke bruker unødvendig tid på navigasjon under selve eksamenen.
Fra krav til design: et Azure-scenario
Et realistisk AZ-305-scenario kan starte med en organisasjon som har et lokalt datasenter, en ERP-løsning med SQL-avhengigheter, flere interne webapplikasjoner og et krav om at sensitive personopplysninger skal behandles innenfor europeiske rammer. Samtidig ønsker virksomheten bedre beredskap, mer standardisert drift og lavere risiko ved endringer.
Første arkitekturvalg er ikke hvilken Azure-tjeneste som virker mest moderne. Det er å skille mellom funksjonelle krav, som at applikasjonen skal være tilgjengelig for ansatte, og ikke-funksjonelle krav, som gjenopprettingstid, datalagring, revisjonsspor, nettverkssegmentering og driftsansvar.
En mulig løsning kan være en hub-spoke-arkitektur der felles nettverkstjenester ligger i hub, mens applikasjonsmiljøer skilles i egne spoke-nettverk. Privat tilgang til PaaS-tjenester kan etableres med Private Endpoints, men da må DNS-designet være korrekt. En vanlig feil er å opprette private endepunkter uten å planlegge navneoppslag på tvers av lokale nettverk, Azure Virtual Networks og eventuelle private DNS-soner. Resultatet kan bli en løsning som ser sikker ut på tegnebrettet, men feiler i drift.
For datalagring må arkitekten vurdere om data skal replikeres mellom regioner, hvordan sikkerhetskopiering skal styres, og hvilke konsekvenser valgene har for GDPR, datasuverenitet og beredskap. Norway East og Norway West kan være relevante når kravene peker mot regional datalagring i Norge, men kryssregional katastrofegjenoppretting må fortsatt veies mot kostnad, forsinkelse, avhengigheter og regelverk.
Kostnad er heller ikke et etterarbeid. Et design med høy tilgjengelighet, privat tilkobling, replikering, avansert overvåking og sikkerhetskontroller kan være riktig, men det må være begrunnet. I AZ-305-sammenheng er det ofte mindre viktig å huske alle tjenestenavn enn å vise at valget følger kravene og at avveiingene er forstått.
Bruk Well-Architected-pilarene som eksamensstruktur
Azure Well-Architected Framework og Cloud Adoption Framework er nyttige fordi de gir et språk for å strukturere designbeslutninger. De bør ikke brukes som pynt i en besvarelse, men som en måte å sortere krav, risiko og anbefalinger på.
Når et scenariospørsmål beskriver en løsning med høye krav til oppetid, peker pålitelighet mot redundans, sikkerhetskopiering, gjenoppretting og avhengighetsanalyse. Når teksten beskriver sensitive data eller mange brukerroller, peker sikkerhet mot minste privilegium, identitetsstyring, nettverksisolasjon og overvåking. Når budsjett eller lisensbruk nevnes, bør kostoptimalisering være en del av svaret. Driftsmessig eksellense handler om automatisering, observability, endringskontroll og tydelig eierskap, mens ytelseseffektivitet handler om kapasitet, skalering og tjenestevalg.
Den mest nyttige leseteknikken er å markere kravene før alternativene vurderes. Hvis et svar gir høy tilgjengelighet, men ignorerer datalokalitet, er det ikke nødvendigvis riktig. Hvis et svar reduserer kost, men fjerner nødvendig beredskap, kan det være en felle. AZ-305 belønner evnen til å tenke som en arkitekt som må stå inne for konsekvensene av designet.
Vanlige designfeil som går igjen i Azure-miljøer
Mange kandidater forbereder seg ved å memorere tjenester, men scenariospørsmålene krever mer enn gjenkjenning. Et bedre mønster er å spørre hva løsningen må tåle, hvem som skal drifte den, hvilke grenser som finnes mellom nettverk og identitet, og hva som skjer når noe feiler.
Feilene som oftest skaper problemer, er sjelden eksotiske. De oppstår når arkitekturen mangler tydelige ikke-funksjonelle krav, når Private Endpoint-DNS ikke er planlagt, når hub-spoke-ruting blir uklar, når rolle- og identitetsgrenser blandes sammen, eller når koststyring og operasjonelt ansvar skyves til etter implementering. I et kurs- eller labmiljø kan slike feil være en irritasjon; i produksjon kan de gi driftsavbrudd, svakere sikkerhet eller en løsning som blir dyrere enn planlagt.
| Designvalg |
Fordel |
Avveiing |
Hva kandidaten bør begrunne |
| Private Endpoints for PaaS |
Reduserer offentlig eksponering. |
Krever gjennomtenkt DNS og nettverksruting. |
Hvordan navneoppslag fungerer fra Azure og lokale miljøer. |
| Hub-spoke-nettverk |
Gir sentralisert kontroll over felles tjenester. |
Kan bli komplekst uten klare rute- og eierskapsmodeller. |
Hvor trafikk inspiseres, og hvem som eier nettverksendringer. |
| Kryssregional beredskap |
Bedre robusthet ved regional feil. |
Øker kostnad og kan påvirke datalokalitet. |
Hvorfor valgt regionpar passer krav til risiko og etterlevelse. |
| Streng rollebasert tilgang |
Støtter minste privilegium og revisjon. |
Krever moden identitetsforvaltning. |
Hvordan roller, grupper og ansvar skiller drift fra eierskap. |
Et praktisk øvingsopplegg som ligner virkeligheten
Den beste forberedelsen kombinerer lesing med design og testing. En kandidat bør bygge en liten landing zone i en trygg sandkasse, dokumentere valgene og deretter forsøke å forklare hvorfor løsningen er utformet slik den er.
- Opprett en enkel abonnementstruktur med navngiving, tagging og grunnleggende policy.
- Bygg et hub-spoke-nettverk med tydelige subnett, ruting og sikkerhetsgrenser.
- Legg til identitets- og tilgangsmodell som skiller plattformeierskap fra applikasjonseierskap.
- Publiser en enkel arbeidsbelastning med privat tilgang til en datatjeneste og test DNS-oppslag.
- Konfigurer sikkerhetskopiering eller gjenoppretting og dokumenter hva som faktisk skjer ved feil.
- Vurder kost, overvåking og driftsansvar før designet anses som ferdig.
Poenget er ikke å bygge en stor plattform. Poenget er å utvikle arkitektens vane med å koble krav til konsekvenser. Et strukturert AZ-305-løp hos Readynez kan gi nyttig rammeverk rundt dette arbeidet, men den avgjørende læringen skjer når kandidaten selv må forklare og forsvare designvalgene.
Hva arbeidsgivere ser etter etter AZ-305
AZ-305 kan validere viktig kompetanse, men arbeidsgivere vurderer arkitektkandidater på mer enn sertifikatet. De ser etter evnen til å skrive tydelige beslutningsnotater, beskrive risiko, forklare hvorfor et alternativ ble valgt bort, og samarbeide med sikkerhet, drift, utvikling og forretning.
En sterk Azure-arkitekt kan oversette krav til et design som andre kan implementere og drifte. Det innebærer å dokumentere forutsetninger, synliggjøre kost- og sikkerhetskonsekvenser, og holde designet enkelt nok til at det kan forvaltes over tid.
Der AZ-305 gir mest verdi
AZ-305 gir mest verdi når kandidaten allerede har praktisk erfaring og bruker eksamensforberedelsen til å forbedre designmetodikken sin. Sertifiseringen bør ikke behandles som en øvelse i å huske Azure-tjenester, men som en strukturert måte å trene på arkitekturvalg under realistiske begrensninger.
Den mest effektive neste handlingen er å sammenligne egne prosjekter med AZ-305-målene, identifisere hull i nettverk, identitet, beredskap, styring og kost, og deretter bygge små scenarier som tester disse områdene. Readynez kan støtte forberedelsen med instruktørledet AZ-305-trening, men varig verdi kommer når kunnskapen brukes til bedre beslutninger i faktiske Azure-miljøer.
FAQ
Hva måler AZ-305-eksamenen?
AZ-305 måler evnen til å designe Azure-løsninger for identitet, styring, overvåking, datalagring, forretningskontinuitet og infrastruktur. Kandidaten må vise at anbefalingene oppfyller kravene i scenarioet, ikke bare at vedkommende kjenner tjenestenavnene.
Er AZ-104 obligatorisk før AZ-305?
AZ-104 er ikke et formelt krav for å ta AZ-305, men administratorerfaring er svært nyttig. Kandidater som mangler praktisk erfaring med Azure-ressurser, nettverk, tilgangsstyring og overvåking, bør vanligvis styrke dette før de går inn i arkitektstoffet.
Hvordan kan AZ-305 bidra til bedre forretningskontinuitet?
Forberedelsen til AZ-305 trener kandidaten i å vurdere tilgjengelighet, sikkerhetskopiering, gjenoppretting, regionvalg og avhengigheter som en samlet designbeslutning. Det gjør det lettere å lage løsninger som tåler feil og samtidig er realistiske å drifte.
Hvordan bør norske virksomheter tenke om regionvalg i Azure?
Norske virksomheter bør vurdere datalokalitet, GDPR, beredskap og tjenestetilgjengelighet samlet. Norway East og Norway West kan være relevante for norske krav, men designet må fortsatt forklare hvordan eventuell replikering, gjenoppretting og tilgangsstyring påvirker risiko og etterlevelse.
Hva er den beste måten å øve praktisk til AZ-305 på?
En god øvelse er å bygge en liten landing zone i en sandkasse, inkludert policy, navngiving, nettverk, identitet, privat datatilgang, overvåking og gjenoppretting. Kandidaten bør dokumentere valgene og forklare dem med Well-Architected-pilarene som struktur.
