My Journey to Achieve the Azure Iot Developer Speciality certification (AZ-220)

Hugo Barona included in Azure Certification Microsoft Azure IoT Developer Specialty Azure IoT

2020-11-15 3411 words 17 minutes

/my-journey-to-achieve-the-azure-iot-developer-speciality-certification-az220/featured-image.png

Contents

The Azure IoT Developer Specialty certification will help you learn how to manage the IoT devices lifecycle–set up, configuration, and maintenance–using cloud services and other tools. You will also learn how to implement designs for Azure IoT solutions including device topology, connectivity, debugging, and security, as well as solutions to manage, monitor, and transform IoT-related data pipelines. And when comes to IoT Edge, you will learn how to build and deploy Azure IoT Edge components and configure device networking on the edge.

This post shares with you my journey of two week studying to the Exam AZ-220: Microsoft Azure IoT Developer, to achieve the certification Microsoft Certified: Azure IoT Developer Specialty. Ultimately the resource most used was Microsoft Learn since it is the best source for you to get ready to the exam. Best of luck and hope this article helps you with some lessons learned and a few important notes.

In this study guide, I will share with you some of the useful resources you can use to guide you during your learning path to get this certification.

Prerequisites

If you want to take this certification, you should have experience implementing some of the Azure services that form an IoT solution, including data storage, data analysis, data processing, and platform-as-a-service options. Also, it would be an advantage if you have some knowledge on any of the Azure-supported languages, such as C# or Node.

Certification Path

To achieve this certification, you only need to pass a single exam - AZ-220. Follows below the link of the official exam’s page.

Exam Name	Link
Exam AZ-220: Microsoft Azure IoT Developer	Exam Details

Exam AZ-220: Microsoft Azure IoT Developer

The AZ-220 has a length of three hours and there are 50+ questions and you need 700 points min of 1000 to pass the exam.

First place to go is the Microsoft Learn platform where a dedicated learning path is available, for free. Also, if you prefer to watch videos, instead of read, you can have a look at amazing videos related to Azure IoT, available on Pluralsight.

Skills measured

Note: The content of this exam was updated on September 24, 2020. For more information you can always reference to the Exam Details Page. For more info, please reference this link.

Implement the IoT Solution Infrastructure (15-20%)

Create and configure an IoT Hub

create an IoT Hub
register a device
configure a device twin
configure IoT Hub tier and scaling

Build device messaging and communication

build messaging solutions by using SDKs (device and service)
implement device-to-cloud communication
implement cloud-to-device communication
configure file upload for devices

Configure physical IoT devices

recommend an appropriate protocol based on device specifications
configure device networking, topology, and connectivity

Provision and manage devices (20-25%)

Implement the Device Provisioning Service (DPS)

create a Device Provisioning Service
create a new enrollment in DPS
manage allocation policies by using Azure Functions
link an IoT Hub to the DPS

Manage the device lifecycle

provision a device by using DPS
deprovision an autoenrollment
decommission (disenroll) a device

Manage IoT devices by using IoT Hub

manage devices list in the IoT Hub device registry
modify device twin tags and properties
trigger an action on a set of devices by using IoT Hub Jobs and Direct Methods
set up Automatic Device Management of IoT devices at scale

Build a solution by using IoT Central

define a device type in Azure IoT Central
configure rules and actions in Azure IoT Central
define the operator view
add and manage devices from IoT Central
monitor devices
custom and industry-focused application templates
monitor application health using metrics

Implement Edge (15-20%)

Set up and deploy an IoT Edge device

create a device identity in IoT Hub
deploy a single IoT device to IoT Edge
create a deployment for IoT Edge devices
install container runtime on IoT devices
define and implement deployment manifest
update security daemon and runtime
provision IoT Edge devices with DPS
IoT Edge automatic deployments
deploy on constrained devices
secure IoT Edge solutions
deploy production certificates

Develop modules

create and configure an Edge module
deploy a module to an Edge device
publish an IoT Edge module to an Azure Container Registry

