JN0-460 Practice Questions

RadSec (RADIUS over TLS) is a protocol defined in RFC 6614 to secure RADIUS communications. Unlike traditional RADIUS, which uses the unreliable UDP protocol, RadSec mandates the use of TCP as the transport protocol. This provides a reliable, connection-oriented session. Over this TCP connection, Transport Layer Security (TLS) is used to encrypt the entire RADIUS payload, ensuring confidentiality, integrity, and authentication between the RADIUS client (e.g., a network access server) and the RADIUS server.

B. This is incorrect because RadSec specifies the use of Transport Layer Security (TLS), not its predecessor, Secure Sockets Layer (SSL), which is now considered deprecated and insecure.

C. This is incorrect because while traditional RADIUS uses UDP, RadSec requires a reliable transport for TLS to function. Therefore, it explicitly mandates the use of TCP, not UDP.

D. This is incorrect for two reasons: it specifies the wrong transport protocol (UDP instead of TCP) and the outdated security protocol (SSL instead of TLS).

1. Juniper Networks TechLibrary, Junos OS Documentation. "Understanding RADIUS over TLS (RadSec)". This document states, "RadSec uses the Transmission Control Protocol (TCP) as the transport protocol to send RADIUS data... RadSec provides a secure communication channel between the RadSec client and server by using Transport Layer Security (TLS) for authentication, data integrity, and confidentiality."

2. Internet Engineering Task Force (IETF) RFC 6614. "Transport Layer Security (TLS) Encryption for RADIUS". Section 2.1, "Transport", explicitly states, "RADIUS/TLS MUST be transported over TCP. The destination port number for RADIUS/TLS is 2083." This RFC is the defining standard for RadSec.

When a switch is claimed into a Mist organization, it is first added to the organization-level inventory. In this initial stage, before it has been associated with a specific site, its state is Unassigned.

After being assigned to a site, the switch will attempt to connect to the Mist cloud. Once it successfully establishes a connection and is fully operational, its state changes to Connected. Both "Unassigned" and "Connected" are valid and distinct states in the lifecycle of a switch after it has been claimed.

B. Inactive: "Inactive" is not a standard device state in the Mist UI. The correct term for a device that has lost its connection to the cloud is "Disconnected".

C. Active: "Active" is not an official device state. The "Connected" state is used to indicate that a switch is online, operational, and actively communicating with the Mist cloud.

1. Juniper Mist Documentation, "Switches Dashboard": This document describes the device statuses displayed in the Mist UI. It explicitly lists "Connected" (green status icon) for online devices and "Unassigned" for devices in the inventory that have not been assigned to a site.

2. Juniper Mist Documentation, "Onboard a Switch": This guide details the process of adding a switch to a Mist organization. It shows that after a switch is claimed, it resides in the organization inventory and must be assigned to a site, confirming the "Unassigned" state as the initial step post-claim.

The Juniper Mist UI is a cloud-based, web interface designed for network administrators. Its primary function is to provide centralized management, configuration, monitoring, and troubleshooting for Juniper network devices. This includes Mist wireless Access Points (APs), Juniper EX Series switches, and SRX Series firewalls. The UI leverages AI through Marvis to provide insights, analytics, and automation for wired, wireless, and WAN assurance, simplifying network operations from a single dashboard.

B. Route distribution is a control plane function of network devices like routers or Layer 3 switches, not a direct function of the management UI itself.

C. End-user clients (e.g., laptops, phones) use their operating system's native wireless utility to connect to a Wi-Fi network, not the administrative Mist UI.

D. Provisioning Virtual Machines (VMs) is a function of cloud compute platforms (like AWS, Azure, or VMware vCenter), not a network management system like Mist.

---

1. Juniper Mist Documentation, "Mist Cloud UI Overview." This document explicitly states, "The Mist UI is a web-based interface that you use to manage your wireless, wired, and WAN networks." This directly confirms that the UI's purpose is to manage network devices.

(Source: Juniper Networks TechLibrary, Mist Cloud and AI, "Mist Cloud UI Overview" section).

