• Home
• Cisco Exams
• 500-220 - Cisco Meraki Solutions Specialist

500-220 Cisco Practice Test Questions and Exam Dumps

Question 1:

What are two possible reasons why an organization might be marked as "Out of License"? (Choose two.)

A. licenses that are in the wrong network
B. more hardware devices than device licenses
C. expired device license
D. licenses that do not match the serial numbers in the organization
E. MR licenses that do not match the MR models in the organization

Correct Answers: B and C

Explanation:

In cloud-managed platforms like Cisco Meraki, licensing is enforced to ensure that each device within an organization is covered under a valid and matching license. When licensing requirements are not met, the organization may become “Out of License,” potentially affecting device functionality or dashboard access. There are several key conditions that can lead to this state, and understanding them helps ensure ongoing compliance and service continuity.

One primary reason is having more hardware devices than available device licenses, which is why option B is correct. Each physical device within a Meraki network—whether it's a switch, access point, or security appliance—requires a corresponding license. If a new device is added to the dashboard but the license count is not increased accordingly, the system detects this mismatch and may label the organization as "Out of License." This ensures organizations can’t operate additional hardware beyond what has been paid for and licensed.

Another major cause is expired licenses, making option C another correct answer. Meraki licenses are time-bound, and if a license reaches its expiration date without renewal, the associated device is no longer considered licensed. This can immediately place the organization in an “Out of License” status. When this occurs, Meraki typically provides a grace period to correct the issue, but failure to act may result in suspension of services or limited functionality until compliance is restored.

Looking at the incorrect options:

Option A, "licenses that are in the wrong network," is misleading. Meraki licenses are typically associated at the organizational level, not specifically at the network level within an organization. While poor organization of networks may lead to confusion, it won’t result in an “Out of License” state as long as the total number of licenses matches the total devices.

Option D, "licenses that do not match the serial numbers in the organization," is inaccurate because Meraki licenses are not tied to specific serial numbers. Instead, licenses are applied to the organization, and devices are matched by model type and quantity, not by individual serial number. As long as the correct number of licenses is applied for the correct model types, the actual serial numbers do not need to match anything specific in the licensing structure.

Option E, "MR licenses that do not match the MR models in the organization," is also incorrect. Meraki uses a co-termination licensing model, where license durations are averaged across all devices. While certain legacy licenses may be specific to device types, in most current environments, licenses are pooled. If the MR license is valid for the general MR product line, it can typically be used across various MR models. Mismatched models would not independently trigger an “Out of License” state unless there is a quantity shortfall or expiration.

In conclusion, the two most common and legitimate reasons an organization would be flagged as “Out of License” are having more devices than licenses and having expired licenses. These conditions directly impact the ability of the Meraki dashboard to validate proper licensing coverage and ensure fair usage of the service.

Question 2:

In an organization using the Co-Termination licensing model, which two actions can apply licenses to the organization? (Choose two.)

A. Renew the Dashboard license
B. License a network
C. License more devices
D. Call Meraki support
E. Wait for the devices to auto-renew

Correct Answers: A and C

Explanation:

Cisco Meraki’s Co-Termination licensing model is designed to simplify license management by averaging the license durations across all devices in an organization and assigning a single, unified expiration date. This eliminates the complexity of tracking individual license terms for each device. Within this model, there are specific ways to apply or extend licensing for continued operation and compliance.

The first correct method is to renew the Dashboard license, making option A correct. When a license term is nearing its expiration, organizations must proactively renew the Dashboard license, which serves as the central point of management for all Meraki devices. This process refreshes the co-termination expiration date and ensures that the entire organization retains full operational access. Renewing the Dashboard license effectively adds time to the organization’s pooled license account, thus resetting the expiration clock for all managed devices.

The second correct method is to license more devices, which corresponds to option C. Adding new devices to a Meraki organization requires purchasing and applying new licenses for them. When these licenses are applied under the co-termination model, the system automatically recalculates the organization’s new expiration date by factoring in the number of devices and the time duration of the newly added licenses. This keeps licensing synchronized and ensures continued compliance. This method applies whether you're expanding your network by adding switches, access points, or firewalls.

Now let’s explore why the other options are incorrect:

