Juniper JN0-460 JNCIS-MistAI-Wired Exam Practice Test

Juniper Mist AI for Wired uses group-based policy (GBP) to enforce segmentation within a single VRF, without requiring separate VRFs per user group. GBP tags classify endpoints logically (e.g., employees, guests, IoT devices) and enforce security rules across the EVPN-VXLAN fabric.

“Group-Based Policy (GBP) provides scalable segmentation by assigning tags to endpoints based on attributes such as user type, role, or device type. These GBP tags are then used in policies to control communication between groups.”

Option A is inefficient: assigning unique tags per endpoint is not scalable.

Option C is incorrect: GBP is identity-based segmentation, not location-based.

Option D is incorrect: assigning a single tag defeats the purpose of segmentation.

Option B is correct: the best practice is to assign GBP tags based on endpoint type (e.g., servers, staff, IoT, guests), which then drives policy enforcement.

Syslogis the standard method for exporting Mist AI event and telemetry messages to third-party collectors.

It supports both UDP and TCP delivery for centralized log correlation.

According to Juniper Mist documentation, the term "Adopting a Switch" specifically refers to the process of bringing an existing, already-configured switch—often termed a brownfield device—under the management of the Juniper Mist cloud. This is distinct from the "claiming" process, which is reserved for greenfield environments where new, factory-default switches are added using a QR code or activation code.

In a brownfield scenario, the switch is typically already in production or has a pre-existing local configuration that must be preserved or integrated into the Mist AI-driven dashboard. To adopt such a switch, the administrator must manually interact with the switch's Command Line Interface (CLI). The Mist portal provides a unique adoption command—a string of Junos OS configuration—that includes the specific URL for the Mist cloud and the organization’s unique registration token. Once this command is pasted into the switch's CLI and committed, the switch initiates an outbound connection to the Mist cloud via TCP port 2200 or 443.

Upon successful connection, the switch's status changes from "Unassigned" to "Connected" in the Mist dashboard. This transition allows the Mist AI engine to begin collecting telemetry, monitoring Service Level Expectations (SLEs), and performing automated troubleshooting. While the adoption process allows for "monitoring only" mode to avoid disrupting existing services, it is the fundamental first step for transitioning legacy Juniper infrastructure into a modern, cloud-managed Wired Assurance environment. This workflow is essential for organizations looking to leverage Marvis AI and automated operations without having to factory-reset their entire existing network.

Juniper Mist is built on a fully open andRESTful API architecture, allowing programmatic access to all functions.

Administrators and developers can automate switch provisioning, monitoring, and troubleshooting directly via the REST API.

This open design supports JSON data formatting and HTTPS authentication, ensuring secure integration with external systems.

Marvis, the AI-driven virtual network assistant in Mist, provides real-time troubleshooting insights for both wired and wireless devices.

When used withWired Assurance, certain actions require Juniper EX or QFX switches for telemetry collection.

Two of these wired-specific actions are:

Bad Cable Detection– triggered when electrical faults or poor cable quality are observed through LLDP or physical diagnostics.

Abrownfield adoptionin Mist AI refers to onboarding existing Juniper switches (with existing configurations) into the Mist Cloud for management and monitoring. For the switch to connect successfully, it must be able to reach Mist Cloud services usingDNSandInternet connectivity.

“To onboard existing (brownfield) switches into Mist Cloud, the device must have outbound Internet connectivity and DNS resolution to discover Mist Cloud service endpoints.”

Option A:Correct— DNS is required for the switch to resolve Mist Cloud URLs.

Option B:Correct— Internet access is required for registration and telemetry exchange.

Option C:Incorrect — templates can be applied later but are not required for adoption.

Option D:Incorrect — Mist uses TCP ports 2200 or 443, not UDP 1280.

According to Juniper Mist documentation, Switch Insights is the dedicated diagnostic and auditing feature within the Mist AI dashboard that provides a granular, chronological record of all events pertaining to a specific switch1. While Site Events or Site Alerts provide a broad overview of health and anomalies across an entire location, Switch Insights is specifically designed for device-level deep dives. When a user navigates to the Insights page for a particular switch, they are presented with a comprehensive timeline that correlates telemetry data with specific system occurrences.

