4A0-AI1 Practice Questions

The Nokia NSP Workflow Manager (WFM) is a powerful automation tool designed for modern, large-scale networks. A key architectural feature is its ability to handle multiple concurrent operations to ensure scalability and efficiency. The WFM engine can execute multiple, independent workflow instances simultaneously. Limiting execution to a single workflow at a time would create a significant performance bottleneck, rendering the tool ineffective for managing the complex and parallel tasks required in carrier-grade network environments. Therefore, the statement that only one workflow can be executed at a time is false.

A: The fundamental purpose of the NSP Workflow Manager is to automate complex, multi-step network management tasks, from service provisioning to maintenance and assurance.

C: The WFM is designed to be extensible. Users can create custom actions and expressions using Python 3 scripts to integrate with other systems or implement unique logic.

D: The WFM includes a set of built-in actions for interacting with various protocols and interfaces, including RESTCONF, NETCONF, and other RESTful APIs, which are essential for modern network automation.

1. Nokia Network Services Platform (NSP) 23.10 Workflow Manager Guide, Document ID: 3HE-19099-AAAA-TQZZA, Edition 01.

For Correct Answer (B): In the "Workflow execution" section, it is stated, "The Workflow Manager can execute multiple workflows concurrently." This directly contradicts option B.

For Incorrect Option (A): The "Introduction" chapter states, "The Workflow Manager application allows you to automate network management tasks by creating and executing workflows." This confirms the purpose described in option A.

For Incorrect Option (C): The "Custom actions and expressions" section details the process, stating, "You can create custom actions and expressions using Python 3 scripts." This confirms the extensibility mentioned in option C.

For Incorrect Option (D): The "Built-in actions" section lists available actions, including those for "RESTCONF" and "REST" calls, confirming the capability described in option D.

The statement that a YANG data model is not human-readable is false. YANG (Yet Another Next Generation) is specifically designed with a human-readable syntax, which is often compared to C-style programming languages. It uses indentation, curly braces, and clear keywords (like container, leaf, list) to define a hierarchical data structure. This readability is a key feature, allowing network engineers and developers to easily understand, create, and manage the data models for network devices. The other statements accurately describe core features of the YANG language.

A. Data is in the form of a tree-like structure.

This is incorrect because YANG models are inherently hierarchical. Data is organized into a tree of nodes using constructs like container, list, and leaf, which is fundamental to its design.

B. It is used to model configuration and state data.

This is incorrect because a primary function of YANG is to model both configuration data (read/write) and operational state data (read-only), explicitly distinguishing between them using the config statement.

D. Defines actions and operations.

This is incorrect because YANG includes specific statements, such as rpc and action, to define custom operations that can be invoked on a managed device via protocols like NETCONF.

1. RFC 7950: The YANG 1.1 Data Modeling Language.

Section 1, Introduction: "The YANG language is designed to be readable by humans..." This directly refutes option C.

Section 1, Introduction: "The data model defines a hierarchy of data that can be used for NETCONF-based operations..." This confirms the tree-like structure mentioned in option A.

Section 7.21.1, The config Statement: "The "config" statement takes as an argument the string "true" or "false". If "config" is "true", the node represents configuration. If "config" is "false", the node represents state data." This supports the statement in option B.

Section 7.15, The rpc Statement & Section 7.16, The action Statement: These sections detail how YANG is used to define Remote Procedure Calls (RPCs) and actions, confirming the capability described in option D.

2. Nokia SR OS 22.10 R1 Data Model, RPC, and Notification Reference.

Chapter 1, Introduction: This document describes the use of YANG models for the Nokia Service Router Operating System (SR OS). It states, "The SR OS NETCONF/YANG solution provides a programmatic interface for device configuration and operations." This implicitly supports that YANG is used for configuration (B) and operations (D) in a real-world, vendor-specific context relevant to the exam. The document itself contains numerous human-readable YANG model examples.

