Microsoft Azure IoT Certification Exam Prep Test

Reference:
https://docs.microsoft.com/en-us/azure/iot-edge/support

Scenario: POV Requirements
Ensure that all message-content during this phase is human-readable to simplify debugging.
Avro uses a binary format, so it is not human readable.
The more lightweight JSON (Javascript object notation) has become a popular alternative to XML for
various reasons. A couple of obvious ones are:
Less verbose- XML uses more words than necessary
JSONisfaster-ParsingXMLsoftwareisslowandcumbersome.
Reference:
https://blog.cloud-elements.com/json-better-xml

Instead, from the Device Provisioning Service, you disable the enrollment group, and you disable device entries in the identity registry of the IoT hub to which the IoT devices are provisioned.

2500* 6 KB * 12 = 180,000 KB/minute = 180 MB/Minute.
B3, S3 can handle up to 814 MB/minute per unit.
Incorrect Answers:
A, C: B1, S1 can only handle up to 1111 KB/minute per unit
B: B2, S2 can only handle up to 16 MB/minute per unit.
Reference:
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-scaling

MQTT over WebSockets uses port 443.
Reference:
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-protocols
Provision and manage devices

Instead add the desired properties to the device twin.
Note: Device Twins are used to synchronize state between an IoT solution's cloud service and its devices. Each device's twin exposes a set of
desired properties and reported properties. The cloud service populates the desired properties with values it wishes to send to the device.
When a device connects it requests and/or subscribes for its desired properties and acts on them.
Reference:
https://azure.microsoft.com/sv-se/blog/deep-dive-into-azure-iot-hub-noti¦cations-and-device-twin/

Automated re-provisioning support.
Microsoft added ¦rst-class support for device re-provisioning which allows devices to be reassigned to a different IoT solution sometime after
the initial solution assignment. Re-provisioning support is available in two options:
✑ 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.
Reference:
https://azure.microsoft.com/en-us/blog/new-year-newly-available-iot-hub-device-provisioning-service-features/

IoT Hub is scaled and priced based on an allowed number of messages per day across all devices connected to that IoT Hub. If you
exceed the allowed message threshold for your chosen tier and number of units, IoT Hub will begin rejecting new messages. To date, there is
no built-in mechanism for automatically scaling an IoT Hub to the next level of capacity if you approach or exceed that threshold.
Reference:
https://docs.microsoft.com/en-us/samples/azure-samples/iot-hub-dotnet-autoscale/iot-hub-dotnet-autoscale/

Create a dedicated consumer group in the IoT hub for the Time Series Insights environment to
consume from. Each Time Series Insights event source must have its own dedicated consumer group
that isn't shared with any other consumer. If multiple readers consume events from the same
consumer group, all readers are likely to exhibit failures.
Reference:
https://docs.microsoft.com/en-us/azure/time-series-insights/time-series-insights-how-to-add-an- eventsource- iothub

When you create a Time Series Insights Preview pay-as-you-go (PAYG)SKU environment, you create
two Azure resources:
An Azure Storage general-purpose V1 blob account for cold data storage.
AnAzureTimeSeriesInsightsPreviewenvironmentthatcanbeconfiguredforwarmdatastorage.
Reference:
https://docs.microsoft.com/en-us/azure/time-series-insights/time-series-insights-update-storage- ingress

You may ¦nd it necessary to deprovision devices that were previously auto-provisioned through the Device Provisioning Service.
In general, deprovisioning a device involves two steps:
1. Disenroll the device from your provisioning service, to prevent future auto-provisioning. Depending on whether you want to revoke access
temporarily or permanently, you may want to either disable or delete an enrollment entry.
2. Deregister the device from your IoT Hub, to prevent future communications and data transfer. Again, you can temporarily disable or
permanently delete the device's entry in the identity registry for the IoT Hub where it was provisioned.
Reference:
https://docs.microsoft.com/bs-latn-ba/azure/iot-dps/how-to-unprovision-devices

The solution does not meet the goal. Changing the credentials for the shared access policy of the IoT devices will not temporarily disable the devices from connecting to the IoT hub. To temporarily disable the devices, you would need to modify the enrollment group's settings in the Device Provisioning Service instance to pause or disable device provisioning.

