Cisco Meraki Solutions Specialist — Practice Set 1

Question 1

In the Cisco Meraki cloud-managed architecture, which plane does the Meraki Dashboard manage and which plane do Meraki devices handle independently?

Accepted Answer

In Cisco Meraki's cloud-managed architecture, the Dashboard (hosted in the cloud) manages the control plane (configuration distribution, policy enforcement) and management plane (device monitoring, firmware updates). Meraki devices — MX, MS, MR, MV, MT — handle the data plane locally, forwarding and switching traffic based on cached configuration even when the cloud connection is temporarily interrupted. This design ensures network resilience: if a Meraki device loses Dashboard connectivity, it continues forwarding traffic using its last-known configuration until connectivity is restored.

Question 2

A Meraki Dashboard administrator uses the REST API to retrieve a list of all organizations under their account. Which HTTP method and endpoint are used, and how must the API key be passed?

Accepted Answer

The Meraki Dashboard API v1 uses REST conventions. To list organizations, the client sends `GET /api/v1/organizations`. Authentication is provided by including the API key in the `X-Cisco-Meraki-API-Key` HTTP request header — not as a Bearer token or query parameter. The API key is generated per user in Dashboard (Account → API access). The API enforces a rate limit of 10 requests per second per organization. API responses are JSON. This API enables automation of configuration, reporting, and provisioning tasks across large Meraki deployments.

Question 3

An organization manages 50 retail sites and wants to push the same SSID and firewall configuration to all sites simultaneously. Which Meraki Dashboard feature enables this without configuring each site individually?

Accepted Answer

Meraki Configuration Templates allow administrators to define a master configuration (SSIDs, VLANs, firewall rules, MX settings) that is shared across multiple networks. Each retail site network is 'bound' to the template. When the template is updated — for example, adding a new SSID or modifying an L7 firewall rule — the change propagates automatically to all bound networks. Site-specific overrides (e.g., local addressing) can be configured at the network level without breaking the template binding. This is the primary tool for consistent, scalable multi-site management without site-by-site manual configuration.

Question 4

A Meraki network uses the 'combined' network type. What does this mean in terms of device management?

Accepted Answer

A Meraki 'combined' network type groups MX security appliances, MS switches, MR access points, and MT/MV devices at the same physical location under a single Dashboard network. This simplifies site management — all devices are visible and configurable from a single network view, and the shared VLAN configuration is consistent across device types. The alternative is 'split' networks where each device type is in a separate network, which is used when different sites need independent configuration or when the site has multiple independently managed device groups. Combined networks are recommended for branch sites.

Question 5

A Meraki administrator wants to automate nightly backup of all network configurations across 200 organizations to a local file system. The script must respect the API rate limit of 10 requests/second. What is the correct approach?

Accepted Answer

The Meraki Dashboard API does not provide a single bulk configuration export endpoint — administrators must iterate through the organization and network hierarchy: GET /api/v1/organizations → GET /api/v1/organizations/{orgId}/networks → GET configuration endpoints per network. The 10 req/sec rate limit applies per organization, so a script managing 200 organizations must implement throttling — a 100ms sleep between requests, or token bucket rate limiting — to avoid HTTP 429 Too Many Requests errors. The rate limit is enforced by the API and cannot be increased through settings. Proper error handling for 429 responses with exponential backoff is a best practice.

Question 6

A Meraki MX is deployed in 'routed mode'. What is the primary characteristic of this deployment mode?

Accepted Answer

In routed mode — the most common MX deployment — the MX functions as a Layer 3 gateway performing NAT (Network Address Translation). Internal hosts are assigned private RFC1918 addresses and the MX translates outbound traffic to the WAN IP address. This is the standard branch deployment: ISP → MX WAN port (public IP) → MX LAN ports (private subnet gateway). Routed mode also enables all MX security features: IPS, content filtering, AMP, and L7 firewall. Passthrough/one-armed concentrator mode is used when the MX must insert into an existing routed topology without replacing the existing gateway.

Question 7

An administrator configures Meraki AutoVPN at a hub-and-spoke topology. The hub MX is at headquarters and 20 branch MX appliances are spokes. What configuration steps are required on the hub MX and do spoke MX appliances require manual configuration of each tunnel?

Accepted Answer

Meraki AutoVPN dramatically simplifies VPN deployment. On the hub MX, the administrator navigates to Security & SD-WAN > Site-to-site VPN, sets the mode to Hub, and selects which local subnets to advertise to spokes. Spoke MX appliances in the same Dashboard organization automatically discover the hub via the cloud controller and register as spokes — no manual IKE configuration, pre-shared key exchange, or tunnel endpoint configuration is required on spoke appliances. AutoVPN uses the Meraki cloud to distribute hub discovery information and manages the IPsec SA negotiation transparently. This scales to hundreds of spokes without manual per-site configuration.

