SkillTestPro | CCNP 300-435 ENAUTO Practice Test 1

CCNP ENAUTO 300-435 Practice Test 1 (Hard) - OpenConfig, IETF & Native YANG Models

CCNP Enterprise logo

1 / 10

An automation architect is building a Python-based configuration tool that must manage interface descriptions and admin state consistently across a mixed fleet of Cisco IOS-XE, Juniper, and Arista devices from a single codebase. Which category of YANG model should the architect target for the interface configuration payloads, and why?

IETF ietf-interfaces models, because IETF status automatically implies every vendor implements every leaf identically with no deviations, making cross-vendor scripting trivial with zero extra handling.

Whichever model the NETCONF server advertises first in its <hello> capabilities list, since capability ordering reflects vendor recommendation for automation use.

Cisco-IOS-XE-native models, because native models are guaranteed to be present on every vendor's platform and offer the richest configuration coverage regardless of manufacturer.

SNMP MIB-derived YANG models, because SMIv2-to-YANG translation produces models that are inherently vendor-agnostic and preferred for multi-vendor automation.

OpenConfig models, such as openconfig-interfaces, because they are vendor-neutral models designed by an operator-driven consortium specifically so that the same container/leaf structure (for example interfaces/interface/config/description and .../config/enabled) can be reused unmodified against any participating vendor's implementation, minimizing per-vendor branching logic in the tool.

A custom YANG module authored by the architect and pushed to each device, since only self-authored modules can guarantee identical leaf names across unrelated vendor implementations.

2 / 10

A programmer working against a Cisco IOS-XE native YANG model (Cisco-IOS-XE-native) needs to retrieve the interface counters and current oper-status of GigabitEthernet1, but notices the native module itself does not define separate /config and /state containers the way OpenConfig does. How should the engineer correctly obtain this operational data using NETCONF?

Add a custom 'state' container to the native YANG module client-side and send it in the RPC filter, which the device will populate automatically even though the server-side schema never defined it.

Issue a <get-config> against the running datastore, since running always includes derived operational counters for native models even though it does not for OpenConfig models.

Native models cannot expose operational state at all, so the engineer must fall back to SNMP polling for counters and oper-status regardless of NETCONF/YANG support.

Use <edit-config> with operation="read" against the candidate datastore, since candidate always reflects live operational values in Cisco IOS-XE implementations.

Query the NMDA operational datastore (<get-data> with datastore=operational, or the legacy <get> operation) as defined in RFC 8342, since NMDA provides a unified operational datastore that returns both the applied configuration and system-maintained state for any schema node, including native models that were never restructured with explicit OpenConfig-style config/state split containers.

Request the data over RESTCONF only, since NETCONF is defined by RFC 6241 as a configuration-only protocol incapable of returning any operational state under any circumstance.

3 / 10

An engineer is writing a NETCONF payload to configure a new eBGP neighbor using the OpenConfig BGP model (openconfig-bgp augmenting openconfig-network-instance). Where in the model hierarchy does the neighbor configuration belong, and what serves as its list key?

