Hva kan du gjøre etter AZ-305?

Når infrastrukturløsninger på Azure må være sikre, robuste og kostnadsbevisste, er AZ-305 microsoft-certified-azure-administrator-exam" data-autoinject="link_injection">Microsoft-eksamenen for fagfolk som skal designe dem.

Publisert og oppdatert: 2026.

For en norsk Azure-administrator, utvikler, DevOps-ingeniør eller teknisk leder betyr AZ-305 sjelden at karrieren plutselig skifter retning av seg selv. Verdien ligger i at sertifiseringen gir et språk for arkitekturvalg: identitet, nettverk, styring, dataplattform, kontinuitet, migrasjon og kostnad må ses i sammenheng. Det er denne helheten arbeidsgivere normalt ser etter når de vurderer kandidater til arkitektroller, senior plattformroller eller konsulentoppdrag.

Eksamenen heter offisielt Designing Microsoft Azure Infrastructure Solutions. Sammen med Azure Administrator-sertifiseringen kan den inngå i Microsoft Certified: Azure Solutions Architect Expert. Det er likevel viktig å skille mellom sertifikat og rollemodenhet. AZ-305 viser at kandidaten forstår hva som bør designes og hvorfor, men arbeidshverdagen krever i tillegg evne til å dokumentere beslutninger, få med sikkerhet og drift, forklare kostnadskonsekvenser og håndtere kompromisser.

Hva AZ-305 faktisk signaliserer til norske arbeidsgivere

I norske stillingsannonser brukes titler som Azure arkitekt, skyarkitekt, løsningsarkitekt, plattformarkitekt, teknisk arkitekt og cloud consultant ofte om overlappende oppgaver. Noen virksomheter legger rollen nær strategi og virksomhetsarkitektur, mens andre forventer at arkitekten også skriver Bicep, Terraform eller CI/CD-maler. Derfor bør AZ-305 forstås som et arkitekturfundament, ikke som en garanti for én bestemt stillingstittel.

Den vanligste misforståelsen etter AZ-305 er at arkitekten alene eier hele løsningen. I praksis bemannes norske Azure-miljøer ofte tverrfaglig. Plattformteamet eier gjerne infrastruktur som kode, miljøstandarder og driftbarhet. Sikkerhetsteamet setter krav til identitet, logging, sårbarhetshåndtering og etterlevelse. Data- og applikasjonsteam eier informasjonsmodell, integrasjoner og tjenestespesifikke krav. Arkitektens verdi ligger i å koble disse perspektivene til én beslutningsmodell som tåler revisjon, budsjettgjennomgang og produksjonsdrift.

Dette er også grunnen til at arbeidsgivere ofte verdsetter praktisk erfaring med Terraform eller Bicep, Kubernetes, Zero Trust-prinsipper, hybrid nettverksdesign og kjennskap til norske kravmiljøer som NSM-grunnprinsippene og Datatilsynets forventninger. Eksamensscore er mindre interessant enn om kandidaten kan forklare hvorfor en løsning er valgt, hvilke risikoer som gjenstår, og hva som skjer når kostnads- eller sikkerhetskrav endres.

Karriereveier etter AZ-305

Etter AZ-305 er det naturlig å vurdere tre hovedspor: intern arkitektrolle, konsulentrolle eller en mer teknisk plattformingeniørrolle. Valget bør ikke tas ut fra tittel alene. Det bør tas ut fra hvor kandidaten ønsker å bruke mest tid: beslutningsarbeid, kundedialog, leveranseansvar eller teknisk standardisering.

Rolleforskjellene blir tydelige i ansvarsgrensene. En cloud architect eller solutions architect skal ofte definere prinsipper og avklare kompromisser, mens plattformingeniøren gjør mønstrene repeterbare. En dataarkitekt vil eie valg rundt datamodell, integrasjon og analyseplattform, mens en programvarearkitekt vil være nærmere applikasjonsdesign og utviklingspraksis. En ledende arkitekt må i tillegg kunne forankre tekniske valg hos ledelse, økonomi, sikkerhet og produktmiljøer.

