Cloud-Managed Networking Architecture and the Meraki Dashboard
The control plane is in the cloud; the data plane is not
Every Meraki device keeps a persistent outbound HTTPS (TCP 443) connection to the Meraki cloud controller - the Dashboard. Configuration, inventory, firmware scheduling, and telemetry ride that channel; user traffic never does. Once a device has synced, it stores its configuration locally, so losing the cloud connection does not stop switching, routing, or VPN forwarding - it only prevents new configuration pushes and fresh Dashboard statistics.
Organization vs. network scope
The hierarchy is organization → network → device. Organization-level objects include inventory, licenses, administrators, API access, configuration templates, and the change log. Network-level objects include VLANs, SSIDs, firewall rules, and device ports. Many questions simply test which scope owns a setting: licenses and admins are organizational; SSIDs and firewall rules are per-network.
Templates, roles, and resilience
Configuration templates bind many networks to one master configuration, so a change propagates consistently. Administrators can be full, read-only, or scoped to specific networks, and SAML/SSO can sit on top. Devices also expose a local status page for out-of-band visibility when the cloud is unreachable.
Traps: "all traffic is tunneled through the Meraki cloud" is false; "the firewall stops working when the Dashboard is unreachable" is false; mixing organization-scope and network-scope answers is the most common error.
Rule of thumb: if the setting spans networks (license, admin, inventory, template), it lives at Organization; if it describes a subnet, SSID, or port, it lives at Network.
Worked example: an MX loses upstream connectivity for two hours. Existing sessions keep forwarding on the last known configuration; you simply cannot push changes until it reconnects.