Question 8

An MX administrator configures IPS in 'Protection' mode. How does Protection mode differ from 'Detection' mode?

Accepted Answer

Meraki MX IPS operates in two modes: Detection mode alerts on and logs traffic matching Snort-based Talos signatures without blocking it — useful for baselining and validating rule sets to avoid false-positive blocking; Protection mode actively drops or TCP-resets traffic that matches signatures, providing active threat prevention. Both modes use Cisco Talos threat intelligence signatures. Administrators typically start in Detection mode, review the generated alerts for false positives, then switch to Protection mode for active blocking. Both modes require the Advanced Security License (MX-SEC) on the MX appliance.

Question 9

A Meraki MX at a branch site has two WAN uplinks: a 100Mbps fiber connection and a 50Mbps cable connection. The administrator wants to route latency-sensitive VoIP traffic over fiber and route all other traffic using both links. Which MX SD-WAN feature enables this?

Accepted Answer

Meraki MX SD-WAN performance-based routing allows administrators to define traffic policies that select WAN uplinks based on real-time path quality metrics — latency, jitter, and packet loss. A performance profile for VoIP can be configured to prefer the fiber uplink (lower latency) and automatically failover to cable when fiber latency or jitter exceeds defined thresholds. General traffic uses the default load balancing or failover policy across both uplinks. The MX continuously monitors path quality using active probes and makes routing decisions without manual intervention. This is the core SD-WAN capability that replaces static policy-based routing.

Question 10

A Meraki MX must establish a site-to-site VPN to a non-Meraki firewall (Palo Alto Networks) at a partner site. What are the requirements and configuration approach on the MX side?

Accepted Answer

Meraki MX supports site-to-site VPN with non-Meraki peers via the Non-Meraki VPN peers configuration. The administrator provides: the peer's public static IP address (dynamic IP is not supported), a pre-shared key, the remote subnet(s) to route over the tunnel, and IKE parameters (IKEv1 or IKEv2, encryption, hashing). The partner firewall must be configured with matching IKE and IPsec parameters. AutoVPN is exclusive to Meraki-to-Meraki tunnels and uses cloud-based peer discovery. Non-Meraki VPN peers use standard IKE/IPsec negotiation requiring both sides to be statically configured.

Question 11

An MX administrator configures client VPN using L2TP over IPsec with Active Directory authentication. A remote user can connect to the VPN but can only access internal resources, not the internet. What MX client VPN setting controls this behavior?

Accepted Answer

Meraki MX client VPN supports two routing modes: Full tunnel (Send all traffic = enabled) routes all client traffic — both internal and internet-bound — through the VPN tunnel and out the MX's WAN uplink; this is why the user can access internal resources but internet traffic also traverses the VPN. Split tunnel mode only routes traffic destined for the configured internal subnets through the VPN, while internet traffic goes directly from the client's local ISP — allowing simultaneous VPN and local internet access. The 'Send all traffic' toggle in Dashboard controls this behavior. Split tunnel reduces VPN bandwidth consumption but may expose internet traffic to untrusted local networks.

Question 12

How is an access port configured on a Meraki MS switch in the Dashboard?

Accepted Answer

Meraki MS switches are fully cloud-managed — all port configuration is performed through the Dashboard, not via CLI or local status page. To configure an access port: Dashboard > Switch > Configure > Switch ports. Select the port(s), set Type to 'Access', set the Access VLAN to the desired VLAN ID (e.g., VLAN 10 for users), and optionally set a Voice VLAN for IP phones. Changes are pushed from the Dashboard to the switch in real time. Trunk ports are configured by setting Type to 'Trunk' and specifying the allowed VLANs. There is no SSH-based CLI management for standard Meraki MS configuration.

Question 13

A Meraki MS network has VLANs configured. An administrator adds VLAN 20 with subnet 192.168.20.0/24 and wants clients in VLAN 20 to use the MX as their default gateway. How is this configured?

Accepted Answer

In a typical Meraki combined network, inter-VLAN routing is handled by the MX security appliance, not the MS switch. VLAN configuration in Dashboard (Switch > Configure > VLANs) defines the VLAN ID, name, and subnet. The MX is configured with a subinterface or VLAN interface for each VLAN and acts as the Layer 3 gateway. Clients receive the MX's VLAN IP as their default gateway via DHCP (also served by MX). For networks without an MX (MS-only), some MS models support Layer 3 routing with SVIs, but in combined networks the MX is the routing engine.

