AZ-220 certificeringen handler om mere end at kunne kalde Azure IoT SDK'et fra kode. Eksamen tester, om en udvikler kan omsætte Azure IoT-arkitektur til en løsning, der kan klargøre enheder, håndtere drift, beskytte data og flytte telemetri videre til de rigtige tjenester.
AZ-220 er rettet mod Azure IoT Developer-rollen, hvor udvikleren implementerer IoT-infrastruktur og tjenester i Microsoft Azure. Indholdet nedenfor er senest opdateret i juli 2026 og afspejler de AZ-220-eksamensmål, som bør kontrolleres mod Microsoft Learn før booking, sammen med dokumentationen for Azure IoT Hub, Device Provisioning Service, Azure IoT Edge og device twins.
Hvad AZ-220 tester i praksis
Eksamen handler om mere end enheder, der sender målinger til skyen. Den tester evnen til at designe og implementere en sammenhængende IoT-løsning, hvor enhedstopologi, forbindelser, sikkerhed, routing, overvågning og databehandling fungerer sammen. En kandidat skal kunne genkende, hvordan Azure IoT-tjenester konfigureres både i portalen, via CLI eller infrastrukturværktøjer og direkte i kode.
Det gør eksamen relevant for den måde IoT-løsninger bygges på nu. Flere projekter bruger Azure IoT Edge til lokal behandling, Device Provisioning Service til skalerbar klargøring og meddelelsesrouting til at sende telemetri videre til storage, functions eller analytics. Når en løsning fejler, skyldes det sjældent ét forkert SDK-kald; fejlen ligger ofte i samspillet mellem enhedens identitet, twin-konfiguration, ruter, adgangspolitikker og de downstream-tjenester, der modtager data.
I hverdagen dukker eksamensmålene op i opgaver som at onboarde en ny type sensor, udskifte en statisk connection string med DPS, deploye et Edge-modul til en gateway, tilføje enrichments til telemetri eller forklare, hvorfor en rute ikke modtager beskeder. Derfor bør forberedelsen tage udgangspunkt i scenarier og ikke kun i læsning af dokumentation.
Fra eksamensmål til virkelige projekter
En stærk AZ-220-forberedelse begynder med at oversætte hvert emne til noget, der kan bygges. Når Microsoft beskriver IoT Hub, device lifecycle, DPS, IoT Edge, message routing, security og monitoring som målområder, bør kandidaten spørge, hvor de færdigheder optræder i en faktisk løsning. Det skaber en mere robust forståelse end at memorere produktnavne.
Et typisk mini-case kan være en produktionslinje med Edge-gateways i flere lokationer. Enhederne skal registreres uden manuelle connection strings, gateways skal kunne køre videre ved midlertidige netværksafbrydelser, telemetri skal sendes til analyse, og firmwarestatus skal kunne læses fra device twins. I et sådant scenarie bliver DPS, IoT Edge, IoT Hub-routing, reported properties og monitoring ikke isolerede eksamensemner, men dele af samme leverance.
En nyttig beslutningsnøgle i scenarieopgaver er forskellen mellem IoT Hub og IoT Central. IoT Hub passer, når løsningen kræver fuld kontrol over kode, identitet, routing, integrationer og downstream-arkitektur. IoT Central passer bedre, når opgaven peger på administreret brugergrænseflade, enhedsskabeloner og hurtig udrulning med mindre specialudvikling. Fejlen i eksamensscenarier er ofte at vælge den mest teknisk fleksible løsning, selv når kravene egentlig efterspørger en administreret applikationsplatform.
Et praktisk arkitekturbillede
Selv uden et grafisk diagram bør kandidaten kunne forklare datarejsen i en Azure IoT-løsning præcist. Tabellen nedenfor viser den arkitektur, mange AZ-220-øvelser kan bygges omkring: en simuleret enhed eller Edge-gateway sender telemetri til IoT Hub, hvorefter ruter og enrichments bestemmer, om data ender i storage, serverless behandling eller analyse.
| Lag |
Rolle i løsningen |
Hvad kandidaten bør kunne validere |
| Enhed eller simulator |
Sender telemetri og rapporterer tilstand via reported properties. |
At enheden bruger korrekt identitet, protokol og connection-indstilling. |
| DPS |
Klargør enheden til den rigtige IoT Hub uden manuel hub-binding i koden. |
At attestation, enrollment og assigned hub stemmer med scenariet. |
| IoT Edge |
Kører lokal logik, filtrering eller protokoloversættelse tæt på udstyret. |
At deployment-manifest, module twin og offline-adfærd fungerer. |
| IoT Hub routing |
Fordeler beskeder efter properties, message body eller endpoint. |
At routes, fallback route og enrichments rammer de forventede beskeder. |
| Storage, Functions eller analytics |
Gemmer, behandler eller analyserer telemetri til forretningen. |
At dataformat, partitionering, autorisation og fejlspor kan kontrolleres. |
Denne arkitektur er også et godt grundlag for fejlfinding. Hvis telemetri ikke lander i storage, kan fejlen ligge i enhedens connection, ruteudtryk, endpoint-tilladelser, message properties eller downstream-tjenestens konfiguration. AZ-220 belønner den kandidat, der kan isolere disse led metodisk frem for at gætte på det første synlige symptom.
En studieplan, der bygger færdighederne i den rigtige rækkefølge
Forberedelsen bør starte med Microsofts officielle AZ-220-side på Microsoft Learn, fordi eksamensmål, status og detaljer kan ændre sig. Derefter bør læsningen kobles til Azure IoT Hub-dokumentationen, DPS-dokumentationen, Azure IoT Edge-dokumentationen og relevante SDK-eksempler. Dokumentation alene er dog ikke nok; kandidaten skal kunne vise, at konfigurationen virker i en sandbox.
Læs AZ-220-målene og marker de emner, der kræver praktisk opsætning.
Byg en IoT Hub med en simuleret enhed og send telemetri med et understøttet SDK.
Tilføj DPS med en enrollment group og fjern hårdkodet hub-tilknytning fra enhedskoden.
Implementer et IoT Edge-modul og valider deployment, module twin og offline-adfærd.
Opret routing til storage eller en function og kontroller resultatet med metrics og logs.
Gentag scenariet med fejl, for eksempel afbrudt netværk eller forkert attestation.
En praktisk faldgrube er at bruge al øvetiden på SDK-kald og for lidt på klargøring, routing og Edge. I øvelser ses fejl ofte omkring DPS, hvor kandidaten blander X.509- og symmetric key-attestation, eller omkring device twins, hvor desired og reported properties behandles som det samme. En anden almindelig årsag til spildtid er routing uden fallback route eller enrichments, der aldrig rammer, fordi message properties ikke sættes der, hvor ruteudtrykket forventer dem.
Sandbox-hygiejne betyder også noget. Vælg en passende IoT Hub-SKU til øvelser, saml ressourcer i en dedikeret resource group og ryd op efter hver session, for eksempel med Azure CLI-kommandoen az group delete, når miljøet ikke længere skal bruges. Det holder øvelserne overskuelige og reducerer risikoen for, at gamle endpoints, policies eller routes forstyrrer den næste lab.
Hands-on eksempel med DPS og device twin
Eksemplet nedenfor viser et lille Python-flow, hvor en enhed registrerer sig via Device Provisioning Service og derefter opdaterer sin reported twin state i IoT Hub. Det er relevant for AZ-220, fordi det binder klargøring og device twins sammen i én arbejdsgang, hvilket er tættere på virkelige IoT-projekter end en statisk connection string.
Example — DPS registration and reported twin update
import asyncio
import os
from azure.iot.device.aio import IoTHubDeviceClient, ProvisioningDeviceClient
PROVISIONING_HOST = "global.azure-devices-provisioning.net"
ID_SCOPE = os.environ["DPS_ID_SCOPE"]
REGISTRATION_ID = os.environ["DPS_REGISTRATION_ID"]
DEVICE_KEY = os.environ["DPS_DEVICE_SYMMETRIC_KEY"]
async def main():
provisioning_client = ProvisioningDeviceClient.create_from_symmetric_key(
provisioning_host=PROVISIONING_HOST,
registration_id=REGISTRATION_ID,
id_scope=ID_SCOPE,
symmetric_key=DEVICE_KEY,
)
registration_result = await provisioning_client.register()
if registration_result.status != "assigned":
raise RuntimeError(f"Device was not assigned: {registration_result.status}")
assigned_hub = registration_result.registration_state.assigned_hub
device_id = registration_result.registration_state.device_id
device_client = IoTHubDeviceClient.create_from_symmetric_key(
symmetric_key=DEVICE_KEY,
hostname=assigned_hub,
device_id=device_id,
)
await device_client.connect()
twin = await device_client.get_twin()
desired = twin.get("desired", {})
await device_client.patch_twin_reported_properties(
{
"provisioningStatus": "assigned-by-dps",
"firmwareVersion": "1.0.0",
"telemetryIntervalSeconds": desired.get("telemetryIntervalSeconds", 30),
}
)
await device_client.disconnect()
await provisioning_client.shutdown()
if __name__ == "__main__":
asyncio.run(main())
Koden forudsætter, at miljøvariablerne peger på en DPS-konfiguration, hvor enheden kan attesteres med en device-specific symmetric key. Efter registreringen bruger enheden den tildelte hub og opdaterer reported properties, så driftsteamet kan se provisioning-status, firmwareversion og den telemetri-intervalværdi, enheden faktisk bruger. I en lab bør kandidaten bagefter kontrollere device twin i Azure IoT Explorer eller via CLI og verificere, at værdierne ændrer sig som forventet.
Hvordan du ved, om du er klar
Parathed til AZ-220 kan ikke måles sikkert ved at læse et emne én gang og genkende produktnavne. En mere pålidelig indikator er, om kandidaten kan bygge en lille end-to-end-løsning uden at følge en klik-for-klik-guide. Det kræver, at opsætning, kode, routing, Edge-konfiguration og fejlfinding hænger sammen.
- Du kan forklare, hvornår IoT Hub er det rigtige valg, og hvornår IoT Central passer bedre.
- Du kan klargøre en enhed med DPS og forklare forskellen på X.509- og symmetric key-attestation.
- Du kan ændre desired properties og se enheden rapportere sin faktiske tilstand tilbage.
- Du kan oprette en route med et endpoint og bevise, at beskederne rammer den rigtige destination.
- Du kan fejlfinde med metrics, logs og Azure IoT Explorer i stedet for kun at læse kode.
Robusthed bør også testes, fordi virkelige IoT-miljøer sjældent er stabile hele tiden. Afbryd netværket for en Edge-enhed, genstart et modul, send flere beskeder end forventet, eller lav en bevidst forkert route og observer, hvordan løsningen reagerer. Den øvelse giver en mere eksamensrelevant forståelse af backoff, genafspilning, offline-køer og monitorering end et rent lykkesti-scenarie.
Eksamensdagens strategi
På selve eksamensdagen bør kandidaten læse scenarieopgaverne som arkitekturkrav, ikke som produktquizzer. Ord som administreret UI, hurtig applikationsopbygning, fuld kodekontrol, offline edge processing, automatisk enrollment eller downstream routing peger ofte mod bestemte designvalg. Hvis to svar virker teknisk mulige, bør det valgte svar være det, der opfylder kravene med mindst unødig kompleksitet.
Det er også værd at være opmærksom på detaljer i formuleringen. Et spørgsmål om en enheds ønskede konfiguration handler typisk ikke om den samme egenskab som den rapporterede tilstand. Et spørgsmål om routing kan afhænge af, om data findes i message body, system properties eller application properties. Den type skel er grunden til, at praktiske labs er mere værdifulde end passiv repetition.
Næste skridt mod en stærkere AZ-220-forberedelse
Den mest effektive næste handling er at bygge én lille IoT-løsning, der bruger DPS, IoT Hub, en device twin, en route og et simpelt downstream-endpoint. Når den virker, bør kandidaten ødelægge den kontrolleret og reparere den igen. Det træner den kombination af implementering og fejlfinding, som Azure IoT Developer-rollen kræver.
Hvis et team har brug for en mere struktureret vej gennem emnerne, kan Readynez bruges som ramme for at samle teori, labs og eksamensforberedelse uden at gøre læringen afhængig af memorering. Det afgørende er stadig den praktiske kunnen: En kandidat, der kan forklare designvalgene og validere dem i Azure, står stærkere end en kandidat, der kun kan genkende begreberne.