The Device Provisioning Service is included in the Basic Tiers (such as B1).
Incorrect Answers:
B, C, D: The Standard tier is needed for cloud-to-device messaging, Azure IoT Edge, and device twins.
Reference:
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-scaling

MQTT over WebSockets, AMQP over WebSocket, and HTTPS use port 443.
Reference:
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-p

Scenario:Youplanto usea 30-second periodtocalculate theaveragetemperature reading ofthe
sensors.
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.
InAnswers:
A: 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, so events can belong to more than one Hopping window result
set.
Reference:
https://docs.microsoft.com/en-us/azure/stream-analytics/stream-analytics-window-functions

Each device uses its derived device key with your unique registration ID to perform symmetric key attestation with the enrollment during provisioning. To generate the device key, use the key you copied from your DPS
enrollment to compute an HMAC-SHA256 of the unique registration ID for the device and convert the result into Base64 format.
Reference:
https://docs.microsoft.com/en-us/azure/iot-edge/how-to-auto-provision-symmetric-keys

The device telemetry category tracks errors that occur at the IoT hub and are related to the telemetry pipeline. This category includes errors
that occur when sending telemetry events (such as throttling) and receiving telemetry events (such as unauthorized reader). This category
cannot catch errors caused by code running on the device itself.
Note: The metric d2c.telemetry.ingress.sendThrottle is the number of throttling errors due to device throughput throttles.
Reference:
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-monitor-resource-health

Releases via the REST API. All of the operations that can be performed from the Console can also be automated using the REST API. You might do this to automate your build and release process, for example. You can build ¦rmware using the Particle CLI or directly using the compile source code API. Note: Over-the-air (OTA) ¦rmware updates are a vital component of any IoT system. Over-the-air ¦rmware updates refers to the practice of remotely updating the code on an embedded device. Reference: https://docs.particle.io/tutorials/device-cloud/ota-updates/

To use the file upload functionality in IoT Hub, you must first associate an Azure Storage account with your hub. Select File upload to display a list of file upload properties for the IoT hub that is being modified. For Storage container: Use the Azure portal to select a blob container in an Azure Storage account in your current Azure subscription to associate with your IoT Hub. If necessary, you can create an Azure Storage account on the Storage accounts blade and blob container on the Containers A: IoT Hub has an endpoint specifically for devices to request a SAS URI for storage to upload a ¦le. To start the ¦le upload process, the device sends a POST request to {iot hub}.azure-devices.net/devices/{deviceId}/¦les with the following JSON body: { "blobName": "{name of the ¦le for which a SAS URI will be generated}" } Incorrect Answers: D: Deprecated: initialize a ¦le upload with a GET. Use the POST method instead. Reference: https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/iot-hub/iot-hub-con¦gure-¦le-upload.md

Use AMQP on field and cloud 6gateways to take advantage of connection multiplexing across devices

MQTT is used on all devices that do not require to connect multiple devices (each with its own per-device credentials) over the same TLS connection.

Use HTTPS for devices that cannot support other protocols.

Reference:
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-protocols

Scenario: You discover connectivity issues between the IoT gateway devices and iothub1, which
cause IoT devices to lose connectivity and messages.
Tolog device connection events and errors, turn on diagnostics for IoT Hub. We recommend turning on
these logs as early as possible, because if diagnostic logs aren't enabled, when device disconnects
occur, you won't have any information to troubleshoot the problem with.
Step 1:
1. Sign in to the Azureportal.
2. Browse to your IoThub.
3. Select Diagnostics settings.
4. Select Turn on diagnostics.
5. Enable Connections logs to becollected.
6. For easier analysis, turn on Send to Log Analytics (see
pricing). Step 2:
Set up alerts for device disconnect at scale
Togetalertswhendevicesdisconnect,configurealertsontheConnecteddevices(preview)metric.
Reference:
https://docs.microsoft.com/bs-cyrl-ba/azure/iot-hub/iot-hub-troubleshoot-connectivity

To restore the hot path during the POV phase, you should create an explicit route for the hot path. This will ensure that telemetry from IoTHub flows to the hot path as intended. By creating a specific route for the hot path, you can direct the telemetry data to the appropriate processing and analytics components for real-time alerts and other required actions.