This feature displays a detailed list of Switch Events, including but not limited to interface state transitions (Up/Down), Spanning Tree Protocol (STP) role changes, LLDP neighbor updates, and PoE controller status. Importantly, Switch Insights also tracks administrative actions, such as configuration commits and software upgrades, allowing an administrator to see exactly when a change was made and if that change coincided with a performance degradation in the Wired Service Level Expectations (SLEs).

Beyond simple logging, Switch Insights allows for retroactive troubleshooting. By adjusting the time slider, an administrator can go back in time to review the exact state of the switch during a reported issue2. For example, if a user reports a video conferencing issue that occurred three hours ago, the administrator can use Switch Insights to see if any port flaps, storm control events, or configuration changes took place during that specific window. This AI-driven visibility eliminates the need for manual syslog analysis or persistent CLI monitoring, providing a transparent and easily accessible audit trail for all switch-specific activity within the managed organization.

According to the provided exhibit, several visual indicators confirm the operational status and compliance of the EX4100-48MP switch within the Juniper Mist dashboard1.

First, the statement that PoE is enabled is verified by multiple sections of the dashboard2. In the Front Panel view, several ports display a green icon representing a wireless access point, and the PoE status indicator in the top right is lit green, indicating the subsystem is active. Furthermore, the Statistics panel shows a "Total Power Draw" of 48.40 W, and the Metrics section displays "100% PoE Compliance," confirming that the switch is successfully delivering Power over Ethernet to connected devices such as the three Mist APs listed in the summary.

Second, the exhibit indicates that the Junos OS version on this switch is not compliant with the other switches in the site5. This is explicitly shown in the Metrics section, where the Version Compliance tile is highlighted in red with a value of 0%6. In the Mist AI-driven interface, a red compliance tile signifies that the current software version running on the device (identified as 23.2R1.13 in the Properties panel) does not match the "Configured Version" or the "Approved Version" set at the Site or Organization level.

The other options are incorrect based on the visual evidence. While Mist APs are connected, the Front Panel shows them connected to 2.5GbE (mGig) ports (ports 0, 2, 8, etc.) and standard 1GbE ports, not specifically just "ge" interfaces in a traditional sense8. Additionally, the 0% Version Compliance score directly contradicts the idea that the switch is compliant with the organization's standards.

ThePost-Install (Installer)role has minimal access—sufficient only toclaim APs or switches, assign or unassign them, and place them on maps.

It cannot unclaim or remove devices and typically expires after installation.

According to Juniper Mist documentation, Dynamic Port Configuration (DPC)—also referred to as Dynamic Port Profiles—is the feature specifically designed to automate the assignment of VLANs and port settings based on the type of device connected to a switch. This technology enables the concept of "colorless ports," where any device (such as a Juniper Mist Access Point, an IP camera, or a VoIP phone) can be plugged into any available switch port without prior manual configuration.

The system functions by using "port assignment rules" that leverage various device properties to identify the connected hardware. These properties include LLDP attributes (System Name, Chassis ID, or Description), MAC addresses (including specific OUI ranges), and RADIUS attributes. For example, a rule can be configured to detect an LLDP System Description starting with "Mist Systems" and automatically apply a "Wireless AP" port profile. This profile typically includes the management VLAN, PoE settings, and Spanning Tree Protocol (STP) parameters required for an access point to function.

The primary benefit of DPC is the reduction of manual labor and the elimination of configuration errors in large-scale deployments. In traditional environments, an administrator would have to manually assign a VLAN to a specific physical port; with DPC, the Juniper Mist cloud detects the device and pushes the relevant configuration to the switch in real-time. If the device is disconnected, the port can be configured to revert to a "restricted" or "guest" VLAN, ensuring that the network remains secure against unauthorized access. This AI-driven approach drives consistency across multiple sites while significantly streamlining the onboarding of new hardware.