Readynez dekker AZ-305 som en del av strukturert sertifiseringsforberedelse, men selve karriereverdien kommer først når kunnskapen omsettes i konkrete arbeidsartefakter: referansearkitektur, beslutningslogg, kostmodell, policysett og en plan for drift og forbedring.

Lønn og etterspørsel i Norge: hvordan tall bør leses

Det er fristende å lete etter ett lønnstall for «Azure Solutions Architect» i Norge, men det gir ofte et unøyaktig bilde. Stillingsinnhold, region, sektor, konsulentandel, personalansvar, sikkerhetsklarering og teknisk dybde påvirker nivået. En arkitekt i et offentlig digitaliseringsprogram vurderes ikke nødvendigvis likt som en konsulent i privat sektor eller en plattformarkitekt i finans.

Et nøkternt bilde bør bygges fra flere kilder. SSB kan gi bakgrunn for lønnsnivåer i relevante yrkesgrupper, men treffer ikke alltid moderne skytitler presist. FINN og LinkedIn Job Insights kan vise etterspørsel og kravord i annonser, men annonser oppgir ikke alltid lønn. Glassdoor kan gi indikasjoner fra rapporterte lønninger, men datagrunnlaget kan variere mellom byer og bransjer. Derfor bør tall brukes som intervaller og samtalegrunnlag, ikke som fasit.

En praktisk metode er å sammenligne tre ting før lønnsforventninger settes: hvilke beslutninger rollen faktisk eier, hvor nær rollen er produksjonsansvar, og hvor mye forretnings- eller kundedialog den krever. Roller som kombinerer arkitektur, sikkerhet, koststyring og praktisk implementering har ofte sterkere forhandlingsposisjon enn roller der sertifiseringen ikke kobles til dokumentert leveranse.

Ansvarslinjer: BCDR, identitet, styring og kostkontroll

AZ-305 legger stor vekt på designvalg for robusthet, sikkerhet og styring. I en norsk virksomhet betyr det sjelden at arkitekten får totalansvar for alle områdene. Business continuity and disaster recovery, ofte omtalt som BCDR, eies vanligvis i et samspill mellom tjenesteeier, drift, sikkerhet, arkitektur og virksomhetsledelse. Arkitekten designer mønstrene, men virksomheten må definere toleranse for nedetid, datatap, manuelle beredskapsrutiner og akseptabel kostnad.

Identitet og tilgangsstyring er et tilsvarende delt ansvar. Arkitekten bør kunne designe bruk av Microsoft Entra ID, betinget tilgang, rollebasert tilgangskontroll og privilegert tilgang. Sikkerhetsteamet må samtidig vurdere risikomodell, logging, hendelsesrespons og etterlevelse. IT-drift eller plattformteamet må sørge for at prinsippene faktisk implementeres som standarder, ikke som enkeltstående unntak.

Kostkontroll er en av de vanligste svakhetene etter AZ-305. Mange kandidater kan beskrive skalerbare løsninger, men undervurderer hvordan nettverkstrafikk, lagringsredundans, backup, testmiljøer og observability påvirker kostnader. En arkitekt bør derfor kunne lage en enkel kostmodell før designet godkjennes. Den trenger ikke være perfekt, men den må synliggjøre antakelser, drivere og hva som skjer når bruksmønsteret endrer seg.

Et norsk eksempel: landing zone light med BCDR

En mellomstor norsk virksomhet som flytter interne fagsystemer til Azure, trenger ofte ikke en omfattende enterprise-landing-zone fra første dag. Den trenger et kontrollert minimum som kan vokse. Et godt første design kan bestå av tydelige abonnementer for plattform og arbeidslaster, sentral logging, nettverkssegmentering, standardiserte policyer, identitetsroller, backup-prinsipper og en testet gjenopprettingsplan for de mest kritiske tjenestene.

