Automation practice questions

RESTCONF

Why wrong: RESTCONF is a model-driven network management protocol that uses HTTP methods (GET, POST, PUT, DELETE) to manipulate YANG-defined data structures over HTTPS. It is designed for structured, API-based device configuration and state retrieval, not for emulating CLI commands or interacting with a device's command-line interface. Backing up a running configuration via CLI requires an SSH/CLI transport, which RESTCONF does not provide, making it unsuitable for this specific task.

Ansible

Why wrong: Ansible is an open-source automation platform that uses YAML playbooks and modules (e.g., ios_command, ios_config) to manage network devices over SSH or other protocols. While Ansible can automate configuration backups, it is a standalone tool requiring an Ansible control node and inventory, not a Python library that can be directly imported into a custom script. Because the engineer needs to integrate SSH-based backup into a Python automation workflow, Ansible would be an external orchestration layer, not the underlying SSH connectivity library.

Netmiko

Why wrong: Netmiko is a high-level Python library built on top of Paramiko that abstracts away many SSH and CLI complexities for network device interaction. While Netmiko could also be used to automate configuration backups and is convenient for multi-vendor support, the question specifically targets the underlying SSH library that provides raw SSH connectivity — which is Paramiko. Netmiko adds a layer of device-specific command handling and expects a deterministic CLI prompt, whereas Paramiko is the actual SSH protocol implementation that Netmiko relies on; thus Paramiko is the more fundamental correct answer.

The switch has not been discovered by DNA Center

Why wrong: A switch in the 'Managed' state inside DNA Center has already passed the discovery and inventory phases, so it is present in the inventory with a reachable SSH/NETCONF transport. Therefore, the failure to apply a CLI template cannot be attributed to the switch not being discovered; that prerequisite is already satisfied. Discovery is the first step but is not the root cause here.

The switch is not in Plug and Play mode

Why wrong: Plug and Play (PnP) is used exclusively for zero-touch onboarding of new or replacement devices before they are fully managed, typically on the LAN Automation or PnP page. Once a switch is already being managed by DNA Center and has been discovered, the configuration workflow uses the Provisioning/Compliance engine, not PnP, to deploy templates. Consequently, PnP mode is not a condition for template application to an existing device.

The switch does not have a valid DNA license

Why wrong: A missing or invalid DNA license on the switch would be reflected as a licensing compliance issue or capacity mismatch in the inventory, and DNA Center uses Smart Licensing on the controller side. Template rendering and deployment are performed through standard device configuration protocols like SSH or NETCONF, which work regardless of the device's DNA licensing state, as long as the device is reachable and credentials are valid. Therefore, licensing is not the reason a template fails to apply.

Set ansible_ssh_private_key_file in the inventory but omit the passphrase

Why wrong: Setting ansible_ssh_private_key_file in the inventory tells Ansible which private key file to use for SSH connections, but it does not unlock that key. If the key is encrypted with a passphrase, Ansible cannot read it without the passphrase, and simply omitting the passphrase from the inventory or command line will not bypass that requirement. The key must be decrypted and loaded into the SSH agent, which is exactly what ssh-add accomplishes; otherwise, the SSH connection will fail with a 'Permission denied' error, even though the key file path is correct.

Set ansible_user to the correct username in the inventory

Why wrong: Configuring ansible_user to the correct username in the inventory is necessary for any SSH connection, but it only defines the SSH login identity, not the authentication mechanism. A username alone cannot authenticate to a device that requires a specific private key, especially one protected by a passphrase. Ansible still needs an available, decrypted key, either via the SSH agent or an explicit passphrase, so this setting alone does not solve the passphrase issue or load the key into the agent.

Enable keyboard-interactive authentication on the IOS devices

Why wrong: Enabling keyboard-interactive authentication on the IOS devices would allow interactive password or challenge-response authentication, but it is unrelated to SSH key authentication. The problem here is a passphrase-protected private key, not a password prompt needing a keyboard-interactive exchange. IOS devices would still require the key to be presented, and keyboard-interactive would not make Ansible supply the passphrase, so this option fails to address the key-loading requirement and could even introduce an unintended security weakness by enabling interactive login methods.

