When trying to subscribe to an MQTT broker on the internet, the MQTT client is on a private subnet and must be NATed to reach the public broker. What is the expected outcome when this configuration…

Question

Options

• AThe client periodically reconnects to the default gateway.
• BThe client connects only once using the PENDING message to the broker.
• CThe client periodically reconnects to the broker over the NAT connection.
• DThe client connects only once using the CONNECT massage to the broker.

• A
  16% (10)
• B
  8% (5)
• C
  3% (2)
• D
  72% (44)

Explanation

Option D is correct because MQTT uses a persistent TCP connection initiated by the client with a single CONNECT packet. Since NAT allows outbound-initiated connections, the client successfully establishes the session once and relies on MQTT's built-in keep-alive mechanism (PINGREQ/PINGRESP heartbeats) to maintain the NAT mapping - no reconnection is needed.

Why the distractors are wrong:

• A is wrong because MQTT communicates with the broker, not the default gateway - that's a Layer 3 routing concept unrelated to MQTT session management.
• B is wrong because PENDING is not a valid MQTT control packet; the protocol uses CONNECT, CONNACK, PUBLISH, SUBSCRIBE, PINGREQ, etc.
• C is wrong because periodic reconnection describes a failure scenario (e.g., NAT timeout shorter than keep-alive interval), not the expected normal behavior of a properly configured MQTT client behind NAT.

Memory tip: Think of MQTT as a phone call - you dial once (CONNECT), and then both sides periodically say "still there?" (PINGREQ/PINGRESP) to keep the line open. NAT just forwards that one outbound call; it doesn't force repeated redialing.

No community discussion yet for this question.