Estas 40 preguntas de entrevista sobre MQTT cubren lo que realmente preguntan los responsables de contratación para puestos de IoT, sistemas embebidos y backend: fundamentos, QoS, sesiones, mensajes retenidos, Last Will, MQTT 5 y seguridad. Cada respuesta es lo bastante breve para decirla en voz alta, y la sección de práctica muestra cómo demostrar cada concepto en un broker real antes de la entrevista.
Cómo usar estas preguntas de entrevista sobre MQTT
Lee una respuesta y luego intenta explicarla sin mirar. A los entrevistadores les importan menos las definiciones memorizadas que los compromisos: cuándo usarías QoS 0, por qué pueden sorprenderte los mensajes retenidos, qué se rompe si dos dispositivos comparten client ID. Siempre que puedas, ejecuta los comandos de la sección de práctica contra el servidor MQTT público gratuito para poder describir lo que viste, no lo que leíste.
Fundamentos (preguntas 1 a 10)
1. ¿Qué es MQTT?
Un protocolo de mensajería publish/subscribe ligero que funciona sobre TCP, diseñado para dispositivos limitados y redes poco fiables. Las versiones 3.1.1 y 5.0 son estándares de OASIS.
2. ¿Qué es un broker?
El servidor que recibe todos los mensajes publicados y los enruta a los clientes con suscripciones coincidentes. También gestiona las sesiones, los mensajes retenidos y los Wills. Consulta qué hace un broker MQTT.
3. ¿En qué se diferencia publish/subscribe de request/response?
Publicadores y suscriptores nunca se dirigen unos a otros; el broker los desacopla en espacio, tiempo y sincronización. Nuestro artículo sobre el modelo publish/subscribe explica los tres.
4. ¿MQTT usa TCP o UDP?
TCP, opcionalmente envuelto en TLS o WebSocket. MQTT-SN es la variante para UDP y redes de datagramas.
5. ¿Cuáles son los puertos estándar?
1883 para TCP sin cifrar y 8883 para TLS. Los puertos WebSocket dependen del broker; son habituales el 8083 y el 8084 con la ruta /mqtt.
6. ¿Qué es un topic?
Una cadena UTF-8 con niveles separados por /, como site1/line2/temp. Los topics se crean implícitamente al publicar en ellos.
7. Explica los comodines + y #.
+ coincide exactamente con un nivel; # coincide con todos los niveles restantes y debe ser el último carácter de un filtro. Los comodines solo son válidos en suscripciones.
8. ¿Para qué sirve el client ID?
Identifica la sesión en el broker. Dos conexiones con el mismo ID hacen que el broker desconecte la más antigua, lo que a menudo provoca un bucle de reconexiones.
9. ¿Qué es el keep-alive?
El silencio máximo en segundos que promete un cliente. Envía PINGREQ cuando está inactivo; el broker corta la conexión tras aproximadamente 1,5 veces el intervalo sin tráfico.
10. ¿Por qué es MQTT tan popular en IoT?
Poca sobrecarga por paquete, entrega push, conexiones solo salientes que funcionan a través de NAT y funciones de fiabilidad integradas como QoS y sesiones persistentes.
QoS y entrega (preguntas 11 a 18)
11. Describe los tres niveles de QoS.
QoS 0 es como máximo una vez, sin confirmación. QoS 1 es al menos una vez, con PUBACK. QoS 2 es exactamente una vez, usando PUBREC, PUBREL y PUBCOMP.
12. ¿El QoS es de extremo a extremo?
No. El QoS se aplica por separado al tramo del publicador al broker y al del broker al suscriptor. El suscriptor recibe con el menor entre el QoS publicado y el QoS de su suscripción.
13. ¿Cuándo elegirías QoS 0?
Para telemetría frecuente en la que la siguiente muestra sustituye a la anterior y en la que una pérdida ocasional es aceptable.
14. ¿Por qué QoS 1 puede producir duplicados?
Si se pierde el PUBACK, el emisor retransmite con el flag DUP activado. Las aplicaciones deben ser idempotentes o eliminar duplicados.
15. ¿Qué cuesta QoS 2?
Cuatro paquetes por mensaje y estado adicional en ambos lados, lo que reduce el throughput. Úsalo solo cuando los duplicados sean realmente dañinos. Más en niveles de QoS de MQTT explicados.
16. ¿MQTT garantiza el orden?
Los mensajes de un publicador en un topic con el mismo QoS llegan en orden. No hay garantía de orden entre topics ni entre publicadores.
17. ¿Qué es una ventana en vuelo (inflight window)?
El número de mensajes QoS 1/2 sin confirmar permitidos a la vez. MQTT 5 la expone como Receive Maximum.
18. ¿Qué pasa si nadie está suscrito a un topic?
El broker descarta el mensaje, salvo que sea retenido.
Sesiones, mensajes retenidos y Last Will (preguntas 19 a 27)
19. ¿Qué es una sesión persistente?
Estado en el broker para un client ID (suscripciones y mensajes QoS 1/2 en cola) que se conserva entre desconexiones.
20. ¿Clean Session o Clean Start?
En 3.1.1, Clean Session controla tanto la reutilización como la duración de la sesión. MQTT 5 lo divide en Clean Start (reutilización al conectar) y Session Expiry Interval (duración).
21. ¿Qué es un mensaje retenido?
El último mensaje de un topic marcado con retain, que el broker guarda y entrega de inmediato a los nuevos suscriptores.
22. ¿Cómo se borra un mensaje retenido?
Publicando un payload vacío con el flag retain en el mismo topic.
23. ¿Cuál es un error habitual con los mensajes retenidos?
El estado obsoleto: un dispositivo que murió hace tiempo sigue apareciendo como "on" porque nunca se borró su último estado retenido. Combínalo con un Last Will.
24. ¿Qué es Last Will and Testament?
Un mensaje registrado al conectar que el broker publica si el cliente se desconecta sin un DISCONNECT correcto, por ejemplo tras un fallo de red.
25. ¿Cómo se construye un estado online/offline fiable?
Publicando un "online" retenido tras conectar y registrando un Will retenido "offline" en el mismo topic.
26. ¿Qué es Will Delay Interval?
Un ajuste de MQTT 5 que pospone el Will para que un cliente que se reconecta rápido no dispare una falsa alerta de desconexión.
27. ¿Cuánto tiempo se guardan los mensajes offline?
Mientras viva la sesión y lo permitan las cuotas del broker. En MQTT 5, Session Expiry y Message Expiry le ponen límites explícitos.
MQTT 5 (preguntas 28 a 34)
28. Nombra las principales novedades de MQTT 5.
Reason codes, user properties, expiración de sesión y de mensajes, topic aliases, suscripciones compartidas, propiedades de request/response y autenticación mejorada. Resumen en funciones de MQTT 5.
29. ¿Qué son los reason codes?
Códigos de un byte en las confirmaciones y en DISCONNECT que explican el resultado, por ejemplo 0x87 Not authorized o 0x97 Quota exceeded.
30. ¿Qué es una suscripción compartida?
Un filtro de la forma $share/group/topic que reparte los mensajes entre los miembros del grupo para balancear la carga.
31. ¿Qué es un topic alias?
Un entero que sustituye a un nombre de topic largo dentro de una conexión, reduciendo los bytes por PUBLISH.
32. ¿Cómo soporta MQTT 5 el patrón request/response?
El solicitante establece un Response Topic y Correlation Data; quien responde publica su respuesta en ese topic con la misma correlation data.
33. ¿Qué son las user properties?
Pares clave/valor de cadenas arbitrarias adjuntos a los paquetes, similares a las cabeceras HTTP, útiles para metadatos como la versión del contenido o IDs de traza.
34. ¿Qué es Message Expiry Interval?
Una vida útil por mensaje tras la cual el broker lo descarta si no se ha entregado, lo que evita que comandos obsoletos se ejecuten más tarde.
Seguridad y operación (preguntas 35 a 40)
35. ¿Cómo se asegura MQTT?
TLS en el 8883, credenciales únicas por dispositivo, permisos de topic de mínimo privilegio cuando el broker lo admite y nada de datos sensibles en brokers públicos. Consulta buenas prácticas de seguridad MQTT.
36. ¿Qué es TLS mutuo?
TLS en el que el cliente presenta su propio certificado para que el broker pueda autenticarlo criptográficamente.
37. ¿Por qué no usar el puerto 1883 en producción?
Las credenciales y los payloads viajan sin cifrar y pueden capturarse en cualquier salto de la red.
38. ¿Qué son los topics $SYS?
Topics reservados del broker que exponen información de estado. Las suscripciones con el comodín # no coinciden con topics que empiezan por $.
39. ¿Cómo se escalan los consumidores MQTT?
Con suscripciones compartidas para repartir la carga, callbacks rápidos y suscripciones con comodines de alcance acotado.
40. ¿Broker autoalojado o broker MQTT gestionado?
El autoalojamiento da control total, pero añade trabajo de parches, certificados, monitorización y escalado. Un broker MQTT gestionado traslada esa carga operativa al proveedor.
Practica antes de la entrevista
Nada supera haberlo hecho. Instala mosquitto_pub y mosquitto_sub, elige un sufijo aleatorio y ejecuta esto contra broker.connectmq.com, el servidor MQTT público gratuito de ConnectMQ (anónimo, client ID único, datos públicos; úsalo para practicar, nunca con datos de producción):
# P21-22: mensaje retenido y luego borrarlo
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
# P24-25: Last Will. Inícialo y luego cierra la terminal a la fuerza (no Ctrl+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
# P30: suscripción compartida (MQTT 5). Ejecútalo en dos terminales con distinto -i
mosquitto_sub -h broker.connectmq.com -p 1883 -V mqttv5 -i iq-w1-5c9d \
-t '$share/workers/connectmq/demo/5c9d/jobs' -v
Una lista de práctica para ir completando:
- Publica con QoS 0, 1 y 2 y observa el flujo de paquetes con
-d(salida de depuración). - Crea un mensaje retenido, suscríbete y luego bórralo.
- Provoca un Last Will matando un cliente de golpe.
- Reutiliza un mismo client ID en dos terminales y observa el bucle de desconexiones.
- Prueba una suscripción compartida con dos workers y cuenta cuál recibe cada mensaje.
Repasa el tutorial de MQTT para todo lo que aún te resulte confuso.
Practica en tu propio broker de ConnectMQ
A los entrevistadores les encantan los candidatos que han gestionado un despliegue real. Regístrate en app.connectmq.com para obtener un broker Serverless gratuito (sin tarjeta de crédito), conéctate por TLS con las credenciales generadas y usa el cliente integrado en el navegador y el explorador de topics en vivo de ConnectMQ para mostrar exactamente cómo se comportan las sesiones, los mensajes retenidos y los Wills. ConnectMQ admite MQTT 3.1.1 y 5.0, así que puedes demostrar ambas versiones.
Preguntas frecuentes
¿Qué temas de MQTT salen más en las entrevistas?
Los niveles de QoS, las sesiones persistentes, los mensajes retenidos, el Last Will y el diseño de topics son casi universales. Las funciones de MQTT 5 y la seguridad son habituales en puestos sénior.
¿Necesito conocer MQTT 5 para una entrevista?
Para proyectos IoT nuevos, sí, al menos lo básico: reason codes, expiración de sesión, suscripciones compartidas y user properties.
¿Cómo debo prepararme para una prueba práctica de MQTT?
Domina una biblioteca cliente (paho-mqtt en Python o MQTT.js) y las herramientas CLI de Mosquitto, y sé capaz de conectarte por TLS con credenciales.
¿Qué buena pregunta puedo hacerle al entrevistador?
Pregunta qué broker y qué versión de MQTT usan, cómo gestionan la identidad de los dispositivos y cómo monitorizan el estado de las conexiones. Demuestra conciencia operativa.
