Free JN0-460 Practice Test Questions 2026

Explanation:

In EVPN (Ethernet VPN), when two different sites use the same IP subnet (e.g., 172.16.1.0/24), the routes from each site would normally overlap in the BGP table, causing confusion. To make these routes unique across the MPLS/IP network, EVPN uses a Route Distinguisher (RD).

Why the other options are incorrect:

A. It elects a designated forwarder (DF)
— DF is used in EVPN for multi-homing (all‑active or single‑active) to avoid duplicate BUM traffic forwarding. It does not solve overlapping subnet problems between different sites.

B. It uses a Layer 2 gateway
— A Layer 2 gateway bridges traffic but does not distinguish overlapping IP subnets from different sites. This is a topology/connectivity concept, not a control‑plane mechanism to avoid route overlap.

D. It uses an Ethernet segment identifier (ESI)
— ESI identifies a multihomed link from a customer edge (CE) to multiple PEs for redundancy. It has no role in differentiating overlapping IP prefixes from distinct sites.

Reference:

RFC 7432 (BGP MPLS-Based Ethernet VPN) — Sections covering Route Distinguisher and EVPN Route Types.

Juniper TechLibrary — EVPN Overview — Explains that RDs allow PEs to distinguish customer address spaces even when prefixes overlap.

Explanation:

In the Juniper Mist configuration model, settings follow a specific inheritance hierarchy: Organization-level > Site-level > Device-level. Hostnames are unique identifiers for each switch and must be configured directly on the device itself.

Why the other options are incorrect

A. Organization switch template
— These templates push the same configuration to multiple switches simultaneously. Assigning a hostname here would apply the same name to every switch, defeating the requirement for unique identifiers per switch. Organization-level templates support variables to help manage differences, but the actual unique hostname assignment is still resolved at the device level.

B. Site switch configuration
— This level applies to all switches within a specific site. While you can override template settings here, it is still too broad for setting a unique identifier for each individual switch. Unique hostnames must be configured per device, not per site.

D. Device profiles
— Device profiles are designed to apply a specific configuration to a group of similar devices (primarily Access Points) across an organization. They are not used for assigning unique identifiers like hostnames to individual switches.

Reference:

Juniper Networks Documentation
— "Overview of Template-Based Switch Configuration" — Explains the hierarchy (Organization > Site > Device) and notes that adding hostnames is a device-specific update.

Juniper Networks Documentation
— "Switch Configuration Options" — Details how to override templates at the site level.

Explanation:

The Juniper Mist architecture is built on a 100% API-first principle, meaning everything visible in the Mist portal can also be accessed programmatically. Mist provides three primary methods for collecting data from its backend, each serving a distinct purpose:

RESTful API (A)
— This is a synchronous, request-response method used for configuration, automation, reporting, and pulling inventory or statistics. Clients send HTTP requests (GET, POST, PUT, DELETE) to specific endpoints and receive data in JSON format. For example, you can use a GET /api/v1/sites/:site_id/stats/devices call to retrieve device statistics.

webhook (B)
— This is an asynchronous push mechanism where the Mist backend sends real-time notifications to a specified URL when events occur. Unlike APIs which require polling, webhooks push data immediately for events like alarms, device up/down, client associations, and audit logs.

WebSocket (C)
— This protocol provides a persistent, full-duplex connection for streaming near-real-time data. Once a client subscribes to a channel (e.g., site device statistics), the server continuously pushes updates as they happen. This is ideal for live dashboards and monitoring dynamic stats like client counts and radio information.

Why the other options are incorrect

D. Syslog
— While Mist data can be forwarded to a Syslog server, this is not a native method of collecting data directly from the Mist backend. Instead, it is typically achieved by using a webhook to receive the data, then transforming and forwarding it to a Syslog server (e.g., using the Juniper Alert Format Relay). Syslog is an output destination, not a primary collection method from Mist itself.

E. SNMP
— Mist devices do not support traditional SNMP polling for configuration or statistics retrieval. The Mist architecture uses modern API methods. Although the Juniper Alert Format Relay can translate Mist webhooks into SNMP traps for legacy NMS systems, native SNMP data collection from the Mist backend is not supported.

Reference
Juniper Mist API and Webhook Integration Guide
Juniper Networks Documentation — WebSocket Streaming
Juniper Networks Documentation — RESTful API Overview

Explanation:

