500-220 Engineering Cisco Meraki Solutions Exam Topics and Questions

Meraki's defining characteristic is that everything meaningful happens in the cloud, and this topic tests whether you understand what that actually means for architecture, operations, and control. Before you can design or troubleshoot anything, you need to know how the dashboard reaches devices, how organisations are structured, and where licensing fits in. Get these foundations wrong and every subsequent topic becomes harder to reason about.

– Cloud architecture and access

The Meraki cloud is not just a management plane bolted onto traditional hardware. Data traffic and management traffic take different paths, and knowing which path carries what is the kind of distinction the exam will probe. Dashboard access covers both the web interface and direct device access methods, including the local status page and API endpoints. You need to be clear on what each method can and cannot do, because the exam will present a scenario where one method is appropriate and the others are not. Authentication, role-based access, and which settings require a specific access level are all in scope here.

– Organisational structure and segmentation

Meraki uses a hierarchy of organisations, networks, and templates, and the segmentation decisions made at each level have downstream consequences that the exam likes to exploit. Permissions are assigned at the organisation level, the network level, or both, and the difference matters when a question involves delegating access to a third party or isolating one customer from another in a shared environment. Templates are the mechanism for scaling configuration across many networks, and understanding what can be bound, what cannot, and what happens when you unbind is a reliable source of exam difficulty.

– Licensing and deployment workflows

Meraki co-termination licensing is the feature most candidates underestimate. Adding a device to an existing organisation shifts the expiry date of every licence in that organisation, and the exam will test whether you can predict the outcome of that addition before it happens. Renewals and licence stacking follow rules that are specific to Meraki and do not map cleanly onto other Cisco licensing models, so prior Cisco experience can mislead you here. Deployment workflows, including claim, configuration, and the order in which steps are performed, round out this topic. The exam will distinguish between workflows that are functionally similar but differ in when the device comes online or when configuration is applied.

How Cisco Meraki Cloud Management is tested

At 15% of the exam, this topic accounts for a meaningful portion of your score, and items tend to be scenario-based rather than recall-based. You will not be asked to recite architecture facts in isolation. Instead, you will be given a situation, such as a new device being claimed into an organisation with an existing licence pool, and asked what happens next or what the right action is.

The traps are consistent. Candidates confuse organisation-level and network-level permissions and choose an access model that is either too broad or too narrow for the scenario. They also misread co-termination outcomes, particularly when a device with a longer licence term is added to a pool with a shorter one. The exam rewards candidates who can work through the licensing arithmetic mentally and who know the precise boundaries of each dashboard access method. Items on deployment workflows reward sequential thinking: what must be done before what, and what the system does automatically versus what requires a manual step.

With cloud management as your foundation, the exam shifts to the hardest-weighted topic on the syllabus. Design questions do not have a single obvious answer. They ask you to weigh trade-offs: availability against complexity, security against user friction, scalability against operational overhead. Every sub-topic here demands that you know not just how a feature works but when to choose it and what it costs you.

– SD-WAN, VPN, and routing architecture

Auto VPN is one of Meraki's most-tested features because it abstracts a lot of complexity but still requires you to understand what is happening underneath. Hub-and-spoke versus full-mesh is the starting point, but the exam goes further: how many hubs, what happens when a hub fails, and how traffic is routed when a spoke has multiple uplinks. The virtual MX (vMX) adds a cloud-hosted hub option, and its deployment considerations, including the cloud provider integration and the absence of physical WAN ports, are a distinct area of difficulty. Dynamic path selection sits on top of this: you need to design policies that steer traffic based on performance thresholds and understand what happens when no path meets the policy criteria. Routing design covers both the redistribution of routes between Auto VPN and local subnets and the interaction between static routes and dynamic protocols in mixed environments.

– Enterprise network services: availability, QoS, and security

This group covers five tightly related sub-topics that the exam often combines into a single scenario. Redundant networks and high availability require you to know warm spare configuration on the MX, failover timing, and the conditions under which failover is triggered. QoS for voice and video on Meraki switching and wireless is not just about marking traffic: you need to design a strategy that works end-to-end across the MX, MS, and MR, because a mark applied at one layer can be overwritten at another. Layer 2 security covers features such as dynamic ARP inspection and DHCP snooping on the MS, and the exam will ask you to place them correctly in a design. Firewall and IPS rules on both the MX and MR are in scope, including the order of evaluation and the difference between layer 3 and layer 7 rules. Network access control brings 802.1X, RADIUS, and Meraki-specific integrations together, and design questions here often hinge on what happens to a client that fails authentication.

– Enterprise wireless design

