Azure IoT Developer (AZ-220) common mistakes
Azure IoT Developer (AZ-220) · Understand the traps and how to avoid them.
When sizing an IoT Hub tier, the candidate picks a tier by device count alone and ignores the throttling limits on daily message quota, twin/identity registry operations, and device-to-cloud vs cloud-to-device message sizes, then cannot explain why a high-throughput solution fails on a lower tier.
Study material often summarizes tiers as 'S1 for small, S2 for medium, S3 for large' by device count, so candidates memorize a device-count table and never learn that operations-per-second and daily message allowance are separate quotas that drive tier selection.
What to do instead
Build a one-page comparison of Basic vs Standard tiers and the S1/S2/S3 units, listing device-to-cloud throttle, cloud-to-device throttle, identity registry operation limits, twin read/write limits, and file upload limits. For each practice scenario, compute required messages per day and peak operations per second and state which quota binds first; also note that only Standard tiers support twins, direct methods, and cloud-to-device messaging.
The candidate configures shared access policies with registry-write or service-connect permissions and hands that connection string to a field device, or reuses the hub-level owner policy in application code instead of scoping permissions.
Portal quickstarts show a single iothubowner connection string copied into sample code, so candidates treat it as the default credential and never learn that device-facing code should use per-device credentials or a narrowly scoped policy.
What to do instead
Practice creating separate policies per consumer: registry read/write for provisioning services, service connect for backend apps, device connect only where needed. Remember device code uses device-specific symmetric keys or X.509, not hub-level SAS. For each scenario, write down which identity calls which operation and confirm the policy grants only that operation.
When asked to choose a provisioning approach, the candidate picks Device Provisioning Service for a fixed set of devices on a single hub, or picks manual per-device registration for a fleet that needs zero-touch, geo-distributed enrollment with later reassignment.
DPS is presented as the 'advanced' topic, so candidates equate it with the correct answer in every provisioning question and skip the decision criteria around scale, tenancy, and lifecycle.
What to do instead
Memorize the decision rule: manual registration for small fixed fleets or testing; DPS when devices self-register at scale, need load balancing across hubs, or must be reassigned after reprovisioning. Practice describing an enrollment group with symmetric key attestation, a TPM or X.509 individual enrollment, and the allocation policies (hashed, geo-latency, static, custom) with one scenario each.
The candidate describes reprovisioning as simply deleting and re-adding the device, missing that the device must be disenrolled or the enrollment updated and that the initial twin state and device ID behavior depend on the reprovision policy configured on the enrollment.
Reprovisioning is a short topic, so candidates skim the reprovision policy settings and cannot explain what happens to the device twin when a device moves to a different hub.
What to do instead
Learn the reprovision policy options (reprovision and reset to initial state, reprovision and migrate device data, never reprovision) and which twin data is preserved. Walk through a migration scenario end to end: disable or update enrollment, have the device re-run registration, and confirm the resulting hub, device ID, and twin contents.
When writing an IoT Edge deployment manifest, the candidate puts module images without matching the module twin desired properties to the module's expected property names, or sets routes using the wrong source or condition syntax so messages silently drop.
Manifests are long JSON documents and candidates copy structure without understanding that routes match on source (for example telemetry versus twin change) and that a module only reads desired properties it actually implements.
What to do instead
Practice authoring a two-module manifest by hand: define module images, create the module twin desired properties block with the exact property path the module code reads, and write routes such as FROM /messages/modules//outputs/* INTO $upstream plus a route to a local storage or brokered endpoint. Verify each route's source and sink and explain what happens to unmatched messages.
The candidate configures an IoT Edge device and assumes it works offline, without accounting for the edgeHub store-and-forward settings, time-to-live, and priority on routes, or without verifying the device connection string and provisioning method used at install time.
Cloud-connected demos always have connectivity, so candidates never exercise offline behavior and do not connect route priority/TTL to message buffering and expiry.
What to do instead
Study the edgeHub desired properties for store and forward: time to live, priority, and the storage folder. Simulate an offline window and predict which messages are buffered and which expire. Also practice both manual connection-string provisioning and DPS enrollment for Edge, and confirm the IoT Edge runtime status and module logs after install.
The candidate routes all telemetry straight to a storage account or Event Hubs and never uses the built-in Event Hubs-compatible endpoint, or configures a Stream Analytics job with an input, query, and output that do not match the message schema and timestamp expectations.
Business integration questions blend several services, and candidates learn each service in isolation without practicing how message body, content type, and event enqueued time flow from hub to downstream consumer.
What to do instead
Practice an end-to-end pipeline: IoT Hub built-in endpoint as the Stream Analytics input, a query that projects fields from the JSON payload, and an output to Blob storage or a function. Confirm which timestamp the job uses, how to handle malformed messages, and when to prefer Event Grid for reactive notifications versus Event Hubs for high-volume stream consumption.
The candidate treats device-to-cloud routing queries and message enrichment as interchangeable, or writes a routing query that filters on a twin property without realizing twin-based filtering requires the message to be routed through the twin update path or a specific query syntax.
Routing query syntax is terse and the docs mix message properties, application properties, and twin conditions, so candidates blur the distinction between filtering telemetry and enriching it before routing.
What to do instead
Memorize the three filter surfaces: message body, message application and system properties, and twin properties with the $twin prefix. Practice writing queries for each and adding message enrichments as key-value pairs that appear as application properties downstream. For each scenario, state whether enrichment or filtering is needed and why.
When troubleshooting, the candidate jumps to restarting or recreating the device instead of using the available diagnostics: metrics and diagnostic settings, the device connection and telemetry events in the portal, distributed tracing, and the resource health and activity logs.
Hands-on practice is usually limited to the happy path, so candidates have no mental checklist for a failing device and default to destructive fixes.
What to do instead
Build a triage checklist: first confirm device status and last connection time, then check hub metrics for throttling or authorization errors, then enable diagnostic logs to Log Analytics and query for connection and twin errors, then use distributed tracing for message flow. Practice reading a 401 or 429 error and mapping it to a credential or quota cause before changing configuration.
The candidate designs device security around symmetric keys only, or stores the connection string in application configuration, and cannot explain when to use X.509 certificates, when to use TPM or DPS attestation, and how to scope a managed identity for a backend service.
Security is spread across provisioning, hub configuration, and Edge, so candidates learn each fragment separately and miss the layered model of device identity, transport encryption, and service-side authorization.
What to do instead
Practice mapping each credential type to a scenario: symmetric keys for low-cost constrained devices with per-device keys, X.509 for certificate lifecycle and CA-signed enrollment, TPM for hardware-rooted attestation. For backend services, prefer managed identity with narrowly scoped role assignments over shared keys. Also review TLS requirements, the minimum TLS version setting, and how to rotate or revoke credentials without re-registering devices.