Juniper Mist Wired Assurance provides AI-driven visibility and service level management for EX Series and QFX Series switches. The platform delivers complete operational visibility into switch health, port status, and client experiences. It enables administrators to define Service Level Expectations (SLEs) for key metrics such as throughput (meeting bandwidth thresholds), successful connects (authentication and DHCP success rates), and switch health (CPU, memory, temperature). Critically, Mist monitors both pre-connection metrics (DHCP offer time, RADIUS response time, LLDP neighbor discovery) and post-connection metrics (packet loss, latency, error counters, MAC flaps). Marvis, the AI engine, proactively compares real-time data against SLEs to detect anomalies and suggest root causes.

Why other options are incorrect:

B – False because Mist absolutely provides operational visibility and SLEs for EX/QFX switches. The statement denies core Wired Assurance features.

C – Incorrect because Mist monitors both pre-connection and post-connection phases. Focusing only on post-connection would miss critical client onboarding issues like DHCP or RADIUS delays.

D – Incorrect because Mist does not focus primarily on pre-connection metrics. It equally monitors throughput, successful connects, and switch health post-connection, and fully supports EX/QFX switches.

References

Juniper TechLibrary – Wired Assurance Overview – Confirms operational visibility, SLEs for wired clients (LLDP, 802.1X, DHCP), throughput measurement, and health monitoring across pre- and post-connection phases.

Juniper Mist Wired Assurance Data Sheet – Lists SLEs for throughput, successful connects, and switch health with AI-driven insights for EX and QFX.

Explanation:

In Juniper Mist cloud services, Service Level Expectation (SLE) telemetry is collected from every device (wireless access points, wired switches, and gateways) and stored with full granularity for 30 days (1 month) . This 30-day retention period allows network administrators to perform detailed trend analysis, troubleshoot client experience issues (e.g., successful connects, throughput, coverage), and generate meaningful reports over a standard business cycle . After 30 days, the detailed high-resolution telemetry data is typically aggregated into lower-resolution, long-term summaries for historical trend observation .

Note on Extended Retention: Customers requiring longer retention can subscribe to Juniper Mist Premium Analytics, which extends historical data storage up to 13 months or more .

❌ Why other options are incorrect

B. 2 months — Incorrect. Standard Mist SLE telemetry retention is 30 days, not 60 days. The 2-month duration has no basis in Juniper's standard or premium analytics policies.

C. 7 days — Incorrect. Mist retains granular SLE data for 30 days, which is substantially longer than one week to support meaningful trend analysis and troubleshooting across multiple business cycles.

D. 24 hours — Incorrect. While Mist does maintain some real-time operational data, SLE telemetry is explicitly retained for 30 days to enable historical analysis, not just a single day.

📚 References

Juniper Official Documentation - Premium Analytics FAQ — Standard analytics (included with Mist subscriptions) stores 30 days of data; Premium Analytics extends to 13+ months .

Juniper Mist Premium Analytics Overview — States that Premium Analytics extends observability beyond the 30 days available with standard Mist analytics service .

✅ Explanation:

The Juniper Mist solution is built on a 100% API-first architecture using REST API (Representational State Transfer). All actions performed in the Mist UI—such as configuring devices, pushing templates, retrieving analytics, and managing sites—can also be executed programmatically via REST API calls. These calls use standard HTTP methods (GET, POST, PUT, DELETE) and return data in JSON format. REST is stateless, scalable, and widely adopted for cloud-based networking solutions, making it the native and exclusive API style for Mist.

Clarification: JSON is the data format used in API requests/responses, not the API itself.

❌ Why other options are incorrect

B. SOAP— Incorrect. Mist does not use SOAP (Simple Object Access Protocol), which is an older, heavier XML-based protocol. Mist's modern architecture exclusively uses REST.

C. JSON — Incorrect. JSON (JavaScript Object Notation) is a lightweight data interchange format, not an API. Mist APIs use JSON to structure payloads, but the API itself is REST.

D. RPC — Incorrect. RPC (Remote Procedure Call) is a different architectural style (e.g., gRPC, XML-RPC). While Mist uses WebSockets for streaming, the primary configuration and data retrieval API is REST, not traditional RPC.

📚 References

Juniper Mist API Documentation — "Mist APIs are organized around REST. Our API is designed to have predictable, resource-oriented URLs and uses HTTP response codes to indicate API errors."

Juniper TechLibrary — Mist Architecture Overview — "The Mist platform is 100% API-driven, leveraging RESTful APIs for all configuration, monitoring, and automation tasks."

✅Explanation:

A 3-stage campus fabric IP Clos (also known as a spine-leaf architecture when adapted to campus) follows a hierarchical, non-blocking design. In this model:

Access layer (leaf) — Connects to end devices (servers, clients, APs).

Distribution layer (spine) — Acts as the aggregation point, with every access switch connecting to every distribution switch.

Core layer — In a pure 3-stage Clos, there is no separate "core" beyond the spine; if a core exists, it connects multiple distribution blocks.

However, the defining characteristic of a 3-stage Clos (or spine-leaf) is that every access switch connects to every distribution switch, and there are no direct access-to-access or distribution-to-distribution links. Therefore, the correct statement among the options is that the distribution layer is connected to the access layer — this is the fundamental connectivity in the fabric.

Clarification on D: In traditional 3-stage Clos, spine (distribution) devices are not directly connected to each other; that would create a 4‑stage design. Core-to-core connections occur only in multi-clos designs (e.g., super-spines).

❌ Why other options are incorrect

B. The distribution layer is connected to the core layer
— This exists in a traditional three‑tier campus design (access‑distribution‑core), not specifically defining a Clos fabric. While possible in expanded fabrics, it is not the unique correct statement for a 3-stage Clos.

C. The core layer is connected to the access layer
— Incorrect. In any hierarchical design, access switches never connect directly to core switches; they connect via distribution/spine.

D. The core layer devices are connected to each other
— Incorrect for a pure 3‑stage Clos. Spine/distribution devices do not peer directly; they only connect to leaf/access switches. Core-to-core links exist in super‑spine designs (e.g., 5‑stage Clos).

📚 References

Juniper TechLibrary — IP Fabric Underlay for Campus — "A 3-stage Clos fabric consists of leaf (access) switches connected to all spine (distribution) switches. There are no spine-to-spine or leaf-to-leaf links."

Juniper Design Guide — Campus Fabric Architecture — Diagrams show access-to-distribution connectivity as the foundation of the Clos topology.

✅ Explanation:

Mist does not directly send Syslog, SNMP Traps, or NETCONF to external collectors. Instead, Mist uses Webhooks as its native, real-time event forwarding mechanism. When you configure a webhook in the Mist UI (Organization or Site level), Mist sends HTTP POST requests containing JSON-formatted event data (alarms, audits, client associations, device state changes) to your external log collector's endpoint. From there, you can transform the data into Syslog or other formats if needed. The Juniper Alert Format Relay is an example tool that receives Mist webhooks and forwards them as Syslog or SNMP traps to legacy systems.

❌ Why other options are incorrect

A. Syslog
— Incorrect. Mist does not generate native Syslog streams. Syslog is a destination format, not a native Mist output. You must use webhooks + a relay (e.g., Alert Format Relay) to convert webhooks to Syslog.

C. NETCONF
— Incorrect. NETCONF is used for configuration management (e.g., pushing configs to Junos devices), not for forwarding real-time event messages from Mist cloud to external log collectors.

D. SNMP Traps
— Incorrect. Mist does not send native SNMP traps. Similar to Syslog, you can use webhooks + the Alert Format Relay to convert webhooks to SNMP traps for legacy NMS integration.

📚 Reference:

Juniper TechLibrary — Webhooks Overview — "Webhooks allow Mist to push real-time notifications (alarms, audits, device events) to external systems via HTTP POST."

Juniper Alert Format Relay Documentation — Explains how to receive Mist webhooks and forward as Syslog or SNMP traps.

✅ Explanation:

When a switch first connects to the Juniper Mist Cloud, it authenticates using its claimed device serial number and appears in the Inventory page with a status of "Unassigned" . This indicates the switch has successfully established an outbound SSH connection to the Mist cloud (port 2200) but has not yet been mapped to a specific site. A site defines VLANs, port profiles, SLE policies, and other configuration contexts. Until the switch is assigned to a site, Mist does not push any configuration to it, and its status will not change to "Connected" . Once you select the unassigned switch and assign it to a site, Mist deploys the site‑level configuration, and the status transitions to "Connected" .

❌ Why other options are incorrect

A. Rescan QR code
— Incorrect. QR codes are used for Mist Access Points (APs) during initial zero-touch provisioning (ZTP). Switches are adopted via claiming the serial number in the inventory, not via QR codes.

B. Restart each switch
— Incorrect. Restarting does not change assignment status. The switch is already communicating with the cloud; it simply lacks a site assignment. A restart would not resolve this.

C. Troubleshoot with CLI commands
— Incorrect. The show system connections | grep 2200 and show configuration system services outbound-ssh commands are used to verify that the switch can reach the Mist cloud. If the status is "Unassigned," the switch is already connecting successfully. No troubleshooting is needed; assignment to a site is the missing step.