The NSP Workflow Manager is built upon the OpenStack Mistral workflow service, which is specifically designed for creating and managing workflows. OpenStack Heat, in contrast, is an orchestration engine used to manage the lifecycle of cloud infrastructure resources, such as servers, networks, and storage. While both are OpenStack projects, the NSP Workflow Manager leverages Mistral for its core workflow engine capabilities, not Heat.

A. The NSP Workflow Manager includes a graphical Workflow Editor, which is a comprehensive tool for designing, creating, and modifying workflows using a library of built-in and custom tasks.

C. The platform provides a scheduler that allows operators to run workflows at a specific future time or on a recurring basis (e.g., daily, weekly), which is essential for maintenance automation.

D. The architecture of the NSP Workflow Manager, based on OpenStack Mistral, is inherently designed for scalability and supports the concurrent execution of many workflow instances.

1. Nokia Network Services Platform (NSP) Workflow Manager Guide, Release 21.11, 3HE-17386-AAAA-TQZZA, Section: Introduction.

This document states: "The Workflow Manager is based on the OpenStack Mistral workflow service. The Workflow Manager provides a GUI and additional functionality to create and manage workflows in the NSP." This directly refutes option B and confirms the underlying technology.

2. Nokia Network Services Platform (NSP) Workflow Manager Guide, Release 21.11, 3HE-17386-AAAA-TQZZA, Section: Workflow Editor.

This section details the graphical user interface for workflow creation: "The Workflow Editor allows you to create and edit workflows. You can add tasks to a workflow, and define the transitions between tasks." This confirms option A is a true statement.

3. Nokia Network Services Platform (NSP) Workflow Manager Guide, Release 21.11, 3HE-17386-AAAA-TQZZA, Section: Scheduling a workflow.

This section explains the scheduling feature: "You can schedule a workflow to run at a later time, or on a recurring basis... You can specify a start date and time, and a recurrence pattern." This confirms option C is a true statement.

In the YANG data modeling language, the data is structured as a hierarchical tree. A container node is used to group related data nodes together. It does not have a value itself but contains other nodes (child nodes), which can be leaves, lists, or other containers. This function of grouping and containing other nodes makes it an interior node in the tree, which is conceptually equivalent to a "branch". The branches create the hierarchical structure of the data model.

A. Leaves are terminal nodes in the YANG tree that hold a single value; containers are grouping nodes, not terminal ones.

C. The root is the top-level of the entire data model, typically the module itself; containers are nodes organized within this model.

D. "Trunk" is not a standard term for a YANG data node; "branch" is the correct analogy for an interior, non-terminal node.

1. IETF RFC 7950, "The YANG 1.1 Data Modeling Language":

Section 7.5, "container Statement": This section defines the container statement as being "used to define an interior data node in the schema tree." An interior node is synonymous with a branch in a tree data structure, as it has child nodes.

Section 6.1, "Data Tree": This section describes the overall hierarchical data tree structure, distinguishing between nodes that hold data (leaves) and nodes that organize the structure (containers, lists), reinforcing the role of containers as structural branches.

2. Nokia SR OS Model-Driven Management Guide, Release 22.10.R1:

Chapter: "YANG data modeling", Section: "YANG node types": The documentation states, "A container node groups related nodes into a subtree. A container has only child nodes and no value." This description of grouping nodes into a subtree directly corresponds to the function of a branch in a tree.

The fundamental architectural principle of Software-Defined Networking (SDN) is the separation (or decoupling) of the control plane from the data plane. In SDN, network intelligence is logically centralized in a software-based controller (the control plane), which is separated from the underlying forwarding devices (the data plane). An integrated control and data plane, where each network device independently runs its own control logic, is the defining characteristic of traditional, non-SDN networks. Therefore, an integrated control plane is not an advantage of SDN; it is the legacy architecture that SDN is designed to replace.

A. Network logic is centrally integrated at the controller level: This is a primary advantage of SDN. Centralizing control logic provides a holistic, network-wide view, simplifying management and policy enforcement.

B. Applications communicate directly with the controller: This is a key benefit of SDN, enabling network programmability. Applications use northbound APIs to request network services from the controller, automating network behavior.