SNMP community strings are misconfigured

Why wrong: SNMP community strings are used for read/write access to a device's MIB, enabling Catalyst Center to poll performance metrics and apply configuration via SNMP. If the community strings are misconfigured, Catalyst Center would fail to authenticate SNMP requests, causing inventory polling to fail and the device to be marked as 'Unreachable' in the GUI. However, this does not indicate a loss of IP-level reachability—the device would still respond to ICMP echo requests. The root cause would appear as SNMP authentication timeouts, not as a network path failure.

Devices were reassigned to different roles

Why wrong: Device roles in Catalyst Center are logical designations such as access, distribution, core, or border, used for applying network profiles and intent-based policies. Reassigning these roles updates the design hierarchy and can trigger template re-provisioning, but it does not modify the device's IP address, routing tables, or management plane access. Consequently, a role reassignment cannot make an appliance lose IP connectivity to the devices. The symptom would be a policy or configuration drift issue, not an 'unreachable' state in the inventory.

Certificate trust between devices and Catalyst Center expired

Why wrong: Certificate trust between Catalyst Center and managed devices is used for encrypting and authenticating management sessions, such as NETCONF over SSH or TLS-based telemetry. When the trust expires, the secure channel fails to establish, and the device may report errors like 'certificate validation failed', but the underlying IP connectivity remains intact. The device is still pingable and can be reached on the network layer; only the cryptographic handshake fails. Therefore, an expired certificate would not cause the appliance to lose contact with the device at the network layer.

The RESTCONF API returned an error but the script ignored it

Why wrong: 201 Created indicates success.

The loopback interface number is incorrect in the URI

Why wrong: The URI syntax is correct.

The script is not authenticated properly

Why wrong: Authentication errors would return 401 or 403.

The connection timeout is set too low

Why wrong: The 'SSH session not active' exception is distinct from a timeout. If connect_timeout were set too low, Netmiko would raise NetmikoTimeoutException with a socket time-out message, not an internal Paramiko state error. Timeout errors occur before or during the TCP/SSH handshake, while this specific exception indicates the Paramiko transport object exists but its SSH session has become inactive.

The device has reached the maximum number of SSH sessions

Why wrong: Hitting the maximum SSH sessions on a Cisco device causes the server to reject the transport-layer negotiation with a 'connection refused' or 'no more session' error, not an 'SSH session not active' error. Netmiko would surface this as a connection error or as an authentication failure during the handshake. The error implies the client-side transport has been closed, not that the server refused to establish a new session.

The device requires an enable password but none was provided

Why wrong: An enable password governs the transition from user EXEC to privileged EXEC mode after SSH has already been authenticated. Netmiko's `secret` parameter is used only after the SSH session is up, so a missing enable password would cause a failure in entering enable mode, not an inactive SSH session. The SSH transport itself remains active and the error would be a separate failure message.

Ohai

Why wrong: Ohai is a system inventory and data collection service embedded within the Chef architecture. When the Chef client converges a node, Ohai first runs to gather platform, hostname, network interface, memory, and other system attributes, which are then exposed to recipes as node attributes. It does not apply any configuration, execute resources, or enforce policy; it is simply the fact-gathering layer that feeds information to the Chef client. Thus, while it is part of the process, it is not the component responsible for automating network device configuration.

Chef workstation

Why wrong: The Chef workstation is a separate development environment used by network engineers or automation engineers to author, modify, and test cookbooks, recipes, and policies. These artifacts are uploaded from the workstation to the Chef server for distribution, but the workstation itself never runs on managed devices and does not participate in enforcing configuration. It is a tool for creating automation content, not the agent that executes it on network devices, so it cannot be the answer.

Chef server

Why wrong: The Chef server functions as the central repository and control plane for the Chef architecture, storing cookbooks, node metadata, policies, and search indexes. It exposes an API that Chef clients use to retrieve their run lists and cookbooks, and it tracks node check-ins and compliance status. However, the server never resides on or directly configures network devices; it only serves the configuration data to the Chef client that runs on each device. Therefore, it is infrastructure that supports automation rather than the component that performs the device configuration.