Option B, "License a network," is incorrect because licensing is not managed at the network level in a Meraki organization. All licensing is applied at the organizational level. Even if a new network (such as a separate branch) is created within the Meraki dashboard, the license pool covers all devices across all networks. So you don’t apply licenses to networks specifically, but rather to the devices within the organization.

Option D, "Call Meraki support," is not a valid method for applying licenses. While Meraki support can assist with troubleshooting, merging organizations, or transferring licenses between organizations (when necessary), simply calling support does not itself apply or activate a license. The organization must still go through the proper channel—typically the Meraki dashboard or sales portal—to purchase and apply a license key.

Option E, "Wait for the devices to auto-renew," is not accurate because Meraki licenses do not automatically renew. The licensing model requires manual renewal or purchase through an authorized reseller. Auto-renewal is not currently supported. Waiting without action could result in the organization becoming out of license, which can affect access to configuration, visibility, or functionality.

In conclusion, applying licenses in a Co-Termination model revolves around renewing the organization’s license pool and ensuring new devices are properly licensed before deployment. These actions keep the unified license expiration date up to date and help organizations maintain operational continuity.

Question 3:

How does a Meraki device behave if cloud connectivity is temporarily lost?

A. The offline device continues to run with its last known configuration until cloud connectivity is restored.
B. The offline device reboots every 5 minutes until connection is restored.
C. The offline device stops passing traffic.
D. The offline device tries to form a connection with a local backup server.

Correct Answer: A

Explanation:

When a Meraki device loses connectivity to the cloud, it does not immediately shut down or cease operations. Instead, it is designed to continue functioning locally based on the last known configuration stored on the device. This resilience is a core design principle of Cisco Meraki’s cloud-managed architecture, ensuring minimal disruption in network operations during temporary internet outages.

Option A correctly states that the offline device continues to run with its most recent settings. Meraki devices are engineered to cache the current configuration so that in the event of a loss in cloud connectivity—whether due to an ISP issue, routing problem, or some other internet disruption—the device can continue routing, switching, and applying security rules as previously configured.

Option B is incorrect because Meraki devices do not reboot periodically in an effort to reestablish cloud connectivity. Such behavior would lead to unnecessary downtime and instability, which goes against the product’s goal of reliability and uninterrupted service.

Option C is also incorrect. The device does not stop passing traffic. In fact, most of the core networking features—including DHCP, NAT, firewall policies, and LAN/WLAN access—continue functioning normally. The main limitations during cloud disconnection involve things like the inability to make real-time configuration changes, view live statistics, or receive alerts via the dashboard.

Option D suggests that the device attempts to connect to a local backup server, but Meraki devices do not include this as a default behavior. The architecture relies on the Meraki cloud as the centralized management and monitoring platform. While some administrators might set up local failover systems or monitoring servers for custom implementations, this is outside standard Meraki device behavior and not part of the default functionality.

Therefore, in practical terms, a Meraki device remains functional during a cloud outage by maintaining local control and enforcing pre-configured policies. Once internet connectivity is restored, the device automatically reconnects to the cloud dashboard and resumes syncing logs, status updates, and configuration changes if any are pending. This approach balances centralized management with local autonomy, which is a significant advantage of cloud-managed networks.

Question 4:

Which two types of organization-level permissions can be assigned to users within the Cisco Meraki dashboard to control access across all networks? (Choose two.)

A. Full
B. Read-only
C. Monitor-only
D. Write
E. Write-only

Correct Answer: A and B

Explanation:

Cisco Meraki provides a centralized dashboard that allows administrators to manage multiple networks within an organization. To maintain appropriate levels of access and control, the platform defines specific organization-level permissions that govern what users can view or modify. These permissions are essential for ensuring secure operations and for assigning responsibilities based on roles within the IT team or broader business structure.

The two correct organization-level permission types are Full and Read-only, which correspond to options A and B.

Option A, Full, is the highest level of access at the organization level. A user with Full permissions has complete control over every network under the organization, including the ability to make configuration changes, add or remove networks, invite or delete users, and manage licenses and settings. This type of access is typically granted to IT administrators who need full visibility and control over the infrastructure.

Option B, Read-only, allows a user to view settings, reports, and data across all networks within the organization but does not permit any changes to configurations or user management. This access level is appropriate for roles such as auditors, business leaders, or support staff who need visibility into the network's performance or security posture without having the ability to make changes that could disrupt services.