Configure an IoT Edge device

select and deploy an appropriate gateway pattern
implement Industrial IoT solutions with modules like Modbus and OPC
implement module-to-module communication
implement and configure offline support (including local storage)

Process and manage data (15-20%)

Configure routing in Azure IoT Hub

implement message enrichment in IoT Hub
configure routing of IoT Device messages to endpoints
define and test routing queries
integrate with Event Grid

Configure stream processing

create ASA for data and stream processing of IoT data
process and filter IoT data by using Azure Functions
configure Stream Analytics outputs

Configure an IoT solution for Time Series Insights (TSI)

implement solutions to handle telemetry and time-stamped data
create an Azure Time Series Insights (TSI) environment
connect the IoT Hub and the Time Series Insights (TSI)

Monitor, troubleshoot, and optimize IoT solutions (15-20%)

Configure health monitoring

configure metrics in IoT Hub
set up diagnostics logs for Azure IoT Hub
query and visualize tracing by using Azure Monitor
use Azure Policy definitions for IoT Hub

Troubleshoot device communication

establish maintenance communication
verify device telemetry is received by IoT Hub
validate device twin properties, tags and direct methods
troubleshoot device disconnects and connects

Perform end-to-end solution testing and diagnostics

estimate the capacity required for each service in the solution
conduct performance and stress testing

Implement security (15-20%)

Implement device authentication in the IoT Hub

choose an appropriate form of authentication
manage the X.509 certificates for a device
manage the symmetric keys for a device

Implement device security by using DPS

configure different attestation mechanisms with DPS
generate and manage x.509 certificates for IoT Devices
configure enrollment with x.509 certificates
generate a TPM endorsements key for a device
configure enrollment with symmetric keys

Implement Azure Security Center (ASC) for IoT

enable ASC for IoT in Azure IoT Hub
create security modules
configure custom alerts

Additional Notes

During the process of studying to this certification and the AZ-220 exam, I took some notes. So I am sharing below the notes of some important concepts I studied to the exam.

Azure CLI - IoT Extension

Create IoT Hub: az iot hub create –name {your iot hub name} –resource-group {your resource group name} –sku S1
Delete IoT Hub: az iot hub delete –name {your iot hub name} –resource-group {your resource group name}
Create Device ID: az iot hub device-identity create –hub-name {your iot hub name} –device-id {your device id}
Create Edge Device: az iot hub device-identity create –hub-name {hub_name} –device-id myEdgeDevice –edge-enabled
Get Connection String for IoT Hub’s Device: az iot hub device-identity show-connection-string –hub-name {your iot hub name} –device-id {your device id}
Query Event Hub Endpoint: az iot hub show –query properties.eventHubEndpoints.events.endpoint –name {YourIoTHubName}
Query Event Hub Path: az iot hub show –query properties.eventHubEndpoints.events.path –name {YourIoTHubName}
Query Device Policy Primary Key: az iot hub policy show –name service –query primaryKey –hub-name {YourIoTHubName}
Creata app in the IoT Central: az iot central app create –resource-group learn-b8d56515-8f6a-496f-87f1-505104af152f –name $APP_NAME –sku ST2 –location centralus –subdomain $APP_NAME –template iotc-pnp-preview@1.0.0 –display-name ‘Store Management’
Deploy Module to Edge device: az iot edge set-modules –device-id [device id] –hub-name [hub name] –content [file path]
View modules on your device: az iot hub module-identity list –device-id [device id] –hub-name [hub name]

Azure Device Provisioning Service (DPS)

Individual or Group enrolments
Individual enrollments are best used for devices that have a unique configuration, and require greater security than the connection strings you may have used in other Learn modules or Azure samples. Unique configurations aren’t what we’re looking for in our scenario, where we have many sensors configured to provide an identical format of telemetry data.
Allocation Policies
- Allocation policies only apply when you’ve multiple IoT Hubs handling telemetry from a huge number of devices, and want to direct the incoming data to one of these hubs based on a policy.
- Values
  - Lowest latency (assigns device to the IoT Hub with lowest latency)
  - Evenly weighted distribution (Evenly distribute devices per IoT hubs linked to the DPS)
  - Static configuration (using enrollment list)
  - Custom (Use Azure Function)
