Free JN0-481 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

In Juniper Apstra, all modifications to a blueprint's design and topology are performed in the 'Staged' environment. The 'Active' environment is a read-only representation of the currently deployed network configuration. To change the physical cabling (the cable map), the operator must navigate to the 'Staged' tab, then select the 'Physical' view, and finally the 'Links' sub-tab. Here, links between device ports can be added, modified, or deleted to match the physical reality before committing the changes to the live network.

A. The 'Active' view is read-only and used for monitoring the current state of the network, not for making configuration changes.

C. 'Connectivity Templates' define logical server attachments, not the physical fabric links. Also, the 'Active' view is read-only.

D. 'Connectivity Templates' are used for defining how servers and external systems connect to the fabric, not for modifying the core spine-leaf cabling map.

1. Juniper Apstra User Guide 4.2.1, "Blueprints > Staged > Physical > Links". This section of the documentation explicitly details the procedure for viewing and editing device-to-device physical links within the staged version of a blueprint.

2. Juniper Networks TechLibrary, "Day One+: Deploying a Data Center with Juniper Apstra", Chapter 4: "Build Your Network Blueprint". This guide illustrates the workflow, showing that all design changes, including physical topology, occur in the 'Staged' section.

During the Deploy phase Apstra allocates required items (ASN ranges, VLAN/VNI IDs, IP pools, etc.) from the global resource pools without user action. The blueprint consumes the next available values, guaranteeing uniqueness across all blueprints unless the operator overrides them before deployment.

A. Device profiles and assignments are unrelated to automatic pool allocation.

B. Pools exist globally by default; user-created pools are optional, not mandatory.

C. Resources are defined globally, not created within each blueprint.

1. Juniper Networks, “Apstra Resource Pools and Allocation Guide 4.2”, §4 “Automatic Allocation at Deploy Time” (pp. 42-45).

2. Juniper Networks, “Apstra Concepts Guide 4.2”, §3.4 “Global vs Blueprint Resource Pools”.

The exhibit displays the properties of a selected device within the Apstra UI. The key properties shown are "System Type: generic" and "Internal: True". A "generic system" in Apstra is a device connected to the fabric that is not a spine, leaf, or other standard fabric role. The "Internal: True" property signifies that this device is managed by Apstra, meaning an Apstra agent is installed on it, and Apstra is responsible for rendering its configuration. Therefore, the device is correctly identified as an internal generic system.

A. A peer switch would have a specific fabric role, such as 'leaf' or 'spine', not 'generic'.

B. An external generic system would have the property "Internal: False", indicating it is not managed by an Apstra agent.

D. An access switch would typically be assigned the 'access' or 'leaf' role within the Apstra data model, not the 'generic' system type.

1. Juniper Apstra User Guide, "Generic Systems". The documentation distinguishes between internal and external generic systems. It states, "Internal generic systems are managed by Apstra (agent installed)... External generic systems are not managed by Apstra." The exhibit's "Internal: True" property directly corresponds to the definition of an internal generic system.

The "Analytics" tab in the Juniper Apstra UI is the central location for all operational telemetry and time-series data. It contains pre-defined dashboards and probes for monitoring various aspects of the network's health and performance. For capacity planning, an operator would navigate to this tab to find historical and real-time data on metrics such as link utilization, which are collected and visualized by Apstra's analytics engine.

A: The "Active" tab shows the current deployed topology and its real-time state, not historical time-series information for trend analysis.

B: The "Staged" tab is used for designing and modifying the blueprint's intent before deployment; it contains no operational data.

D: The main "Dashboard" provides a high-level, multi-blueprint overview, while detailed time-series data for a specific blueprint is found within its "Analytics" tab.

1. Juniper Apstra User Guide 4.2.1, "Analytics". This section explicitly states, "From the blueprint, navigate to Analytics to see IBA dashboards that are collecting and analyzing relevant data."

2. Juniper Networks, "Automate the Data Center with Juniper Apstra," Courseware. Module 4, "Apstra Operating," demonstrates using the Analytics tab to inspect time-series data for interfaces.