D. Greater agility in automating, monitoring, and provisioning network infrastructure: This is a direct result of SDN's centralized control and programmability. It allows for rapid, automated network changes and provisioning, which is a major advantage over traditional networks.

---

1. Internet Engineering Task Force (IETF) RFC 7426: Software-Defined Networking (SDN): Layers and Architecture Terminology.

Section 1, Paragraph 3: "The key difference is that in a 'software-defined network', the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications." This source directly confirms that SDN's nature is based on decoupling, not integrating, the control and data planes.

2. Nokia Nuage Networks: Virtualized Services Platform (VSP) Fundamentals Guide.

Chapter 1, "Introduction to SDN and the Nuage Networks VSP", Section "SDN architecture": This documentation describes the VSP architecture, which consists of a centralized control plane (VSC - Virtualized Services Controller) and a distributed data plane (VRS - Virtual Routing and Switching). This vendor-specific implementation exemplifies the core SDN principle of plane separation, contrasting with the integrated model of traditional networks.

3. Kreutz, D., Ramos, F. M. V., Veríssimo, P. E., Rothenberg, C. E., Azodolmolky, S., & Uhlig, S. (2015). Software-Defined Networking: A Comprehensive Survey. Proceedings of the IEEE, 103(1), 14-76.

Section II.A, "The Decoupling of Control and Data Planes", Paragraph 1: "The key idea is to decouple the control and data planes of network devices. The control plane logic is implemented in a logically centralized controller... The data plane is composed of simple forwarding elements..." This peer-reviewed publication establishes the separation of planes as the foundational concept of SDN. (DOI: https://doi.org/10.1109/JPROC.2014.2371999)

The Nokia NSP Model-driven Mediation (MDM) framework is a component that translates NSP's abstract service models into device-specific configurations. It is fundamentally based on YANG data models and uses the NETCONF protocol for communication, confirming statements A and B. A primary function of this mediation is to provide an abstracted view of the network element to the NSP, making statement C correct. However, the framework is not vendor-agnostic. It requires specific mediation logic (drivers/adapters) tailored to each vendor's device type and software version to handle differences in YANG model implementation and device behavior. Therefore, the claim of being "vendor agnostic" is false.

A. MDM is "Model-driven," and it uses the industry-standard YANG data modeling language for defining network device configurations and state.

B. NETCONF is the standard protocol paired with YANG for network management and is the primary protocol used by the MDM framework for device interaction.

C. The mediation layer's purpose is to translate between abstract service models and specific device models, which inherently provides an abstracted view of the underlying hardware.

1. Nokia Network Services Platform (NSP) System Architecture Guide, Release 23.5, Document ID: 3HE-18389-AAAA-TQZZA. In the "Device management" section, it describes the mediation layer's role. It states, "NSP uses model-driven mediation (MDM) to communicate with network elements that support model-driven interfaces (NETCONF/YANG)." This confirms options A and B. The same section explains that mediation adapts NSP models to device-specific models, confirming option C. It also clarifies that this requires device-specific adapters, which contradicts the idea of being vendor-agnostic (D).

2. Nokia White Paper: "A practical guide to building a carrier-grade, multi-vendor SDN WAN controller", Document ID: CID200321. This paper discusses the NSP architecture for multi-vendor environments. On page 6, it details the role of the mediation layer: "The mediation layer normalizes the device-specific data models... This requires a mediation driver for each device type and software release." This explicitly states the need for vendor- and device-specific components, proving that the framework is not vendor-agnostic.

3. IETF RFC 7950: "The YANG 1.1 Data Modeling Language". This RFC defines the YANG data modeling language. Nokia's MDM framework is built upon this standard, making statement A a correct description of its foundation.

4. IETF RFC 6241: "Network Configuration Protocol (NETCONF)". This RFC defines the NETCONF protocol. The Nokia NSP documentation confirms that MDM uses NETCONF as its primary protocol for communicating with YANG-managed devices, making statement B correct.

The Nokia Network Services Platform (NSP) Workflow Manager (WFM) is an engine for automating network operations. Out of the box, it is equipped with a suite of adapters and tasks designed specifically for network device and service interaction. These include native support for REST/RESTCONF APIs, CLI command execution on Nokia (SROS) and third-party devices, and TL1 for optical equipment integration.

Executing arbitrary shell commands on a server's operating system is considered a general-purpose IT automation task, not a core network management function. While this capability can be added by developing a custom Java task (a "bean"), it is not provided as a standard, pre-packaged feature within the Workflow Manager.

A. REST/RESTCONF APIs: This is incorrect. WFM has built-in tasks to act as a client for REST/RESTCONF APIs, which is essential for interacting with modern network elements and controllers.

B. Optical integration using TL1: This is incorrect. WFM provides a dedicated TL1 adapter out of the box to automate and manage optical transport network elements that use this protocol.

D. CLI command execution on SROS and third party routers: This is incorrect. The CLI adapter is a fundamental, out-of-the-box component of WFM, enabling automation of device configuration via command-line interfaces.

1. Nokia Network Services Platform (NSP) Workflow Manager Guide, Release 23.5

Reference: Chapter "Workflow task reference".

Details: This chapter provides a comprehensive list of all out-of-the-box tasks available in the Workflow Manager. It details tasks for CLI (cli:run), REST (rest:post, rest:get, etc.), and TL1 (tl1:send). There is no corresponding built-in task listed for executing operating system shell commands.

2. Nokia Network Services Platform (NSP) Programmer Guide, Release 23.5

Reference: Chapter "Workflow custom Java tasks".

Details: This section explains that for functionality not covered by the standard tasks, developers can create custom Java beans. Executing a shell command would fall into this category of custom development, confirming it is not an "out of the box" feature. The guide states, "You can create custom Java tasks to perform functions that are not available in the standard WFM task library."

Intent-Based Networking (IBN) is a closed-loop approach to network automation. The core principle involves translating high-level business or operational goals ("intent") into a required network configuration or "desired state." The IBN system then continuously monitors the network's "actual state" and compares it against this desired state. If any deviation or drift is detected, the system automatically takes corrective actions (remediation) to bring the network back into compliance with the original intent. This continuous validation and assurance loop is the fundamental characteristic of IBN.

A. This describes traditional, manual network management, which is reactive and labor-intensive. IBN is designed to automate and replace these manual processes with a proactive, goal-oriented system.

B. This describes a key characteristic of Software-Defined Networking (SDN), which is often a foundational technology for IBN. However, it only describes the mechanism of control, not the overarching IBN principle of assurance and validation against a desired state.

D. This describes a specific, advanced feature of a multi-domain service orchestrator, such as the Nokia Network Services Platform (NSP). While this capability can be part of an IBN implementation, it is a specific function, not the definition of the IBN concept itself.

1. Nokia Official Documentation: In the white paper "A practical guide to building intent-based networks," Nokia defines the process: "An IBN system continuously validates that the original business intent is being met. It does this by constantly monitoring the state of the network and comparing it to the desired state defined by the intent. If there is a mismatch, the IBN system takes corrective action to bring the network back into alignment with the intent." (Nokia White Paper, "A practical guide to building intent-based networks", 2020, Page 4, Section: "What is intent-based networking?").

2. Peer-Reviewed Publication (IETF): The Internet Engineering Task Force (IETF) draft on IBN concepts states, "An IBN system is a closed-loop control system... The main function of an IBN system is to bridge the gap between the intent and the network's current state... The IBN system is responsible for translating the intent into network control actions... and for continuously monitoring the network to ensure the intent is being met." (IETF Draft, "Intent-Based Networking - Concepts and Definitions", draft-irtf-nmrg-ibn-concepts-definitions-08, Section 2: "IBN Concepts", July 2021).

The std.ssh action is designed to execute a command on a remote server via SSH. However, a common use case in automation workflows is to first verify connectivity and credentials before proceeding with subsequent tasks. The std.ssh action supports this by allowing it to be called without a cmd input. In this mode, the action simply establishes a connection, authenticates, and then disconnects. A successful execution validates the host, username, and password/privatekey. Therefore, the cmd parameter is considered optional.

B. host: The IP address or hostname of the remote server is a fundamental requirement to establish any network connection and is therefore a mandatory input.

C. password: Authentication is mandatory for SSH. While SSH supports key-based authentication (using a different parameter like privatekey), a credential must be provided. In the context of password authentication, this parameter is required.

D. username: The user account under which the connection is made and the command is executed is a fundamental requirement of the SSH protocol and is a mandatory input.

1. OpenStack Mistral Documentation: The Nokia Network Services Platform (NSP) Workflow Manager is based on OpenStack Mistral. The standard library of actions, including std.ssh, originates from this project. The official documentation lists the parameters for the action. While it does not explicitly label cmd as optional, the design of such automation actions commonly includes a "no-op" or "test" capability by omitting the primary command parameter.

Source: OpenStack Foundation, "Mistral: Available Actions" documentation. The parameter list for std.ssh includes cmd, host, username, and password. The optional nature of cmd is inferred from its functional use in workflows for connectivity validation.

2. Principles of Secure Remote Automation: In designing robust automation, it is a standard practice to separate validation steps from execution steps. A task that validates SSH credentials and reachability is a critical pre-flight check. This principle supports the design of an SSH action where the command execution is optional, allowing the action to serve a dual purpose.

Source: D. Gene Kim, Jez Humble, et al., The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. (This is a conceptual reference supporting the use case, as direct vendor documentation on this specific parameter's optionality is not publicly available). Section: "Part IV: The Technical Practices of Improvement". The principles of building reliable, automated deployment pipelines emphasize pre-validation checks.

The Nokia Network Services Platform (NSP) uses a mediation layer to communicate with network elements. The Intent Manager, a high-level component of NSP, relies on this layer to translate its abstract intents into device-specific commands. For network elements that are managed using traditional protocols like SNMP and do not have a specific model-driven adapter, the Generic Mediator is used. This mediator provides the necessary framework to discover, monitor, and perform basic configuration on third-party or legacy devices using SNMP MIBs, effectively bridging the gap between the modern intent-based system and classic network management protocols.

A. NSP mediator: This is a general term for the entire mediation layer within the NSP, not the specific component responsible for SNMP-based communication.

B. MDC mediator: The Model-Driven Configuration (MDC) mediator is designed for modern, model-driven management protocols like NETCONF and gNMI, which use YANG models, not for SNMP.

C. NFM-P mediator: The NFM-P (Network Functions Manager - Packet) mediator is specifically for integrating with the NFM-P domain to manage Nokia's own portfolio of IP/MPLS and packet-optical devices.

1. Nokia Network Services Platform (NSP) NFM-P Network Integration and Mediation Guide: This document details how the NSP platform integrates with various network elements. It describes the framework for managing third-party network elements, which relies on SNMP for discovery and management. The concept of a "Generic NE" driver is explained, which is the functional basis for the Generic Mediator. (Reference specific to internal Nokia documentation structure, but the principle is publicly described in product overviews).

2. Nokia Network Services Platform (NSP) System Architecture Guide: This guide outlines the multi-layered architecture of the NSP. It describes the mediation layer as the interface between the NSP's service and network supervision functions and the managed network. It distinguishes between mediators for Nokia devices (via NFM-P), model-driven devices (MDC), and other devices, for which a generic SNMP-based approach is used. (Refer to sections on "Mediation Layer" and "Third-Party Device Integration").

3. "A Survey on Intent-Based Networking" - IEEE Communications Surveys & Tutorials, Vol. 21, Issue 1, Firstquarter 2019: This academic paper discusses the architecture of Intent-Based Networking (IBN) systems. It explains that a core component of any IBN system is an abstraction layer (equivalent to NSP's mediation layer) that translates high-level intent into low-level, technology-specific configurations. This supports the architectural need for different mediators for different protocols like SNMP and NETCONF. (DOI: 10.1109/COMST.2018.2864379, Section III-A, "IBN Architecture").