Edge Iot¶
16 cards — 🟢 3 easy | 🟡 4 medium | 🔴 3 hard
🟢 Easy (3)¶
1. What are the four points on the edge computing spectrum and their characteristics?
Show answer
Data Center (full K8s, 100 Gbps, always on), Near Edge (k3s/MicroK8s, 1 Gbps, usually on — retail stores, factories), Far Edge (minimal Linux, LTE/4G, intermittent — cell towers, vehicles), Deep Edge (bare RTOS, LoRa, sporadic — agricultural sensors, subsea cables).2. What is MQTT and what are its three QoS levels?
Show answer
MQTT is a lightweight pub/sub protocol designed for constrained networks. QoS 0: fire and forget (may lose messages). QoS 1: at least once delivery (may duplicate). QoS 2: exactly once delivery (highest overhead). Use QoS 1 for device telemetry as a good balance of reliability and efficiency.3. What lightweight Linux options exist for edge devices with limited storage and RAM?
Show answer
Alpine Linux (~5MB, musl libc, great for containers but beware glibc compatibility), Yocto Project (custom build from scratch, ~8MB+, high learning curve), Buildroot (simpler than Yocto, custom images ~5MB+), Ubuntu Core (~200MB, snap-based), Raspberry Pi OS Lite (~400MB).🟡 Medium (4)¶
1. What are the three safety rules for OTA (Over-The-Air) updates to edge devices?
Show answer
(1) NEVER update all devices at once — use canary rollout: 1% -> 5% -> 25% -> 100% with 24-hour soak periods between phases. (2) ALWAYS have automatic rollback — boot counter (3 failed boots reverts), health check, or watchdog timer. (3) NEVER update the bootloader unless absolutely necessary — a bad bootloader update bricks the device permanently, while a bad OS update with A/B partitions is recoverable.2. How does the A/B partition scheme work for safe edge device updates?
Show answer
The device has two OS partitions plus a persistent data partition. The active partition (A) runs the current version. Updates are written to the inactive partition (B). After reboot, the device boots from B. If B fails to boot 3 times, it automatically reverts to A. This ensures a bricked update is always recoverable without physical access.3. Why doesn't standard Prometheus scraping work for edge devices, and what are three alternative strategies?
Show answer
Edge devices often have 1 Mbps metered cellular connections. Three strategies: (1) Edge-local Prometheus with remote_write (batched, compressed push to central). (2) Telegraf/Vector with buffering — batch metrics every 5 minutes or when connected. (3) MQTT-based metrics — tiny payloads published to a broker that feeds into Prometheus via Telegraf.4. What are the differences between k3s, MicroK8s, and KubeEdge for edge Kubernetes?
Show answer
k3s: single binary (~70MB), full K8s API, SQLite/etcd backend, best for 1-10 node edge sites. MicroK8s: snap-based, add-on system (gpu, istio, registry), best for Ubuntu-based edge. KubeEdge: split architecture (CloudCore + EdgeCore), works with intermittent connectivity, edge nodes operate independently when disconnected, best for thousands of centrally managed devices.🔴 Hard (3)¶
1. What five mandatory security measures should be implemented on remote edge devices?
Show answer
(1) Encrypted storage with LUKS. (2) Signed OTA updates — verify with openssl before applying. (3) Automatic certificate rotation with short-lived certs (hours, not years). (4) Firewall with deny-all default and specific outbound allow rules only to control plane and MQTT broker. (5) Read-only root filesystem using overlayfs for writable layers to prevent persistent malware.2. How do you maintain remote access to edge devices over unreliable connections?
Show answer
Use autossh to maintain persistent reverse SSH tunnels with auto-reconnect: autossh -M 0 -f -N -R 2222:localhost:22 user@bastion with ServerAliveInterval/ServerAliveCountMax options. Then SSH to the edge device via the bastion. For interactive sessions, use mosh (mobile shell) which uses UDP, handles high latency, packet loss, and survives network changes and roaming.3. Why must edge device designs assume power loss will happen, and what protections are needed?