Practice MQTT protocol vocabulary: broker, topic hierarchy, QoS levels, retained messages, last will and testament, and MQTT over WebSocket language.
0 / 14 completed
1 / 14
In MQTT, what is the role of the 'broker'?
The MQTT broker is the intermediary: publishers send messages to the broker, and the broker routes them to all clients subscribed to the matching topic. The broker decouples producers and consumers in IoT architectures. Common brokers: Mosquitto, HiveMQ, AWS IoT Core.
2 / 14
In the topic 'home/sensor/temperature', what does the hierarchy represent?
MQTT topic hierarchies use '/' as a separator. Subscribers can use wildcards: 'home/+/temperature' subscribes to temperature from any sensor, and 'home/#' subscribes to everything under 'home'. Well-designed topic hierarchies make large IoT deployments manageable.
3 / 14
What does MQTT QoS level 2 guarantee?
MQTT QoS levels: 0 = at most once (fastest, no guarantee); 1 = at least once (duplicates possible); 2 = exactly once (four-step handshake ensures the message arrives exactly once). QoS 2 is used for commands where duplicates would cause problems (e.g., unlocking a door twice).
4 / 14
What is a 'retained message' in MQTT?
A retained message is the 'last known good' value for a topic. When a new device subscribes to 'home/sensor/temperature', it immediately receives the last retained value without waiting for the next publish event — critical for IoT state initialisation.
5 / 14
What is the 'Last Will and Testament' (LWT) feature in MQTT?
LWT lets a device pre-register a 'I went offline' message with the broker. If the device disconnects without sending a proper DISCONNECT packet (e.g., power failure), the broker publishes the LWT to the specified topic — enabling real-time offline detection in IoT fleets.
6 / 14
PR Description
During code review, Sarah mentions she's using a 'publish retention' strategy for her sensor data. Mark asks, 'Can you elaborate on what that means in the context of MQTT? Specifically, how does it relate to message delivery and potential duplicates?'
Publish retention is a key MQTT concept that involves the broker storing the last published message value for a topic. This allows subscribing clients to receive the previous message's value whenever they request it, which is particularly useful in scenarios where clients need to maintain state based on historical data. It's important to distinguish this from QoS levels, which govern delivery reliability – retention solely relates to message storage and retrieval at the broker.
7 / 14
PR Description
During code review, Sarah mentions she's using a 'publish retention' strategy for her sensor data. Mark asks, 'Can you elaborate on what that means in the context of MQTT? Specifically, how does it relate to message delivery and potential duplicates?'
Publish retention is a key MQTT concept that involves the broker storing the last published message value for a topic. This allows subscribing clients to receive the previous message's value whenever they request it, which is particularly useful in scenarios where clients need to maintain state based on historical data. It's important to distinguish this from QoS levels, which govern delivery reliability – retention solely relates to message storage and retrieval at the broker.
8 / 14
PR Description
During code review, Sarah mentions she's using a 'publish retention' strategy for her sensor data. Mark asks, 'Can you elaborate on what that means in the context of MQTT? Specifically, how does it relate to message delivery and potential duplicates?'
Publish retention is a key MQTT concept that involves the broker storing the last published message value for a topic. This allows subscribing clients to receive the previous message's value whenever they request it, which is particularly useful in scenarios where clients need to maintain state based on historical data. It's important to distinguish this from QoS levels, which govern delivery reliability – retention solely relates to message storage and retrieval at the broker.
9 / 14
PR Description
During code review, Sarah mentions she's using a 'publish retention' strategy for her sensor data. Mark asks, 'Can you elaborate on what that means in the context of MQTT? Specifically, how does it relate to message delivery and potential duplicates?'
Publish retention is a key MQTT concept that involves the broker storing the last published message value for a topic. This allows subscribing clients to receive the previous message's value whenever they request it, which is particularly useful in scenarios where clients need to maintain state based on historical data. It's important to distinguish this from QoS levels, which govern delivery reliability – retention solely relates to message storage and retrieval at the broker.
10 / 14
David: 'I'm using a retained message for my device status updates. It's really helpful for the dashboard.' What is the primary benefit of utilizing a retained MQTT message in this scenario?
Retained messages provide a crucial feature: they propagate the last known value of a topic to any new subscribers. This avoids the need for subscribers to request the latest state from the broker upon connection, significantly reducing latency and improving dashboard responsiveness. Option A describes a different mechanism (disconnection handling), B is the core function of retention, and C/D relate to message delivery guarantees or transformations, not the specific benefit of retained messages.
11 / 14
Liam sends a Slack message: 'I've configured QoS level 2 for all my sensor data. What does this primarily guarantee about the delivery of these messages?'.
QoS level 2 guarantees reliable delivery to *at least* one subscriber. The broker sends a copy of the message to multiple brokers (defined in the MQTT configuration), and if one subscriber receives it, the original publisher is notified. This provides reliability without the overhead of QoS 1's repeated attempts. Options A and D are incorrect; QoS level 2 doesn't guarantee retries or priority delivery. Option B describes a different QoS level.
12 / 14
Elena is writing a PR description for her MQTT implementation. She states: 'I'm using a 'clean session' flag when connecting to the broker. Why is this important?'.
Setting the 'clean session' flag instructs the MQTT client to not retain any previously established session data (like username/password) with the broker. This is essential for security and allows clients to start fresh each time they connect, preventing potential vulnerabilities associated with stale credentials. Options A describes a different feature (reconnection), B accurately explains the effect of clean session, and D relates to encryption.
13 / 14
Ben is troubleshooting an MQTT connection issue. He notices that his device is consistently sending a 'Last Will and Testament' (LWT) message even though it's not connected to the broker. What does this typically indicate?
The LWT message is automatically sent by the broker when a client disconnects unexpectedly. It serves as a notification to any subscribed clients that the device is unavailable. Therefore, seeing this message being sent without a disconnection suggests the device is *attempting* to communicate its offline status – the core purpose of the LWT feature. Options A/C are incorrect; the broker isn't rejecting messages, and the client isn't sending an unsolicited message.
14 / 14
Chloe is designing a system where sensors automatically send data to a central server. She's considering using MQTT with a publish retention of '5 seconds'. What is the most likely reason for implementing this retention period?
Publish retention effectively manages bandwidth usage by storing the last published value of a topic. This avoids redundant transmissions to subscribers who may have already received the latest data, especially in scenarios with intermittent connectivity or high message volume. Option B is incorrect—retention doesn't guarantee delivery; it's about minimizing bandwidth. Options C/D describe other potential uses of buffering or prioritization.
What does the "MQTT Protocol Vocabulary" exercise cover?
Practice MQTT protocol vocabulary: broker, topic hierarchy, QoS levels, retained messages, last will and testament, and MQTT over WebSocket language.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "MQTT Protocol Vocabulary"?
This exercise has 14 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Edge Iot exercises?
Browse the full Edge Iot hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.