Wired Assurance in Mist Cloud provides automated configuration for Juniper EX Series switches. The automation is built on open APIs and supports programmable workflows, which allow seamless integration with external systems and reduce manual configuration errors.

“Wired Assurance leverages 100% open APIs, enabling integration with third-party automation and orchestration tools. Combined with programmable workflows, this provides a consistent and scalable automation framework for switch deployment and management.”

Option A (100% open APIs): Correct — APIs enable automation and external integration.

Option C (programmable workflows): Correct — workflows automate repetitive tasks and provisioning.

Option B (client SLEs): Incorrect — this is part of user experience monitoring, not automation.

Option D (switch insights): Incorrect — this relates to telemetry and visibility, not automation.

Wired AssurancedefinesSLEs (Service Level Expectations)to provide measurable performance indicators for wired networks. These metrics identify root causes of network degradation by monitoring switch health, connection success, and throughput performance.

“Juniper Mist Wired Assurance delivers AI-driven insights across key wired SLEs including Successful Connects, Throughput, and Switch Health, giving visibility into user experience and switch performance.”

Option A (Capacity):Incorrect — capacity is used in wireless SLEs, not wired.

Option B (Successful Connects):Correct— tracks connection success rate and anomalies.

Option C (Switch Health):Correct— monitors hardware, software, and PoE status.

Option D (Coverage):Incorrect — pertains to wireless SLEs.

Option E (Throughput):Correct— measures data transfer rate, latency, jitter, and loss.

InEVPN-VXLAN,BUM (Broadcast, Unknown unicast, and Multicast)traffic is handled differently than unicast traffic. EVPN provides two main forwarding mechanisms to distribute BUM traffic betweenVTEPs(VXLAN Tunnel Endpoints):

“BUM traffic in EVPN-VXLAN fabrics is replicated using eitheringress replicationorunderlay multicast(PIM-based). Both methods ensure that broadcast and unknown unicast frames reach all remote VTEPs within the same VXLAN segment.”

Option A:Incorrect — static routes are unrelated to BUM forwarding.

Option B:Incorrect — BGP is thecontrol plane, not a data-plane forwarding method.

Option C:Correct—Ingress replicationreplicates BUM packets to all remote VTEPs in the same VNI using unicast tunnels.

Option D:Correct—Underlay replication (multicast)uses multicast groups in the IP underlay to distribute BUM frames efficiently.

In Juniper Mist,Greenfield adoptionapplies to new, cloud-ready switches (such as EX4100, EX4400, and QFX series) using aclaim or activation codeto securely connect to the Mist cloud.

Brownfield adoption, however, supports switches already deployed or not factory-fresh. These are manually onboarded by configuring outbound management connectivity and adopting them through the Mist portal.

This distinction enables both new and legacy EX/QFX environments to be cloud-managed under Wired Assurance.

According to Juniper Mist documentation, the Throughput Service Level Expectation (SLE) is the primary metric used to represent the ability of wired users to pass traffic across the network without impedance. This SLE provides a comprehensive oversight of network performance by identifying issues that degrade the user experience, such as storm control events, interface anomalies, and specifically uplink congestion.

Within the Throughput SLE, the Congestion classifier (also referred to as Congestion Uplink) is specifically designed to monitor for buffer saturation and packet drops (TxDrops). When traffic arriving at an interface exceeds its processing or forwarding capacity, packets are queued in a buffer; if this buffer becomes full, the switch begins dropping packets. Juniper Mist utilizes a specific formula considering the ratios of TxDrops to TxPackets, Transmitted bps to Link Speed, and Received Speed to Link Speed to determine if a "Bad User Minute" has occurred due to congestion.

