Microsoft retired AZ-220, the Azure IoT Developer examination, on July 31, 2023. The retired specialty credential cannot be earned by booking that exam in 2026, but its architecture subjects remain useful when maintaining device fleets or comparing an older system with current Azure services. This article preserves the original readers’ interest in IoT Hub, provisioning, messaging, edge computation and operational security while clearly separating historical objectives from present deployment guidance.
An IoT solution begins with a device identity, network connection and trustworthy telemetry contract. The cloud must know which device sent an event, how messages are routed and what changes an operator can safely apply to a remote device. If a device is offline or compromised, the system also needs a recovery procedure. These operational questions are more durable than any retired examination’s question format or score requirement.
What AZ-220 originally represented
The AZ-220 certification was designed specifically for Azure IoT developers — professionals who implement the cloud and edge components of Azure IoT solutions as their primary technical responsibility. This includes setting up and managing IoT hubs, provisioning devices at scale, implementing device communication protocols, building data processing pipelines for IoT telemetry, configuring security across device and cloud layers, and deploying workloads to edge devices. the former specialty credential assumes that candidates are working in or transitioning into roles where IoT development is a central technical function rather than a peripheral awareness requirement.
The typical candidate for AZ-220 has experience with Azure cloud services, familiarity with at least one programming language used for IoT development such as Python, C, or C#, and some exposure to IoT concepts either through professional work or substantive project experience. Candidates who come from software development backgrounds with Azure experience find the cloud services portions of the historical assessment accessible, while those who come from embedded systems or industrial automation backgrounds may need to invest more preparation time in the Azure services dimensions of the content. The specialty nature of this certification means it is most valuable for professionals who are committed to IoT as a career focus rather than those who want a general cloud credential.
IoT Hub and device identity
Azure IoT Hub is the central service in most Azure IoT architectures, serving as the cloud gateway through which IoT devices communicate with the Azure platform. the retired AZ-220 syllabus places significant emphasis on IoT Hub configuration, and engineers should understand this service in considerable depth. Configuration topics include IoT Hub tiers and their capabilities, message routing rules and endpoints, built-in event processing, device twin properties and their synchronization with physical devices, direct methods for invoking actions on devices, and the message enrichment capabilities that add metadata to messages before routing them to their destinations.
Device management within IoT Hub is another heavily tested area that encompasses device provisioning, device registry operations, device twin management, and the tools available for managing large fleets of IoT devices at scale. engineers should understand how to use the Azure IoT Hub Device Provisioning Service to automate the registration and configuration of devices as they connect to the cloud for the first time, how to use device twins to maintain desired and reported state for individual devices, and how to apply configuration updates across groups of devices using automatic device management. the historical assessment tests these capabilities at a level of detail that requires hands-on familiarity rather than conceptual awareness alone.
Security work begins at enrollment: authenticate a device, restrict privileges and define revocation and rotation procedures. Test how the system behaves when a token expires, a certificate is replaced or a provisioned device is removed. Audit who can read telemetry and issue cloud-to-device commands. A communication path is not secure merely because an Azure service encrypts its transport; identity, device firmware, secrets and operational permissions all matter.
Provisioning and edge deployment
The Azure IoT Hub Device Provisioning Service is a helper service for IoT Hub that enables zero-touch, just-in-time provisioning of IoT devices to the correct IoT Hub without requiring human intervention at device deployment time. For organizations deploying thousands or millions of IoT devices across distributed locations, the ability to automate device provisioning is not a convenience — it is an operational necessity. the retired AZ-220 syllabus tests candidates’ understanding of DPS in considerable depth, including enrollment group configuration, individual enrollment configuration, attestation mechanisms, and the allocation policies that determine which IoT Hub a device is assigned to when multiple hubs are available.
Attestation mechanisms are a particularly important topic within the DPS domain because they represent the security foundation of the provisioning process. engineers should understand X.509 certificate attestation, Trusted Platform Module attestation, and symmetric key attestation — including the security trade-offs between these approaches and the scenarios where each is most appropriate. the historical assessment frequently presents scenarios where candidates must select the appropriate attestation mechanism based on device capabilities, security requirements, and operational constraints. Developing a clear understanding of when each attestation approach is suitable, and what configuration is required to implement each one, is essential preparation for this portion of the historical assessment.
Azure IoT Edge is one of the most distinctive components of the Azure IoT platform, enabling organizations to run cloud workloads directly on IoT devices rather than sending all data to the cloud for processing. the retired AZ-220 syllabus dedicates significant coverage to IoT Edge because it represents a technically complex and practically important capability that distinguishes Azure’s IoT offering. engineers should understand the IoT Edge runtime architecture, including the role of the IoT Edge agent and IoT Edge hub modules that run on every IoT Edge device, and how these system modules manage the lifecycle and communication of the custom modules that implement business logic at the edge.
Module deployment to IoT Edge devices is managed through deployment manifests that specify which modules should run on a device, how those modules should communicate with each other through message routes, and what environment variables and configuration settings each module should receive. the retired AZ-220 syllabus tests candidates’ understanding of deployment manifest structure and configuration, the layered deployment model that allows base configurations to be applied to large groups of devices while allowing device-specific overrides, and the monitoring mechanisms available for verifying that IoT Edge deployments are functioning as intended. Candidates who invest time in actually deploying IoT Edge modules to test devices — whether physical hardware or simulated virtual devices — develop the intuitive understanding of this deployment model that scenario-based examination questions require.
Before building an edge demonstration, document the software version, supported hardware, managed-device capabilities and current retirement or maintenance notice for every SDK and runtime. Older tutorials may use commands or modules that have since changed. An isolated test fleet with synthetic telemetry is safer than joining an archived device image to a production network. Keep identity credentials separate from code and make certificate replacement part of the exercise.
Messages, telemetry and downstream processing
IoT devices communicate with Azure services using a variety of protocols that differ in their capabilities, overhead, and suitability for different device types and network conditions. the retired AZ-220 syllabus tests candidates’ knowledge of MQTT, AMQP, and HTTPS as the primary protocols supported by Azure IoT Hub, including the specific capabilities that each protocol supports and the trade-offs involved in choosing between them. MQTT is typically preferred for resource-constrained devices because of its low overhead, while AMQP is better suited for scenarios where multiplexing multiple device connections through a single connection is valuable. HTTPS is the most universally accessible protocol but carries higher overhead per message.
Message patterns are another important topic within device communication, covering the different ways that devices and cloud services exchange information in Azure IoT architectures. Device-to-cloud messages carry telemetry from devices to the cloud for processing and storage. Cloud-to-device messages allow backend services to send commands or notifications to individual devices. Direct methods enable synchronous request-response communication between the cloud and devices. Device twin desired properties allow the cloud to specify configuration targets for devices, while reported properties allow devices to communicate their current configuration back to the cloud. Each of these patterns has specific use cases, limitations, and implementation characteristics that the historical assessment tests in realistic scenario contexts.
IoT deployments generate continuous streams of telemetry data that must be processed, filtered, transformed, and routed to appropriate storage and analytics destinations. the retired AZ-220 syllabus covers the Azure services used to process IoT telemetry, with particular emphasis on Azure Stream Analytics as the primary service for real-time processing of IoT data streams. engineers should understand how to configure Stream Analytics jobs to consume input from IoT Hub or Event Hub, write queries that filter, aggregate, and transform streaming data, and route output to destinations including Azure Storage, Azure SQL Database, Power BI, and other services.
A good telemetry design specifies what a device sends, whether messages need ordering, how duplicates will be handled and where raw events should be retained. A temperature reading without time, source and units can be misleading even if it arrives successfully. Test backpressure, disconnected operation and delayed delivery. The ability to explain the full path from device to consumer is a practical skill, independent of whether an exam has been retired.
Security, digital twins and system boundaries
Security is one of the most heavily weighted topics in the retired AZ-220 syllabus, reflecting the genuine security challenges that IoT deployments present. IoT devices often operate in physically accessible locations where they cannot be protected by the same perimeter security controls that protect data center equipment. They may run for years or decades without opportunities for security updates. They communicate over networks that may be shared with other devices and systems. And compromised IoT devices can serve as entry points into larger organizational networks with far more valuable assets. the historical assessment tests candidates’ understanding of security practices that address these distinctive IoT security challenges.
Azure Digital Twins is a platform service that enables organizations to build digital models of physical environments — buildings, factories, cities, or any other spatial context — and populate those models with real-time data from IoT sensors. the retired AZ-220 syllabus includes coverage of Azure Digital Twins as an increasingly important component of sophisticated IoT architectures. engineers should understand the Digital Twins Definition Language used to define models, how to create and manage twin instances that represent physical objects, and how to query the digital twin graph to extract insights about the modeled environment.
The integration of Azure Digital Twins with other Azure IoT services is another examination topic, including how IoT Hub device telemetry flows into Digital Twins to update twin properties in real time and how Azure Digital Twins integrates with Time Series Insights for historical analysis of twin property changes over time. the historical assessment tests candidates’ ability to design architectures that incorporate Digital Twins appropriately for scenarios where spatial modeling and environmental awareness add value, as well as their understanding of when simpler architectures without Digital Twins better serve the requirements of a given IoT solution.
Monitoring, test evidence and a safe modern learning path
Operating IoT solutions in production requires robust monitoring and troubleshooting capabilities because IoT deployments involve large numbers of devices operating in diverse and sometimes challenging environments where failures can be difficult to diagnose remotely. the retired AZ-220 syllabus covers the monitoring and diagnostic tools available for Azure IoT solutions, including Azure Monitor metrics and logs for IoT Hub, the built-in monitoring capabilities of IoT Edge, and the diagnostic message routing features that allow IoT Hub to send operational events and error information to Azure Storage or Event Hub for analysis.
Treat old AZ-220 laboratories as scenario references, not a promise of a current exam or a universal best-practice architecture. A useful lab records the starting state, the failure introduced, logs observed, repair decision and resulting device state. Compare deprecated service names and configuration screens with the supported Azure documentation before translating any archived instructions into a production runbook.
For historical AZ-220 technical practice, use official archived learning material as a reference for IoT Hub device identity, provisioning, telemetry, monitoring and edge deployment. The Azure IoT Developer Specialty examination retired July 31, 2023 and is not currently bookable; old exam timings, scoring assumptions and test-taking tips should not be presented as 2026 registration advice.
Build a controlled IoT scenario instead. Register a test device, assess how Device Provisioning Service enrollment changes device identity, send sample telemetry to IoT Hub, and investigate a failed connection through logs, credentials and network paths. Document expected and observed behavior. Confirm that each service, SDK and edge runtime is still supported before applying any archived procedure to a current deployment.
Security and recovery are more valuable than memorizing a retired assessment. Test what happens when a device certificate expires, a connection is lost, a provisioned identity is revoked or duplicate telemetry arrives. Make the corrective procedure reproducible and identify where human approval is needed for device access or production changes.
The value of the old AZ-220 blueprint lies in the architecture and engineering problems it describes, not in a currently available specialty badge or a guaranteed career advantage. Use active vendor documentation and a practical portfolio to demonstrate what you can build, secure, monitor and maintain.