Juniper Apstra's Security Policies define rules for traffic flow between different application groups or network zones. When these abstract policies are rendered and pushed to network devices, they are translated into platform-specific configurations. For Juniper Junos devices, these policies are implemented as firewall filters. For other vendors like Arista EOS or Cisco NX-OS, they are implemented as Access Control Lists (ACLs). Both firewall filters and ACLs are functionally equivalent in this context, serving as stateless packet filters to permit or deny traffic based on defined criteria.

A. Filter-based forwarding (FBF)

FBF is a routing feature that directs traffic to a specific next-hop based on filter criteria, which is different from the permit/deny function of a security policy.

C. Policy-based routing (PBR)

PBR is used to override default routing behavior based on policy, not for implementing the stateless firewall rules defined in Apstra Security Policies.

1. Juniper Apstra User Guide, "Policy". The documentation states, "Apstra policies are rendered as access control lists (ACLs) on the interface of the leaf devices."

2. Juniper TechLibrary, "Day One+: Deploying in the Data Center with Apstra", Chapter 5: Security Policies. This guide explains that Apstra policies are translated into device-specific ACLs or firewall filters to enforce the desired security posture.

Property sets in Juniper Apstra are collections of key-value pairs, typically in JSON format, that function as variables. Their primary purpose is for variable substitution within Jinja2 templates, most commonly used in configlets. When a configlet that references a property set is imported into a blueprint, the property set must also be imported to make the variables available. For modularity, a single configlet can be designed to reference and utilize variables from multiple different property sets simultaneously, allowing for flexible and reusable configuration templates.

C. Property sets are also used in Intent-Based Analytics (IBA) probes, not just configlets, for defining dynamic or reusable probe parameters.

D. The syntax for creating a property set is standard JSON (key-value pairs), which is a vendor-agnostic format defined within Apstra itself.

1. Juniper Apstra User's Guide, "Design > Configlets". This section explains that configlets use Jinja2 templating and can reference property sets for variable substitution. It also shows the workflow of importing both configlets and their associated property sets into a blueprint.

2. Juniper Apstra User's Guide, "Property Sets". This section details the creation and management of property sets, stating, "Property sets are collections of key/value pairs that are used for variable substitution in configlets and IBA probes." This confirms their use beyond just configlets.

A three-stage Clos network, commonly known as a spine-and-leaf architecture, is a foundational design for modern data center fabrics. A key principle is that endpoint devices, such as servers and storage, connect to the leaf switches (the "edge" of the fabric). The spine layer serves as a high-speed backbone, interconnecting all leaf switches. For traffic entering or leaving the data center (North-South traffic), specialized "border leaf" devices are used. These border devices connect to external networks (like the Internet or WAN) and handle the ingress and egress of traffic for the entire fabric.

A. Spines are the core of the fabric and should not have external connections, as this would create a bottleneck and add complexity.

D. Servers connect to leaf devices to provide access to the fabric; connecting them directly to spines would violate the Clos architecture principles.

1. Juniper Networks, "Data Center Fabric Architecture Design Guide", Chapter 2: "Data Center Fabric Architecture". This guide explicitly states, "In a spine-and-leaf architecture, servers and storage devices connect to leaf devices."

2. Juniper Networks, "EVPN-VXLAN Data Center Fabric and DCI", Chapter 2: "Campus and Data Center Designs". This document describes the role of border leaf devices: "Border leaf devices provide Layer 3 connectivity between the data center and external networks."

When a device managed by Juniper Apstra has its configuration changed out-of-band (OOB) via the CLI, Apstra detects this as a "Config Deviation" anomaly. Clicking the "Accept Changes" button instructs Apstra to learn these OOB changes and incorporate them into its rendered or "golden" configuration for that specific device. This action effectively updates Apstra's intent to match the new reality on the device, resolving the anomaly.

A: Apstra does not guess intent or add similar configurations; it incorporates the exact changes that were made out-of-band.

C: Clicking "Accept Changes" resolves the deviation immediately; it does not hold changes pending a "Full Config" push.

D: This describes ignoring the anomaly. Accepting the changes prevents them from being overwritten by the next configuration push from Apstra.

1. Juniper Apstra User Guide 4.2.1, "Anomalies > Config Deviation". The guide explains that accepting changes "updates the pristine configuration with the out-of-band configuration."