Wireless design questions test your ability to make decisions before a single access point is deployed. High-density environments require channel planning, power settings, and client steering choices that differ from a standard office deployment. The exam will give you a constraint, such as a venue with thousands of concurrent clients, and ask which RF profile settings or band-steering configuration achieves the stated goal. Enterprise SSID design covers authentication methods, VLAN assignment, and the integration of MR with external identity sources. Guest access introduces a separate set of considerations: isolation, captive portal options, and bandwidth limits. The exam distinguishes between a guest network that is adequately isolated and one that is not, and the difference often comes down to a single configuration choice.

– Endpoint and application management

Systems Manager (SM) endpoint management is frequently underweighted by candidates who focus on network infrastructure. The exam expects you to compare enrollment methods, specifically supervised enrollment for Apple devices and device owner mode for Android, and to understand what each method enables and restricts. Supervised enrollment unlocks a set of management capabilities that device owner mode does not, and the exam will present a business requirement and ask which enrollment type satisfies it. Application deployment covers the difference between pushing an app silently versus requiring user interaction, volume purchasing, and the scoping of app deployments to device groups. The design question here is usually about matching the deployment method to the use case, not about the mechanics of the dashboard configuration.

How Design is tested

At 30% of the exam, this is the topic where the exam is won or lost. Items are almost exclusively scenario-based and frequently multi-layered: a single question may combine a VPN topology requirement, a QoS constraint, and a security policy, and ask you to identify the design that satisfies all three.

Candidates lose marks in two consistent ways. The first is choosing a design that works in isolation but fails when the full scenario is considered, for example selecting a routing approach that handles normal traffic correctly but breaks under a hub failover. The second is confusing what a feature does by default with what it does when explicitly configured. The exam rewards candidates who can read a business or technical requirement and map it to a specific Meraki design decision, not candidates who can describe features in the abstract.

Items on wireless design reward RF planning logic over feature knowledge. Items on endpoint management reward knowing the precise capability boundary between enrollment types. In both cases, the strongest option in any item is the one that satisfies the stated requirement without introducing an unnecessary trade-off.

Design decisions only matter if you can implement them correctly, and this topic tests exactly that. The shift from Design to Implementation is a shift from 'what should be built' to 'how to build it in the dashboard.' At 25%, this is the second-largest topic on the exam, and it spans six device families: MX, MS, MR, SM, MV, and MI. Depth is expected across all of them, not just the ones you use most in your day job.

– MX security appliance configuration

MX configuration covers more ground than most candidates expect. SVIs, static routes, and dynamic routing are the baseline, but the exam goes into Auto VPN configuration specifics: hub designation, subnet advertisement, and the interaction between VPN and local routing tables. Traffic shaping and SD-WAN configuration require you to know the difference between a performance class, an uplink policy, and a traffic shaping rule, and to apply the right one to a given scenario. Threat protection covers Advanced Malware Protection and IDS/IPS settings, including the difference between detection and prevention modes. Content filtering rules involve both category-based and URL-based filtering, and the order in which rules are evaluated matters. Access policies and 802.1X on the MX round out this sub-topic, covering wired client authentication on MX switch ports where applicable.

– MS switch configuration

MS switch configuration overlaps with MX in some areas but has its own distinct scope. SVIs and routing on the MS are available only on certain models, and the exam expects you to know what is configurable versus what must be handled upstream. QoS on Meraki switching networks uses DSCP and CoS markings, and the exam will ask you to configure or interpret a QoS policy that spans access and distribution layers. Access policies and 802.1X on the MS mirror the MX topic in concept but differ in dashboard location and available options. Replicating a switch configuration is a Meraki-specific workflow that uses the dashboard's clone or template features, and the exam will test whether you know the scope of what is replicated and what must be configured independently on each device.

– MR wireless access point configuration

MR configuration questions are among the most detailed on the exam. SSID configuration for enterprise deployments covers authentication methods, VLAN tagging, and band selection. BYOD SSIDs introduce additional considerations around certificate-based authentication and device onboarding. Traffic shaping on MR applies per-SSID bandwidth limits and application-aware policies, and the exam distinguishes between a limit that applies per client and one that applies to the SSID as a whole. RF profiles control transmit power, channel width, and minimum bitrate settings, and the exam will ask you to select or modify a profile to achieve a specific outcome in a described environment. Air Marshal is Meraki's wireless intrusion detection and prevention system: the exam tests configuration of containment policies and the distinction between a rogue AP and a neighbouring AP.

– SM, MV, and MI configuration

Systems Manager configuration covers the three areas most likely to appear on the exam. Management profiles define what is pushed to a device and in what scope: the exam will ask you to build or interpret a profile that satisfies a stated policy requirement. Security policies on SM cover device compliance rules, such as passcode enforcement and encryption requirements, and what happens to a non-compliant device. Sentry ties SM to the network: a device that falls out of compliance can be blocked from the SSID or VLAN automatically, and the exam tests the configuration path that enables this.