2. Juniper Mist Documentation, "Get Started with Switches." This guide details the process of onboarding and managing wired devices, stating, "You can manage your Juniper EX Series Switches from the Mist cloud. When you manage a switch from the Mist cloud, the cloud pushes a baseline configuration to the switch..." This demonstrates the UI's role in managing physical network hardware.

(Source: Juniper Networks TechLibrary, Mist Wired Assurance, "Get Started with Switches," Introduction section).

3. Juniper Mist Documentation, "Juniper Access Points and the Mist Cloud." This resource clarifies the management relationship for wireless devices: "You manage your Juniper access points (APs) from the Juniper Mist cloud. The Mist cloud provides centralized management for your APs..." This reinforces the UI's function as a management tool for the wireless portfolio.

(Source: Juniper Networks TechLibrary, Mist Wireless LAN, "Juniper Access Points and the Mist Cloud," Overview section).

The Juniper Mist platform uses a hierarchical structure for configuration: Organization > Site > Device. A "Site" is a fundamental configuration level that represents a distinct physical location, such as a building, campus, or branch office. This is where you define site-specific settings like WLANs, RF templates, and floorplans. The term "location" is conceptually synonymous with "Site" in the Mist hierarchy. Therefore, a new site configuration is created at the level representing a physical location.

A. clients: Clients are end-user devices connecting to the network. They are not a level in the administrative configuration hierarchy.

C. access points: Access points are devices managed within a site. A site configuration is a container for access points, not created under them.

D. organization: The organization is the top-level container under which one or more sites are created, but the site configuration itself constitutes the "site" (or "location") level of the hierarchy.

1. Juniper Mist, Wi-Fi Assurance Configuration Guide: In the "Sites" section, it states, "A site is a physical location, such as a campus, a building, or a store." This document directly equates the configuration entity "Site" with the concept of a "location". (Reference: "Sites" chapter).

2. Juniper Mist, Mist Configuration Basics: This guide outlines the platform's structure: "The Mist platform has a hierarchical structure. At the top of the hierarchy is the organization... Below the organization are sites." This confirms that "Site" is the hierarchical level below "Organization". (Reference: "Configuration Hierarchy" section).

3. Juniper Networks, Juniper Mist Cloud Services Datasheet: This document describes the architecture: "...a hierarchical structure for managing networks across the organization, sites, and floors." This reinforces the official terminology and placement of "sites" in the hierarchy. (Reference: "Juniper Mist Cloud Architecture" section).

Juniper Mist Wired Assurance provides a suite of remote testing and troubleshooting tools accessible directly from the Mist cloud portal. For a selected switch, administrators can initiate several diagnostic actions. These include Layer 1 diagnostics with the cable test (TDR) to check for physical cabling faults. Layer 3 connectivity can be verified using ping from the switch to any destination IP address. Additionally, to resolve client connectivity or PoE issues, the bounce port function allows an administrator to administratively disable and re-enable a specific switch port, effectively power-cycling a connected device or re-initializing the link. These tools enable rapid, remote troubleshooting without requiring physical access or CLI interaction.

B. iPerf: This is a network performance tool and is not integrated as a switch-initiated testing utility within the Mist Wired Assurance UI.

D. load factory-default: This is a device reset command used for provisioning or recovery, not a diagnostic tool for troubleshooting active network issues.

1. Juniper Mist Documentation, "Switch Details Page": The "Utilities" dropdown menu on the Switch Details page in the Mist UI explicitly lists "Ping" and "Test Cable" as available tools. The "Bounce Port" action is available by selecting a port on the switch's front panel view. This documentation confirms these three tools are native to the platform. (Source: Juniper TechLibrary, Mist Cloud UI Documentation).

2. Juniper Networks, "Wired Assurance" Feature Guide: This guide describes the remote troubleshooting capabilities of Wired Assurance, highlighting features such as cable diagnostics and port-level actions. It states, "Remotely troubleshoot wiring issues with the cable test tool... Remotely bounce a port to reset a device." (Source: Juniper Networks Official Product Documentation).