Question 14

A Meraki MS administrator wants to aggregate two physical ports into a logical link for increased bandwidth to a server. Which protocol and Dashboard configuration achieve this?

Accepted Answer

Meraki MS supports Link Aggregation using LACP (IEEE 802.3ad) or static LAG. To configure a link aggregate in Dashboard: select the ports to be aggregated in Switch > Configure > Switch ports, and set the aggregation type to LACP (negotiated, preferred) or Static LAG (no negotiation). LACP provides dynamic negotiation and failure detection between the switch and the connected device. The connected server or upstream switch must also be configured for LACP. Meraki supports 2–8 ports per aggregate. PAgP is Cisco proprietary and not supported on Meraki MS; RSTP is the spanning tree protocol, not a LAG protocol.

Question 15

A Meraki MS network is connected to an upstream switch with legacy spanning tree. An administrator is concerned about loop prevention for access ports. What STP behavior does Meraki MS implement by default for access ports, and can it be manually disabled?

Accepted Answer

Meraki MS runs RSTP (Rapid Spanning Tree Protocol, IEEE 802.1w) as the default spanning tree protocol. For access ports — ports where no STP BPDUs are received — Meraki automatically treats them as edge ports (equivalent to PortFast), meaning they transition directly to the forwarding state without going through listening and learning states. This eliminates the 30-second convergence delay for end devices. BPDU Guard can be enabled on access ports to protect against accidental switch connections. Meraki does not expose full manual STP configuration per port but handles edge port detection automatically, which is the recommended behavior for access ports connected to end devices.

Question 16

An administrator needs to configure a corporate SSID that authenticates users against a RADIUS server for 802.1X authentication. Which security setting is used in Meraki Dashboard?

Accepted Answer

WPA2-Enterprise (802.1X) authentication requires a RADIUS server to authenticate individual users with credentials (username/password via EAP-PEAP, or certificates via EAP-TLS). In Meraki Dashboard: Wireless > Configure > SSIDs > Security = 'WPA2-Enterprise with my RADIUS server'. The administrator provides the RADIUS server IP address, the shared secret between the MR and RADIUS server, and the authentication port (default 1812). WPA2-Personal uses a static pre-shared key for all clients. WPA3-Personal uses SAE for stronger personal network security but is not the 802.1X enterprise authentication method.

Question 17

A Meraki MR RF profile is configured with band steering enabled. What does band steering do and why is it beneficial?

Accepted Answer

Band steering (also called 'prefer 5 GHz' in Meraki RF profiles) encourages dual-band clients to connect on the 5 GHz band rather than 2.4 GHz. It works by delaying or suppressing probe responses on 2.4 GHz for capable clients, nudging them to associate on 5 GHz where there are more non-overlapping channels, less interference from neighboring networks and non-Wi-Fi devices (microwave ovens, Bluetooth), and typically higher throughput. Single-band 2.4 GHz-only devices (legacy) are still served on 2.4 GHz. Band steering is enabled in the RF profile and applies across all APs using that profile.

Question 18

A Meraki MR access point is configured for a guest SSID using the 'Click-through' splash page type. A guest connects and is redirected to a web page before accessing the internet. What does the click-through splash page require from the guest?

Accepted Answer