📚 References

Juniper TechLibrary — Switch Adoption Workflow — "After a switch claims successfully, it appears in Inventory as 'Unassigned.' Assign it to a site to complete adoption; status changes to 'Connected.'"

Juniper Mist Adoption Guide for EX Switches— "Unassigned means the switch is communicating with the cloud but not yet bound to a site configuration. Site assignment is mandatory for managed status."

✅ Explanation:

Switch configuration templates in Juniper Mist allow network administrators to define a standardized baseline configuration (VLANs, port profiles, AAA, SNMP, NTP, syslog, etc.) that can be applied to multiple switches across an organization or site. The primary benefit is consistency — ensuring every switch in a given role or location receives identical settings, reducing human error, simplifying compliance, and streamlining changes. When you update a template, all associated switches inherit the change automatically, eliminating the need to manually reconfigure each device.

❌ Why other options are incorrect

A. They improve the performance of switches
— Incorrect. Templates affect configuration consistency and management efficiency, not switch forwarding performance (e.g., throughput, latency). Performance is determined by hardware and Junos forwarding plane.

B. They reduce Junos OS upgrade times
— Incorrect. OS upgrades are independent of configuration templates. Upgrade time depends on image size, device model, and reboot duration. Templates do not accelerate this process.

C. They make it easier to make switch-specific changes
— Incorrect. Templates are designed for shared, consistent settings. Switch‑specific changes (e.g., unique hostname, management IP) are made at the individual device level, overriding the template when necessary. Templates actually discourage per‑device customization to maintain consistency.

📚 References:

Juniper TechLibrary — Switch Templates Overview — "Templates enable consistent configuration across multiple switches, reducing operational overhead and ensuring uniformity."

Juniper Mist Configuration Hierarchy Documentation— "Organization‑level templates provide a baseline; site‑level and device‑level overrides allow exceptions while maintaining overall consistency."

✅ Explanation:

Brownfield adoption refers to the process of onboarding switches that are already deployed in a live network (e.g., EX Series switches with an existing configuration). For these switches to successfully connect to the Juniper Mist Cloud and appear in the inventory for assignment, two fundamental network-layer requirements must be met:

DNS Resolution (A):
The switch must be able to resolve the fully qualified domain name of the Mist cloud endpoint (oc-term.mistsys.net). Without proper DNS resolution, the switch cannot locate the server to initiate the connection.

Internet Connectivity (B):
The switch requires a route to the public internet to reach the Mist cloud infrastructure. This is typically achieved via the management port (me0) or an IRB interface (irb.0).

❌ Why the other options are incorrect

C. An imported Configuration Template:
Incorrect. A configuration template is used to apply consistent settings (like VLANs) after the switch is assigned to a site. It is not required for the initial connection or to change the status from "Unassigned" to "Connected".

D. Outbound UDP 1280 access:
Incorrect. Juniper Mist switches communicate with the cloud using outbound TCP port 2200 (SSH). UDP port 1280 is not used for this purpose.

References
Juniper Networks Documentation: "Onboarding brownfield-existing Junos and troubleshooting"
Juniper Networks Documentation: "Greenfield vs. Brownfield Switches"
Juniper Networks Documentation: "Adopting a Juniper EX Switch"

✅ Explanation:

In Juniper Mist, predefined or custom roles can be created with granular permissions. A role named "Post-Install" typically refers to a limited, task‑specific role designed for field technicians or third‑party installers who need to:

Physically install access points (APs) and switches
Claim devices to the organization
Assign devices to sites
Verify basic connectivity (LED status, cloud connection)
However, they should not have access to:
Configuration templates
WLANs, VLANs, port profiles
SLE dashboards or client history
Organization or billing settings

Thus, the Post-Install role is not an admin, read‑only, or help‑desk role — it is a scoped installer role limited to device adoption and placement.

❌ Why other options are incorrect

A. Help‑desk monitoring for all sites
— Incorrect. A help‑desk role would need read‑only access to SLEs, client events, and device status. Post-Install lacks those permissions.

C. Read‑only access to all sites
— Incorrect. Read‑only (Observer) can view configurations and analytics but cannot install/claim devices. That is the opposite of Post-Install.

D. Full access to all sites
— Incorrect. Full access (Admin) includes billing, organization settings, templates, and all configurations — far beyond installation tasks.

📚 Reference

Juniper Mist RBAC Documentation — Defines roles: Admin (full), Observer (read‑only), Installer (claim & assign devices, no config access). The Post-Install role in practice aligns with Installer.