Global Device Endpoint: global.azure-devices-provisioning.net

Device Twin Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


{
  "deviceId": "cheesecave-device1",
  "etag": "AAAAAAAAAAI=",
  "deviceEtag": "ODQ5NDU4NjM4",
  "status": "enabled",
  "statusUpdateTime": "0001-01-01T00:00:00Z",
  "connectionState": "Connected",
  "lastActivityTime": "0001-01-01T00:00:00Z",
  "cloudToDeviceMessageCount": 0,
  "authenticationType": "selfSigned",
  "x509Thumbprint": {
    "primaryThumbprint": "ADF4F9E9BB7FBB198D1E65C42C78AA83C0535C22E79F9DFC1532EB273B05E289",
    "secondaryThumbprint": "ADF4F9E9BB7FBB198D1E65C42C78AA83C0535C22E79F9DFC1532EB273B05E289"
  },
  "version": 4,
  "properties": {
    "desired": {
      "temperature": "50.123",
      "<text>$</text>metadata": {
        "<text>$</text>lastUpdated": "2020-11-01T16:30:44.4412237Z",
        "<text>$</text>lastUpdatedVersion": 2,
        "temperature": {
          "<text>$</text>lastUpdated": "2020-11-01T16:30:44.4412237Z",
          "<text>$</text>lastUpdatedVersion": 2
        }
      },
      "<text>$</text>version": 2
    },
    "reported": {
      "fanstate": "off",
      "humidity": 79,
      "temperature": 60,
      "<text>$</text>metadata": {
        "<text>$</text>lastUpdated": "2020-11-01T16:26:23.8412491Z",
        "fanstate": {
          "<text>$</text>lastUpdated": "2020-11-01T16:26:23.8412491Z"
        },
        "humidity": {
          "<text>$</text>lastUpdated": "2020-11-01T16:26:23.8412491Z"
        },
        "temperature": {
          "<text>$</text>lastUpdated": "2020-11-01T16:26:23.8412491Z"
        }
      },
      "<text>$</text>version": 2
    }
  },
  "capabilities": {
    "iotEdge": false
  }
}

Automated re-provisioning support
- Factory reset: in which the device twin data for the new IoT hub is populated from the enrollment list instead of the old IoT hub. This is common for factory reset scenarios as well as leased device scenarios.
- Migration: in which device twin data is moved from the old IoT hub to the new IoT hub. This is common for scenarios in which a device is moving between geographies.
DPS Device Registration
- Get Provisioning Device Client: ProvisioningDeviceClient provClient = ProvisioningDeviceClient.Create(GlobalDeviceEndpoint, dpsIdScope, security, transport);
- Register Client: DeviceRegistrationResult result = await _provClient.RegisterAsync().ConfigureAwait(false);
- Create Client using IoT Hub Info on the DeviceRegistrationResult: s_deviceClient = DeviceClient.Create(result.AssignedHub, auth, TransportType.Amqp);
Enrollment-level allocation rules
- Specifying allocation policy per enrollment gives finer-grain control.
- Linked hub scoping allows the allocation policy to run over a subset of hubs.
Custom allocation logic
- With custom allocation logic, the Device Provisioning Service will trigger an Azure Function to determine where a device ought to go and what configuration should be applied to the device. Custom allocation logic is set at the enrollment level.

Device Receiver (Cloud Backend app)

Create client
- s_eventHubClient = EventHubClient.CreateFromConnectionString(connectionString.ToString());
Create receiver
- var eventHubReceiver = s_eventHubClient.CreateReceiver("$Default", partition, EventPosition.FromEnqueuedTime(DateTime.Now));
Invoke Direct Method
var methodInvocation = new CloudToDeviceMethod(“SetTelemetryInterval”) { ResponseTimeout = TimeSpan.FromSeconds(30) };
methodInvocation.SetPayloadJson(“10”);