A common problem with many legacy devices is that they often have an identity that is composed of a single piece of information. This identity information is usually a MAC address or a serial number. Legacy devices may not have a certificate, TPM, or any other security feature that can be used to securely identify the device. The Device Provisioning Service for IoT hub includes symmetric key attestation. Symmetric key attestation can be used to identify a device based off information like the MAC address or a serial number.
Reference: https://docs.microsoft.com/bs-latn-ba/azure/iot-dps/how-to-legacy-device-symm-key

Purchase X.509 certificates from a root certificate authority (CA). This method is recommended for production environments.
The hardware security module, or HSM, is used for secure, hardware-based storage of device secrets, and is the most secure form of secret storage. Both X.509 certificates and SAS tokens can be stored in the HSM Reference:
https://docs.microsoft.com/en-us/azure/iot-dps/concepts-security

The TPM simulator's Registration ID and the Endorsement key, are used when you create an individual enrollment for your device.
Reference:
https://docs.microsoft.com/en-us/azure/iot-edge/how-to-auto-provision-simulated-device-linux
Implement Edge

Execute az extension add --name azure-cli-iot-ext once and try again.
In order to read the telemetry from your hub by CLI, you have to enable IoT Extension with the following commands:
Add: az extension add --name azure-cli-iot-ext
Reference:
https://github.com/MicrosoftDocs/azure-docs/issues/20843

To log device connection events and errors, turn on diagnostics for IoT Hub. We recommend turning on these logs as early as possible, because
if diagnostic logs aren't enabled, when device disconnects occur, you won't have any information to troubleshoot the problem with.
1. Sign in to the Azure portal.
2. Browse to your IoT hub.
3. Select Diagnostics settings.
4. Select Turn on diagnostics.
5. Enable Connections logs to be collected.
6. For easier analysis, turn on Send to Log Analytics

Reference:
https://docs.microsoft.com/bs-cyrl-ba/azure/Iot-hub/iot-hub-troubleshoot-connectivity

Box 1: tags.engine.warpDriveType='VM105a'
Use tags to target twins. Before you create a con¦guration, you must specify which devices or modules you want to affect. Azure IoT Hub
identi¦es devices and using tags in the device twin, and identi¦es modules using tags in the module twin.
Box 2: properties.desired.warpOperating
The twin path, which is the path to the JSON section within the twin desired properties that will be set.
For example, you could set the twin path to properties.desired.chiller-water and then provide the following JSON content:
{
"temperature": 66,
"pressure": 28
}
Reference:
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-automatic-device-management

not-available-via-ai

Use the following workflow to deploy and test your Azure Security Center for IoT security agents:
1. Enable Azure Security Center for IoT service to your IoT Hub
2. If your IoT Hub has no registered devices, Register a new device.
3. Create an azureiotsecurity security module for your devices.
Azure Security Center for IoT makes use of the module twin mechanism and maintains a security module twin named azureiotsecurity for each of your devices.
Note: To manually create a new azureiotsecurity module twin for a device use the following instructions:
1. In your IoT Hub, locate and select the device you wish to create a security module twin for.
2. Click on your device, and then on Add module identity.
3. In the Module Identity Name field, enter azureiotsecurity.
4. Click Save.
Reference:
https://docs.microsoft.com/en-us/azure/asc-for-iot/quickstart-create-security-twin

The module twin for the IoT Edge agent is called $edgeAgent and coordinates the communications between the IoT Edge agent running on a device and IoT Hub. The desired properties are set when applying a deployment manifest on a specific device as part of a single-device or at-scale deployment.
These properties include:
runtime.settings.registryCredentials.{registryId}.username runtime.settings.registryCredentials.registryId}.password
Reference: https://docs.microsoft.com/en-us/azure/iot-edge/module-edgeagent-edgehub

Device Twins are used to synchronize state between an IoT solution's cloud service and its devices. Each device's twin exposes a set of desired
properties and reported properties. The cloud service populates the desired properties with values it wishes to send to the device. When a
device connects it requests and/or subscribes for its desired properties and acts on them.
Reference:
https://azure.microsoft.com/sv-se/blog/deep-dive-into-azure-iot-hub-noti¦cations-and-device-twin/

100 KB * 24 is around 2,400 bytes.
The 100 KB message is divided into 4 KB blocks, and it is billed for 25 messages. 25 times 24 is 600
Note: The maximum message size for messages sent from a device to the cloud is 256 KB. These messages are metered in 4 KB blocks for the
paid tiers so for instance if the device sends a 16 KB message via the paid tiers it will be billed as 4 messages.
Reference:
https://azure.microsoft.com/en-us/pricing/details/iot-hub/

