CCNA Automation and Programmability: 51 practice questions

12 of the 51 Automation and Programmability questions in the Certsqill CCNA bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for CCNA? Take the free 5-min readiness check →

1. Control plane: Which network plane does OSPF operate in?

1. Data plane, which forwards packets using the tables the device has already built

   The data plane (forwarding plane) performs the actual packet-by-packet forwarding based on tables already populated by the control plane. OSPF populates those tables but does not perform the forwarding itself.
2. Management plane, which handles administrative access such as SSH and SNMP

   The management plane handles administrative access to the device — SSH, SNMP, Syslog, Telnet. OSPF is not a management protocol.
3. Control plane, which builds the routing and switching decisions on the device ✓

   The control plane handles routing decisions and protocol logic — OSPF, STP, ARP, and other protocols that determine HOW traffic should be forwarded operate in the control plane. The routing table is a product of control plane activity.
4. Application plane, a layer described above the controller in SDN models

   'Application plane' is not a standard network plane in the context of traditional network devices — routing protocols like OSPF do not operate there.

Control plane = routing decisions and protocol logic (OSPF, STP, ARP). Data plane = actual packet forwarding. Management plane = device management (SSH, SNMP).

2. Northbound REST API: Which API should the developer use?

1. Southbound NETCONF API, the interface DNA Center uses to reach the network devices

   Southbound APIs face downward toward network devices — DNA Center uses NETCONF, RESTCONF, and other protocols to configure and monitor individual devices. External application developers do not interact with southbound APIs directly.
2. Southbound REST API, an interface DNA Center would use toward managed devices

   While REST can be used in various contexts, the southbound interface on DNA Center uses device-specific protocols like NETCONF/YANG and RESTCONF — not the REST API that external applications consume.
3. Northbound NETCONF API, an interface offered upward to orchestration tooling

   NETCONF is a southbound protocol used by DNA Center to communicate with network devices — not the interface exposed to external application developers.
4. Northbound REST API, the interface DNA Center exposes to external applications ✓

   Northbound APIs on DNA Center face upward toward applications and orchestration tools — they expose REST APIs that external applications use to query and manage the network through DNA Center.

DNA Center northbound API = REST (for external apps/dashboards). Southbound API = NETCONF/RESTCONF (for communicating with network devices).

3. The model generates the most probable text for the request: Which characteristic of generative AI does this il

1. The model's answer is correct but the router requires a feature license before the command becomes visible in the CLI

   A licensing gap is a real phenomenon, but the scenario states the command exists in no IOS release, so this is a generated command rather than a hidden one.
2. The model reproduces its answer verbatim from the vendor documentation it was given for that platform when the request was made

   If the answer were retrieved verbatim from documentation, the command would exist. The model composed text that merely follows the pattern of real IOS commands.
3. The model generates the most probable text for the request, so it can produce plausible output that is factually wrong ✓

   Generative models predict likely token sequences rather than looking up verified facts. Output that reads like valid IOS syntax but names a non-existent command is the classic hallucination failure mode.
4. The model can only answer questions about the devices it is actively monitoring through streaming telemetry feeds

   The assistant answered without any device connection at all — which is precisely why nothing validated the command against a real platform and software version.

Generative models produce statistically likely text, not verified facts. Fluent, well-formatted output can therefore contain commands or claims that do not exist — the reason AI output is always validated against vendor documentation and a lab.

4. Ansible, which reaches the existing IOS devices over SSH: Which tool is most appropriate for automating device

1. Ansible, which reaches the existing IOS devices over SSH or NETCONF with no agent installed on them ✓

   Ansible is agentless: the control node connects to each device over SSH or NETCONF and applies tasks from YAML playbooks, so nothing has to be installed on the managed device.
2. A custom Python script, which the team writes and then maintains separately for every task it automates

   Scripting can drive devices over SSH, but it is not a configuration management mechanism: there is no inventory, no reusable module set, and no idempotency unless the team builds all of it.
3. Streaming telemetry, which continuously exports operational data from the devices out to a collector

   Streaming telemetry is a monitoring mechanism that only sends data outward. It reads device state and cannot apply any configuration.
4. Terraform, which provisions infrastructure by calling a provider's API to create and destroy resources

   Terraform is in scope for the exam and is also agentless, but its purpose is provisioning infrastructure to a declared end state through provider APIs — not pushing day-to-day configuration onto existing IOS devices.

Ansible is agentless — the control node connects over SSH or NETCONF and needs no software on the managed device. Terraform provisions through APIs, scripts are not a management framework, and telemetry only reads.

5. Predictive AI: Which capability is the platform demonstrating?