// Invoke the direct method asynchronously and get the response from the simulated device.
var response = await s_serviceClient.InvokeDeviceMethodAsync(“MyDotnetDevice”, methodInvocation);
Declare Registry Manager to use for Device Twins Operations
- private static RegistryManager registryManager;
Create Registry Manager
- registryManager = RegistryManager.CreateFromConnectionString(s_serviceConnectionString);
Get Device Twin
- var twin = await registryManager.GetTwinAsync(“CheeseCaveID”);
Update Device Twin
- await registryManager.UpdateTwinAsync(twin.DeviceId, patch, twin.ETag);
Create Device Twin Query
- var query = registryManager.CreateQuery(“SELECT * FROM devices WHERE tags.cellar = ‘Cellar1’”, 100);
Execute Device Twin Query
- var twinsInCellar1 = await query.GetNextAsTwinAsync();

IoT Device

Define Direct Method
- private static Task SetFanState(MethodRequest methodRequest, object userContext)
Create Method Handler
- s_deviceClient.SetMethodHandlerAsync(“SetTelemetryInterval”, SetTelemetryInterval, null).Wait();
Send Telemetry
- await s_deviceClient.SendEventAsync(message);
Set Desired Properties Method Handler
- await s_deviceClient.SetDesiredPropertyUpdateCallbackAsync(HandleSettingChanged, null);
Create Device
- s_deviceClient = DeviceClient.CreateFromConnectionString(s_connectionString, TransportType.Mqtt);
- s_deviceClient = DeviceClient.Create(result.AssignedHub, auth, TransportType.Mqtt);
Update Properties
- await client.UpdateReportedPropertiesAsync(reportedProperties).ConfigureAwait(false);

IoT Security

The device management component uses the registryReadWrite policy.
The event processor component uses the service policy.
The run-time device business logic component uses the service policy.
Individual devices connect using credentials stored in the IoT hub’s identity registry.

Protocols

IoT Hub and the device SDKs support the following protocols for connecting devices:

HTTPS
AMQP
AMQP over WebSockets (Full duplex channel - bi-directional communication)
MQTT
MQTT over WebSockets (Full duplex channel - bi-directional communication)

Note: If your solution cannot use the device libraries, devices can use the MQTT v3.1.1, HTTPS 1.1, or AMQP 1.0 protocols to connect natively to your hub.
If your solution cannot use one of the supported protocols, you can extend IoT Hub to support custom protocols:

Use Azure IoT Edge to create a field gateway to perform protocol translation on the edge.
Customize the Azure IoT protocol gateway to perform protocol translation in the cloud.

Pricing Tiers

Basic: Uni-directional communication
- Tier 1,2,3
Standard: Bi-directional communication
- Tier 1,2,3
Standard/Free extra features
- Cloud-to-device messaging
- Device Twins, Module Twins and Device Management
- Azure IoT Edge
- IoT Plug and Play
- Device Streams

Events
Events are issues triggered by the device, and communicated to the IoT Central app. Events can be one of three types: Error, Warning, or Informational.

IoT Central

Capability Types
- Telemetry, Commands, Properties
Keys to connect app to IoT Central
- ID Scope, Device ID, and Primary Key
Commands to Device
- Nodejs: hubClient.onDeviceMethod(‘GoToCustomer’, CmdGoToCustomer);

REST API

Create a simulated device

1
2
3
4
5
6
7
8


az rest -m put -u https://$APP_NAME.azureiotcentral.com/api/preview/devices/storemon-sim-001
--headers Authorization="$API_TOKEN" --body
'{
    "instanceOf": "store_monitoring_device",
    "simulated": true,
    "displayName": "Simulated store monitoring device - 001",
    "approved": true
}'

Data Export
- Destinations: Azure Blob Storage, Azure Event Hubs, or Azure Service Bus