To demonstrate that the IoT hub can receive messages from a device, you should perform the following actions in sequence:

1. Connect the device to the IoT hub and ensure that it is sending messages.
2. Set up a route in the IoT hub to direct incoming messages to a desired endpoint, such as a storage account or a function app.
3. Monitor the incoming messages in the endpoint to verify that the IoT hub is successfully receiving them.

You deploy modules to your device by applying the deployment manifest that you con¦gured with the module information.
Change directories into the folder where your deployment manifest is saved. If you used one of the VS Code IoT Edge templates, use the
deployment.json ¦le in the con¦g folder of your solution directory and not the deployment.template.json ¦le.
Use the following command to apply the con¦guration to an IoT Edge device: az iot edge set-modules --device-id [device id] --hub-name [hub
name] --content [¦le path]
Reference:
https://docs.microsoft.com/en-us/azure/iot-edge/how-to-deploy-modules-cli

https://docs.microsoft.com/en-us/azure/time-series-insights/time-series-insights-how-to-add-an-event-source-iothub

Consider using jobs when you need to schedule and track progress any of the following activities on a set of devices:
✑ Invoke direct methods
✑ Update desired properties
✑ Update tags
Reference:
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-jobs

Properties related to every Azure Security Center for IoT security agent are located in the agent configuration object, within the desired properties section, of the azureiotsecurity module.
To modify the configuration, create and modify this object inside the azureiotsecurity module twin identity.
Note: Azure Security Center for IoT’s security agent twin configuration object is a JSON format object. The configuration object is a set of controllable properties that you can define to control the behavior of the agent.
These configurations help you customize the agent for each scenario required. For example, automatically excluding some events, or keeping power consumption to a minimal level are possible by configuring these properties.
Reference: https://docs.microsoft.com/en-us/azure/asc-for-iot/how-to-agent-configuration

EventHubName: Functions 2.x and higher. The name of the event hub. When the event hub name is also present in the connection string, that
value overrides this property at runtime.
Connection: The name of an app setting that contains the connection string to the event hub's namespace. Copy this connection string by
clicking the Connection
Information button for the namespace, not the event hub itself. This connection string must have send permissions to send the message to the
event stream.
Reference:
https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-event-iot-output

In your Azure IoT Central application, add a real device to the device template
1. On the Devices page, select the Environmental sensor device template.
2. Select + New.
3. Make sure that Simulated is Off. Then select Create.
Click on the device name, and then select Connect. Make a note of the device connection information on the Device Connection page - ID
scope, Device ID, and
Primary key. You need these values when you create your device code:

Reference:
https://docs.microsoft.com/bs-cyrl-ba/azure/iot-central/core/tutorial-connect-device-python

In some cases, if you are applying an enrichment with a value set to a tag or property in the device twin, the value will be stamped as a string value. For example, if an enrichment value is set to $twin.tags.field, the messages will be stamped with the string "$twin.tags.field" rather than the value of that field from the twin. This happens in the following cases:
✑ (C) Your IoT Hub is in the standard tier, but the device sending the message has no device twin.
✑ (E) Your IoT Hub is in the standard tier, but the device twin path used for the value of the enrichment does not exist. For example, if the enrichment value is set to $twin.tags.location, and the device twin does not have a location property under tags, the message is stamped with the string "$twin.tags.location".
✑ Your IoT Hub is in the basic tier. Basic tier IoT hubs do not support device twins.
Reference:
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-message-enrichments-overview
Monitor, troubleshoot, and optimize IoT solutions

To meet the POV requirements, two ways to configure Stream Analytics are:

1. From IoT Hub, create a custom event hub endpoint, and then configure the endpoint as an input to Stream Analytics. This allows Stream Analytics to receive the telemetry data from the IoT devices through the custom event hub endpoint.

2. Create an input in Stream Analytics that uses the built-in events endpoint of IoT Hub as the source. This enables Stream Analytics to directly receive the telemetry data from the IoT Hub's built-in events endpoint.

By implementing both of these configurations, Stream Analytics will be able to receive and process the telemetry data in real-time, calculate the median rate, compare telemetry to thresholds, and issue alerts when necessary.

