Mist Cloud and Architecture Fundamentals
This domain tests how the Mist cloud is built, how APs and switches reach it, and what happens when they cannot. Expect questions on microservices, outbound connectivity, adoption, and the org/site hierarchy.
What the cloud actually does
Mist is a cloud-native, multi-tenant platform built as microservices on Kubernetes and hosted in public cloud regions. The control plane lives in the cloud: configuration, firmware management, telemetry collection, SLE calculation, and Marvis. The data plane stays local: APs and switches forward user traffic, and client traffic does not tunnel through Mist.
How devices connect
APs and Juniper EX switches reach Mist with outbound-only connections over TCP 443, so they work behind NAT and need no inbound firewall rules. They use DHCP for an address, DNS to resolve Mist endpoints, and NTP because certificate validation needs correct time. If the cloud is unreachable, an AP keeps serving its cached WLAN configuration; you lose monitoring and new config changes, not the SSID.
Adoption and hierarchy
Devices are claimed into an Organization using a claim code or serial number, then assigned to a Site. Org-level objects such as WLAN templates, RF templates, switch templates, and device profiles push down; site settings and per-device overrides take precedence.
Worked example: an AP powers up, gets DHCP, but never appears as connected. DHCP worked, so Layer 2/3 is fine; the likely failure is DNS resolution, outbound 443 blocked by the firewall, or missing NTP causing TLS failure. Claiming it in Inventory does not fix reachability - claim is ownership, not connectivity.
Traps: believing the AP needs inbound ports; treating Mist as a monitoring overlay when it is the config source of truth; mixing up claimed (in org inventory) with connected (cloud session up); assuming client traffic flows through the cloud.