Arkitektens arbeid i et slikt scenario handler om å gjøre risiko synlig. Dersom virksomheten velger geo-redundant lagring, høy tilgjengelighet og automatisert gjenoppretting for alle tjenester, kan kostnaden bli høyere enn nytten for mindre kritiske systemer. Dersom den velger for enkel redundans, kan driftsavbrudd bli vanskelig å håndtere. AZ-305-kompetanse brukes derfor til å plassere arbeidslaster i riktig kritikalitetsklasse og velge mønstre som passer både budsjett og risiko.

Et sentralt artefakt er et lite sett med policyer som hindrer de vanligste avvikene. Eksempelet under viser ikke en full styringsmodell, men illustrerer hvordan arkitekturprinsipper kan gjøres håndhevbare i Azure.

Example — Azure Policy for påkrevd region

{
  "properties": {
    "displayName": "Tillat bare godkjente Azure-regioner",
    "policyType": "Custom",
    "mode": "All",
    "parameters": {
      "allowedLocations": {
        "type": "Array",
        "metadata": {
          "displayName": "Godkjente regioner"
        }
      }
    },
    "policyRule": {
      "if": {
        "not": {
          "field": "location",
          "in": "[parameters('allowedLocations')]"
        }
      },
      "then": {
        "effect": "Deny"
      }
    }
  }
}

Policyen gjør et arkitekturvalg konkret: ressurser kan bare opprettes i godkjente regioner. Før en slik policy aktiveres bredt, bør teamet teste unntak, globale tjenester, eksisterende ressurser og konsekvenser for automatiserte leveranser. Læringspoenget er at arkitektur ikke stopper ved diagrammer; den må oversettes til kontroller som drift og utvikling kan leve med.

Vanlige fallgruver etter sertifisering

Den første fallgruven er å bruke sertifiseringen som sluttpunkt. AZ-305 dekker sentrale designområder, men den erstatter ikke erfaring med produksjonsmiljøer, hendelser, budsjettendringer eller gamle integrasjoner. Særlig hybride miljøer kan være krevende fordi nettverk, identitet, navneoppløsning og tilgang ofte er formet av mange års lokale valg.

Den andre fallgruven er svak beslutningsdokumentasjon. En god arkitekt kan forklare hvorfor et design ble valgt, hvilke alternativer som ble avvist, hvilke forutsetninger som gjelder, og hvem som aksepterte risikoen. Architecture Decision Records, ofte forkortet ADR, er nyttige nettopp fordi de gjør tekniske kompromisser etterprøvbare.

Den tredje fallgruven er å undervurdere menneskelige grensesnitt. Rollen fra administrator eller utvikler til arkitekt handler mindre om å ha alle svarene og mer om å få riktige personer til å ta riktige beslutninger. Det krever språk for kost, sikkerhet, ytelse, driftbarhet og juridiske krav, ikke bare dyp produktkunnskap.

En praktisk 90-dagers plan etter AZ-305

De første månedene etter sertifiseringen bør brukes til å gjøre kunnskapen synlig gjennom leveranser. Målet er ikke å samle flest mulig nye emner, men å bygge bevis på arkitekturevne: små, forklarbare artefakter som kan vises i intern fagdialog, portefølje, intervju eller konsulentprofil.

1. Lag en enkel referansearkitektur for en Azure landing zone med identitet, nettverk, logging, policy og kostforutsetninger.
2. Dokumenter minst tre arkitekturbeslutninger som ADR-er, inkludert alternativer, risiko og konsekvens.
3. Bygg et lite policysett for region, tagging, offentlige endepunkter og logging, og test det mot et sandkassemiljø.
4. Lag en kostmodell for én arbeidslast, med antakelser om compute, lagring, trafikk, backup og overvåking.
5. Gjennomfør en BCDR-gjennomgang med tjenesteeier, drift og sikkerhet, og avklar krav til gjenoppretting før teknologi velges.
6. Velg ett fordypningsspor, for eksempel IaC, Kubernetes, Zero Trust, dataplattform eller migrasjonsstrategi.