1. Threshold-based alerting, which raises an event only once a configured utilization limit has been crossed

   Threshold alerting is reactive and needs a limit to be configured in advance. The scenario states no threshold was set and the condition has not happened yet, so the platform is forecasting rather than alerting.
2. Signature matching, which compares observed traffic against a stored database of known attack patterns

   Signature matching is an IPS/antivirus detection technique for known malicious patterns. It has nothing to do with projecting future link utilization.
3. Generative AI, which produces new artifacts such as configuration drafts or written summaries when prompted

   Generative AI creates new content that resembles its training data. Here nothing is being authored — a numeric trend is being extended into the future, which is prediction, not generation.
4. Predictive AI, which extrapolates from historical time-series data to forecast a future capacity condition ✓

   Predictive AI/ML learns the pattern in historical measurements and projects it forward. Forecasting when a circuit will reach a utilization level months ahead is the classic capacity-planning use case.

Learning from historical measurements and projecting them forward is predictive AI/ML — the capacity-planning use case named in CCNA objective 6.4. Generative AI creates content; threshold alerting only reacts after a configured limit is crossed.

6. Adopt streaming telemetry so devices push fine-grained: Which change most directly improves the quality of the

1. Move the network management station closer to the core so that SNMP replies experience less round-trip delay

   Polling latency is not the constraint. The limitation is how often and how granularly data is captured, which does not change when the collector moves.
2. Replace the SNMP community strings with SNMPv3 authentication and encryption for all of the polled network devices

   SNMPv3 is a genuine security improvement, but it does not change the sampling interval or the level of detail the model receives.
3. Adopt streaming telemetry so devices push fine-grained data continuously instead of being polled every 15 minutes ✓

   Model quality depends on the granularity and freshness of the input data. Streaming telemetry delivers frequent, structured, pushed measurements, which resolves short-lived events that 15-minute averages hide entirely.
4. Increase the retention period of the existing 15-minute samples from 90 days to several years of stored history

   More history helps with long-term trends, but every sample remains a 15-minute average. Events shorter than the polling interval stay invisible no matter how long the data is kept.

AI/ML in network operations is only as good as its input data. Streaming telemetry pushes frequent, structured measurements, so models see short-lived events that 15-minute SNMP averages average away.

7. XML, the data encoding format used by the NETCONF: Which data format is being used?

1. XML, the data encoding format used by the NETCONF management protocol ✓

   XML (Extensible Markup Language) uses hierarchical tags and is the data encoding format used by NETCONF — the southbound protocol DNA Center uses to communicate with and configure network devices.
2. JSON, the data encoding format used by most northbound REST interfaces

   JSON is used by REST APIs (the northbound interface of DNA Center). The southbound NETCONF protocol uses XML, not JSON.
3. YAML, the data encoding format used by Ansible for automation playbooks

   YAML is used by Ansible playbooks for configuration automation — it is not the encoding format used by NETCONF for device communication.
4. CSV, the data format used for comma-delimited record exports

   CSV is a flat tabular format not suitable for hierarchical network configuration data — it is not used by NETCONF or other network management protocols.

NETCONF (southbound) uses XML. REST APIs (northbound) use JSON. Ansible playbooks use YAML.

8. Consistency — automation applies identical configurations: Which benefit directly addresses the risk of human

1. Reduced hardware costs — automation lowers the total number of physical devices the network must buy

   Network automation does not reduce hardware requirements — it manages existing hardware more efficiently. Hardware cost reduction is not a direct benefit of automation.
2. Consistency — automation applies identical configurations to all devices with no typos or omissions ✓

   Network automation executes the same configuration template identically on every device, eliminating typos, missed commands, and copy-paste errors that are common in manual CLI work across hundreds of devices.
3. Increased security — automation discovers and patches vulnerabilities on every device on its own

   While automation can be used to deploy security configurations, it does not automatically discover or patch vulnerabilities — that requires security-specific tools and processes beyond basic automation.
4. Improved routing — automation optimizes forwarding-path selection across the whole network

   Routing optimization is performed by routing protocols (OSPF, EIGRP) — not by configuration management automation tools like Ansible.

Network automation provides consistency (identical configs applied at scale), speed (faster deployment), and reduced human error — core automation benefits on the CCNA exam.

9. The control plane is centralized in a controller: In an SDN architecture, what fundamental change is made to t

1. The data plane is centralized in a controller, while devices retain only the control plane for routing choices locally

   This is reversed. In SDN, the CONTROL plane is centralized in the controller. The DATA plane remains distributed on network devices for hardware forwarding at line rate.