A 5-stage IP Clos network is a highly scalable, hierarchical network topology designed for large-scale campus or data center deployments. It extends the foundational 3-stage Clos architecture (typically consisting of access/leaf and distribution/spine layers) by introducing two additional layers. These are often referred to as spine and super-spine (or edge-spine and core-spine) layers. This expansion allows for the interconnection of multiple 3-stage Clos "pods," enabling massive scalability, predictable performance, and fault isolation across a large physical area, such as a multi-building campus, while maintaining a consistent, centrally managed fabric.

A. An IP Clos is a network architecture or topology, not a routing protocol. Protocols like BGP are used to enable routing within this architecture.

B. EVPN-VXLAN is a technology (control plane and encapsulation) used to build an overlay network on top of an IP Clos physical underlay, not the architecture itself.

C. This describes the traditional three-tier network model. While hierarchical, the 5-stage IP Clos is a more specific evolution with distinct leaf, spine, and super-spine layers.

1. Juniper Networks Documentation, Campus Fabric Core-Distribution Deployment Guide: In the "Campus Fabric IP Clos Architecture" section, it states, "For very large networks, you can extend the architecture to a five-stage Clos architecture by adding another layer of spine devices, known as super-spines. In a five-stage IP Clos, the super-spines are at the top of the Clos architecture and connect to the spines in the different pods." (Reference: Campus Fabric IP Clos Architecture > Overview)

2. Juniper Networks Documentation, EVPN-VXLAN Campus Network Design and Migration Guide: This guide explains the scalability of the architecture: "A 5-stage Clos architecture is essentially a spine-leaf topology in which the leaf layer is composed of multiple spine-leaf topologies... The 5-stage Clos architecture is also known as a multi-pod design." (Reference: Chapter 2: EVPN-VXLAN Campus Architecture > 5-Stage Clos Architecture)

3. Juniper Networks TechLibrary, EVPN-VXLAN Fabric Architecture: "A typical IP fabric data center design follows a two-tier spine-and-leaf architecture, also known as a three-stage Clos fabric... For larger fabrics, you can add another layer of spines, creating a five-stage Clos fabric, which provides additional scalability." (Reference: Technology Overview > EVPN-VXLAN Fabric Architecture)

The Juniper Mist platform operates on a hierarchical configuration model. Settings configured at a more specific level (Site) take precedence over settings from a more general level (Organization Template). In this scenario, because the WLAN and its policy are explicitly configured at the Site A level, this configuration will override the settings for the same WLAN within the organization-level template applied to Site A. Therefore, the policy created at the site level is the one that will be enforced.

A. The policy from the organization-level template is overridden by the more specific site-level configuration and will not be the one that is executed.

B. Organization-level configuration templates can be applied to individual sites, multiple selected sites, or site groups, not exclusively to site groups.

D. The core function of an organization-level template is to be applied to specific sites or groups of sites, which are explicitly selected during template configuration.

1. Juniper Mist Documentation, "Use Configuration Templates": In the section detailing configuration hierarchy, it states, "Mist has a configuration hierarchy. You can configure settings at the Organization level and at the Site level. Site-level settings override Organization-level settings. For example, if you enable a specific band in a template and disable it at the site level, the site-level setting (disabled) takes precedence." This directly supports the principle that site-level configurations are executed over template-level ones.

2. Juniper Learning Portal, JNCIA-MistAI Courseware, "Module 3: Mist Configuration Basics": This module explains the object hierarchy (Organization > Site). It details that templates are created at the organization level to provide a baseline configuration for multiple sites, but any configuration made directly on a site object will override the template settings for that specific site. This confirms that the site-level policy is the effective one.

3. Juniper TechLibrary, "Mist Cloud—An Introduction to the Cloud-Native Platform": This document outlines the architectural design, which includes the hierarchical management structure. It explains that this structure allows for both broad, consistent policy application via organization-level templates and granular, site-specific exceptions and configurations, with the latter taking precedence.

Juniper Mist's Dynamic Packet Capture (dPCAP) is an automated troubleshooting feature. It is enabled by default and requires no administrative configuration to function. When the Mist AI engine detects a client connection failure (such as an authorization or DHCP issue), it automatically triggers a packet capture on the relevant access point for the specific client involved. This captured data is then directly linked to the corresponding failure event within the client's timeline on the "Client Insights" page, providing immediate access to diagnostic information for rapid problem resolution.

