CCNA Automation · Domain 5 of 6

CCNA Automation Domain 5: Infrastructure and Automation

The automation core of the exam: model-driven programmability, controller versus device management, Cisco Modeling Labs and pyATS, CI/CD and infrastructure as code, Ansible, Terraform and NSO, and interpreting scripts, playbooks, query results, YANG models, diffs and sequence diagrams.

Exam weight
20%
Official objectives
14
Estimated questions estimate
~19–21
Suggested study time estimate
18–24 hrs

About 16 min read Reviewed October 2026

Overview

Infrastructure and Automation carries 20% of the 200-901 exam and has fourteen objectives, the most of any domain. Objectives 5.1 to 5.6 are descriptive: the value of model-driven programmability, controller-level against device-level management, simulation and test tools such as Cisco Modeling Labs and pyATS, CI/CD for infrastructure, infrastructure as code, and the capabilities of Ansible, Terraform and Cisco NSO.

Objectives 5.7 to 5.14 are interpretive. You identify the workflow automated by a Python script using ACI, Meraki, Catalyst Center or RESTCONF, by an Ansible playbook, and by a Bash script. You interpret RESTCONF and NETCONF query results, basic YANG models and unified diffs, describe the benefits of code review, and read sequence diagrams that include API calls. Reading artefacts accurately is the main skill tested.

How it's tested

Most questions present an artefact such as a Python script, an Ansible playbook, a Bash script, a RESTCONF reply, a YANG tree, a unified diff or a sequence diagram, and ask what it does or what result it produced. Descriptive items compare tools or management approaches. Reading code line by line, not skimming, is what earns marks.

  • What does this automate?

    A script or playbook is shown and you choose the sentence that describes its overall workflow, such as backing up configurations or creating VLANs.

  • Interpret the output

    A RESTCONF or NETCONF reply, YANG model or unified diff is shown, and you extract a value or state what changed.

  • Pick the tool or approach

    A requirement such as declarative cloud provisioning, multivendor service rollback or pre-change testing is described, and you choose the tool.

Reasoning it through

A unified diff shows a hunk header @@ -12,3 +12,4 @@ followed by an unchanged interface line, a line starting with minus containing shutdown, and lines starting with plus containing no shutdown and a new description. The minus line was removed and the plus lines added, so the change enables the interface and adds a description. The new file has one more line in that hunk.

Objectives 14

Official objectives from the Cisco outline, in outline order.

