BLE can't reach the internet directly, it's a short-range, non-IP link, so the data must be bridged through a gateway that has both BLE and internet connectivity. The most common pattern is a smartphone: the sensor (BLE peripheral) connects to a phone app (BLE central), and the app relays the data to the cloud over the phone's WiFi or cellular, often via MQTT or HTTPS. Alternatively a dedicated hub/gateway device (with BLE plus WiFi or Ethernet) sits in the environment and continuously bridges one or more BLE sensors to the cloud, better for unattended operation since it doesn't depend on a phone being present and the app being open. The gateway typically also handles buffering (storing readings when the cloud link is down), security translation (BLE pairing on one side, TLS to the cloud on the other), and protocol mapping (GATT characteristics to MQTT topics, say). The key architectural point is that BLE's low power comes precisely from not carrying a full IP stack and internet radio, so reaching the cloud is intentionally offloaded to a more capable, usually mains-or-large-battery gateway, and if your product must be cloud-connected without relying on the user's phone, you ship or specify that hub. Designs that need direct cloud reach on the device itself would use WiFi or cellular instead of BLE.
Networking & IoT · Interview question
A BLE sensor needs to get its data to the cloud. How?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
BLE & WiFi for Embedded
Two wireless worlds: BLE's ultra-low-power short-range GATT model (wearables, sensors, phone-tethered) vs WiFi's high-bandwidth, IP-native, internet-direct connectivity, and the power tradeoff.