C. This is incorrect. A key feature of dPCAP is that it is automatic and requires no configuration at the organization, site, or device level to capture failure events.

D. This is incorrect. The packet capture is attached to the specific failure event on the Client Insights page, not directly to the "Affected Items" list of any SLE, including Successful Connects.

1. Juniper Mist Documentation, "Dynamic Packet Capture." This document states, "The Mist platform automatically performs a dynamic packet capture (dPCAP) when it detects a client failure... You don’t need to configure anything to enable this feature." This directly supports option A.

2. Juniper Mist Documentation, "Dynamic Packet Capture." The same document explains how to access the data: "To view the packet capture, go to the Client Insights page for the client that experienced the failure... In the Events section, find the failure event. Click the View Packet Capture link." This confirms that the capture is attached to the client event on the Insights page, supporting option B.

In the Juniper Mist platform, administrator roles are defined with specific privileges. The Super User role has unrestricted access to all organization and site settings, including the ability to claim devices. The Network Admin role has full access to network configuration and management tasks, which includes claiming switches. The Installer role is specifically designed for on-site personnel to onboard new devices, and its primary functions include claiming and provisioning hardware like switches and access points into the Mist organization's inventory.

D. Observer: This is a read-only role that cannot perform any configuration changes, including claiming or managing device inventory.

E. Helpdesk: This role has limited privileges focused on viewing client information and performing basic troubleshooting, but it cannot manage network devices or inventory.

1. Juniper Mist Documentation, "Administrator Roles": This official document provides a detailed matrix of privileges for each administrator role. The table under the "Privileges" section explicitly shows that Super User, Network Admin, and Installer roles have the permission to "Claim/Release APs/Switches," while the Observer and Helpdesk roles do not.

Source: Juniper Mist - Cloud Services Documentation

Section: Administrator Roles > Privileges Table (Specifically, the row for "Claim/Release APs/Switches").

2. Juniper Networks, "Mist Administration Guide": This guide details the administrative functions within the Mist dashboard. It describes the scope of each role, confirming that inventory management tasks such as claiming devices are restricted to roles with higher-level network management or specific installation privileges.

Source: Juniper Networks Technical Documentation

Section: Managing Administrators and Roles.

For a greenfield deployment, Juniper Mist provides several flexible methods to onboard switches. The Juniper Mist AI mobile application can be used to scan the QR code on a switch, which contains the unique claim code, to add it to an organization's inventory. For large-scale deployments, an entire purchase order can be linked to the Mist organization, automatically populating the inventory with all associated devices. Additionally, the comprehensive Mist API allows for programmatic and automated onboarding of switches, which is highly efficient for new, large-scale site rollouts.

A. The serial number is a device identifier but is not used as the primary input for the initial claiming process in the Mist portal or app; the claim/activation code is required.

E. The system MAC address is used for device identification and communication on the network, but it is not the primary credential used to claim a new switch into a Mist organization.

1. Juniper Mist Documentation, "Onboard a Switch to Your Organization": This document explicitly lists the valid methods for claiming a switch: "You can claim a switch by using one of the following methods: Activation Code, QR Code, Purchase Order." This directly supports options B and C. The document also mentions the API as a method for automation. (Source: Juniper Networks TechLibrary, Mist Wired Assurance section).

2. Juniper Mist Documentation, "Claim Switches by Purchase Order": This guide details the procedure for linking a Juniper sales order to a Mist organization. It states, "You can claim switches by using the purchase order (PO) that you used to buy the switches... When you claim switches by using a PO, all the switches in that PO are automatically assigned to your organization." This validates option C as a bulk onboarding method ideal for greenfield sites. (Source: Juniper Networks TechLibrary, Mist Wired Assurance section).

3. Juniper Mist API Documentation: The official API documentation outlines the endpoints available for managing an organization's inventory. Specifically, the POST /api/v1/orgs/{orgid}/inventory endpoint allows for programmatically adding devices to the inventory using their activation codes. This confirms that the API can be used to automate the provisioning and onboarding process, supporting option D. (Source: api.mist.com, Official Juniper Mist API Documentation, Org Inventory Operations).