Under /network-instances/network-instance[name]/protocols/protocol[identifier='BGP'][name]/bgp/neighbors/neighbor, where the neighbor list is keyed by neighbor-address (the peer's IP address), with peer-level leaves such as peer-as and enabled placed inside that neighbor entry's config container.

Under /interfaces/interface/routing-protocols/bgp/neighbor, since OpenConfig ties all routing protocol adjacencies to the physical interface they egress rather than to a network-instance.

Under /routing-policy/bgp/neighbors, since neighbor definitions are considered routing-policy objects rather than protocol configuration in the OpenConfig schema.

Directly under /bgp/neighbor at the module's top level, keyed by an autoincrementing integer neighbor-id assigned by the device rather than by IP address.

Under /system/bgp/peer-groups/peer-group, since OpenConfig models individual eBGP neighbors exclusively as members of a mandatory peer-group construct with no standalone neighbor list.

Under /network-instances/network-instance/protocols/protocol/bgp/global/neighbor, since neighbor entries are children of the 'global' container that also holds the local AS number.

4 / 10

While reviewing openconfig-if-ethernet.yang, an engineer sees it does not define its own top-level 'interfaces' container but instead adds ethernet-specific nodes (like port-speed and duplex-mode) into the existing tree defined by openconfig-interfaces.yang. Which YANG language construct enables this, and what is its purpose?

The 'extension' statement, which defines new YANG statement types and is how Cisco vendor-specific ethernet leaves are spliced into the standard interfaces tree.

The 'import' statement alone, since importing a module automatically merges all of its top-level containers into the importing module's own schema tree at the root.

The 'deviation' statement, which lets a module remove or alter nodes another module defines to match a specific implementation's limitations, and is how ethernet-specific leaves are merged into openconfig-interfaces.

The 'augment' statement, which lets one module inject additional nodes at a specified target path in another module's schema tree (here, adding an 'ethernet' container under interfaces/interface in openconfig-interfaces), so that interface-type-specific data can be layered onto a common base model without modifying the base module itself.

The 'submodule'/'belongs-to' mechanism, which requires openconfig-if-ethernet to be compiled as a submodule of openconfig-interfaces sharing one namespace, rather than existing as an independently augmenting module.

The 'grouping' and 'uses' statements, which physically copy the entire openconfig-interfaces schema into openconfig-if-ethernet.yang, producing a single merged top-level container owned by the ethernet module.

5 / 10

An engineer inspecting the Cisco-IOS-XE-native.yang module notices its structure very closely parallels the IOS-XE CLI, e.g. a top-level container 'native', a list 'interface', and a child list 'GigabitEthernet' keyed by name, with leaves matching CLI keywords like 'description' and 'shutdown'. What does this tell the engineer about how to construct edit-config payloads against this model?

The payload structure should be built by mentally walking the CLI configuration hierarchy, since native models are essentially a direct, largely 1:1 YANG rendering of the platform's CLI command tree, so a leaf such as native/interface/GigabitEthernet/description maps to the 'description' command issued under 'interface GigabitEthernet1' in CLI, unlike OpenConfig which normalizes structure independent of any one vendor's CLI.

The native model is simply a wrapper around OpenConfig, so the same openconfig-interfaces payload can be submitted unchanged against the native namespace and Cisco IOS-XE will silently translate it.

Native models never contain 'list' or 'container' keyed structures for interfaces; instead every interface is a single flat leaf-list of interface names with no per-interface configuration nodes.

The close CLI resemblance means the native model omits namespaces entirely, so edit-config payloads targeting it do not require an xmlns declaration the way OpenConfig payloads do.

Since the model mirrors CLI syntax exactly, any valid Cisco IOS CLI command can be sent unmodified as the body of a NETCONF <edit-config> RPC without translation into XML/YANG element structure.

Because it mirrors the CLI, the native model has no formal YANG schema and payloads must instead be sent as raw CLI text strings wrapped in a generic <config> element with no XML structure.

6 / 10

A Cisco IOS-XE platform's implementation of the standard ietf-ip.yang module does not support every leaf defined by the upstream IETF module, for example omitting support for a particular optional feature. Cisco publishes an accompanying Cisco-IOS-XE-ietf-ip-deviation.yang file alongside it. What is the purpose of a YANG deviation module in this context?

It replaces the entire ietf-ip module with a completely different namespace and node structure, meaning ietf-ip effectively no longer exists on the device once a deviation module is loaded.

It is a YANG extension used exclusively for defining vendor-proprietary RPCs, unrelated to modifying support for existing standard module nodes.

It defines additional optional features an operator may enable via a feature-flag CLI command, but has no effect on which standard leaves the device actually supports.

It is only used by RESTCONF servers to translate JSON payloads into XML for NETCONF; NETCONF servers ignore deviation files entirely.

It silently patches the running ietf-ip module in memory so that clients never need to be aware any deviation exists, since deviation files are purely internal to the device and are never advertised to NETCONF/RESTCONF clients.

It formally documents, using the 'deviation' statement, exactly how this specific implementation diverges from the standard module's schema (for example deviating a node to 'not-supported', or narrowing its type/default), so that clients parsing the server's advertised YANG modules and deviations can programmatically determine which parts of the standard model are safe to use on this platform before constructing a payload.

7 / 10

Comparing OpenConfig's openconfig-interfaces module to Cisco's native interface model, an engineer notices OpenConfig explicitly separates every configurable leaf into a /config container and its corresponding operational value into a /state container (both often holding a leaf of the same name, e.g. config/description and state/description). What is the primary design rationale behind this OpenConfig config/state split?

OpenConfig's config/state split means /config leaves can only be modified via RESTCONF while /state leaves can only be modified via NETCONF, ensuring protocol-level separation of duties.

It reflects a security boundary: /config is only readable by administrators while /state is readable by any authenticated user, enforced natively by the YANG schema itself.

It was required because early NETCONF servers physically could not process a <get> RPC, so /state was invented as the only way to retrieve any interface data at all prior to RFC 8342 (NMDA).

The split exists solely so pyang can auto-generate two separate tree diagrams per module; it has no bearing on client/server RPC behavior at runtime.

It exists purely for XML payload size reduction; duplicating leaves under /config and /state has no semantic meaning and either container can be used interchangeably for both reads and writes.

It lets a client cleanly distinguish the intended configuration it wrote (or last read as configured) from the actual, possibly divergent, operationally applied and reported value, which is useful for verifying that a pushed configuration actually took effect and for reading purely derived/read-only telemetry-style data (like oper-status or counters) that has no corresponding writable /config counterpart.

8 / 10

An automation team notices that openconfig-interfaces.yang includes a statement like 'openconfig-extensions:openconfig-version "3.4.0";' near the top of the module. If the team upgrades to a newer release of the module where this version string changes from 3.4.0 to 4.0.0, what should the team infer and do, following OpenConfig's semantic versioning convention?

A major version bump (3.x to 4.0.0) signals a backward-incompatible schema change under OpenConfig's semantic versioning scheme, so the team should treat this as a breaking change requiring careful review and likely code updates (e.g., renamed or removed nodes), rather than assuming existing payloads and parsing logic will keep working unmodified.

Since OpenConfig is a Cisco-only initiative, the version number reflects the specific Cisco IOS-XE release train the module ships with, unrelated to schema compatibility across releases of the module itself.

A change from 3.4.0 to 4.0.0 always indicates a purely additive, fully backward-compatible change, since OpenConfig only increments the major digit for new optional leaves and never for breaking changes.

The version digits (major.minor.patch) refer to the YANG language version the module compiles under (YANG 1.0 vs 1.1 vs 1.2), not to the module's own compatibility history.

The version string is purely informational metadata with no defined semantics in OpenConfig tooling or conventions, so no special action is required regardless of which digit changes.

Because OpenConfig models are IETF standards-track documents, any version change requires a full new RFC number, meaning openconfig-version numbers are unrelated to compatibility and instead track IETF document revisions.

9 / 10

An engineer needs to automate a Cisco IOS-XE-specific capability, Flexible NetFlow exporter configuration with vendor-specific export-protocol tuning options, and finds that no OpenConfig module models this feature at the required level of detail. What is the most appropriate modeling approach for this specific automation task?

Use the applicable Cisco native YANG model (e.g., under Cisco-IOS-XE-native or a dedicated Cisco flow-monitor native module) to configure the feature, since OpenConfig's model coverage is intentionally focused on common, cross-vendor operational constructs and does not yet cover every platform-specific feature, and native models remain the correct tool for capabilities OpenConfig has not modeled.

Wait for a future OpenConfig release, since submitting configuration through any YANG model other than OpenConfig is considered unsupported practice by Cisco regardless of feature coverage.

Downgrade the requirement and use SNMP SET operations exclusively, since SNMP MIBs always provide complete coverage for any feature missing from OpenConfig.

Use the ietf-interfaces IETF model instead, since IETF standard models are guaranteed to be a strict superset of every vendor's native feature set, including Flexible NetFlow.

Conclude that the feature cannot be automated via YANG at all and must be configured manually via CLI forever, since OpenConfig's lack of coverage means no YANG-based path can ever exist for it.

Force the configuration through openconfig-interfaces by placing Flexible NetFlow leaves as a vendor extension directly beneath /interfaces/interface/config, since any missing feature can always be shoehorned into the nearest existing OpenConfig container.

10 / 10

While constructing a NETCONF edit-config payload for openconfig-interfaces, an engineer needs to set the interface type leaf, which is defined with type 'identityref' based on the base identity 'ianaift:InterfaceType' from the IANA-maintained iana-if-type module. For a physical Ethernet interface, what value should this leaf be set to, and why does the model use an identityref here rather than a plain string or enumeration?

The leaf should be set to the plain string "ethernet", since identityref types in YANG are simply syntactic sugar for an unconstrained string type with no validation against any defined identity set.

The leaf should be left unset for physical Ethernet interfaces, since identityref-typed leaves are, by YANG definition, always operational/read-only and cannot be configured by a client.

The leaf should be set to "GigabitEthernet", matching the Cisco IOS-XE CLI interface type keyword, since OpenConfig identityref values are always derived from the platform's own CLI naming.

The leaf should be set to an integer ifType value such as 6 (matching the legacy IF-MIB ifType OID value), since identityref in YANG always resolves to the corresponding SNMP integer code.

The leaf should be set to the identity value ianaift:ethernetCsmacd, and identityref is used (instead of a plain string or a closed enumeration) because it lets the type value be drawn from an extensible, centrally maintained set of identities defined in the IANA iana-if-type module, allowing new interface types to be added over time without requiring every referencing module (including OpenConfig's) to be revised.

The leaf should be set to "1" representing a boolean 'is-ethernet' flag, since identityref types in YANG 1.1 are restricted to boolean semantics only.

Your score is

The average score is 0%