The device is in a different VRF and not reachable

Why wrong: Even if the device resides in a different VRF, the engineer has already confirmed that it is reachable from the control node (e.g., via ping or SSH). A VRF mismatch would typically manifest as a timeout or 'unreachable' error during the connection phase, but since reachability was verified, the playbook would at least be able to open a connection. Therefore, VRF placement cannot be the reason the playbook is failing; the issue lies elsewhere in the Ansible configuration or task definition.

The ACL syntax in the playbook is incorrect

Why wrong: If the ACL syntax in the playbook were truly invalid, Ansible would return a syntax or parsing error during the 'getting started' phase or when the ios_config module attempts to validate the proposed configuration. Such an error would be explicit and would prevent the play from running further, not cause a generic failure before any device interaction. Since the troubleshooting is centered on the playbook failing to connect or execute properly, incorrect ACL syntax is not the root cause; it would be an execution-time error, not a connectivity/precondition issue.

The ios_config module requires the netmiko library to be installed on the control node

Why wrong: The ios_config module, like all native Ansible network modules, uses Ansible's own connection layer–network_cli–which handles SSH natively and is independent of the Netmiko library. Netmiko is an external Python library used by other automation scripts or legacy modules, but it is not a prerequisite for Ansible's network modules. Installing Netmiko on the control node would not change the behavior of the playbook; the failure is due to the missing connection plugin configuration, not a missing third-party library.

The loopback interface is administratively down

Why wrong: The exhibit shows the loopback interface in an up/up state, so administratively down is factually incorrect. Even if it were down, loopback interfaces are logical and do not carry physical signals, and Ansible's ios_config module is manipulating the running configuration rather than interface state. Since the playbook is already reaching the device to execute configuration changes, a down interface cannot be the reason the intended commands are not applied.

The playbook is sending the wrong CLI commands

Why wrong: The CLI commands in the playbook are syntactically correct and would produce the desired configuration if they were actually pushed to the device. The problem is not the command strings themselves but the module's behavior: by default, ios_config merges changes and does not explicitly remove commands that conflict with the intended state, so existing CLI commands may remain. Therefore, the wrong-commands explanation confuses the module's merge-and-compare logic with a typographical or syntactical error.

The SNMP community strings are not configured correctly

Why wrong: The ios_config module is a network_cli-based Ansible module that connects to the IOS device over SSH, not over SNMP. SNMP community strings are used for read/write management via SNMP protocols, such as for monitoring traps or occasional writes, and play no role in Ansible's configuration workflow. Misconfigured community strings would not prevent the playbook from establishing its SSH connection or from executing configuration commands, so they are irrelevant to the failure.

The script is not authenticated

Why wrong: A RESTCONF server must authenticate every request before processing; if the script lacked credentials, the server would respond with 401 Unauthorized, and the payload would never be processed. The HTTP 201 Created status in the exhibit is definitive proof that the request's authentication (e.g., HTTP Basic, token, or client certificate) was accepted and the resource was created. An unauthenticated client cannot receive a 201, so this is not the cause of the failure.

The URI should be /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1

Why wrong: When using POST to create a new list entry, RESTCONF targets the collection URL—here /restconf/data/ietf-interfaces:interfaces/interface—and the new instance's key is supplied in the JSON payload, not as a path suffix. A URL with `interface=GigabitEthernet1` would address an existing resource and would be correct for a PUT, PATCH, or DELETE, but not for a POST create. The exhibit's URI is therefore the correct endpoint for the request being made, so this is not the problem.

The JSON syntax is invalid

Why wrong: The exhibit's payload is well-formed JSON; all braces, brackets, quotes, and commas align correctly, so a JSON parser will accept it without error. RESTCONF distinguishes between a parse error and a YANG validation error: a syntax problem would trigger an `invalid-json` error before any data-model processing, whereas the observed failure occurs during semantic validation. Thus, invalid JSON cannot be the cause given the error type described.

Reduce the collection frequency to every 4 hours

Why wrong: Lowering the collection interval to every 4 hours does not address the underlying cause of the timeout. The script still iterates through 500 devices sequentially within a single run, so the total execution time remains unchanged and will still exceed any fixed timeout threshold. This change merely reduces how often the problem occurs, not the problem itself, and could degrade monitoring granularity.