MV camera configuration is narrower in scope. Video retention settings and motion-based alerting are the two areas tested. Retention involves both local storage on the camera and cloud archive, and the exam will ask you to configure or interpret a retention policy against a stated requirement. MI application assurance covers configuring standard application monitoring and setting thresholds that trigger alerts, which connects directly to the troubleshooting topic that follows.

How Implementation is tested

Implementation items are task-oriented. You are given a stated requirement and asked which configuration achieves it, or you are given a partial configuration and asked what is missing or wrong. The exam rewards candidates who know the dashboard deeply enough to distinguish between two options that look similar but produce different outcomes.

The most common trap is confusing a feature that exists on one device family with a feature that has a similar name on another. Traffic shaping on MX and traffic shaping on MR share terminology but are configured differently and have different scopes. Candidates who do not separate these clearly lose marks on both sub-topics.

A second consistent trap is the scope of replication and template binding. The exam will present a scenario where a configuration change is made at the template level and ask which devices are affected. Candidates who have not worked through this logic carefully will choose an option that is either too broad or too narrow. Items on SM Sentry reward knowing the precise trigger condition and the network-side response, not just the general concept of policy enforcement.

After implementation, the work shifts to keeping the network healthy and fixing it when it is not. This topic shares the top weight with Design, which tells you how seriously Cisco expects candidates to understand operational workflows in Meraki. The dashboard is the primary tool here, and the exam tests whether you know which part of it to use for which problem, not just that the dashboard exists.

– Monitoring, reporting, and the dashboard API

Meraki's monitoring surface is broader than a single pane. Alerts can be delivered through the dashboard, SNMP, Syslog, and NetFlow, and the exam will ask you to select the right mechanism for a given operational requirement. A question might describe a third-party SIEM that needs event data: you need to know which delivery method provides the right data in the right format. Logging and reporting in the dashboard covers event logs, summary reports, and the client traffic view, and the exam distinguishes between information that is available in real time and information that requires a report to be generated.

The dashboard API sub-topic is scoped to monitoring and maintenance use cases. You are not expected to write code, but you are expected to understand what the API enables, what authentication it requires, and what kinds of operational tasks, such as retrieving device status or pushing a configuration change at scale, are within its scope.

– Firmware upgrades and network-wide maintenance

Firmware upgrades in Meraki are managed centrally, but the details matter on the exam. You need to know the difference between a scheduled upgrade, a staged upgrade, and an immediate upgrade, and what each option means for network availability during the maintenance window. The exam will describe a scenario with a constraint, such as a network that cannot tolerate simultaneous reboots across all switches, and ask which upgrade approach satisfies that constraint. The interaction between firmware versions across device families in the same network is also in scope: Meraki occasionally introduces compatibility requirements between MX and MS firmware versions, and the exam expects you to recognise when a version mismatch could cause a problem.

– Troubleshooting Enterprise networks

This is the broadest and most operationally demanding group in the topic. Layer 2 troubleshooting using the dashboard covers spanning tree topology, port status, and MAC address table information available through the dashboard's switch tools. Layer 3 troubleshooting covers routing table inspection, ping and traceroute from the dashboard, and VPN tunnel status. Wireless client connectivity troubleshooting uses the client detail view, event log, and RF spectrum data to isolate whether a problem is authentication-related, RF-related, or policy-related.

Device local status pages provide a fallback when dashboard connectivity is lost, and the exam tests what information is available there versus what requires a dashboard connection. Security Center surfaces threat events from IDS/IPS and AMP, and the exam will ask you to interpret an event and identify the appropriate response. Meraki Insight provides application performance visibility, and items in this area reward knowing how to distinguish a WAN path problem from an application server problem using the data Insight presents.

How Monitoring and Troubleshooting is tested

At 30%, this topic demands the same attention as Design, but the item style is different. Design items ask you to build something. Monitoring and troubleshooting items ask you to interpret something: a dashboard view, an event log, a tunnel status, or an alert. The exam rewards candidates who can read a described output and identify the fault or the next diagnostic step.

The traps here are about tool selection and data interpretation. Candidates lose marks by choosing a troubleshooting tool that would work eventually but is not the most direct path to the answer in the described scenario. The exam consistently rewards the dashboard-native approach over a workaround. A second trap is misreading what the local status page can show without cloud connectivity: candidates who assume full dashboard capability is always available will choose options that are not possible in a cloud-disconnected state.

Items on Meraki Insight reward distinguishing between performance problems caused by the WAN path and those caused by the application endpoint. The data Insight presents makes that distinction possible, and the exam tests whether you can make it.