Diese 40 MQTT-Interviewfragen decken ab, was Personalverantwortliche für IoT-, Embedded-, Backend- und zunehmend auch Automatisierungsrollen in Industrie-4.0-Projekten tatsächlich fragen: Grundlagen, QoS, Sessions, Retained Messages, Last Will, MQTT 5 und Sicherheit. Jede Antwort ist kurz genug, um sie laut auszusprechen, und der Praxisteil zeigt, wie Sie jedes Konzept vor Ihrem Interview auf einem echten Broker nachweisen.
So nutzen Sie diese MQTT-Interviewfragen
Lesen Sie eine Antwort und versuchen Sie dann, sie ohne Hinsehen zu erklären. Interviewern sind auswendig gelernte Definitionen weniger wichtig als Abwägungen: Wann würden Sie QoS 0 einsetzen, warum können Retained Messages Sie überraschen, was geht kaputt, wenn sich zwei Geräte eine Client-ID teilen? Führen Sie die Befehle aus dem Praxisteil nach Möglichkeit gegen den kostenlosen öffentlichen MQTT-Broker aus, damit Sie beschreiben können, was Sie gesehen haben, und nicht nur, was Sie gelesen haben.
Grundlagen (Fragen 1 bis 10)
1. Was ist MQTT?
Ein schlankes Publish/Subscribe-Messaging-Protokoll über TCP, entwickelt für eingeschränkte Geräte und unzuverlässige Netzwerke. Die Versionen 3.1.1 und 5.0 sind OASIS-Standards.
2. Was ist ein Broker?
Der Server, der alle veröffentlichten Nachrichten empfängt und an Clients mit passenden Subscriptions weiterleitet. Er verwaltet außerdem Sessions, Retained Messages und Wills. Siehe was ein MQTT-Broker tut.
3. Wie unterscheidet sich Publish/Subscribe von Request/Response?
Publisher und Subscriber adressieren einander nie; der Broker entkoppelt sie in Raum, Zeit und Synchronisation. Unser Artikel über das Publish/Subscribe-Modell erklärt alle drei Aspekte.
4. Nutzt MQTT TCP oder UDP?
TCP, optional in TLS oder WebSocket verpackt. MQTT-SN ist die Variante für UDP- und Datagramm-Netze.
5. Was sind die Standard-Ports?
1883 für reines TCP und 8883 für TLS. WebSocket-Ports sind broker-spezifisch; 8083 und 8084 mit dem Pfad /mqtt sind üblich.
6. Was ist ein Topic?
Ein UTF-8-String mit durch / getrennten Ebenen, etwa site1/line2/temp. Topics entstehen implizit, sobald darauf publiziert wird. In industriellen Projekten folgt der Topic-Baum oft einem Unified Namespace (UNS), dessen Ebenen der ISA-95-Hierarchie entsprechen (Enterprise, Site, Area, Line, Cell), etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur; wer das im Interview erklären kann, punktet bei Stellen in der Fertigung. Hintergrund liefert Sparkplug B und Unified Namespace.
7. Erklären Sie die Wildcards + und #.
+ passt auf genau eine Ebene; # passt auf alle verbleibenden Ebenen und muss das letzte Zeichen eines Filters sein. Wildcards sind nur in Subscriptions zulässig.
8. Wofür wird die Client-ID verwendet?
Sie identifiziert die Session auf dem Broker. Bei zwei Verbindungen mit derselben ID trennt der Broker die ältere, was oft zu einer Reconnect-Schleife führt.
9. Was ist Keep-Alive?
Die maximale Funkstille in Sekunden, die ein Client zusagt. Im Leerlauf sendet er PINGREQ; der Broker trennt die Verbindung nach etwa dem 1,5-Fachen des Intervalls ohne Verkehr.
10. Warum ist MQTT im IoT so beliebt?
Geringer Paket-Overhead, Push-Zustellung, rein ausgehende Verbindungen, die durch NAT funktionieren, und eingebaute Zuverlässigkeitsfunktionen wie QoS und persistente Sessions.
QoS und Zustellung (Fragen 11 bis 18)
11. Beschreiben Sie die drei QoS-Stufen.
QoS 0 ist höchstens einmal ohne Bestätigung. QoS 1 ist mindestens einmal mit PUBACK. QoS 2 ist genau einmal mittels PUBREC, PUBREL und PUBCOMP.
12. Gilt QoS Ende-zu-Ende?
Nein. QoS gilt getrennt für die Strecke vom Publisher zum Broker und vom Broker zum Subscriber. Der Subscriber empfängt mit der niedrigeren von veröffentlichter QoS und Subscription-QoS.
13. Wann würden Sie QoS 0 wählen?
Für häufige Telemetrie, bei der der nächste Messwert den letzten ersetzt und ein gelegentlicher Verlust akzeptabel ist.
14. Warum kann QoS 1 Duplikate erzeugen?
Geht das PUBACK verloren, überträgt der Sender erneut mit gesetztem DUP-Flag. Anwendungen müssen idempotent sein oder deduplizieren.
15. Was kostet QoS 2?
Vier Pakete pro Nachricht und zusätzlichen Zustand auf beiden Seiten, was den Durchsatz senkt. Setzen Sie es nur ein, wenn Duplikate wirklich schädlich sind. Mehr dazu in MQTT-QoS-Stufen erklärt.
16. Garantiert MQTT die Reihenfolge?
Nachrichten eines Publishers auf einem Topic mit derselben QoS kommen in Reihenfolge an. Über Topics oder Publisher hinweg gibt es keine Reihenfolgegarantie.
17. Was ist ein Inflight Window?
Die Anzahl der gleichzeitig erlaubten unbestätigten QoS-1/2-Nachrichten. MQTT 5 stellt sie als Receive Maximum bereit.
18. Was passiert, wenn niemand ein Topic abonniert hat?
Der Broker verwirft die Nachricht, sofern sie nicht retained ist.
Sessions, Retained Messages und Last Will (Fragen 19 bis 27)
19. Was ist eine persistente Session?
Broker-seitiger Zustand für eine Client-ID (Subscriptions und wartende QoS-1/2-Nachrichten), der über Verbindungsabbrüche hinweg erhalten bleibt.
20. Clean Session oder Clean Start?
In 3.1.1 steuert Clean Session sowohl die Wiederverwendung als auch die Lebensdauer der Session. MQTT 5 teilt das in Clean Start (Wiederverwendung beim Verbinden) und Session Expiry Interval (Lebensdauer) auf.
21. Was ist eine Retained Message?
Die letzte mit Retain-Flag markierte Nachricht auf einem Topic, die der Broker speichert und neuen Subscribern sofort zustellt.
22. Wie löschen Sie eine Retained Message?
Publizieren Sie eine leere Payload mit Retain-Flag auf dasselbe Topic.
23. Was ist ein typischer Fallstrick bei Retained Messages?
Veralteter Zustand: Ein Gerät, das längst ausgefallen ist, erscheint weiterhin als „an“, weil sein letzter retained Status nie gelöscht wurde. Kombinieren Sie das mit einem Last Will.
24. Was ist Last Will and Testament?
Eine beim Verbindungsaufbau registrierte Nachricht, die der Broker publiziert, wenn sich der Client ohne ordnungsgemäßes DISCONNECT trennt, etwa nach einem Netzwerkausfall.
25. Wie bauen Sie einen zuverlässigen Online-/Offline-Status?
Publizieren Sie nach dem Verbinden ein retained „online“ und registrieren Sie einen retained Will „offline“ auf demselben Topic.
26. Was ist das Will Delay Interval?
Eine Einstellung in MQTT 5, die den Will hinauszögert, damit ein schnell wieder verbundener Client keinen falschen Offline-Alarm auslöst.
27. Wie lange werden Offline-Nachrichten aufbewahrt?
Solange die Session lebt und die Broker-Kontingente es zulassen. In MQTT 5 setzen Session Expiry und Message Expiry explizite Grenzen.
MQTT 5 (Fragen 28 bis 34)
28. Nennen Sie wichtige Neuerungen von MQTT 5.
Reason Codes, User Properties, Session und Message Expiry, Topic Aliases, Shared Subscriptions, Request/Response-Properties und erweiterte Authentifizierung. Überblick in MQTT-5-Funktionen.
29. Was sind Reason Codes?
Ein-Byte-Codes in Bestätigungen und DISCONNECT, die Ergebnisse erklären, zum Beispiel 0x87 Not authorized oder 0x97 Quota exceeded.
30. Was ist eine Shared Subscription?
Ein Filter der Form $share/group/topic, der Nachrichten zur Lastverteilung auf die Mitglieder einer Gruppe verteilt.
31. Was ist ein Topic Alias?
Eine Ganzzahl, die innerhalb einer Verbindung einen langen Topic-Namen ersetzt und so die Bytes pro PUBLISH reduziert.
32. Wie unterstützt MQTT 5 Request/Response?
Der Anfragende setzt ein Response Topic und Correlation Data; der Antwortende publiziert seine Antwort auf dieses Topic mit denselben Correlation Data.
33. Was sind User Properties?
Beliebige Schlüssel/Wert-String-Paare an Paketen, ähnlich HTTP-Headern, nützlich für Metadaten wie Inhaltsversion oder Trace-IDs.
34. Was ist das Message Expiry Interval?
Eine Lebensdauer pro Nachricht, nach der der Broker sie verwirft, falls sie nicht zugestellt wurde. So werden veraltete Befehle nicht später noch ausgeführt.
Sicherheit und Betrieb (Fragen 35 bis 40)
35. Wie sichern Sie MQTT ab?
TLS auf 8883, eindeutige Zugangsdaten pro Gerät, Topic-Berechtigungen nach dem Least-Privilege-Prinzip, wo der Broker sie unterstützt, und keine sensiblen Daten auf öffentlichen Brokern. Siehe Best Practices für MQTT-Sicherheit.
36. Was ist Mutual TLS?
TLS, bei dem der Client ein eigenes Zertifikat vorlegt, damit der Broker ihn kryptografisch authentifizieren kann.
37. Warum sollte man Port 1883 nicht in Produktion nutzen?
Zugangsdaten und Payloads werden unverschlüsselt übertragen und können an jedem Netzwerk-Hop mitgeschnitten werden.
38. Was sind $SYS-Topics?
Vom Broker reservierte Topics, die Statusinformationen bereitstellen. Wildcard-Subscriptions mit # erfassen keine Topics, die mit $ beginnen.
39. Wie skalieren Sie MQTT-Konsumenten?
Mit Shared Subscriptions die Last verteilen, Callbacks schnell halten und Wildcard-Subscriptions eng fassen.
40. Selbst betriebener oder verwalteter MQTT-Broker?
Der Eigenbetrieb bietet volle Kontrolle, bringt aber Patches, Zertifikate, Monitoring und Skalierung mit sich. Ein verwalteter MQTT-Broker verlagert diese Betriebslast zum Anbieter.
Üben vor dem Interview
Nichts schlägt eigene Erfahrung. Installieren Sie mosquitto_pub und mosquitto_sub, wählen Sie ein zufälliges Suffix und führen Sie Folgendes gegen broker.connectmq.com aus (anonym, eindeutige Client-ID, öffentliche Daten):
# F21-22: Retained Message, danach löschen
mosquitto_pub -h broker.connectmq.com -p 1883 -i iq-pub-5c9d \
-t "connectmq/demo/5c9d/lamp" -m "on" -r -q 1
mosquitto_sub -h broker.connectmq.com -p 1883 -i iq-sub-5c9d \
-t "connectmq/demo/5c9d/#" -v -C 1
mosquitto_pub -h broker.connectmq.com -p 1883 -i iq-pub-5c9d \
-t "connectmq/demo/5c9d/lamp" -r -n
# F24-25: Last Will. Starten, dann das Terminal beenden (nicht Strg+C)
mosquitto_sub -h broker.connectmq.com -p 1883 -i iq-will-5c9d \
-t "connectmq/demo/5c9d/ping" -k 10 \
--will-topic "connectmq/demo/5c9d/status" --will-payload "offline" \
--will-retain --will-qos 1
# F30: Shared Subscription (MQTT 5). In zwei Terminals mit unterschiedlichem -i ausführen
mosquitto_sub -h broker.connectmq.com -p 1883 -V mqttv5 -i iq-w1-5c9d \
-t '$share/workers/connectmq/demo/5c9d/jobs' -v
Eine Übungs-Checkliste zum Abarbeiten:
- Publizieren Sie mit QoS 0, 1 und 2 und beobachten Sie den Paketfluss mit
-d(Debug-Ausgabe). - Erstellen Sie eine Retained Message, abonnieren Sie sie und löschen Sie sie dann.
- Lösen Sie einen Last Will aus, indem Sie einen Client abrupt beenden.
- Verwenden Sie eine Client-ID in zwei Terminals und beobachten Sie die Disconnect-Schleife.
- Probieren Sie eine Shared Subscription mit zwei Workern aus und zählen Sie, welcher welche Nachricht erhält.
Wiederholen Sie im MQTT-Tutorial alles, was sich noch unklar anfühlt.
Üben Sie auf Ihrem eigenen ConnectMQ-Broker
Interviewer lieben Kandidaten, die schon ein echtes Deployment betrieben haben. Registrieren Sie sich unter app.connectmq.com für einen kostenlosen Serverless-Broker (ohne Kreditkarte), verbinden Sie sich mit den generierten Zugangsdaten über TLS und zeigen Sie mit dem Browser-Client und dem Live-Topic-Explorer von ConnectMQ genau, wie sich Sessions, Retained Messages und Wills verhalten. ConnectMQ unterstützt MQTT 3.1.1 und 5.0, sodass Sie beide Versionen vorführen können.
Häufig gestellte Fragen
Welche MQTT-Themen kommen in Interviews am häufigsten vor?
QoS-Stufen, persistente Sessions, Retained Messages, Last Will und Topic-Design sind nahezu universell. MQTT-5-Funktionen und Sicherheit sind bei Senior-Rollen üblich.
Muss ich für ein Interview MQTT 5 kennen?
Für neue IoT-Projekte ja, zumindest die Grundlagen: Reason Codes, Session Expiry, Shared Subscriptions und User Properties.
Wie bereite ich mich auf eine praktische MQTT-Aufgabe vor?
Seien Sie mit einer Client-Bibliothek (Python paho-mqtt oder MQTT.js) und den Mosquitto-CLI-Tools vertraut und in der Lage, sich mit Zugangsdaten über TLS zu verbinden.
Welche Gegenfrage kann ich dem Interviewer gut stellen?
Fragen Sie, welchen Broker und welche MQTT-Version das Team einsetzt, wie die Geräteidentität gehandhabt wird und wie der Verbindungsstatus überwacht wird. In der Industrie lohnt zusätzlich die Frage, ob ein UNS geplant ist und wie SPS- und OPC-UA-Daten in MQTT gelangen. Das zeigt Betriebsbewusstsein.