Replace Netmiko with SNMP polling using the pysnmp library

Why wrong: Switching to SNMP polling with pysnmp changes the data-collection paradigm entirely: SNMP requires every router to have an SNMP agent configured with community strings or credentials, and it can only return OIDs defined in MIBs, not arbitrary CLI output or show commands. While SNMP GETs are lightweight and could be parallelized, the missing metrics or the need to rewrite the entire collection logic makes this a non-trivial replacement that does not directly solve the existing timeout issue. It also adds operational overhead for SNMP configuration and security policy.

Use Ansible playbooks instead of a custom Python script

Why wrong: Ansible can parallelize device connections using the 'forks' parameter, but a default of 5 concurrent forks is often insufficient for 500 devices, and the control node's SSH connection handling can still hit timeout or performance bottlenecks. The playbook approach also shifts to a different automation framework, requiring inventory management and YAML task definitions, and does not inherently fix the root cause—the need for concurrent connections. If forks are not explicitly increased and connection timeout values not tuned, the same timeout behavior will persist.

The NETCONF server is using a non-standard port

Why wrong: The NETCONF over SSH transport uses the well-known TCP port 830 (or occasionally port 22) on Cisco IOS XE. Since the administrator can successfully open an interactive SSH session, the router is definitely listening on the standard SSH port, meaning the NETCONF client is also reaching the correct port. A non-standard port would cause a TCP connection failure before any SSH handshake, which is not the symptom observed here.

The routers have reached the maximum number of SSH sessions

Why wrong: IOS XE routers have a finite number of VTY lines and concurrent SSH session limits, but those limits apply uniformly to all SSH sessions, including interactive ones. The existing SSH session used by the administrator is working, which proves the router has not exhausted its available SSH session slots. If the maximum had been reached, even the interactive SSH login would fail, so this option cannot explain a failure that only affects the NETCONF client.

The 'netconf ssh' command was removed from the router configuration

Why wrong: The `netconf ssh` command explicitly enables the NETCONF server over SSH on IOS XE, and the command is still present in the router configuration. Therefore, the NETCONF feature itself is active and listening for connections. The failure must be occurring at a lower layer, such as the SSH transport or authentication, rather than because the service is disabled.

Ansible lacks the appropriate module for VLAN configuration

Why wrong: Ansible does have a dedicated ios_vlan module (part of the cisco.ios collection) specifically for creating and modifying VLANs on IOS devices. If the module were truly missing, the playbook would fail on every switch with a 'module not found' or similar error during task resolution, not on just one host. The fact that only a single switch experiences a CLI-level error while others succeed proves the module is present and functional.

The inventory file has a syntax error for that specific host

Why wrong: Ansible parses the entire inventory file (whether INI or YAML) before executing any tasks, so a syntax error on any host would cause the playbook to abort with a parse error before a single device is contacted. That would affect all hosts, not produce a per-host CLI error on one switch. A syntactically invalid host definition cannot be reached individually because the inventory cannot be loaded at all.

SSH connectivity to the switch is blocked by an ACL

Why wrong: If SSH to the switch were blocked by an ACL, Ansible would fail to establish a transport connection, timing out or receiving a connection refused before any CLI command is sent. That would produce an unreachable or connection failure message, not a CLI parsing error about VLAN syntax. Since the reported error is specifically a command rejection from the device (e.g., 'invalid input'), the switch was reachable and the failure occurred at the configuration stage, making an ACL blocking SSH an unlikely cause.

Use a single source of truth for all configurations

Why wrong: Centralizing configurations in a single source of truth (e.g., GitOps or IaC templates) improves consistency and auditability, but it does not inherently provide any failure-recovery capability. The source of truth merely describes the desired state; if a bad configuration is committed, that bad state becomes the new desired state. Without a separate rollback mechanism (like snapshots or prior-state retrieval), a single source of truth cannot restore service after a failed deployment.

Implement idempotent configuration scripts