5.1 Describe the value of model driven programmability for infrastructure automationWhy YANG-based APIs beat screen-scraping the CLI.
What it means
Model-driven programmability uses YANG models to define configuration and operational data, which devices expose through NETCONF, RESTCONF or gNMI as structured XML or JSON.
What to understand
The value lies in consistency and reliability: data has a known schema, so scripts do not need fragile text parsing of show output. Vendor-neutral models such as OpenConfig allow one script to work across platforms. NETCONF transactions allow all-or-nothing changes, and streaming telemetry built on the same models replaces polling.
How it shows up
Choose the main benefit of model-driven interfaces over CLI scraping.
Common confusion
Thinking YANG itself transports data; protocols such as NETCONF carry it.
5.2 Compare controller-level to device-level managementManaging through a controller versus box by box.
What it means
Device-level management configures each device directly through its CLI or its own API. Controller-level management uses a central platform such as Catalyst Center, APIC or Meraki Dashboard that holds the network-wide view and pushes configuration to devices.
What to understand
Controllers provide abstraction, intent-based policies, a single API, inventory and assurance, and reduce the number of endpoints a script must touch. Device-level access gives fine-grained control and works without a controller but scales poorly and needs per-device credentials and logic. Many environments mix both approaches.
How it shows up
Choose controller or device management for a scale, abstraction or granularity requirement.
Common confusion
Assuming device-level APIs are obsolete once a controller exists.
5.3 Describe the use and roles of network simulation and test tools (such as Cisco Modeling Labs and pyATS)Testing changes before they reach production.
What it means
Cisco Modeling Labs (CML) runs virtual Cisco devices in simulated topologies for design, training and testing. pyATS is Cisco's Python test framework that connects to devices, parses output into structured data with the Genie library, and compares network state before and after changes.
What to understand
CML gives a safe place to try configurations and run automation against realistic topologies, and has its own API for building labs. pyATS supports automated test cases, snapshots of operational state, and diffs that show what a change actually did. Both fit naturally into CI/CD pipelines for network changes.
How it shows up
Match CML to simulation and pyATS to automated testing and state comparison.
Common confusion
Thinking pyATS emulates devices; it tests real or simulated ones.
5.4 Describe the components and benefits of CI/CD pipeline in infrastructure automationApplying software pipelines to network configuration.
What it means
In infrastructure CI/CD, configuration or code changes are committed to Git, which triggers a pipeline that lints and validates the change, tests it in a simulated or staging network, and deploys it to production with an automation tool.
What to understand
Typical components are a source repository, pipeline runner, linting and schema validation, test environment such as CML, test framework such as pyATS, deployment tool such as Ansible, Terraform or NSO, and post-deployment verification. Benefits include consistent, auditable, repeatable changes with fewer outages and quick rollback.
How it shows up
Order the stages of a network CI/CD pipeline or name a benefit.
Common confusion
Skipping pre-production testing and treating the pipeline as a deployment script only.
5.5 Describe the principles of infrastructure as codeDefining infrastructure in version-controlled files.
What it means
Infrastructure as code describes the desired state of network, compute or cloud resources in text files that are stored in version control and applied by tools.
What to understand
Principles include declarative definitions where possible, idempotency so repeated runs give the same result, version control for history and review, automated testing, and treating the repository as the source of truth so manual changes are avoided. Drift, where real state differs from the code, is detected and corrected by reapplying the definition.
How it shows up
Identify an IaC principle such as idempotency or source of truth from a description.
Common confusion
Equating any script with IaC; IaC needs version-controlled, repeatable desired state.
5.6 Describe the capabilities of automation tools such as Ansible, Terraform, and Cisco NSOThree tools and where each fits.
What it means
Ansible is an agentless automation tool that runs YAML playbooks of tasks over SSH or APIs from a control node against an inventory. Terraform is a declarative provisioning tool using HCL files, providers and a state file, with plan and apply steps. Cisco NSO is a model-driven orchestrator that uses YANG service models and network element drivers to configure multivendor devices transactionally.
What to understand
Ansible suits configuration management and procedural tasks with many Cisco modules. Terraform suits lifecycle management of cloud and infrastructure resources, comparing desired state to its state file. NSO suits service provider and large enterprise services, keeping a configuration database of the whole network with rollback.
How it shows up
Choose the tool for a declarative provisioning, agentless configuration or multivendor service need.
Common confusion
Saying Ansible requires agents on managed devices.
5.7 Identify the workflow being automated by a Python script that uses Cisco APIs including ACI, Meraki, Cisco Catalyst Center, and RESTCONFReading platform scripts and summarising what they do.
What it means
This objective shows a Python script using requests or an SDK against a Cisco API and asks what overall workflow it automates, for example retrieving device inventory, creating a tenant, updating an SSID or changing an interface description.
What to understand
Follow the sequence: authentication, the endpoint and method of each call, any loop, and what is printed or written. A POST to aaaLogin.json signals APIC login; X-Auth-Token signals Catalyst Center; X-Cisco-Meraki-API-Key or a bearer token signals Meraki; /restconf/data paths signal device-level RESTCONF. The HTTP method shows whether data is read or changed.
How it shows up
Choose the description that matches a shown script.
Common confusion
Judging the script by its variable names instead of the actual calls it makes.
5.8 Interpret the workflow being automated by an Ansible playbook (management packages, user management related to services, basic service configuration, and start/stop)Reading plays, tasks and modules.
What it means
A playbook is YAML containing plays that target hosts from an inventory and list tasks, each calling a module such as apt or yum for packages, user for accounts, template or copy for configuration files, service or systemd for start and stop, or ios_config and similar modules for network devices.
What to understand
Read hosts, become, vars and each task's module and parameters in order. state: present installs or creates, state: absent removes, and state: started, stopped or restarted controls services. Handlers run when notified by a changed task. Modules are idempotent, so rerunning a playbook makes no change if the target already matches.
How it shows up
Describe what a playbook does, or what happens to a service after it runs.
Common confusion
Reading state: present as an action to restart a service.
5.9 Interpret the workflow being automated by a bash script (such as file management, app install, user management, directory navigation)Reading shell scripts line by line.
What it means
Bash scripts combine commands, variables, conditionals and loops to automate tasks such as installing packages with apt or yum, creating users with useradd, moving through directories with cd, and copying, archiving or deleting files.
What to understand
Note the shebang (#!/bin/bash), variable assignment without spaces and use with $, if [ ] tests, for loops, and command substitution with $(...). Watch for sudo, set -e which stops on error, and redirection with > and >>. The exam asks what end state the script produces.
How it shows up
Predict the result of a short Bash script or describe its purpose.
Common confusion
Confusing > (overwrite) with >> (append).
5.10 Interpret the results of a RESTCONF or NETCONF queryReading structured replies from devices.
What it means
A RESTCONF reply is JSON or XML under the module and container named in the request, such as ietf-interfaces:interface with name, type, enabled and ipv4 fields. A NETCONF reply is an rpc-reply containing a data element with XML that follows the YANG model.
What to understand
To extract a value, follow the hierarchy from the module prefix through containers and lists to the leaf. Lists appear as JSON arrays or repeated XML elements. An ok element in a NETCONF reply means an edit succeeded, and rpc-error carries the failure. RESTCONF errors appear as HTTP status codes with an errors body.
How it shows up
Read a reply and state an interface's address, status or other value.
Common confusion
Missing the module prefix in RESTCONF JSON keys when tracing the path.
5.11 Interpret basic YANG modelsReading module, container, list, leaf and type statements.
What it means
YANG modules declare a namespace and prefix, then define containers that group data, lists of entries identified by a key, leaves holding single values with types such as string, uint32 or boolean, and leaf-lists holding multiple values. config false marks operational data.
What to understand
Tree views produced by pyang show rw for configuration and ro for state, with list keys in square brackets. Constraints such as range, pattern and mandatory restrict valid values. Reading the model tells you the exact path and data type a RESTCONF or NETCONF request must use.
How it shows up
Determine a valid value, the list key or whether a node is configurable from a model.
Common confusion
Treating a ro node as configurable.
5.12 Interpret a unified diffReading git diff and diff -u output.
What it means
A unified diff starts with --- and +++ lines naming the old and new files, then hunks introduced by @@ -start,count +start,count @@. Lines starting with a minus were removed, lines starting with a plus were added, and lines starting with a space are unchanged context.
What to understand
The hunk header gives the starting line and line count in each version. A modified line appears as a removal followed by an addition. Diffs are used in code review, configuration comparisons and pyATS state checks, so you must state precisely what changed.
How it shows up
Describe the change a diff shows, or the number of lines added.
Common confusion
Reading the --- file as the new version.
5.13 Describe the principles and benefits of a code review processPeer review of changes before merge.
What it means
Code review is the practice of having peers examine changes, usually through a pull or merge request, before they are merged into the main branch.
What to understand
Benefits include catching defects early, enforcing standards, spreading knowledge across the team and keeping an audit trail of decisions. Good practice keeps reviews small, focuses on correctness and readability, uses automated checks for style, and treats feedback constructively. For infrastructure as code, review is a change-control step.
How it shows up
Identify a benefit or principle of code review.
Common confusion
Thinking automated tests make human review unnecessary.
5.14 Interpret a sequence diagram that includes API callsFollowing interactions over time between systems.
What it means
A sequence diagram shows participants as vertical lifelines and messages as arrows in time order from top to bottom, with solid arrows for requests and dashed arrows for responses, sometimes with loops, alternatives and activation bars.
What to understand
To interpret one, read top to bottom and note who calls whom, which API and method is used, and what returns. Typical flows include a script requesting a token, then using it to call a controller, which in turn talks to devices and returns a task ID. Questions ask about order or which participant performs a step.
How it shows up
Identify the step order or the component that makes a particular call.
Common confusion
Reading a dashed return arrow as a new request.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Controller-level management

    Central platform with a network-wide API.

    Remember
    Abstraction and scale.
    Tested as
    Management approach comparisons.
    Trap
    Assuming it removes device APIs.

  • pyATS and Genie

    Python test framework and parser library.

    Remember
    Snapshot, compare and test network state.
    Tested as
    Test tool selection.
    Trap
    Thinking pyATS simulates devices.

  • Cisco Modeling Labs

    Simulation platform for virtual Cisco topologies.

    Remember
    Safe pre-production testing.
    Tested as
    Pipeline and test questions.
    Trap
    Confusing it with DevNet Sandbox.

  • Idempotency

    Applying the same definition repeatedly yields the same state.

    Remember
    Core to Ansible and IaC.
    Tested as
    IaC principle questions.
    Trap
    Expecting reruns to duplicate configuration.

  • Ansible

    Agentless, YAML playbooks, inventory, modules.

    Remember
    Runs over SSH or APIs.
    Tested as
    Tool comparison and playbook reading.
    Trap
    Claiming it needs an agent.

  • Terraform

    Declarative HCL with providers and state.

    Remember
    Plan shows changes before apply.
    Tested as
    Tool comparison.
    Trap
    Calling it procedural.

  • Cisco NSO

    YANG-based multivendor orchestrator with transactions.

    Remember
    Uses NEDs and a configuration database.
    Tested as
    Tool comparison.
    Trap
    Treating it as a monitoring system.

  • YANG tree notation

    rw for config, ro for state, keys in brackets.

    Remember
    Shows paths and types.
    Tested as
    Model interpretation.
    Trap
    Editing ro nodes.

  • Unified diff hunk header

    @@ -old,count +new,count @@

    Remember
    Minus removed, plus added.
    Tested as
    Diff interpretation.
    Trap
    Reversing old and new.

  • NETCONF rpc-reply

    XML envelope holding data, ok or rpc-error.

    Remember
    ok means success.
    Tested as
    Query result interpretation.
    Trap
    Missing an rpc-error in a long reply.

  • Sequence diagram arrows

    Solid for calls, dashed for returns, time downwards.

    Remember
    Order is vertical.
    Tested as
    Diagram interpretation.
    Trap
    Treating return arrows as new calls.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Automation tools

ConceptMeaningKey differenceCommon trap
Ansible Agentless task automation in YAML Procedural playbooks, no state file Expecting it to track state like Terraform
Terraform Declarative provisioning with HCL State file and plan before apply Using it for ad hoc configuration tasks
Cisco NSO Model-driven service orchestration Transactional multivendor config database Thinking it is Cisco-only

Management approach

ConceptMeaningKey differenceCommon trap
Controller-level Central API manages many devices Abstraction, policy and assurance Assuming no device detail is possible
Device-level Script talks to each device directly Fine-grained but scales poorly Ignoring per-device credentials

Simulation and testing

ConceptMeaningKey differenceCommon trap
Cisco Modeling Labs Virtual network topologies Provides the test network Expecting it to run test cases itself
pyATS Automated test and validation framework Runs tests and compares state Expecting it to create devices

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Tool choice

    What candidates pick
    Ansible for declarative cloud resource lifecycle with state tracking
    Why it looks right
    Ansible is the best-known tool
    Why it's wrong
    Declarative provisioning with a state file and plan is Terraform's model.

    Clue to watch for Words like plan, state or desired infrastructure lifecycle.

  2. Playbook outcome

    What candidates pick
    The service restarts on every run
    Why it looks right
    A service task is present
    Why it's wrong
    state: started only starts a stopped service; a restart needs state: restarted or a notified handler.

    Clue to watch for Read the state value exactly.

  3. Diff reading

    What candidates pick
    The plus line was deleted
    Why it looks right
    Plus looks like it adds to the old file
    Why it's wrong
    In a unified diff, plus lines exist only in the new version, so they were added.

    Clue to watch for Check the --- and +++ headers.

  4. YANG configurability

    What candidates pick
    Set an ro leaf with PATCH
    Why it looks right
    Every leaf looks editable
    Why it's wrong
    Nodes marked ro or config false hold operational state and cannot be configured.

    Clue to watch for The tree shows ro beside the leaf.

  5. Test tool role

    What candidates pick
    CML to compare before and after state
    Why it looks right
    CML is a Cisco testing product
    Why it's wrong
    CML simulates topologies; snapshotting and diffing operational state is a pyATS function.

    Clue to watch for The stem mentions snapshots, parsers or test results.

Answer framework

Apply these steps whenever this domain shows an artefact or asks you to choose a tool or management approach.

  1. Name the artefact type first: Python script, playbook, Bash script, RESTCONF or NETCONF reply, YANG model, diff or sequence diagram.
  2. Read it top to bottom, noting authentication, each call or task in order, and any loop or condition that repeats or skips steps.
  3. Decide whether each step reads or changes state, using HTTP methods, module state values, ro and rw markers, or plus and minus lines.
  4. Summarise the end state in one sentence before reading the options, then pick the option that matches that sentence exactly.
  5. For tool questions, test each option against declarative or procedural style, state handling, agent requirements and multivendor support.

Practice question

An Ansible play targets the webservers group with become: true. Its tasks are: apt with name nginx and state present; template copying nginx.conf.j2 to /etc/nginx/nginx.conf with notify restart nginx; and service with name nginx and state started. The handler restarts nginx. What happens on a second run when nothing has changed?

Want more like this? The CCNA Automation practice test has questions for every domain.

Checklist

0 of 14

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Because eight of the fourteen objectives ask you to interpret artefacts, build a personal library of them. Collect or write a short example of each type: a Catalyst Center inventory script, an APIC tenant script, a RESTCONF interface update, an Ansible playbook for packages, users and services, a Bash install script, a NETCONF reply, a YANG tree from pyang, a git diff and a sequence diagram. For each, write one sentence describing what it does, then check yourself by running it in a sandbox or CML lab.

For the descriptive objectives, make a three-column table comparing Ansible, Terraform and NSO, and a two-column table for controller and device management. Run pyATS once against an IOS XE sandbox to snapshot interfaces, change a description and diff the result; this single exercise covers simulation, testing, CI/CD and diffs together. In the final week, practise timed interpretation items, aiming to read each artefact once carefully rather than skimming and rereading.

FAQ

How much of the exam is Infrastructure and Automation?

Infrastructure and Automation is 20% of the 200-901 CCNA Automation exam and has fourteen official objectives, the most of any domain.

Which automation tools must I know?

Objective 5.6 names Ansible, Terraform and Cisco NSO. Objective 5.8 also asks you to interpret Ansible playbooks, so Ansible gets the most attention.

Do I need to write Ansible playbooks?

The objectives ask you to interpret playbooks rather than write them, but writing a few small ones is the quickest way to read them confidently.

What is pyATS used for?

pyATS is Cisco's Python test framework. With the Genie library it parses device output, captures state snapshots and compares them before and after a change.

How deep is the YANG content here?

Objective 5.11 says basic YANG models: containers, lists, keys, leaves, types and whether nodes are configuration or state.

What should I know about sequence diagrams?

Know that time flows downwards, solid arrows are calls, dashed arrows are returns, and be able to follow authentication then API calls between a script, controller and devices.

Other Networking certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 5 knowledge

Practise reading scripts, playbooks, YANG models, diffs and sequence diagrams under time pressure to see if you are ready for this 20% domain.

Take the CCNA Automation practice test Check your CCNA Automation readiness

Keep going