Set Up the Azure IoT Hub Solution Infrastructure
What you must know
IoT Hub sits at the centre of the solution. Understand the tiers: Basic (device-to-cloud only) versus Standard (adds cloud-to-device, twins, device management, and modules). Know the scale and quota table - units per hub, messages per day per unit, and per-unit throttles. Know that partition count is fixed at creation and cannot be changed later. Understand shared access policies (registry read, registry write, service connect, device connect) and that per-device credentials are separate from hub-level SAS policies.
Also know the related services that questions try to blend into IoT Hub: Device Provisioning Service (DPS) for zero-touch enrolment, Event Hubs-compatible endpoints for built-in routing, message routing to Blob, Service Bus, Event Hubs, or custom endpoints, and Azure Storage for file uploads. Know the built-in endpoint retention (default 1 day, configurable up to 7) versus the retention of a routed storage account.
Traps
- Choosing Basic for a scenario that needs twins or cloud-to-device messages - Basic cannot do it.
- Assuming you can increase partitions after creation - you cannot.
- Confusing message routing (rich queries, multiple endpoints) with the legacy custom endpoints feature.
- Forgetting that DPS requires the hub and the DPS instance to be in the same region for linked hubs in many scenarios, and that allocation policies (even, lowest latency, static, custom) change the answer.
Rule of thumb
If the stem mentions twins, modules, jobs, direct methods, or cloud-to-device messaging, the answer is Standard tier. If it mentions only telemetry ingestion at lowest cost, Basic is acceptable.
Worked example
A scenario needs 4 million messages per day and device twins. Standard tier S1 gives 400,000 messages/day per unit, so 10 units cover 4 million. Twins require Standard, so S1 with 10 units is the answer - not a Basic tier with more units.