Azure IoT Developer (AZ-220) cheat sheet

IoT Hub tiers: Basic (no cloud-to-device, no twins, no device management) vs Standard (all features); S1/S2/S3 scale units set daily message quota, not throughput per unit.

Tier/scale change is a one-way path: Basic to Standard is allowed; Standard to Basic is not; scale up or down within a tier is allowed at any time.

Message quota is per-unit: S1 = 400,000 messages/day/unit, S2 = 6,000,000, S3 = 300,000,000; exceeding quota throttles rather than bills overage.

Throttle limits are per-unit: device-to-cloud sends 12 KB/s per unit, cloud-to-device 1.5 KB/s per unit, twin reads 10/s per unit, twin writes 10/s per unit.

Choose partitioning: number of partitions is fixed at creation (default 4, configurable) and affects concurrent readers on the built-in endpoint.

Shared access policies: iothubowner (full), service (ServiceConnect), device (DeviceConnect), registryRead, registryReadWrite; scope keys per policy, never reuse iothubowner in device code.

IoT Hub is regional; use a device provisioning service for cross-region enrollment, and route messages to endpoints (Event Hubs, Service Bus, Storage, Cosmos DB) via message routing queries.

Device-to-cloud max message size is 256 KB; larger payloads must be chunked or uploaded via the file upload (blob) path with SAS URI notification.

Device Provisioning Service (DPS) enrollment types: individual enrollment (one device, custom allocation) vs group enrollment (X.509 intermediate/root CA signed, shared settings).

DPS attestation mechanisms: X.509 certificate, TPM endorsement key, and symmetric key; symmetric key group enrollments derive per-device keys from the group primary/secondary key.

Allocation policies: hashed (even distribution), geolatency (lowest latency linked hub), static (fixed hub), custom (Azure Function); reprovisioning policy controls behavior on re-enrollment.

Device twin is JSON: desired properties (solution sets), reported properties (device reports), and tags (solution-only metadata); twin operations are eventually consistent.

Direct methods are synchronous request/response with a response timeout (default 30 s, max 300 s); invoke only on connected devices or use jobs for offline devices.

IoT Hub jobs handle twin updates, direct method invocation, and device deletion at scale; jobs can be scheduled and their status polled.

Device lifecycle: create identity in registry (deviceId unique, case-insensitive), then connect; disabling a device rejects connections while retaining identity and twin.

Symmetric key device connection string contains SharedAccessKey; SAS token expiry is generated client-side; primary and secondary keys allow non-disruptive rotation.

IoT Edge runtime has two system modules: edgeAgent (deployment/reporting) and edgeHub (message broker, routing, offline store-and-forward).

Deployment manifests (JSON) declare modules, routes, and desired properties for $edgeAgent and $edgeHub; layered deployments apply partial manifests by priority.