IoT Hub is one of the first Azure services to support distributed tracing. As more Azure services
support distributed tracing, you'll be able trace IoT messages throughout the Azure services involved in
your solution.
Note:
Enabling distributed tracing for IoT Hub gives you the ability to:
Precisely monitor the flow of each message through IoT Hub using trace context. This trace context
includes correlation IDs that allow you to correlate events from one component with events from
another component. Itcanbe appliedforasubsetor allIoTdevicemessages using devicetwin.
Automatically log the trace context to Azure Monitor diagnostic logs.
Measure and understand message flow and latency from devices to IoT Hub and routing endpoints.
Start considering how you want to implement distributed tracing for the non-Azure services in your IoT
solution.
Reference:
https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-distributed-tracing

The device telemetry is usually passed as JSON from the device through the IoT Hub - this is handled nicely by Azure Streaming Analytics queries. The IoT Hub message routing should be con¦gured as follows: Data source: Device Telemetry Messages Routing query: true (as the routing query is an expression that evaluates to true or false for each received message, the simplest way to send all messages to the endpoint is to just supply true as the query). Reference: https://darenmay.com/blog/azure-iot-streaming-analytics-data-lake-analytics-and-json/

Reference:
https://docs.microsoft.com/bs-latn-ba/azure/iot-hub/iot-hub-security-x509-get-started

Step: With DPS (Device Provisioning Service) you can generate device credentials and con¦gure the devices o©ine without registering the devices through IoT Central UI. Connect devices that use SAS tokens without registering 1. Copy the IoT Central application's group primary key 2. Use the dps-keygen tool to generate the device SAS keys. Use the group primary key from the previous step. The device IDs must be lowercase: dps-keygen -mk: -di: 3. The OEM §ashes each device with a device ID, a generated device SAS key, and the application ID scope value. 4. When you switch on a device, it ¦rst connects to DPS to retrieve its IoT Central registration information. The device initially has a device status Unassociated on the Devices page and isn't assigned to a device template. On the Devices page, Migrate the device to the appropriate device template. Device provisioning is now complete, the device status is now Provisioned, and the device can start sending data. On the Administration > Device connection page, the Auto approve option controls whether you need to manually approve the device before it can start sending data. Reference: https://docs.microsoft.com/en-us/azure/iot-central/core/concepts-get-connected

Explanation:
Step 1: Provision Time Series Insights
Select Provisionnew IoTHubtocreateanew IoThub.
Step2:Route telemetry fromIoT Hubto a custom event.
Step 3:Add a data access policy to TimeSeries Insights forthe dashboard web app
Scenario: Requirements. PilotRequirements
During the pilot phase, devices will be deployed to 10 offices. Each office will have up to 1,000
devices.
During this phase, you will add Azure Time Series Insights in parallel to Stream Analytics to support
real-time graphs and queries in a dashboard web app.
Thepilotdeploymentmustminimizeoperating costs. Incorrect
Answers:
No need touse an endpoint.
Reference:
https://docs.microsoft.com/en-us/azure/time-series-insights/time-series-insights-update-create- environment

Instead add the desired properties to the device twin.
Note: Device Twins are used to synchronize state between an IoT solution's cloud service and its devices. Each device's twin exposes a set of
desired properties and reported properties. The cloud service populates the desired properties with values it wishes to send to the device.
When a device connects it requests and/or subscribes for its desired properties and acts on them.
Reference:
https://azure.microsoft.com/sv-se/blog/deep-dive-into-azure-iot-hub-noti¦cations-and-device-twin/

https://docs.microsoft.com/en-us/azure/iot-edge/module-composition

Box 1: Measurement -
Telemetry/measurement is a stream of values sent from the device, typically from a sensor. For example, a sensor might report the ambient
temperature.
Box 2: Property -
The template can provide a writeable fan speed property represent point-in-time values. For example, a device can use a property to report the target temperature it's trying to reach. You can
set writeable properties from IoT Central.
Box 3: Settings -
Box 4: Command -
You can call device commands from IoT Central. Commands optionally pass parameters to the device and receive a response from the device.
For example, you can call a command to reboot a device in 10 seconds.
Reference:
https://docs.microsoft.com/en-us/azure/iot-central/core/howto-set-up-template