2. Both the control plane and the data plane are fully centralized inside the single SDN controller node

   Centralizing the data plane would create a massive bottleneck — all traffic would route through the controller. SDN centralizes only the control plane; the data plane stays on devices for efficient forwarding.
3. The control plane is centralized in a controller, while devices retain only the data plane for packet forwarding ✓

   SDN separates the control plane (routing decisions, protocol logic) from the data plane (packet forwarding). A centralized SDN controller handles all routing decisions and programs forwarding rules into devices via southbound APIs — devices become 'dumb' forwarders.
4. SDN swaps OSPF for a proprietary Cisco routing protocol that still runs on each individual device

   SDN does not replace OSPF with another distributed routing protocol — it removes distributed control plane intelligence from devices and centralizes it in a controller.

SDN = centralized control plane (controller makes routing decisions) + distributed data plane (devices forward packets per controller's instructions).

10. The ITSM tool uses the northbound REST API to query DNA: Which statement correctly describes the API interacti

1. The ITSM tool uses the southbound NETCONF API to query DNA Center; DNA Center uses northbound REST with YANG to configure the access switches

   Both directions are reversed. Southbound faces devices (not ITSM tools); northbound faces applications. ITSM tools consume the northbound REST API; switches are configured via southbound NETCONF.
2. The ITSM tool uses the northbound NETCONF API to query DNA Center; DNA Center uses southbound REST with YANG to configure the switches

   The direction is correct (northbound for ITSM, southbound for devices) but the protocols are wrong. Northbound uses REST, not NETCONF; southbound uses NETCONF/YANG, not REST.
3. The ITSM tool and DNA Center both exchange data over REST APIs, while YANG is used only for data validation within the platform

   YANG is not limited to internal validation — it is the data modeling language used in NETCONF/RESTCONF communications to network devices. The southbound interface to switches uses NETCONF with YANG, not REST.
4. The ITSM tool uses the northbound REST API to query DNA Center; DNA Center uses southbound NETCONF with YANG to configure the switches ✓

   Northbound REST API = DNA Center's interface to external applications (ITSM, dashboards, orchestration). Southbound NETCONF/YANG = DNA Center's interface to network devices. These are the correct API layers for each direction.

DNA Center: northbound = REST API (for apps/ITSM). Southbound = NETCONF + YANG (for network devices). YANG defines the data model structure for device configuration.

11. PATCH, which applies a partial update to only: Which HTTP method should be used to update an existing device's

1. PUT, which replaces the entire resource so every unspecified field is overwritten to default

   PUT replaces the whole resource, so sending only the hostname would null out the other fields; it requires a complete representation, unlike PATCH.
2. PATCH, which applies a partial update to only the specified fields of an existing resource ✓

   PATCH performs a partial update, modifying only the named fields of an existing resource, so it is correct for changing just the hostname.
3. POST, which creates a brand-new resource rather than modifying one that already exists

   POST is the Create operation and would add a new configuration object instead of updating the existing device.
4. GET, which only retrieves a resource and cannot modify any of its configuration fields

   GET is a read-only operation that retrieves a resource without changing it, so it cannot update configuration data.

PATCH performs partial updates on existing resources. PUT replaces the entire resource. POST creates new resources. GET retrieves resources.

12. JSON uses brace objects and bracket arrays: Which statement correctly describes a key difference between JSON

1. JSON must include a schema definition to be valid, while XML needs no schema of any kind

   This is reversed and inaccurate: JSON needs no schema (JSON Schema is optional), and XML's DTD/XSD schemas are also optional, so neither requires one.
2. XML natively supports numeric and boolean types, while JSON sends every value as a string

   This is reversed: JSON natively supports strings, numbers, booleans, null, objects, and arrays, while XML treats content as text unless an XSD enforces types.
3. JSON uses brace objects and bracket arrays, while XML wraps each element in open/close tags ✓

   JSON represents data with {key: value} objects and [array] notation, whereas XML wraps every element in matching open and close tags, making XML more verbose.
4. JSON serves only configuration management, while XML serves only monitoring and telemetry data

   Neither format is limited to one use case; both carry configuration and monitoring data, RESTCONF uses either, and NETCONF uses XML.

JSON uses {key:value} and [arrays] — compact. XML uses <opening><closing> tags — verbose. JSON natively supports data types; XML treats everything as text by default.

Other CCNA domains

• Network Fundamentals — 116 questions →
• IP Connectivity — 97 questions →
• Network Access — 96 questions →
• Security Fundamentals — 68 questions →
• IP Services — 66 questions →
• All 494 CCNA questions →