Denne planen fungerer også som et intervjuforberedende verktøy. Kandidaten kan vise hvordan en sertifisering blir omsatt til beslutninger, styring og driftbarhet. Det er ofte mer overbevisende enn å gjengi eksamensmål.

Hvordan AZ-305 passer inn i videre sertifisering og læring

AZ-305 står ofte på skuldrene av Azure Administrator-kompetanse. Kandidater som kommer fra utvikling, kan ha nytte av å styrke utviklerperspektivet gjennom Azure Developer-målene. De som arbeider tett med leveranseflyt og plattformautomatisering, bør forstå hvordan DevOps Engineer-området påvirker arkitekturvalg.

Videre læring bør også komme fra praksisfellesskap og produktoppdateringer. Microsoft Tech Community og Azure-delen av Microsoft Tech Community kan være nyttige for å følge diskusjoner om nye tjenester, anbefalte mønstre og kjente utfordringer. Det viktigste er likevel å filtrere nyheter gjennom virksomhetens behov. En arkitekt bør kunne si nei til en tjeneste som er teknisk interessant, men unødvendig kompleks for problemet som skal løses.

Microsofts rollebaserte sertifiseringer må også holdes ved like. Retningslinjer for fornyelse bør sjekkes direkte hos Microsoft, særlig via siden for fornyelse av Microsoft-sertifiseringer, fordi krav og prosesser kan endres.

Neste steg for en sterkere Azure-arkitektprofil

AZ-305 gir et tydelig signal om at kandidaten kan tenke på tvers av Azure-tjenester, men det som bygger karriere etterpå er dokumentert dømmekraft. Norske arbeidsgivere trenger arkitekter som kan forene sikkerhet, kostnad, drift og forretningsbehov i løsninger som lar seg implementere.

Det mest effektive neste steget er å velge ett konkret prosjekt og gjøre arkitekturen etterprøvbar. En liten landing zone, en realistisk kostmodell, et policysett og en BCDR-vurdering gir mer læring enn passiv repetisjon av pensum. Hvis strukturert opplæring fortsatt er nødvendig, kan Readynez brukes som støtte for eksamensforberedelse og ferdighetsbygging, men den avgjørende utviklingen skjer når kunnskapen brukes i faktiske beslutninger.

FAQ

Hva er AZ-305?

AZ-305 er Microsofts eksamen for design av Azure-infrastrukturløsninger. Den måler evnen til å utforme løsninger for blant annet identitet, styring, datalagring, forretningskontinuitet, infrastruktur og overvåking.

Hvilke jobber kan være aktuelle etter AZ-305?

Aktuelle roller kan være Azure arkitekt, skyarkitekt, løsningsarkitekt, plattformarkitekt, senior cloud engineer eller Azure-konsulent. Hvilken rolle som passer best, avhenger av om kandidaten vil arbeide mest med strategi, rådgivning, implementering eller standardisering av plattform.

Gir AZ-305 høyere lønn?

AZ-305 kan styrke en kandidatprofil, men den gir ingen automatisk lønnsøkning. Lønn påvirkes av erfaring, ansvar, sektor, region, konsulentandel, sikkerhetskrav og hvor godt kandidaten kan vise praktiske resultater. SSB, FINN, LinkedIn Job Insights og Glassdoor kan brukes som datakilder, men tall bør vurderes med tydelige forbehold.

Må man ha AZ-104 før AZ-305?

Microsofts Azure Solutions Architect Expert-løp er knyttet til både administrasjons- og arkitektkompetanse. Mange kandidater bygger først et solid administratorgrunnlag gjennom Azure Administrator før de går videre til AZ-305, fordi arkitekturvalg ofte krever forståelse av daglig drift og styring.

Hvor ofte må sertifiseringen fornyes?

Microsofts rollebaserte sertifiseringer har egne fornyelsesregler. Kandidater bør kontrollere gjeldende krav direkte hos Microsoft via siden for fornyelse av sertifiseringer, fordi reglene kan oppdateres.