A critical feature of Wired Assurance is the automatic identification of uplink interfaces. Mist identifies these high-capacity ports by analyzing switch telemetry for characteristics such as having a switch or router as an LLDP neighbor, being designated as a Spanning Tree Protocol (STP) root port, or exhibiting significantly higher packet counts compared to access ports. When congestion is detected on an interface identified as an uplink, the system recognizes that this bottleneck impacts every user on that switch. By correlating these drops with the Throughput SLE, network administrators can proactively identify when a site requires more bandwidth or a different fabric architecture to handle current traffic demands, rather than simply monitoring if the link is physically "up" or "down".

ForJuniper cloud-ready EX Series switches(EX2300, EX3400, EX4100, EX4400, etc.) to successfully onboard to theJuniper Mist Cloud, specific connectivity requirements must be met:

“Cloud-managed EX switches require outbound connectivity to the Mist Cloud on TCP ports 2200 or 443. Switches must also have access to DNS services to resolve cloud service URLs during onboarding.”

Option A:Incorrect — minimum version depends on switch model; older models may onboard with earlier releases (e.g., 20.x, 21.x).

Option B:Correct— outbound TCP 2200 or 443 connectivity is required for cloud registration.

Option C:Incorrect — switches connect directly to Mist Cloud, not the Agile Licensing Portal.

Option D:Correct— DNS resolution is mandatory for discovering Mist Cloud endpoints.

In Juniper Mist, thesyslogfeature allows administrators to forward event messages and alerts from the Mist cloud to an external syslog server.

This is often used for centralized event monitoring, compliance, and correlation with tools like Splunk or SIEM systems.

Syslog operates over UDP or TCP and can capture switch events, system logs, and Marvis actions for both Wired and Wireless networks.

In theCampus Fabric Deployment Wizard, the first step is defining thetopology type(3-stage or 5-stage IP Clos) and mapping thephysical connectionsbetween devices (core, distribution, and access).

“The first step in the campus fabric deployment process is to define the topology and identify physical connections between devices. This ensures correct port mapping between core, distribution, and access tiers.”

Option A:Correct— topology definition and physical connectivity mapping occur in the initial step.

Option B:Incorrect — the underlay network configuration happens after topology definition.

Option C:Incorrect — overlay configuration handles EVPN/VXLAN and routing setup, not physical cabling.

Option D:Incorrect — applying intent finalizes the deployment but does not define connectivity.

In Juniper Mist campus fabric architectures, thelocation of the Layer 3 gateway (IRB interface)differentiatescentrally-routed bridging (CRB)fromedge-routed bridging (ERB):

InCRB, thegateway resides at the core layer— routing occurs centrally, and access/distribution layers perform Layer 2 bridging.

InERB, thegateway moves to the edge (distribution layer), enabling routing to occur closer to endpoints, improving performance and scalability.

“In a centrally-routed bridging (CRB) topology, Layer 3 gateways reside at the core. When transitioning to an edge-routed bridging (ERB) design, the Layer 3 gateways are moved to the distribution layer, closer to the access switches and clients.”

Therefore, when moving from acore-distribution CRBto anERBmodel, thegateway moves from the distribution to the access layerin campus terms (edge = access).

Option A:Incorrect — ERB gateways are not at the distribution layer only.

Option B:Incorrect — opposite direction.

Option C:Correct— the gateway movesfrom distribution to access (edge).

Option D:Incorrect — this describes CRB, not ERB.

Route targets (RTs)are extended BGP communities used inMultiprotocol BGP (MP-BGP)forEVPN-VXLANto control route import/export between VRFs.

“A route target identifies the VRF instances that should import or export specific MP-BGP routes. It enables the association of EVPN routes with particular VRFs in multi-tenant environments.”

Option A:Incorrect — EVPN family support is identified through BGP capabilities, not RTs.

Option B:Incorrect — that’s handled by BGP EVPN negotiation, not route targets.

Option C:Correct— route targets definewhich VRFs import/export BGP routes.

Option D:Incorrect — RTs can be manually configured and reused where necessary.

Juniper Mist uses open, cloud-native APIs to providereal-time telemetry and integration.

Data is collected and streamed from the backend using:

RESTful APIs– for configuration, automation, and reporting.

Webhooks– to push events, alerts, or SLE changes to third-party systems.

