AZ-204 er en praktisk utviklereksamen som vurderer mer enn kjennskap til Azure-tjenester og eksamensformat. Den måler om en utvikler kan velge og implementere riktige løsninger under realistiske krav til sikkerhet, skalerbarhet, drift og kostnad.
AZ-204 er eksamenen for rollen Microsoft Azure Developer Associate. Den passer for utviklere som bygger applikasjoner på Azure med språk som C#, Python eller JavaScript, og den bør ikke forveksles med AZ-104, som retter seg mot administratorrollen. Kandidaten bør kunne skrive kode, bruke Azure SDK-er, implementere identitet og sikkerhet, jobbe med lagring og meldinger, og feilsøke løsninger i drift.
Microsoft endrer innhold, vekting og eksamenslogistikk over tid, så den offisielle eksamenssiden og skills outline på Microsoft Learn bør alltid være fasit før booking. Denne veiledningen er faglig gjennomgått mot gjeldende Microsoft Learn-mål i juli 2026. Et viktig punkt å korrigere fra eldre artikler er fornyelse: rollebaserte Microsoft-sertifiseringer fornyes årlig gjennom en gratis fornyelsesvurdering på Microsoft Learn når kandidaten er kvalifisert, ikke ved en fast toårsregel.
Hva AZ-204 faktisk tester
AZ-204 måler utviklerferdigheter, ikke generell portalnavigasjon. Kandidaten må forstå hvordan Azure-tjenester oppfører seg når de brukes fra kode: hvordan en Function trigges, hvordan en blob lastes opp via SDK, hvordan Managed Identity brukes mot Key Vault, hvordan en Service Bus-melding behandles, og hvordan Application Insights hjelper ved feilsøking.
De offisielle målene er organisert rundt fem områder: databehandlingsløsninger, lagring, sikkerhet, overvåking og optimalisering, samt integrasjon med Azure- og tredjepartstjenester. Vektingen gir nyttig prioritering, men eksamensspørsmålene kommer ofte som scenarioer der flere mål blandes. En oppgave kan for eksempel starte med en App Service, kreve hemmelighetsfri tilgang til Storage, og samtidig teste logging, retry-policy og riktig meldingstjeneste.
Det er her mange kandidater mister poeng. De kan beskrive hva en tjeneste gjør, men blir usikre når spørsmålet legger inn begrensninger: lav driftskostnad, periodisk trafikk, krav om skalerbarhet, behov for transaksjonell meldingsbehandling eller et sikkerhetskrav som utelukker hardkodede hemmeligheter. Forberedelsen bør derfor handle mindre om å pugge tjenestenavn og mer om å øve på valg, begrunnelse og implementering.
Compute-valg: App Service, Functions og Container Apps
Et tilbakevendende mønster i AZ-204 er å velge riktig compute-plattform for applikasjonsformen. App Service passer godt når applikasjonen er en webapp eller API med relativt kjent kjøreprofil, integrert deployment og behov for en administrert plattform. Azure Functions passer bedre for hendelsesdrevet kode, planlagte jobber og små arbeidsenheter som skalerer etter triggere. Container Apps blir relevant når løsningen trenger containerbasert kjøring, mikrotjenester, bakgrunnsprosesser eller skaleringsregler uten å administrere Kubernetes direkte.
Anti-mønstrene er like viktige som bruksområdene. En langvarig prosess med kompleks livssyklus passer ofte dårlig som en enkel Function. En stateless web-API trenger normalt ikke en full containerplattform hvis App Service dekker behovet enklere. En containerisert workload bør ikke flyttes til AKS bare fordi den er containerisert; eksamenen belønner ofte det minst komplekse alternativet som oppfyller kravene.
I praktisk forberedelse bør kandidaten bygge samme lille API på to måter: først som App Service og deretter som Function. Det gjør forskjellen mellom HTTP-endepunkt, trigger, konfigurasjon, skalering og logging mer konkret. Lokalt bør Functions Core Tools brukes for kjøring og feilsøking, og host.json bør undersøkes fordi innstillinger for samtidighet, timeout og retry kan påvirke både drift og eksamenssvar.
Følgende eksempel viser en typisk AZ-204-ferdighet: en Azure Function som leser konfigurasjon fra miljøet og skriver strukturert logg. Hemmeligheter skal ikke hardkodes i kode; i en full løsning bør de ligge i Key Vault, og applikasjonen bør få tilgang gjennom Managed Identity.
Example — HTTP-trigger med trygg konfigurasjonslesing i .NET
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
public class OrdersApi
{
private readonly ILogger<OrdersApi> _logger;
public OrdersApi(ILogger<OrdersApi> logger)
{
_logger = logger;
}
[Function("CreateOrder")]
public async Task<HttpResponseData> Run(
[HttpTrigger(AuthorizationLevel.Function, "post", Route = "orders")] HttpRequestData req)
{
var storageAccount = Environment.GetEnvironmentVariable("StorageAccountName");
_logger.LogInformation("Received order request for storage account {StorageAccount}", storageAccount);
var response = req.CreateResponse(System.Net.HttpStatusCode.Accepted);
await response.WriteStringAsync("Order accepted for processing.");
return response;
}
}
Eksemplet er kort, men poenget er eksamensrelevant: kode, konfigurasjon og observability henger sammen. Kandidaten bør kunne forklare hvordan innstillingen settes per miljø, hvordan Function App får identitet, og hvordan loggene kan spores videre i Application Insights.
Lagring og sikkerhet må øves sammen
Azure Storage dukker ofte opp som blob, queue, table eller filrelatert scenario. Det tekniske spørsmålet handler sjelden bare om en SDK-metode; det handler om tilgangsmodell, ytelse, konsistens, livssyklus og feilhåndtering. En utvikler bør vite når blob metadata er nok, når en database er mer egnet, og hvordan tilgang begrenses uten å dele nøkler bredt.
En vanlig feil er å øve med connection strings overalt. Det kan fungere i en labb, men det gir feil ryggmargsrefleks. I moderne Azure-utvikling bør Managed Identity være førstevalg når applikasjonen kjører i Azure, Key Vault bør brukes for hemmeligheter, og Azure App Configuration bør brukes for applikasjonsinnstillinger som endres mellom miljøer. Storage-tilgang bør vurderes gjennom RBAC, SAS og tilgangsnøkler med tydelig forståelse av risiko og bruksområde.
Lokalt bør Azurite brukes i stedet for den gamle Storage Emulator. Det gjør labbene mer representative og reduserer risikoen for å lære utdatert verktøybruk. Kandidaten bør også øve på å bytte mellom lokal emulering og skyressurs uten å endre applikasjonslogikken.
Dette Python-eksemplet viser et trygt mønster for blob-opplasting når koden kjører med en identitet som har riktig RBAC-rolle på lagringskontoen. Det bruker ikke hemmeligheter i kildekoden.
Example — Last opp blob med Managed Identity i Python
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient
account_url = "https://stordersprod.blob.core.windows.net"
container_name = "incoming-orders"
blob_name = "order-1042.json"
credential = DefaultAzureCredential()
service_client = BlobServiceClient(account_url=account_url, credential=credential)
container_client = service_client.get_container_client(container_name)
with open("order-1042.json", "rb") as data:
container_client.upload_blob(name=blob_name, data=data, overwrite=False)
Det viktige å verifisere etterpå er ikke bare at filen ligger i containeren. Kandidaten bør sjekke hvilken identitet som ble brukt, hvilke RBAC-rettigheter den hadde, hva som skjer ved en duplikat, og hvordan feilen logges. Slike detaljer skiller en fungerende demo fra en løsning som tåler eksamensscenarioer.
Meldinger og hendelser: tre tjenester som ofte blandes
Service Bus, Event Grid og Event Hubs forveksles ofte fordi alle kan knytte systemer sammen. Forskjellen ligger i hensikten. Service Bus passer for kommandoer og arbeidskøer der en melding skal behandles pålitelig, gjerne med dead-letter queue, utsatt levering, sessions eller transaksjonell kontroll. Event Grid passer for reaktive hendelser, for eksempel at en blob er opprettet og en prosess skal starte. Event Hubs passer for store mengder telemetri eller strømmer der mange hendelser leses og analyseres over tid.
| Tjeneste |
Primær bruk |
Typisk eksamensfelle |
| Service Bus |
Pålitelig arbeidskø, kommandoer og forretningsprosesser |
Å velge Event Grid når meldingen må låses, fullføres eller dead-letteres |
| Event Grid |
Reaksjon på hendelser fra Azure-tjenester og applikasjoner |
Å bruke det som en generell kø for arbeidsordre som krever streng behandling |
| Event Hubs |
Inntak av telemetri og hendelsesstrømmer i høy skala |
Å bruke det for enkel ordrebehandling der Service Bus er mer presist |
Observability henger tett sammen med meldingsvalg. En løsning som bruker Service Bus bør ha tydelig retry-policy, håndtering av dead-letter queue og korrelasjons-ID-er i loggingen. En hendelsesdrevet løsning bør spores gjennom flere komponenter, ofte med Application Insights og distribuert sporing. OpenTelemetry dukker stadig oftere opp i praktisk Azure-arbeid, og kandidatene bør forstå hvorfor spor på tvers av tjenester er nyttigere enn isolerte logglinjer.
Infrastructure as Code og deployment-kunnskap
AZ-204 er ikke en ren DevOps-eksamen, men utviklere forventes å kunne distribuere og konfigurere Azure-ressurser på en repeterbar måte. ARM-maler ligger fortsatt under mye av plattformen, mens Bicep i praksis gir en mer lesbar måte å beskrive Azure-ressurser på. Kandidaten bør forstå parametere, moduler, avhengigheter og hvordan endringer valideres før de rulles ut.
Et godt labbmål er å beskrive en Function App, Storage Account og Application Insights-ressurs i Bicep, deploye dem til et testmiljø, og deretter gjøre en kontrollert endring. Ved feil bør kandidaten kunne lese deployment-feilen, forstå om ressursen er delvis opprettet, og vite hvordan rollback eller ny deployment håndteres. Template specs kan også være verdt å kjenne til fordi de brukes til å dele godkjente maler i mer modne miljøer.
Det er lett å undervurdere dette området fordi det virker mer administrativt enn kodeorientert. I praksis er det utviklerens evne til å automatisere miljøer som gjør feilsøking og repetisjon mulig. En labb som opprettes manuelt i portalen lærer mindre enn en labb som kan slettes og bygges opp igjen på samme måte.
En praktisk 10–14 dagers øvingsplan
En effektiv sluttfase før AZ-204 kombinerer Microsoft Learn, små labber, kodeøving og refleksjon over feil. Planen under passer best for en utvikler som allerede kan grunnleggende Azure og har litt praktisk erfaring. Den bør tilpasses etter svakheter, men rekkefølgen er nyttig fordi compute, sikkerhet, integrasjon og observability bygger på hverandre.
- Dag 1–2: Les den offisielle skills outline på Microsoft Learn og merk hvert mål som trygg, usikker eller ukjent.
- Dag 3–4: Bygg en liten App Service og en Azure Function, og sammenlign konfigurasjon, logging, deployment og skalering.
- Dag 5–6: Øv på Blob Storage med SDK, Azurite lokalt, RBAC i Azure og feilscenarier som duplikater eller manglende tilgang.
- Dag 7–8: Implementer Managed Identity mot Key Vault og skill mellom hemmeligheter, applikasjonskonfigurasjon og tilgangsnøkler.
- Dag 9–10: Lag en Service Bus-kø med retry og dead-letter-håndtering, og sammenlign scenarioet med Event Grid og Event Hubs.
- Dag 11–12: Aktiver Application Insights, følg en forespørsel gjennom flere komponenter og forklar hvordan distribuert sporing hjelper feilsøking.
- Dag 13–14: Gjennomfør tidsstyrte øvingssett, gå tilbake til feil svar, og skriv korte begrunnelser for hvorfor riktig alternativ passer kravene.
Øvingsprøver bør brukes diagnostisk, ikke som erstatning for forståelse. Hvis et feil svar skyldes at kandidaten ikke kunne skille Event Grid fra Service Bus, bør neste økt være en labb, ikke ti nye spørsmål om samme tema. Det er også klokt å unngå såkalte braindumps; de bryter med eksamensregler, lærer ofte feil kontekst og gir svakere praktisk kompetanse.
Noen kandidater har nytte av en mer strukturert ramme enn egenstudier alene. Et instruktørledet Azure Developer-kurs hos Readynez kan være relevant når målet er å kombinere eksamensmål, labber og avklaring av vanskelige valg i et samlet løp. Andre vil foretrekke Microsoft Learn, egne prosjekter og øvingsoppgaver; det viktige er at læringen må ende i fungerende kode og begrunnede arkitekturvalg.
Hvordan lese eksamensspørsmål mer presist
AZ-204-spørsmål inneholder ofte små ord som styrer riktig svar. Krav som «lavest administrasjonskostnad», «uten å lagre hemmeligheter», «garantert rekkefølge», «minst mulig kodeendring» eller «automatisk skalering ved hendelser» peker mot bestemte tjenester og mønstre. Kandidaten bør derfor lese scenarioet som en kravspesifikasjon, ikke som en produktquiz.
Et nyttig grep er å identifisere begrensningen før alternativene vurderes. Hvis kravet handler om sikker tilgang uten hemmeligheter, blir Managed Identity og RBAC mer sannsynlig enn connection strings. Hvis kravet handler om telemetri i høy skala, peker det mot Event Hubs fremfor Service Bus. Hvis kravet handler om pålitelig behandling av forretningsmeldinger, er dead-letter queue og fullføringssemantikk ofte avgjørende.
Tidsstyring bør øves før eksamensdagen, men uten å feste seg ved et bestemt antall spørsmål eller minutter fra eldre kilder. Microsofts eksamensside gir gjeldende logistikk. Under øving bør kandidaten trene på å markere spørsmål, gå videre når usikkerheten er høy, og komme tilbake med friskt blikk. Det reduserer risikoen for å bruke for mye tid på ett scenario.
Ressurser som gir best læringseffekt
Microsoft Learn bør være utgangspunktet fordi eksamensmålene og læringsmodulene følger Microsofts egen struktur. Dokumentasjonen for Azure Functions, App Service, Storage SDK, Key Vault, App Configuration, Service Bus, Event Grid, Event Hubs, Application Insights og Bicep bør brukes når kandidaten bygger labber. Det er bedre å lese dokumentasjon sammen med et konkret problem enn å lese lange seksjoner uten å kode.
Referansebøker og kurs kan gi bedre forklaringer av mønstre, men de bør sjekkes mot gjeldende Microsoft Learn-mål. Azure endrer seg raskt, og eldre ressurser kan bruke utdatert verktøy eller gamle anbefalinger. For utviklere som vil se bredden i Microsoft-opplæring, kan en oversikt over Microsoft-kurs være nyttig som supplement til egenstudier, men AZ-204-forberedelsen bør fortsatt styres av eksamensmålene.
Det kan også være nyttig å avklare om AZ-204 faktisk er riktig første steg. Utviklere som bygger kode for Azure-applikasjoner er målgruppen. Personer som hovedsakelig jobber med drift, nettverk, governance og ressursadministrasjon kan ha mer nytte av et administratorløp først. En generell oversikt på Readynez kan hjelpe med å orientere seg, men valget bør baseres på arbeidsoppgaver og kompetansegap.
Et realistisk mål for sertifiseringen
Å bestå AZ-204 krever mer enn å kjenne navnene på Azure-tjenester. Kandidaten bør kunne forklare hvorfor en løsning bruker Functions fremfor App Service, hvorfor Service Bus er riktig for en arbeidskø, hvordan Managed Identity fjerner behovet for hemmeligheter i kode, og hvordan Application Insights brukes når noe feiler i produksjon.
Den mest praktiske veien videre er å bygge små, repeterbare labber som dekker hvert eksamensmål og deretter bruke øvingsspørsmål til å finne hull. Dersom det er behov for veiledning om sertifiseringsløp eller kursvalg, kan man kontakte Readynez for en faglig samtale. Uansett læringsform bør målet være det samme: trygghet i implementasjon, sikkerhetsvalg og feilsøking, ikke bare gjenkjenning av riktige svar.
FAQ
Hva er AZ-204?
AZ-204 er Microsoft-eksamenen for Azure Developer Associate. Den måler ferdigheter i å utvikle, sikre, integrere, overvåke og optimalisere applikasjoner på Azure.
Er AZ-204 det samme som AZ-104?
Nei. AZ-204 er rettet mot utviklere som bygger Azure-løsninger med kode, mens AZ-104 er rettet mot administratorer som drifter og administrerer Azure-miljøer. Noen trenger begge kompetanseområder, men eksamenene måler ulike roller.
Hvor ofte må Azure Developer Associate fornyes?
Rollebaserte Microsoft-sertifiseringer fornyes årlig gjennom en gratis fornyelsesvurdering på Microsoft Learn når sertifiseringen er kvalifisert for fornyelse. Kandidater bør alltid kontrollere gjeldende regler på Microsoft Learn før fristen.
Hva er de vanligste feilene under forberedelsen?
Vanlige feil er å lese for mye teori uten å bygge labber, bruke hardkodede hemmeligheter i eksempler, overse Managed Identity, blande Service Bus, Event Grid og Event Hubs, og ignorere Application Insights, retry-policy og dead-letter-håndtering.
Hvordan bør en utvikler øve de siste to ukene?
De siste ukene bør brukes på små scenarioer som kombinerer flere mål: en Function som bruker Storage, en API som henter hemmeligheter fra Key Vault, en meldingsflyt med Service Bus, og logging i Application Insights. Øvingsspørsmål bør brukes til å finne svake områder, ikke som eneste læringsmetode.