Option C, Monitor-only, may seem similar to Read-only, but it is actually a network-level permission, not an organization-level one. Monitor-only permissions apply to individual networks within an organization, offering limited functionality that includes viewing configurations and some statistics but restricting changes even more tightly than Read-only in some contexts.

Option D, Write, is not recognized as a standalone organization-level permission type in the Meraki system. The ability to write or modify configurations is included in Full access. Meraki does not offer a separate “Write” role distinct from Full.

Option E, Write-only, is not a valid or practical permission type in any administrative model. Allowing a user to make changes without the ability to view existing settings would lead to misconfiguration and security issues. Meraki does not provide or support this kind of access role.

Thus, Full and Read-only are the only two legitimate organization-level permission types, ensuring users can be appropriately empowered or restricted based on their role and responsibility.

Question 5

When using SAML for single sign-on (SSO) with the Meraki Dashboard, what is the role of the Dashboard as the service provider in the authentication process?

A. The Dashboard generates the SAML request.
B. The Dashboard provides user access credentials.
C. The Dashboard parses the SAML request and authenticates users.
D. The Dashboard generates the SAML response.

Correct Answer: C

Explanation:

SAML (Security Assertion Markup Language) is a widely used protocol that allows for secure single sign-on (SSO) across services. When a user tries to log in to a service using SAML-based SSO, two key entities are involved: the Identity Provider (IdP) and the Service Provider (SP). In the context of Cisco Meraki, the Meraki Dashboard acts as the Service Provider (SP), while an external identity system such as Azure AD, Okta, or ADFS functions as the Identity Provider (IdP).

The process begins when a user attempts to log in to the Meraki Dashboard. The Dashboard, acting as the Service Provider, generates a SAML authentication request and redirects the user to the Identity Provider for authentication. However, it is not the one responsible for generating the SAML response—this responsibility lies solely with the Identity Provider.

Once the user authenticates successfully at the IdP, the IdP sends a SAML response back to the Meraki Dashboard. At this point, the Dashboard’s role is to parse the SAML response and verify its contents, including the user's identity and group membership. This is what is meant by the Dashboard parsing the SAML request and authenticating users—in other words, validating the received response and allowing or denying access based on the roles and permissions mapped to the user.

Let’s review each option in more detail:

• A (The Dashboard generates the SAML request): This is incorrect. While the Dashboard initiates the SAML authentication process, the actual request is typically generated and sent via browser redirection. The key role of the Dashboard is not in creating or managing this request but in handling the response.

• B (The Dashboard provides user access credentials): This is incorrect. The Meraki Dashboard never provides or manages access credentials in SAML SSO. That responsibility belongs entirely to the Identity Provider.

• C (The Dashboard parses the SAML request and authenticates users): This is correct. The Dashboard receives the SAML response from the IdP, parses its contents (such as assertions about the user), and makes access decisions based on predefined policies and user mappings. It doesn’t handle credentials but does determine access rights from the validated response.

• D (The Dashboard generates the SAML response): This is incorrect. The SAML response is generated by the Identity Provider, not the Service Provider. The Dashboard only receives and processes this response.

Therefore, as a Service Provider in the SAML SSO framework, the Meraki Dashboard’s correct role is to parse the SAML response and determine whether the user should be authenticated and granted access. This role ensures secure delegation of authentication while maintaining centralized identity control with the IdP.

Question 6:

A customer plans to host their corporate application servers in Microsoft Azure. What benefit does using a Meraki vMX appliance provide compared to directly connecting to Azure via a standard VPN?

A. malware protection
B. SD-WAN
C. next-generation firewall
D. intrusion prevention

Correct Answer: B

Explanation:

When a customer hosts their corporate applications in Microsoft Azure, they typically need secure connectivity between their on-premises network and the cloud environment. While a traditional VPN connection can provide basic encrypted communication between sites, using a Meraki vMX (virtual MX) appliance introduces advanced capabilities that go beyond what a basic VPN tunnel can offer.

The vMX appliance is a virtual security and SD-WAN device specifically designed for deployment in cloud environments like Microsoft Azure, Amazon Web Services (AWS), or Google Cloud Platform (GCP). Its primary function is to extend the Meraki SD-WAN fabric into the cloud.

The correct benefit in this case is B: SD-WAN.

Let’s explore why:

SD-WAN (Software-Defined Wide Area Network) is a technology that allows intelligent path selection, application-aware routing, performance monitoring, and dynamic failover. When a vMX is deployed in Azure, it behaves just like a physical Meraki MX appliance in an on-premises network. It becomes a full participant in the Meraki SD-WAN architecture, offering benefits such as:

• Seamless integration with other MX devices in the organization

• Simplified cloud-to-site and site-to-site connectivity

• Dynamic path optimization

• WAN performance analytics

• Centralized cloud-based management through the Meraki Dashboard

In contrast, a standard VPN connection from a physical firewall or router to Azure may provide encryption and tunnel establishment but lacks the intelligent path selection, auto-VPN capabilities, and centralized management features of Meraki’s SD-WAN solution.

Let’s consider why the other options are incorrect:

• A (malware protection): While Meraki MX appliances support Threat Protection, including anti-malware (via Cisco AMP), the vMX deployed in Azure does not support full UTM (Unified Threat Management) capabilities like malware scanning. It’s designed mainly for SD-WAN and VPN functionalities, not deep packet inspection or malware detection.

• C (next-generation firewall): The vMX does not offer a complete NGFW feature set in the cloud. Traditional MX appliances have firewall features, but the vMX is limited in terms of deep security inspection when compared to a full physical MX appliance.

• D (intrusion prevention): Similar to malware protection, IPS/IDS capabilities are tied to physical MX appliances that support Snort-based intrusion detection. The vMX appliance lacks this functionality in cloud environments like Azure.

In summary, the primary advantage of using a Meraki vMX in Azure is that it allows the customer to extend their SD-WAN fabric into the cloud. This enables centralized management, application-aware routing, intelligent path selection, and robust connectivity with other Meraki-managed sites. These capabilities go far beyond what a basic VPN setup provides, making SD-WAN the key differentiator.

Question 7:

Which of the following describes a key characteristic of distributed Layer 3 roaming in a Cisco Meraki wireless deployment?

A. An MX Security Appliance is not required as a concentrator.
B. An MX Security Appliance is required as a concentrator.
C. All wireless client traffic can be split-tunneled.
D. All wireless client traffic is tunneled.

Correct Answer: A

Explanation:

In Cisco Meraki wireless networks, Layer 3 roaming allows wireless clients to maintain seamless connectivity when moving across access points (APs) in different subnets. This is crucial in environments like campuses or large office buildings where different floors or areas use different VLANs or IP address spaces.

There are three main roaming options in Meraki:

1. Bridge mode (no roaming)

2. Layer 3 roaming

3. Layer 3 roaming with a concentrator

Each mode addresses different use cases depending on the network topology and requirements.

Distributed Layer 3 roaming—often referred to simply as Layer 3 roaming—is a method where Meraki APs manage client roaming internally without the need for a central concentrator, such as an MX Security Appliance. This model allows clients to keep their IP address while moving between APs on different subnets. The roaming is handled in a distributed fashion directly between the APs, and no traffic tunneling to a centralized appliance is required.

This leads us to Option A, which states that an MX Security Appliance is not required as a concentrator. This is the correct answer because distributed Layer 3 roaming operates independently of the MX and enables local switching and routing without sending all client traffic to a central point. It is more efficient for many enterprise use cases where minimizing latency and avoiding centralized bottlenecks is important.

Let’s examine why the other options are incorrect:

• B (An MX Security Appliance is required as a concentrator): This describes Layer 3 roaming with a concentrator, not the distributed model. In that scenario, the MX appliance acts as a central hub where all client traffic is tunneled, typically used for centralized policy enforcement or traffic inspection.

• C (All wireless client traffic can be split-tunneled): This refers to VPN tunnel behavior (e.g., VPN split tunneling), not specifically Layer 3 roaming. Split tunneling allows some traffic to go directly to the internet while sensitive data goes through a VPN. It is unrelated to how Layer 3 roaming is implemented.

• D (All wireless client traffic is tunneled): Again, this applies to Layer 3 roaming with a concentrator, not distributed roaming. In the distributed model, traffic is not tunneled; it is switched and routed locally by the access points.

In summary, the defining feature of distributed Layer 3 roaming is that it enables roaming across subnets without requiring a centralized controller or security appliance. This enhances performance, simplifies design, and reduces single points of failure, making Option A the correct choice.