IoT Edge

Components: IoT Edge modules, IoT Edge runtime and IoT Edge cloud interface
Configure connection string to the IoT Edge device on the VM running as IoT Edge Device
- az vm run-command invoke -g IoTEdgeResources -n EdgeVM –command-id RunShellScript –script “/etc/iotedge/configedge.sh ‘{device_connection_string}’”
Default modules
- Modules: $edgeAgent, $edgeHub
- The IoT Edge Agent ($edgeAgent) and IoT Edge Hub ($edgeHub) modules are a part of the IoT Edge Runtime. The Edge Hub is responsible for communication, and the Edge Agent deploys and monitors the modules on the device.
Patterns
- Transparent Gateway: This pattern is useful for environments where downstream devices proxy through a single secure endpoint for transmission to the cloud. This strategy can be beneficial in environments with limited bandwidth by governing messaging in an aggregated format. The strategy is also useful for ensuring the security of data leaving an internal network.
- Protocol translation: This pattern allows for translation of legacy data protocols into a secure endpoint for transmission to the cloud. The configuration is often used in environments that employ pre-existing sensors that aren’t capable of supporting MQTT, AMQP, or HTTP. ○ Identity Translation: This configuration allows for translation of legacy data protocols and treats downstream devices as unique entities, allowing for secure command and control at the device level.

IoT Edge Device Deployment Manifest:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55


