Azure IoT Developer (AZ-220) flashcards
Azure IoT Developer (AZ-220) · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- IoT Hub Basic tier limitation
- Basic tier excludes cloud-to-device messaging, device twins, direct methods, and device management. Use Standard for any solution needing twins or commands.
- Scale unit message quota
- Each S1 unit allows 400,000 messages per day; S2 allows 6,000,000; S3 allows 300,000,000. Exceeding the quota causes throttling, not automatic overage billing.
- Tier change direction
- You may upgrade from Basic to Standard but cannot downgrade from Standard to Basic. Scaling units up or down within the same tier is permitted.
- Partition count at creation
- The number of partitions on the built-in Event Hubs endpoint is set when the hub is created and cannot be changed later; it limits concurrent readers.
- iothubowner policy risk
- The iothubowner shared access policy grants full registry and service rights. Never ship it to devices; use it only for administrative tooling.
- Device-to-cloud max message size
- A single device-to-cloud message is limited to 256 KB. Larger payloads must be split or sent through the file upload path with a SAS URI.
- Individual vs group enrollment
- Individual enrollment registers one device with custom allocation. Group enrollment registers many devices sharing attestation, such as an X.509 CA or symmetric key.
- DPS allocation policies
- Hashed spreads devices evenly, geolatency picks the lowest-latency linked hub, static pins a hub, and custom calls an Azure Function for assignment logic.
- Device twin structure
- A twin contains desired properties set by the solution, reported properties sent by the device, and tags used only for querying and grouping devices.
- Direct method timeout
- Direct methods are synchronous and require a connected device. The default response timeout is 30 seconds and the maximum is 300 seconds.
- IoT Hub jobs use case
- Jobs run twin updates, direct methods, or device deletions across many devices, and can be scheduled for offline devices with pollable status.
- Symmetric key rotation
- Each device identity has primary and secondary symmetric keys. Rotate by switching devices to the secondary key, then regenerate the primary key.
- edgeAgent and edgeHub roles
- edgeAgent pulls and reports deployments; edgeHub brokers module messages, handles routing, and buffers messages offline for store-and-forward delivery.
- Layered deployment manifest
- Layered deployments apply partial manifests in priority order, letting a base configuration be overridden by more specific layers without full redeployment.
- edgeHub route syntax
- Routes use FROM source TO sink, for example FROM /messages/modules/mod1/outputs/* INTO $upstream. Route evaluation order is not guaranteed.
- Edge-enabled device identity
- Before the IoT Edge runtime connects, the device must exist in the registry with an edge-enabled identity, indicated by a non-empty deviceScope value.
- Edge offline buffering settings
- edgeHub timeToLiveSecs and the storage path control how long messages are retained offline; priority queues 0 through 9 order messages under load.
- iotedge check command
- The iotedge check tool validates host configuration, certificates, connectivity, and container prerequisites, reporting errors and warnings before deployment.
- Message routing fallback route
- Messages that match no routing query are sent to the fallback route if enabled. Disable it to drop unmatched messages instead.
- Message enrichment limits
- Enrichment adds up to 10 static key-value pairs, sourced from device twin tags, to outgoing messages. Values are literal strings, not expressions.
- Event Grid device events
- IoT Hub publishes deviceCreated, deviceDeleted, deviceConnected, and deviceDisconnected events to Event Grid so workflows can react to lifecycle changes.
- Consumer group isolation
- Each Event Hubs reader should use its own consumer group. Sharing $Default across readers causes partition contention and missed or split reads.
- File upload notification
- After a device uploads a blob, IoT Hub emits a notification message containing the blob URI that can be routed to a service endpoint.
- Stream Analytics window types
- Tumbling windows are fixed and non-overlapping, hopping windows overlap, sliding windows are event-driven, and session windows group by inactivity gaps.
- Twin change event routing
- Routing queries can target twinChangeEvents to route desired or reported property changes, separate from device telemetry messages.
- IoT Plug and Play model ID
- A device declares its DTDL model ID when connecting, letting solutions interpret telemetry, properties, and commands without custom parsing code.
- Built-in endpoint replay limit
- The built-in Event Hubs endpoint retains messages for a limited time. Once read and the retention passes, telemetry cannot be replayed.
- Diagnostic log categories
- IoT Hub resource logs include Connections, DeviceTelemetry, C2DCommands, Routes, and Twins, and can be sent to Log Analytics, Storage, or Event Hubs.
- Throttling response handling
- Throttled requests return HTTP 429 with a retry-after hint. Clients should back off for that interval instead of retrying immediately.
- Twin ETag conflict
- Twin updates with a stale ETag fail with HTTP 412. Send If-Match with the current ETag, or use a wildcard to force the write.
- SAS token authentication
- Devices authenticate with a SAS token signed by their device key, carrying an expiry. Expired tokens produce 401 errors and require token regeneration.
- Private endpoint for IoT Hub
- Disabling public network access and using a private endpoint keeps device and service traffic on the virtual network, reducing exposure to the internet.