Routes are declared in edgeHub desired properties: FROM source TO sink, e.g. FROM /messages/modules/mod1/outputs/* INTO $upstream; route order is not guaranteed.

Module-to-module communication uses the module's input/output names; modules also get a module twin for configuration and a direct method endpoint.

edgeHub store-and-forward: timeToLiveSecs and storage path control offline buffering; priority queues (0-9) determine message ordering under load.

Device must be registered in IoT Hub with an edge-enabled identity (deviceScope set) before the runtime connects; edgeAgent reports deployment status in its twin.

X.509 identity for IoT Edge uses a device CA certificate installed on the host to sign module certificates; the root CA must be trusted by the runtime.

Debug with iotedge check, iotedge logs <module>, and module twin reported properties; the edgeHub/edgeAgent twins expose last desired vs applied state.

Message routing query syntax is based on message properties, system properties (e.g., $.$body, contentType, deviceId), and twin change events; unmatched messages fall to the fallback route.

Built-in endpoint is Event Hubs-compatible; custom endpoints include Storage containers, Event Hubs namespaces, Service Bus queues/topics, and Cosmos DB.

Message enrichment adds up to 10 key-value pairs from device twin tags to outgoing messages; enrichment values are static strings, not expressions.

Event Grid integration fires device lifecycle events (deviceCreated, deviceDeleted, deviceConnected, deviceDisconnected) for reactive workflows.

Azure Functions triggered by Event Hubs use the built-in endpoint with an Event Hub-compatible connection string and consumer group.

Azure Stream Analytics input can be IoT Hub directly; use consumer groups distinct from $Default to avoid reader contention.

Time Series Insights / ADX pattern: route telemetry to a store for analytics while routing alerts to Service Bus or Functions for action.

IoT Hub file upload notifications arrive as a message with a blob URI and can be routed to a service endpoint for downstream processing.

Device-to-cloud message properties: messageId, correlationId, userId, contentType, contentEncoding, iothub-creation-time-utc; system properties are read-only.

Routing queries can filter on body ($body.temperature > 30), application properties, and twin change events via twinChangeEvents.

Stream Analytics windowing: tumbling (fixed, non-overlapping), hopping (fixed, overlapping), sliding (event-driven), session (gap-based).

Warm path vs cold path: hot storage for dashboards, cold storage (Blob/Data Lake) for batch; IoT Hub cannot replay messages once read from the built-in endpoint.

Twin desired properties are applied by the device; reported properties reflect actual state; use tags to query device groups with the registry query language.

File upload stores blobs in a storage account; the device receives a SAS URI from IoT Hub and notifies completion, which can be routed.

Consumer groups on the built-in Event Hubs endpoint allow multiple independent readers; $Default is shared, so create dedicated groups per reader.

Digital twins / IoT Plug and Play use DTDL models to describe telemetry, properties, and commands; the model ID is sent in the connection.

Diagnostic logs: enable IoT Hub resource logs to Log Analytics, Event Hubs, or Storage; categories include Connections, DeviceTelemetry, C2DCommands, Routes, and Twins.

Metrics to watch: d2c.telemetry.ingress.allProtocol, d2c.telemetry.egress.success, c2d.commands.egress.complete, twins.read, and throttling metrics (d2c.telemetry.ingress.throttle).

Throttling errors surface as 429 with a retry-after; back off client-side rather than retrying immediately.

Connection state errors: 401 (auth/SAS expired), 404 (unknown deviceId), 412 (ETag mismatch on twin update), 429 (throttle), 500 (transient).

Twin ETag concurrency: include If-Match on updates; use '*' to force overwrite; otherwise a stale ETag returns 412.

Azure Monitor alerts can fire on metric thresholds (e.g., throttled messages) or on Log Analytics query results; action groups route notifications.

Optimize cost by matching tier/units to message volume, batching telemetry, reducing twin writes, and shortening SAS token lifetimes.

Use distributed tracing (traceparent) and message correlationId to follow a message from device through routes to downstream services.

Authentication options: SAS token (symmetric key), X.509 certificate (thumbprint or CA-signed), and TPM attestation via DPS; SAS tokens are per-device scoped.

Security best practice: never embed iothubowner or service keys in devices; use per-device credentials and rotate primary/secondary keys.

X.509 chain: device presents leaf certificate; IoT Hub validates against the registered thumbprint or a CA uploaded to the registry (verify possession).

DPS group enrollment with CA: devices present a chain to the enrolled intermediate/root; the leaf common name becomes the deviceId by default.

Shared access policy least privilege: devices need DeviceConnect only; backend services need ServiceConnect and/or RegistryRead.

TLS 1.2 is required; disable older protocols; use AMQP over WebSocket (443) when outbound 5671 is blocked.

Private endpoint / managed identity: disable public network access and connect via private endpoint; use managed identity for backend access to IoT Hub.

Azure Defender for IoT provides threat detection (anomalous connections, credential brute force) and can be enabled at the hub level.