Why wrong: Idempotent configuration scripts ensure that repeated runs converge to the same end state without duplicating or conflicting changes, which is valuable for consistency but does not help after a bad change is applied. If a script is idempotent but contains a faulty configuration, running it again will simply reapply that same faulty configuration, making the problem reproducible rather than recoverable. True rollback requires the framework to know and restore a prior good state, which is a distinct capability from idempotency.

Run the deployment in a lab environment first

Why wrong: Running the deployment in a lab environment first is a good validation practice, but it does not provide a recovery mechanism for the production rollout. Lab testing can only reduce the probability of a failure by catching many errors early; it cannot guarantee that production failures won't occur due to scale, traffic patterns, or third-party dependencies. Since downtime can still happen, the pipeline must have a way to restore service (rollback) rather than relying solely on pre-production validation to prevent all issues.

OSPF does not support changing costs on multiple routers at the same time

Why wrong: OSPF fully supports changing the cost value on multiple routers simultaneously; the `ip ospf cost` command can be applied per interface or via the auto-cost reference bandwidth on any number of devices. The underlying limitation is not an inability to change costs, but rather that applying all changes at once disrupts the synchronized link-state database, preventing a stable, loop-free topology from being computed before the next change arrives.

OSPF uses hop count as a metric, and the changes caused a count-to-infinity issue

Why wrong: OSPF is a link-state protocol that uses a dimensionless cost metric derived from interface bandwidth (or manually assigned values), never hop count. The count-to-infinity problem is exclusive to distance-vector protocols like RIP, where routers increment a hop metric and exchange routes gradually. OSPF floods LSAs to build a complete topology map on every router, so no hop-count countdown or routing-loop count-to-infinity mechanism exists.

The OSPF cost values were changed to non-standard values that OSPF cannot process

Why wrong: OSPF accepts any cost value within its 16-bit range (1–65535); values like 10, 1000, or even 50,000 are perfectly legal and processed normally by the SPF algorithm. While unusually large or small costs alter how paths are selected, they never cause the protocol to malfunction or drop routes. The problem in this scenario is not an invalid metric but a topology-change synchronization failure, not a data-format or range issue.

The router's Chef client encountered a syntax error and stopped mid-execution

Why wrong: A syntax error in a Chef cookbook prevents the client from even completing the compile phase, which happens before any resource is converged. Consequently, the Chef client would abort the entire run without applying any changes, so the SNMP community could not be partially removed. The failure would also generate a visible exception in the chef-client output, not a silent loss of management access.

The cookbook accidentally applied a 'private' community string instead of 'public'

Why wrong: If the cookbook had inadvertently set the community string to 'private', the resource would typically call :create with a new community name, leaving the existing 'public' string intact unless a separate :delete action targeted it. The observed symptom is that 'public' is missing, not that a different string exists, so this option cannot explain the outage. Even if 'private' were applied, SNMP would still function with that community string, whereas the problem states no access is available.

The cookbook is not idempotent and reapplied the change multiple times

Why wrong: Idempotency ensures that running a resource multiple times converges to the same declared state; it does not cause progressive deletion of configuration. A non-idempotent cookbook might add duplicate communities or repeat actions, but it would not specifically remove the only community unless the resource's desired state explicitly omitted it. Thus, the removal is a result of the intended (or mistakenly declared) state, not a side effect of repeated application.

NETCONF sessions are stateless

Why wrong: NETCONF sessions are not stateless; they are stateful. A NETCONF session is a persistent communication channel, typically carried over SSH, that maintains a session ID, a hello message with capabilities, and a lock state on datastores. This statefulness is essential because operations like edit-config on the candidate datastore and confirmed-commit rely on the server remembering the session's changes and context across multiple RPC exchanges.

YANG defines both the data model and the RPC operations for network devices

Why wrong: While YANG can define custom RPCs (via the 'rpc' statement) within a module, it is fundamentally a data modeling language, not a protocol definition language. NETCONF's core operations such as get, edit-config, and lock are defined in RFC 6241, not by YANG. YANG models the structure of configuration and state data, and any RPC definitions are additional device-specific extensions rather than a replacement for the standard NETCONF operations.

NETCONF uses TLS as the mandatory transport protocol