2. Juniper Apstra Datasheet. Describes Apstra's role as the "single source of truth," which is maintained by either pushing intent-based config or accepting OOB changes to update the intent.

The Juniper Apstra device agent is a software component installed on managed network devices. Its primary responsibilities are to act as the intermediary between the Apstra controller and the device's operating system. The telemetry agent component collects real-time state, statistics, and logs from the device and streams this data back to the controller for analysis and validation. The deployment agent component is responsible for rendering the intended network configuration based on the blueprint and applying it to the device, ensuring the device's configuration matches the golden configuration.

A. Routing agent: The device's native network operating system (e.g., Junos OS) handles all routing functions. The Apstra agent configures routing protocols but does not perform routing itself.

B. Authentication agent: Device authentication (e.g., SSH, TACACS+) is managed by the device's OS. The Apstra agent authenticates to the device, but it is not an authentication service.

1. Juniper Apstra Documentation, "Device Agents". This document describes the agent's function: "The agent is responsible for all interaction between the device and Apstra, including configuration deployment and telemetry collection."

2. Juniper Apstra User Guide, "Agents". This section explains that agents "execute the generated configuration" (deployment) and "collect telemetry" from the devices they manage.

Juniper Apstra's Intent-Based Analytics (IBA) probes query the Apstra graph database to validate the intended state against the actual operational state of the network. The core component of a probe that specifies which devices, interfaces, or other network objects (represented as nodes in the database) to analyze is the Graph Query. This query selects a set of relevant nodes from the graph database, and the probe's processing logic is then applied to this set.

A. Reference design schema

The reference design schema defines the overall structure and relationships allowed in a blueprint, not the specific objects for a single probe.

C. Database nodes

Database nodes are the objects themselves (e.g., a switch). The graph query is the mechanism used to select these nodes for the probe.

D. Node-edge relationship

This describes the connection between two nodes in the graph database. A graph query traverses these relationships to find the target nodes.

1. Juniper Apstra User Guide, "Intent-Based Analytics > Probes". This section describes the components of a probe, stating, "The first stage of any probe is a graph query that returns a set of nodes."

2. Juniper TechLibrary, "Understanding Apstra Intent-Based Analytics". The documentation explains, "An IBA probe consists of a graph query that selects a set of nodes from the graph..."

Juniper Apstra provides four system-defined user roles that are available in the Apstra GUI

environment. They are: administrator, device_ztp, viewer, and user1. Based on the web search

results, we can infer the following statements:

viewer: This role includes permissions to only view various elements in the Apstra system, such as

blueprints, devices, design, resources, external systems, platform, and others. Users with this role

cannot create, edit, or delete any element12.

user: This role includes permissions to view and edit various elements in the Apstra system, such as

blueprints, devices, design, resources, external systems, platform, and others. Users with this role

cannot create or delete any element12.

authorized: This is not a system-defined user role in Juniper Apstra. It is a term used to describe users

who have been authenticated by an external system, such as LDAP, Active Directory, TACACS+, or

RADIUS3.

root: This is not a system-defined user role in Juniper Apstra. It is a term used to describe the

superuser account on a Linux system, which has full access to all commands and files. Creating a user

in the Apstra GUI does not provide that user access to the Apstra platform via SSH. To access the

Apstra platform via SSH, you must create a local Linux system user4. Reference:

User / Role Management Introduction

User/Role Management (Platform)

AAA Providers

User Profile Management

In Juniper Apstra, resources such as Autonomous System (AS) numbers, IP addresses, and VLAN IDs are managed within pools. These resource pools can be defined with two distinct scopes. They can be created at a global level, making them available for assignment across all blueprints managed by the Apstra controller. Alternatively, a resource pool can be created within a specific blueprint, limiting its scope and usage to only that blueprint. This provides flexibility for both shared resource management and blueprint-specific allocations.

A. User-defined resources are supported.

While this statement is true, it is less precise than option C, which correctly describes the fundamental scoping mechanism for all resource pools, whether default or user-defined.

B. The scope of a pool is limited to a single blueprint.

This is incorrect. Resource pools can also be defined at the global level, making them available to all blueprints.

D. Only the default resources are supported globally.

This is incorrect. Users can create their own custom resource pools at the global level, not just use the default ones.