{
    "modulesContent": {
    "<text>$</text>edgeAgent": {
        "properties.desired": {
        "schemaVersion": "1.1",
        "runtime": {
            "settings":{
            "registryCredentials":{
                // give the IoT Edge agent access to container images that aren't public
            }
            }
        },
        "systemModules": {
            "edgeAgent": {
            // configuration and management details
            },
    "<text>$</text>edgeHub": {
            "properties.desired": {
            "schemaVersion": "1.1",
            "routes": {
                "route1": "FROM <source> WHERE <condition> INTO <sink>",
                "route2": {
                "route": "FROM <source> WHERE <condition> INTO <sink>",
                "priority": 0,
                "timeToLiveSecs": 86400
                }
            },
            "storeAndForwardConfiguration": {
                "timeToLiveSecs": 10
            }
            }
        },
        "modules": {
            "module1": {
            "version": "1.0",
            "type": "docker",
            "status": "running",
            "restartPolicy": "always",
            "startupOrder": 2,
            "settings": {
                "image": "myacr.azurecr.io/module1:latest",
                "createOptions": "{}"
            }
    },
            "module2": {
            // configuration and management details
            }
        }
        }
    },
    "<text>$</text>edgeHub": { ... },
    "module1": { ... },
    "module2": { ... }
    }
}

Define how the IoT Edge runtime installs the modules in your deployment. The IoT Edge agent is the runtime component that manages installation, updates, and status reporting for an IoT Edge device. Therefore, the $edgeAgent module twin contains the configuration and management information for all modules. This information includes the configuration parameters for the IoT Edge agent itself.

Message Routes Source

The source property can be any of the following values:

Source	Description
/*	All device-to-cloud messages or twin change notifications from any module or leaf device
/twinChangeNotifications	Any twin change (reported properties) coming from any module or leaf device
/messages/*	Any device-to-cloud message sent by a module through some or no output, or by a leaf device
/messages/modules/*	Any device-to-cloud message sent by a module through some or no output
/messages/modules//*	Any device-to-cloud message sent by a specific module through some or no output
/messages/modules//outputs/*	Any device-to-cloud message sent by a specific module through some output
/messages/modules//outputs/	Any device-to-cloud message sent by a specific module through a specific output

Message Routes Targets (Sinks)

Sink Description

$upstream Send the message to IoT Hub

rokeredEndpoint("/modules//inputs/<input>") | end the message to a specific input of a specific module |

Sink	Description
$upstream	Send the message to IoT Hub
rokeredEndpoint("/modules//inputs/<input>") \|	end the message to a specific input of a specific module \|

Time Series Insights

Real-time analytics
Queries with three types of visualizations: Chart, Heatmap or table
Built-in integration with IoT Hub

IoT Hub

Messaging Routes
- Queries
  - Message body query: $body.Weather.HistoricalData[0].Month = ‘Feb’
  - Message’s System Property Query: $contentEncoding = ‘UTF-8’
  - Message’s Application Property Query: processingPath = ‘hot’
Device Configuration Management
- Device configurations provide the ability to perform IoT device configuration at scale. You can define configurations and summarize compliance as the configuration is applied.
- Automatic device management works by updating a set of device twins or module twins with desired properties and reporting a summary that’s based on twin reported properties. It introduces a new class and JSON document called a Configuration that has three parts:
  - The target condition defines the scope of device twins or module twins to be updated. The target condition is specified as a query on twin tags and/or reported properties.
  - The target content defines the desired properties to be added or updated in the targeted device twins or module twins. The content includes a path to the section of desired properties to be changed.
  - The metrics define the summary counts of various configuration states such as Success, In Progress, and Error. Custom metrics are specified as queries on twin reported properties. System metrics are the default metrics that measure twin update status, such as the number of twins that are targeted and the number of twins that have been successfully updated.

Direct Methods

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


curl -X POST \
    https://<iothubName>.azure-devices.net/twins/<deviceId>/methods?api-version=2018-06-30 \
    -H 'Authorization: SharedAccessSignature sr=iothubname.azure-devices.net&sig=x&se=x&skn=iothubowner' \
    -H 'Content-Type: application/json' \
    -d '{
    "methodName": "reboot",
    "responseTimeoutInSeconds": 200,
    "payload": {
        "input1": "someInput",
        "input2": "anotherInput"
    }
}'

Stream Analytics

Scenarios Using Stream Analytics
- Send data to services such as Azure Functions, Service Bus Topics or Queues to trigger communications or custom workflows downstream.
- Send data to a Power BI dashboard for real-time dashboarding.
- Store data in other Azure storage services (for example, Azure Data Lake, Azure Synapse Analytics, etc.) to train a machine learning model based on historical data or perform batch analytics.
Windowing functions
- Tumbling Window: Tumbling window functions are used to segment a data stream into distinct time segments and perform a function against them, such as the example below. The key differentiators of a Tumbling window are that they repeat, do not overlap, and an event cannot belong to more than one tumbling window.
- Hopping window: Hopping window functions hop forward in time by a fixed period. It may be easy to think of them as Tumbling windows that can overlap and be emitted more often than the window size. Events can belong to more than one Hopping window result set. To make a Hopping window the same as a Tumbling window, specify the hop size to be the same as the window size.
- Sliding window: Sliding windows, unlike Tumbling or Hopping windows, output events only for points in time when the content of the window actually changes. In other words, when an event enters or exits the window. Every window has at least one event, like in the case of Hopping windows, events can belong to more than one sliding window.
- Session window: Session window functions group events that arrive at similar times, filtering out periods of time where there is no data. It has three main parameters: timeout, maximum duration, and partitioning key (optional). A session window begins when the first event occurs. If another event occurs within the specified timeout from the last ingested event, then the window extends to include the new event. Otherwise if no events occur within the timeout, then the window is closed at the timeout.
- Snapshot window: Snapshot windows groups events that have the same timestamp. Unlike other windowing types, which require a specific window function (such as SessionWindow(), you can apply a snapshot window by adding System.Timestamp() to the GROUP BY clause.

Resources

Resource
Microsoft Learning Path - Introduction to Azure IoT
Microsoft Learning Path - Securely connect IoT devices to the cloud
Microsoft Learning Path - Build the intelligent edge with Azure IoT Edge
Microsoft Learning Path - Develop IoT solutions with Azure IoT Central
Microsoft Certification Page - Microsoft Power Platform Fundamentals
Microsoft IoT Pluralsight Videos
Azure IoT solution accelerators