Why wrong: NETCONF's mandatory transport protocol is SSH, as specified in RFC 6242, not TLS. TLS is an optional transport that can be used per RFC 7589, but it is not mandatory. Therefore, the statement 'NETCONF uses TLS as the mandatory transport protocol' is incorrect because it confuses an optional security layer with the default, required transport mechanism.

Implement idempotency checks in the playbook using the 'check_mode' option

Why wrong: Check mode is a dry-run that computes and reports what would change without actually applying the configuration. It does not test whether the ios_bgp module's internal code matches the device's OS version; module incompatibility errors occur during execution, and check mode may still fail or bypass the relevant code paths. The root issue here is module/OS mismatch, not a lack of idempotency checks.

Set 'gather_facts: no' in the playbook to speed up execution and avoid version detection issues

Why wrong: Disabling fact collection with gather_facts: no prevents Ansible from learning critical attributes like the device's operating system version, which is exactly the information needed to implement a version-aware workaround. The failure stems from the module's execution on the newer OS, not from the overhead of gathering facts, so removing it both eliminates the data needed for conditional logic and misses the actual problem.

Replace the ios_bgp module with the ios_config module and use raw CLI commands for BGP configuration

Why wrong: Falling back to ios_config with raw CLI commands only shifts the problem rather than solving it. If the BGP command syntax has changed in the new IOS version, the raw commands will fail identically, and, even if they work, the approach becomes non-idempotent unless extra logic is added to compare running config. The robust solution is to conditionally use the appropriate module based on the device's OS version, preserving idempotency and adaptability.

The device is configured for HTTP/HTTPS access only.

Why wrong: The ios_config module in Ansible uses the network_cli connection plugin, which establishes an SSH session to the device for executing configuration commands. A device that accepts HTTP/HTTPS only cannot be managed through this module, but the failure would occur at the transport layer (connection refused or unreachable), not as an authentication timeout from incorrect vault credentials. Since the scenario points to an SSH authentication failure, an HTTP/HTTPS-only configuration would not be the underlying cause.

The device has NetFlow enabled, consuming CPU cycles.

Why wrong: NetFlow consumes CPU cycles to export flow records, but this traffic is handled by the data plane and the forwarding engine, while SSH management sessions are processed by the control/management plane with typically lower CPU priority. Although high CPU utilization can cause delayed responses, the presence of NetFlow alone does not invalidate SSH credentials or cause an authentication failure. The timeout in this scenario stems from vault credentials, not from data-plane CPU load.

The device has SNMPv3 enabled with authentication traps.

Why wrong: SNMPv3 with authentication traps sends notifications via UDP to a management station when auth failures occur; these traps are independent of the SSH transport that Ansible uses for ios_config. Enabling SNMPv3 authentication traps does not alter SSH credential validation, nor does it block the management plane. Therefore, this would be an unrelated monitoring feature, not the reason for an SSH-based backup timeout.

A new interface GigabitEthernet0/0/0 is created with the specified IP address.

Why wrong: RESTCONF PATCH targets an existing resource URI; it does not create a new interface. If GigabitEthernet0/0/0 were not present, the server would return a 404 Not Found rather than instantiate it. Creating a new interface would require POST to the interface collection or a PUT with the ?create option.

The request fails because a GET request must be sent first to retrieve the current configuration.

Why wrong: RESTCONF does not impose any prerequisite GET before a PATCH; the server operates directly on the current datastore contents. The optional 'if-match' header uses an ETag from a previous GET for concurrency protection, but omitting it simply allows the PATCH to proceed. A GET is only needed if the client explicitly wants to inspect the current values or obtain a condition for optimistic locking, not as a mandatory step.

The entire interface configuration is replaced with only the fields in the payload.

Why wrong: Replacing the entire interface configuration with the payload is the behavior of the PUT method, not PATCH. In RESTCONF RFC 8040, PATCH is defined with an 'update' operation that merges the payload field-by-field, leaving any unspecified nodes, such as MTU or 'enabled', intact. Consequently, sending only the description and IP address cannot wipe the rest of the interface; any fields omitted from the payload remain in effect.