AZ-220 definerer Azure IoT Developer-rollen som arbejdet med den del af løsningen, hvor fysiske enheder, telemetri, sikker provisioning og edge-kørsel møder Azure – ud over almindelig Azure-udvikling med apps, API’er, storage og integration.
AZ-220 er Microsofts eksamen for Azure IoT Developer-rollen, og den tester, om en kandidat kan implementere og vedligeholde IoT-løsninger med Azure IoT Hub, Device Provisioning Service, IoT Edge, routing, overvågning og sikkerhed. Det gør eksamenen praktisk orienteret: Kandidaten skal kunne forstå arkitekturen, men også vide, hvad der sker, når en enhed ikke provisioneres, en route ikke rammer korrekt, eller et Edge-modul ikke får den forventede konfiguration.
Sidst opdateret: januar 2026. Microsoft kan ændre eksamensindhold, format og vægtning, så den officielle AZ-220-eksamensside og Microsoft Learn bør altid kontrolleres før booking. Denne artikel bruger de kendte kerneområder som arbejdsramme, men undgår faste vægtninger, hvor de kan ændre sig.
Hvad AZ-220 faktisk måler
AZ-220 dækker den fulde IoT-løsningskæde i Azure: opsætning af IoT Hub, enhedsidentitet, Device Provisioning Service, device-to-cloud-kommunikation, cloud-to-device-beskeder, routing, IoT Edge, databehandling, overvågning, fejlfinding og sikkerhed. Det er derfor ikke nok at have set en IoT Hub i portalen. Eksamenen forventer, at kandidaten forstår sammenhængen mellem enheder, cloud-tjenester og drift.
Et godt udgangspunkt er at læse Microsofts officielle exam skills outline og derefter bruge Microsoft Learn til at afstemme studiet med de aktuelle mål. Særligt DPS, IoT Hub message routing, IoT Edge deployment og diagnostik bør behandles som praktiske kompetencer, ikke som definitionsstof. Mange fejl i både labs og virkelige projekter opstår, fordi kandidater manuelt opretter enheder i Hub’en og dermed aldrig lærer, hvordan provisioning, attestation og enrollment virker i en skalerbar løsning.
IoT-området kan virke bredt, især for udviklere, der kommer fra backend- eller cloud-siden. En hurtig genopfriskning af grundlæggende IoT-begreber kan være nyttig, hvis device lifecycle, telemetri, sensordata og edge-begreber ikke allerede sidder fast.
AZ-220 eller en bredere Azure-udviklervej?
AZ-220 passer bedst til udviklere og ingeniører, der arbejder med enheder, telemetri, IoT Hub, DPS og IoT Edge. Hvis arbejdsopgaverne primært handler om webapps, API’er, serverless compute, storage og integration, er en bredere Azure-udviklercertificering ofte mere relevant. Valget bør derfor tage udgangspunkt i hverdagsopgaverne snarere end i certificeringens navn.
En IoT-udvikler skal typisk kunne designe device identity, håndtere forbindelser, konfigurere message routes, arbejde med Edge-moduler og forstå driftsdata fra en løsning, der kan have tusindvis af enheder i feltet. En klassisk Azure app-udvikler arbejder oftere tættere på applikationslaget: compute, API-design, køer, events, storage, authentication og deployment pipelines. Begge profiler kan overlappe, men AZ-220 belønner den kandidat, der kan tænke fra device til cloud og tilbage igen.
Efter AZ-220 vælger mange at styrke den side af profilen, der fylder mest i rollen. Dataorienterede kandidater kan gå dybere i pipelines, streaming og analyse, mens app-orienterede kandidater ofte får mere værdi af bredere Azure-udvikling. Pointen er ikke at samle certificeringer, men at bygge en kompetenceprofil, der matcher de løsninger, kandidaten faktisk skal levere.
De praktiske faldgruber, der koster flest point
Den mest almindelige studiefejl er at læse om hver Azure IoT-komponent isoleret. AZ-220-spørgsmål beskriver ofte et scenario, hvor valget afhænger af samspillet mellem provisioning, identity, routing, Edge og overvågning. Hvis kandidaten kun kender tjenesternes navne, bliver svarmulighederne svære at skelne fra hinanden.
DPS er et tydeligt eksempel. I små labs kan en enhed oprettes manuelt i IoT Hub, men eksamenen tester ofte situationer, hvor enheder skal provisioneres sikkert og gentageligt. Kandidaten bør forstå forskellen mellem enrollment, attestation, linked IoT Hub og tildelingspolitik, samt hvornår certifikater eller nøgler giver mening. I praksis bør der også tænkes over nøglerevokering, deaktivering af kompromitterede enheder og begrænsede adgangspolitikker.
IoT Edge er en anden kilde til fejl. Det er ikke tilstrækkeligt at vide, at Edge kan køre moduler lokalt. Kandidaten skal forstå deployment manifests, module twins, routes mellem moduler, container images og hvordan fejl viser sig i runtime-status, logs og metrics. Mange overser også, at Edge-routes og IoT Hub-routes er forskellige lag i løsningen, selv om begge påvirker, hvor data ender.
Routing og fejlfinding bør trænes sammen. Når en device-to-cloud-besked ikke lander i den forventede destination, kan årsagen være en forkert route query, en manglende endpoint-konfiguration, fallback route-adfærd, adgangspolitik eller selve device-senderen. En eksamensklar kandidat kan isolere fejlen ved at teste beskedafsendelse, kontrollere metrics, læse diagnostic logs og sammenligne route-betingelser med payload og system properties.
En sammenhængende lab er bedre end mange små øvelser
Den mest effektive lab-strategi er at bygge én ende-til-ende-løsning, hvor hvert eksamensemne forstærker de andre. Start med DPS, provisionér en simuleret enhed til IoT Hub, send telemetri, route beskeder til en downstream-tjeneste, tilføj simpel streambehandling, og udvid derefter med en IoT Edge-enhed, der kører et modul lokalt. Det giver et mere realistisk billede af Azure IoT end separate øvelser, der aldrig mødes.
Et godt minicase-scenario er en temperatursensor i en produktionslinje. Enheden provisioneres via DPS, sender device-to-cloud-telemetri til IoT Hub, får beskeder routet efter temperaturværdi, og en Edge-enhed filtrerer eller beriger data lokalt, før de sendes videre. Undervejs bør kandidaten bevidst fremkalde fejl: forkert enrollment, forkert route query, manglende module twin-indstilling og utilstrækkelig policy-adgang. Fejlene gør Microsoft Learn-stoffet konkret.
Hvis artiklen publiceres i et CMS med billedfelter, er to visuelle elementer særligt nyttige: et referencearkitekturdiagram med alt-teksten “Referencearkitektur for Azure IoT-løsning med DPS, IoT Hub, routing og IoT Edge” og et device lifecycle-diagram med alt-teksten “Device lifecycle fra provisioning til drift, overvågning og deaktivering i Azure IoT”. Diagrammerne bør vise ansvar og dataflow, ikke blot produktikoner.
Følgende Azure CLI-eksempel viser en lille del af labben: oprettelse af en IoT Hub og en DPS-instans samt koblingen mellem dem. Kommandoerne er tænkt som studieunderstøttelse, ikke som en komplet produktionsopsætning.
Example — opret IoT Hub og DPS til en AZ-220-lab
az group create --name rg-az220-lab --location westeurope
az iot hub create \
--name iothub-az220-lab \
--resource-group rg-az220-lab \
--sku S1 \
--partition-count 2
az iot dps create \
--name dps-az220-lab \
--resource-group rg-az220-lab \
--location westeurope
az iot dps linked-hub create \
--dps-name dps-az220-lab \
--resource-group rg-az220-lab \
--connection-string "HostName=iothub-az220-lab.azure-devices.net;SharedAccessKeyName=iothubowner;SharedAccessKey=REPLACE_WITH_LAB_KEY" \
--location westeurope
Det centrale læringspunkt er ikke selve syntaksen, men relationen mellem DPS og den tilknyttede IoT Hub. I en sikker lab bør nøgler håndteres via sikre mekanismer og roteres efter brug; i produktion bør adgangspolitikker være langt mere granulære end en bred ejerpolitik.
Edge-delen bør derefter demonstrere, hvordan ønsket konfiguration beskrives i et deployment manifest eller en module twin. Et forenklet udsnit kan vise, hvordan et modul får en temperaturgrænse, som applikationskoden kan reagere på.
Example — module twin-konfiguration for et Edge-modul
{
"properties.desired": {
"temperatureThreshold": 70,
"sendIntervalSeconds": 30,
"routeCriticalReadings": true
}
}
Når denne type konfiguration testes, bør kandidaten verificere både modulets logs og den efterfølgende route i IoT Hub. Det træner den samme tankegang, som eksamenen ofte kræver: find det sted i kæden, hvor antagelsen bryder sammen.
En realistisk 4-ugers studieplan
En måned er en realistisk forberedelsesperiode for en udvikler med grundlæggende Azure-erfaring, hvis der arbejdes struktureret og praktisk. Planen nedenfor forudsætter, at kandidaten bruger Microsoft Learn, bygger en lab og afsætter tid til gentagelse og test.
- Uge 1: Læs den officielle exam skills outline, genopfrisk IoT Hub, device identity og device-to-cloud-kommunikation, og opret den første lab med en simuleret enhed.
- Uge 2: Arbejd med DPS, enrollment, attestation og sikker device lifecycle; test både vellykket og fejlet provisioning.
- Uge 3: Udvid labben med message routing, endpoints, streambehandling og IoT Edge; dokumentér typiske fejl og hvordan de opdages i logs og metrics.
- Uge 4: Repetér sikkerhed, overvågning og fejlfinding, tag practice tests, brug Microsofts exam sandbox, og gennemgå alle forkerte svar med fokus på årsagen.
En struktureret træningsramme kan være nyttig, hvis kandidaten har kort tid eller mangler feedback på labs. Readynez kan i den sammenhæng bruges som et instruktørledt supplement til selvstudie, men den afgørende faktor er stadig, om kandidaten får bygget og fejlrettet en fungerende IoT-løsning selv.
Eksamensdag: læs scenariet som en løsningsarkitekt
På eksamensdagen bør kandidaten bruge de første sekunder på at forstå scenariet, før svarmulighederne vurderes. AZ-220-spørgsmål kan være formuleret, så flere svar lyder teknisk plausible, men kun ét passer til kravene om sikkerhed, skala, drift eller dataflow. Det er især vigtigt ved spørgsmål om provisioning, routes, Edge deployments og policy-adgang.
Microsofts exam sandbox er værd at bruge inden eksamen, fordi den fjerner usikkerhed om navigation, markering af spørgsmål og case-format. Beregningstunge eller meget teksttunge spørgsmål bør ikke få lov til at stjæle rytmen; marker dem, gå videre, og vend tilbage, når de hurtigere spørgsmål er besvaret.
En god vane er at læse kravene i scenariet før teknologien. Hvis spørgsmålet nævner automatisk onboarding af mange enheder, peger det mod DPS frem for manuel device creation. Hvis der er krav om lokal behandling ved ustabil forbindelse, bør Edge overvejes. Hvis telemetri skal sendes til forskellige destinationer uden at ændre device-koden, er routing ofte nøglen.
FAQ om AZ-220
Hvad koster AZ-220? Prisen afhænger af land, valuta og Microsofts aktuelle eksamenspolitik. Den officielle Microsoft-eksamensside viser den gældende pris ved booking.
Hvilke forudsætninger bør kandidaten have? Kandidaten bør have praktisk erfaring med Azure, grundlæggende programmering, IoT-begreber, netværk, sikkerhed og dataflow. Erfaring med Azure IoT Hub, DPS og IoT Edge gør forberedelsen markant mere effektiv.
Hvor tages eksamen? AZ-220 bookes normalt gennem Microsofts eksamensplatform og kan typisk tages online eller hos et testcenter, afhængigt af tilgængelighed og lokale regler.
Kan eksamen tages om? Ja, Microsoft har regler for retake og ventetid mellem forsøg. Disse regler kan ændre sig, så de bør kontrolleres på Microsofts officielle eksamensside inden booking.
Findes AZ-220 på dansk? Eksamenssprog afhænger af Microsofts aktuelle udbud. Kandidaten bør kontrollere sprogmulighederne under booking og vælge sprog ud fra teknisk præcision, ikke bekvemmelighed.
Fra eksamensplan til anvendelige IoT-færdigheder
AZ-220 belønner kandidater, der kan forbinde teori med drift: provisioning, device identity, routing, Edge, sikkerhed og fejlfinding skal hænge sammen i én løsning. Den bedste forberedelse er derfor en realistisk lab, hvor der både bygges, ændres og fejlfindes, indtil årsag og effekt er tydelige.
Efter certificeringen bør næste skridt vælges efter rolle. Nogle får mest ud af at styrke databehandling og analyse, mens andre bør udbygge applikationsudvikling og integration. Hvis læringen skal fortsætte på tværs af Microsoft-teknologier, kan Readynez Unlimited Microsoft Training være en praktisk ramme for at planlægge næste forløb uden at gøre AZ-220 til en isoleret milepæl.