1. Juniper Apstra User Guide, "Resource Pools". This section explicitly states, "You can create resource pools at the global level (Design > Global) or at the blueprint level (Staged > Blueprint > Resources)."

2. Juniper TechLibrary, "Apstra Resource Management". The documentation details the hierarchy and scope of resource pools, confirming that pools can be either global or blueprint-specific.

Juniper Apstra's ability to scale and manage thousands of devices stems from its core architecture as a distributed state system. Apstra maintains a "single source of truth" for the intended state of the entire network. However, the collection of operational state (telemetry) and the rendering of device configurations are distributed tasks handled by agents running on the network devices themselves. This distributed model avoids overwhelming the central Apstra controller with constant polling and low-level configuration tasks for every device. The controller manages the high-level intent, while the distributed components handle the real-time validation and implementation, enabling massive scale.

A. Apstra can be installed in various environments, including the cloud, but the installation location itself is not the architectural reason for its scalability.

B. NGINX is a web server used for the Apstra UI. It is a component of the system but not the core architectural principle that enables network management scalability.

C. An OVA (Open Virtualization Appliance) is a software packaging and deployment format. It simplifies installation but does not define the internal architecture responsible for scalability.

1. Juniper Networks White Paper, "Apstra: Intent-Based Networking for the Data Center". This paper describes Apstra's architecture, stating, "Apstra software is a distributed system that is constantly comparing the intent with the operational state of the network." It emphasizes the role of distributed agents in collecting telemetry, which is key to scaling.

2. Juniper Apstra Product Documentation, "Apstra System Architecture Overview". The documentation explains the roles of the Apstra server (controller) and the device agents. It highlights that agents perform local data collection and processing, which offloads the central server and allows the system to scale efficiently.

In Juniper Apstra, a Logical Device is an abstract model representing a network device's capabilities, such as the number and speed of its ports. When creating a logical device, you must assign it a role that defines its function within a fabric topology. The primary roles available for devices that form the fabric are Spine and Leaf, corresponding to a Clos architecture. The Generic role is used for devices that connect to the fabric but are not part of the spine-leaf topology, such as external routers or firewalls.

B. Empty: "Empty" is not a recognized role for a logical device in Apstra's design templates. It does not represent a functional component of the fabric.

E. Root: "Root" is a term associated with Spanning Tree Protocol (STP) for loop prevention in Layer 2 networks, not a device role within an Apstra EVPN-VXLAN fabric design.

1. Juniper Apstra User Guide, Section: Design > Logical Devices. The documentation explicitly lists the available roles when creating a logical device. The options include Leaf, Spine, and Generic.

2. Juniper Networks (2021), Apstra Fabric Conductor Administration Guide, Release 4.0. In the section on creating logical devices, the guide states, "Select a role for the device (Spine, Leaf, or Generic)."

When a predefined interface map is modified in the Juniper Apstra global catalog, two key things occur. First, this change does not retroactively affect blueprints that have already imported that map. Blueprints maintain their own local catalog, which contains a copy of the interface map as it existed at the time of import. Second, modifying predefined, vendor-supplied elements is not a supported practice. During a software upgrade, the Apstra system will overwrite any user modifications to these predefined elements with the new default versions included in the upgrade package to ensure system integrity and compatibility.

C. Changes made to predefined interface maps can have a significant negative impact, potentially causing unpredictable behavior or failures during software upgrades.

D. Anomalies are generated based on a mismatch between a blueprint's intent and the operational state. A change in the global catalog does not alter a blueprint's intent.

1. Juniper Apstra 4.2 User Guide, "Design" Section: The guide explains that design elements like Interface Maps are stored in a global catalog and can be imported into a blueprint's local catalog. This architecture implies that once imported, the blueprint's version is independent of the global source. (This concept is fundamental to Apstra's blueprint architecture).

2. Juniper Apstra 4.2 Installation and Upgrade Guide, "Upgrading Apstra Controller" Section: Under the "Important" notes for upgrading, the documentation explicitly states: "Modifying predefined elements (for example, rack types, templates, device profiles) is not supported. If you have modified predefined elements, they will be overwritten during the upgrade process." This directly supports the statement that changes are discarded upon upgrade.