EVPN, when used with VXLAN, leveragesBGP MPLS/VXLAN control plane mechanisms. To prevent overlapping IP prefixes between different tenants or sites, EVPN uses aRoute Distinguisher (RD).

“In EVPN-VXLAN, the route distinguisher (RD) makes routes unique when overlapping IP prefixes or MAC addresses are advertised between multiple tenants or sites.”

Option A(designated forwarder) applies to multi-homing in EVPN, not prefix uniqueness.

Option B(Layer 2 gateway) does not prevent IP overlap; it bridges VLANs.

Option D(ESI) is used for identifying multi-homed Ethernet segments, not to differentiate overlapping subnets.

Option C(Route Distinguisher) is correct, as it uniquely identifies routes even if the IP addresses are the same across sites.

In theJuniper Mist AI for Wired dashboard, administrators can select one or more switch ports (as shown in the exhibit, e.g., port ge-0/0/25 on an EX4100-48MP). Once configuration changes are made — such as VLAN assignment, port profiles, PoE settings, or administrative state — theSave buttonmust be clicked to confirm and apply those changes to the device.

“When making configuration changes in the Mist switch interface, the Save button must be used to confirm the modifications. Clicking Save applies the selected port settings to the switch through Mist Cloud.”

Option Ais incorrect: saving does not create a backup. Backups and snapshots are handled through Mist’s configuration archive, not via the Save button.

Option Bis incorrect: Save does not reset configuration; instead, it commits changes.

Option Cis incorrect: there is no preview function tied to Save.

Option Dis correct: the Save button is explicitly forapplying configuration changesto the selected switch or port(s).

Group-Based Policy (GBP)is a Juniper EVPN-VXLAN feature that enablesmicrosegmentationwithout requiring multiple VRFs or VLANs. It is implemented within Juniper Mist’sWired Assurance and Campus Fabricframeworks.

“GBP provides scalable, identity-based segmentation for campus fabrics and is supported on EX4100 and EX4400 Series switches operating in EVPN-VXLAN mode under Mist management.”

The feature requires hardware and software support forEVPN-VXLAN and GBP tagging, which is currently available on specific EX models managed by Mist Cloud.

Option A:Correct— GBP requires compatible access switches, specifically EX4100 and EX4400 models.

Option B:Incorrect — GBP is centrally managed through Mist Cloud, not configured per switch.

Option C:Incorrect — GBP is provisioned via Mist Cloud, not the CLI.

Option D:Incorrect — GBP is not supported onallEVPN-capable switches; only on defined platforms (EX4100/EX4400).

According to the Juniper Mist dashboard's firmware management interface shown in the exhibit, several key details of the switch upgrade process are visible. The "Upgrade switch firmware" dialog box is a standard component of Juniper Mist Wired Assurance used to manage Junos OS updates across the fabric.

The correct statement is that the switch will reboot after the upgrade. This is explicitly confirmed by the checkbox labeled "Reboot switch after image copy," which is currently selected in the exhibit. In Juniper's cloud-managed workflow, once the new software image is successfully transferred from the Mist cloud to the switch's local storage, the system requires a reboot to initialize the new Junos OS kernel and complete the installation process5. While some platforms support non-disruptive upgrades, the standard procedure for EX-series switches in a standalone or Virtual Chassis configuration typically involves a scheduled reboot to ensure the new version is correctly applied.

The other options are incorrect based on the visual evidence provided in the exhibit.

Option A: The exhibit clearly identifies the "Switch Model" as an EX2300-C-12P (the 'P' designating PoE support), not an EX2300-C-12T88.

Option C: The dialog box explicitly states "Total Switches selected to upgrade: 1," confirming this is a single-device operation rather than a bulk upgrade.

Option D: The "Upgrade to Version" field is set to 19.3R1.8, which indicates the target version, not the previous version10101010.

By providing these granular controls, Juniper Mist allows administrators to maintain strict version compliance across the site while choosing whether to immediately reboot or stage the image for a later maintenance window.