The Meraki 'Click-through' splash page is the simplest captive portal type: it presents a customizable web page with an acknowledgment button (e.g., 'I agree to the terms of use') and grants internet access upon clicking. No credentials, social login, or sponsor approval are required. Other Meraki splash page types include: Sign-on (requires username/password against RADIUS, LDAP, or Meraki's built-in user management), Sponsored Guest (requires an internal sponsor to approve via email), and Facebook Wi-Fi (requires Facebook login). Click-through is appropriate for venues that need a simple acceptable-use policy acknowledgment without identity verification.

Question 19

Meraki Wireless Health shows that clients on a specific MR access point are failing at the 'DHCP' stage of connection. The Association and Authentication stages are succeeding. What does this indicate and what should be investigated?

Accepted Answer

Meraki Wireless Health tracks client connection stages: Association (L2 Wi-Fi join) → Authentication (WPA2 handshake or 802.1X) → DHCP (IP address lease) → DNS (name resolution). When Association and Authentication succeed but DHCP fails, the Wi-Fi connection is working correctly but the IP addressing infrastructure has a problem. The investigation should cover: Is the DHCP server reachable? Is the DHCP pool exhausted (all leases in use)? Is the correct VLAN tagged on the switch port connecting the AP to the network? Does the MX have a DHCP relay/helper address configured for the SSID's VLAN? Each of these can prevent DHCP offers from reaching the client.

Question 20

An administrator wants to prevent wireless clients on the corporate SSID from communicating directly with each other (e.g., preventing lateral movement between corporate laptops on Wi-Fi) while still allowing them to access wired resources. Which Meraki MR feature accomplishes this?

Accepted Answer

Client isolation on Meraki MR blocks Layer 2 traffic between wireless clients associated to the same SSID — a laptop cannot directly ping or connect to another laptop on the same Wi-Fi segment. This is implemented by the AP proxy-ARPing and not forwarding client-to-client traffic at Layer 2. Wired-to-wireless and wireless-to-internet traffic is unaffected. Client isolation is a critical security control for corporate wireless networks to prevent lateral movement between compromised or infected wireless clients. It is configured per SSID in Dashboard: Wireless > Configure > SSIDs > Access control > Client isolation.

Question 21

A facilities team wants to deploy Meraki MT sensors to monitor temperature and humidity in server rooms. Which MT sensor model is designed for this use case?

Accepted Answer

The Meraki MT10 is a combined temperature and humidity sensor, making it purpose-built for server room environmental monitoring. Server rooms require temperature monitoring (typically maintained below 27°C/80°F) and humidity monitoring (typically 45–55% RH) to prevent equipment damage and maintain warranty conditions. MT20 is a door/window contact sensor for physical security. MT14 monitors air quality parameters (CO2 concentration and PM2.5 particulate matter) for office environment monitoring. MT40 is a power monitor that measures electrical consumption for energy management. All MT sensors communicate over Bluetooth to Meraki MR access points, which relay data to the cloud.

Question 22

A data center manager wants to receive an alert if server room temperature exceeds 30°C for more than 5 minutes. How is this configured in the Meraki Dashboard for MT sensors?

Accepted Answer

MT sensor alerting is configured entirely within the Meraki Dashboard under Sensors > Alerts. An alert profile specifies: the MT sensor type (MT10 for temperature/humidity), the metric (Temperature), the trigger condition (above 30°C), the sustained duration (5 minutes — so brief spikes do not trigger false alerts), and the notification channel (email to specified addresses, SMS, or webhook to an external system like PagerDuty or Slack). Alert profiles can be applied to individual sensors or sensor groups. The MT sensor itself has no physical configuration interface — all configuration is cloud-managed through the Dashboard.

Question 23

A Meraki MV camera is configured with motion-based video retention. How does this differ from continuous recording, and what is the primary operational benefit?

Accepted Answer

Meraki MV cameras store video locally on internal solid-state storage (no external NVR required). Continuous recording writes video 24/7 until storage is full, then overwrites oldest footage. Motion-based retention records video segments only when the camera's motion detection algorithm detects movement, dramatically reducing storage utilization. This extends the effective retention period — instead of 7 days of continuous video, motion-only recording on a low-traffic camera might retain 30+ days of event footage within the same storage capacity. Motion events are indexed and searchable in the Dashboard video timeline. The tradeoff is that very subtle motion might not be captured if the sensitivity threshold is set too high.

Question 24

A retail operations team wants to use Meraki MV Sense to count the number of people entering their store per hour for staffing optimization. How does MV Sense expose this data and what protocol is used for real-time streaming?

Accepted Answer

Meraki MV Sense is an on-camera analytics capability that uses the MV camera's built-in processor to run computer vision algorithms for object detection — classifying people, vehicles, and other objects without sending raw video to a cloud server. People count and zone occupancy data is accessible in two ways: (1) via the Meraki Dashboard API for historical analytics queries, and (2) via MQTT — the MV camera acts as an MQTT publisher, pushing real-time detection events to a configured MQTT broker so that applications can subscribe to live people count streams. MQTT is the industry-standard lightweight protocol for IoT real-time data streaming. MV Sense processes video locally on the camera, preserving privacy by not sending raw footage externally.

Question 25

A security team needs to share a specific 2-minute video clip from a Meraki MV camera with an external law enforcement agency without giving them Dashboard access. What is the correct procedure?

Accepted Answer

Meraki MV provides a video export and sharing feature for exactly this use case. From the Dashboard video viewer, an administrator can select a specific time range, then either: (1) Generate a time-limited shareable URL that allows the recipient to view the clip in a browser without Dashboard credentials (the link expires after a configurable period for security); or (2) Download the video clip as an MP4 file for local storage and sharing. This allows secure sharing with external parties — including law enforcement, auditors, or HR — without creating Dashboard accounts or exposing other network management capabilities. The local email notification option can also be configured to alert administrators when video links are shared.

— Cisco Meraki Solutions Specialist