Meraki Solutions Specialist common mistakes
Meraki Solutions Specialist · Understand the traps and how to avoid them.
Explains Meraki as 'everything goes through the cloud' and predicts that a WAN outage or a dashboard outage stops inter-VLAN routing, local switching, or established site-to-site tunnels.
The 'cloud-managed' branding and the dashboard's central role invite the assumption that the data plane is centralized. Candidates conflate the management plane with the forwarding plane.
What to do instead
Anchor every architecture answer on the split: configuration storage, management, and cloud-hosted services (e.g., cloud auth, dashboard config pushes) live in the cloud; packet forwarding, local switching, MX inter-VLAN routing, and Auto VPN IPsec tunnels are handled on-device and keep working when the dashboard is unreachable.
Sizes or predicts license expiry by counting devices and assuming each device's license expires on its own independent date, without checking which licensing model the organization uses.
Candidates carry over a per-device perpetual mental model and never look at Organization > License info, where the organization's licensing model and shared expiration are shown.
What to do instead
Check the organization's licensing model first. In co-termination, all licenses in the organization share one expiration date and adding a license shifts that shared date for the whole organization; in per-device licensing, each device carries its own expiration. Always answer licensing questions by first identifying the model in use.
Describes a rollout as 'add the device in the dashboard and it starts working' - never stating that the serial must be claimed into the organization inventory, and then added/assigned to a specific network before any configuration applies.
Claiming and assigning are two separate steps performed in different parts of the UI, so the process looks like a single action; the device also needs DHCP, internet reachability, and a successful cloud check-in before it appears as online.
What to do instead
State the sequence explicitly: device powers on, obtains an address via DHCP, reaches the Meraki cloud, is claimed to the organization inventory (which ties the serial to the organization and consumes licensing), then added to a network or template-bound network. Verify with the device's local status page/LED and the dashboard 'last seen' value.
Edits a configuration template (or a switch profile) and immediately asserts that every bound network and every port is now identical, without checking for local overrides or devices that were offline during the push.
Template propagation is fast but not uniform: individual networks can carry local overrides, switch port configuration can come from profiles rather than the network template, and offline devices only receive changes at their next check-in.
What to do instead
Inspect each bound network for the local-override indicator, distinguish network templates from switch profiles and their per-port settings, and confirm the push in the organization change log. Bring any offline devices online and re-check before claiming the fleet is consistent.
Writes an MX Layer 3 outbound rule set with a permissive 'Allow Any to Any' rule near the top and a specific Deny rule underneath, then expects the deny to actually block the traffic.
Candidates assume rules are matched by specificity or that later rules refine earlier ones, rather than recalling that evaluation is strictly top-down with first match winning.
What to do instead
Order the rule set most-specific-first, place deny rules above any broad allow rule, and remember the rules are stateful (return traffic is automatically permitted) and that the default rule exists as a catch-all that must be considered rather than ignored.
Assigns a Group Policy meant for guest clients at the wrong scope, or assumes a group policy's firewall rules replace the network-wide firewall so the network rules no longer apply to those clients.
Meraki security policy is layered by scope (network-wide Layer 3/Layer 7 firewall and content filtering, group policies, and identity-based policy), and candidates treat these layers as mutually exclusive instead of cumulative.
What to do instead
Confirm where the policy was actually attached (per client, per VLAN/SSID setting, or via RADIUS) and verify on the client's detail page which policy is applied. Treat group policy rules as evaluated ahead of the network rules for the clients in scope, not as a replacement for them, and test from the real client.
Sees a device listed as 'Online' in the dashboard and closes the incident, missing a down WAN uplink, a failed power supply, or a port stuck in an error/blocking state.
The status column reflects cloud connectivity - whether the device recently checked in - not the health of every subsystem; those signals live on separate pages and in alerts.
What to do instead
Open the device's own pages: uplink/WAN status and latency, hardware and power supply health, and port status for errors or blocking. Cross-check Organization > Alerts for active alerts rather than relying on the device list status column.
Investigates an intermittent complaint by reading only the event log, and when nothing appears for an incident from months ago, concludes that no events ever occurred.
Dashboard event log retention is limited (on the order of weeks, not indefinite) and the log records discrete events, not packet-level or flow-level detail, so absence of a record is not evidence of absence of the problem.
What to do instead
Match the tool to the question: event log for configuration, authentication, and connectivity events; packet capture on the MX or port mirroring on a switch for traffic-level proof; client timeline for one client's history; and Syslog or scheduled API polling when history beyond dashboard retention is needed.
Scripts a loop of hundreds of individual update calls to reconfigure switch ports, then hits 429 responses or a timeout, and also assumes a single list request returns every object in the organization.
Candidates treat the API like a local CLI without accounting for per-organization rate limits, pagination of list endpoints, and the dedicated bulk-change mechanism.
What to do instead
Use action batches for multi-device or multi-port changes (respecting the documented actions-per-batch and concurrent-batch limits), follow the Link header's next relation to paginate with per_page up to 1000, and implement retry with backoff honoring Retry-After on 429.
Passes a network ID where the endpoint expects a device serial (or reuses the organization ID as a network ID), and treats a successful API response as proof that the device has already applied the configuration.
Meraki endpoints encode a strict resource hierarchy, and configuration writes are queued: the API acknowledges the intent while the device applies it at its next cloud check-in.
What to do instead
Resolve identifiers first by listing organizations and then networks, keep serials distinct from network IDs, and verify the outcome with a follow-up GET or the change log after the device syncs rather than assuming a 200 means the change is live on the hardware.