If you cannot update a network device's configuration without causing an outage that takes down the entire company's internet, you will never pass the 200-901 exam or survive in a modern IT role. CI/CD pipelines are the automated assembly line that lets network engineers push changes safely, repeatedly, and without fear. This chapter demystifies the entire process so you can understand what a pipeline does, why every DevOps team depends on it, and exactly how the exam tests this knowledge.
Jump to a section
A simple way to picture CI/CD Pipelines and Automation for Network Applications
A general contractor is the person who makes sure your entire home renovation project happens smoothly, from the first blueprint to the final walkthrough. Renovating a single room might seem simple: pick new paint, buy furniture, and arrange it. But renovating an entire house, with new plumbing, electrical wiring, and structural changes, is chaotic without a system. The contractor breaks the project into stages. First is the planning stage: measuring rooms, ordering materials, and getting permits. This is like the 'Commit' stage in a CI/CD pipeline, where code is first written and saved. Next, the plumbers and electricians work in parallel, but they must test their work before the drywall goes up. This is the 'Build' and 'Test' stage. The contractor then 'deploys' the finished work by scheduling the final inspections and handing you the keys. If the contractor discovers a problem, like a pipe that leaks during testing, they send it back to the plumber to fix before it becomes a huge, expensive problem later. Without this staged, automated process, one mistake can ruin the entire project, forcing you to rip out walls after everything looks finished. This is precisely why network engineers use CI/CD pipelines: to catch errors early, automate repetitive checks, and deliver changes safely and quickly.
The contractor also uses a central checklist board that everyone can see — a digital board like Jira or Trello. This board shows the status of every task: 'To Do', 'In Progress', 'In Testing', and 'Done'. If a painter marks a wall as 'Done' but the electrician hasn't installed the sockets yet, the board flags a conflict. This is the 'Continuous Integration' part: merging all changes (paint, electrics, plumbing) into one shared view and automatically testing them together. When everything passes, the contractor gives the final approval to 'Deploy' — moving all the furniture in and declaring the house ready to live in. This whole pipeline — plan, build, test, deploy — eliminates the chaos of renovating a house room by room with no coordination.
CI/CD stands for Continuous Integration and Continuous Delivery/Continuous Deployment. It is a set of practices that automates the process of moving software or configuration changes from a developer's machine to production. For network automation, this means taking a script that changes a router's access control list (a rule that controls traffic) and running it through a series of automated checks before it ever touches a real network device.
Before CI/CD, network changes were manual. An engineer would log in to a switch, type commands, pray nothing broke, and then manually verify. This was slow, error-prone, and risky. One typo could bring down an entire data centre. The problem was that changes were a black box — no one knew if they would work until they were already in production.
A CI/CD pipeline solves this by turning the change process into a repeatable, automated workflow. It has several stages, and each stage must pass before the next one starts. The stages are:
Source: The code or configuration is stored in a version control system like Git. This is a central repository that tracks every change, who made it, and when. Think of it as a collaborative document with version history, like Google Docs.
Build: The pipeline takes the source code and compiles it or packages it. For network automation, this might mean linting (checking syntax) an Ansible playbook (a YAML file that describes desired network state) to ensure there are no typos.
Test: Automated tests run against the build. For networks, this could involve deploying the configuration to a virtual router in a lab environment and verifying that the network still routes traffic correctly. Tests can be simple (ping test) or complex (simulate a full traffic load).
Stage: The change is deployed to a staging environment that mimics production. This is a safe sandbox where the final checks happen before the change goes live.
Deploy: The change is pushed to production. This can be manual (with a button click) or fully automated (the pipeline pushes at 2 am).
The 'Continuous' part means that as soon as a developer commits new code to the source repository, the pipeline automatically triggers. The build, test, and deploy stages happen without human intervention. This is crucial for network automation because networks change constantly — new devices added, configurations updated, security patches applied. If every change required a human to manually run tests, the network team would be overwhelmed.
Why does this matter for the DevNet Associate exam? Cisco wants you to understand that CI/CD is not just for app developers. Network engineers now use the same tools and pipelines. The exam tests your understanding of the pipeline's purpose, the role of version control, the importance of automated testing, and how tools like Jenkins, GitLab CI, or GitHub Actions orchestrate these stages. You do not need to know how to build a pipeline from scratch, but you must be able to read a pipeline diagram and explain what happens at each stage.
The old way: an engineer gets a ticket to 'Open port 443 on firewall'. They log in, type the command, save, and leave. If the rule blocks critical traffic, the network breaks until someone figures out what changed. The CI/CD way: the engineer writes a configuration file in YAML, commits it to Git, and a pipeline tests it in a virtual firewall, confirms it doesn't conflict with existing rules, then deploys it automatically during a maintenance window. If the test fails, the pipeline stops and sends an alert to the engineer. No downtime. No panic.
Key tooling in this space includes Jenkins, an automation server that runs pipelines; Ansible, a tool for automating network device configuration; and Docker, a containerisation platform that lets you run isolated test environments. For networks, Cisco provides tools like Cisco Modeling Labs (CML) to simulate network devices for testing. The pipeline can launch a virtual router in CML, apply the configuration, and verify connectivity — all without touching physical hardware.
CI/CD pipelines also enforce 'shift-left' testing. This means moving testing earlier in the development process. Instead of waiting until deployment to discover a problem, you catch it during the test stage. This saves time, money, and reduces risk. The exam will focus on the concept that automation reduces human error and that every stage has a specific purpose: source control for collaboration, testing for validation, and deployment for delivery.
Commit Code or Configuration
The engineer writes a configuration file (e.g., an Ansible playbook in YAML) and commits it to a Git repository. This action triggers the pipeline automatically. Git tracks every change, so you can always revert to a previous version if something goes wrong.
Syntax Check and Linting
The pipeline runs a linter tool that checks the YAML or JSON file for syntax errors. For example, it ensures colons and indentation are correct. If the syntax is invalid, the pipeline stops and notifies the engineer, preventing malformed configurations from progressing.
Unit and Integration Testing
The pipeline deploys the configuration to a simulated network environment, such as a virtual router in Cisco Modeling Labs (CML). It runs automated tests like ping checks, routing protocol validation, and security rule verification. This stage catches logical errors that a linter cannot detect.
Stage Deployment and Regression Tests
If integration tests pass, the pipeline deploys the configuration to a staging environment that mirrors production. A full suite of regression tests runs to ensure the change does not break existing functionality. This is the final safety net before production.
Approval Gate and Production Deployment
A human (like the network manager) must approve the deployment to production. Once approved, the pipeline applies the change to live network devices, often during a scheduled maintenance window. After deployment, health checks verify the network is stable, and the pipeline logs the entire process for auditing.
Monitoring and Rollback
After production deployment, the pipeline monitors key metrics (latency, packet loss, bandwidth) for a defined period. If anomalies are detected, the pipeline automatically triggers a rollback to the previous working configuration, minimising downtime.
An IT professional, such as a network automation engineer, would use CI/CD pipelines on a daily basis to manage changes to a company's network infrastructure. Consider a scenario at a large e-commerce company that runs hundreds of routers and switches across multiple data centres. The network supports thousands of customers, so any misconfiguration could cost millions in lost revenue.
The engineer's task is to update the VLAN configuration (Virtual Local Area Network, which logically separates network traffic) on all core switches to support a new application being deployed next week. In the old world, the engineer would manually log into each switch, type the VLAN commands, and hope for the best. In the modern world, the engineer uses a CI/CD pipeline.
Here is the step-by-step process the engineer follows:
The engineer writes an Ansible playbook that defines the desired VLAN configuration. The playbook is stored in a Git repository along with all other network configurations. Every change is tracked.
The engineer creates a new branch in Git (a copy of the main configuration) to work on the VLAN update without affecting the live configuration.
The engineer commits the playbook changes and opens a 'pull request' — a request to merge the changes into the main branch. The pull request triggers the CI/CD pipeline automatically.
The pipeline's first stage (testing) checks the playbook syntax. It runs a linter that catches errors like missing colons or incorrect indentation. If linter fails, the engineer gets an email and the pipeline stops.
The next stage (integration testing) uses Cisco Modeling Labs (CML) to spin up a virtual copy of the network's core switches. The pipeline applies the VLAN changes to this virtual network and runs automated tests: it pings all the important servers, checks that routing protocols work, and verifies that the new VLAN is reachable from the inside but not from the outside.
If integration tests pass, the pipeline moves to the 'stage' environment. This is a separate set of physical switches that are not in production. The pipeline applies the configuration there and runs a full regression test suite — essentially repeating all previous tests plus additional edge cases.
After staging passes, the pipeline presents a 'deploy to production' button. The engineer's manager must approve this. Once approved, the pipeline applies the VLAN changes to production switches during the scheduled maintenance window.
The pipeline automatically runs health checks after deployment. It monitors network latency, packet loss, and bandwidth utilisation for 15 minutes. If anything looks abnormal, the pipeline automatically rolls back the change to the previous working configuration.
All results are logged in a central dashboard that the engineer checks in the morning. The entire process, from writing the playbook to production deployment, took two hours instead of two days. The engineer never once logged into a production switch directly.
The tools used in this scenario include GitLab for version control and pipeline execution, Ansible for configuration management, CML for network simulation, and custom Python scripts for health checks. The engineer does not need to be a software developer, but they must understand the pipeline's stages and how to trigger and monitor them.
This workflow dramatically reduces risk. If the engineer had manually typed the commands, one typo could have created a routing loop that disrupted all traffic. Because the pipeline tested in an identical virtual environment first, that typo was caught before touching production. The business benefits are huge: faster deployment of new features, fewer outages, and a full audit trail of every change.
The 200-901 DevNet Associate exam tests your conceptual understanding of CI/CD pipelines and automation for network applications. You will not be asked to write a pipeline script, but you will need to interpret pipeline diagrams, identify the correct stage for a given activity, and understand the relationship between CI, CD, and automation tools.
The exam typically includes 5-10 questions on this topic, spread across multiple choice, drag-and-drop, and multiple select formats. The questions often fall into these categories:
Stage Identification: You will be shown a diagram of a pipeline with stages labelled A, B, C, D. You must match descriptions like 'runs unit tests' or 'deploys to production' to the correct stage. For example, 'running unit tests on the code' belongs to the Test stage, not the Build stage. The trap is that some questions use terms like 'Validate' interchangeably with 'Test'. Cisco expects you to know that testing is a broad term that includes validation.
Tool Association: The exam lists several tools (Jenkins, Git, Ansible, Docker, Cisco Modeling Labs) and asks which one performs a specific function. For instance, 'Which tool is used to automate the configuration of network devices?' The answer is Ansible, not Jenkins. Jenkins orchestrates the pipeline; Ansible or Terraform executes the configuration changes on devices. A common mistake is to confuse the pipeline orchestrator (Jenkins) with the configuration tool (Ansible).
CI vs. CD vs. Continuous Deployment: The exam loves to test the distinction. Continuous Integration means frequently merging code changes into a shared repository and automatically testing them. Continuous Delivery means the code is always in a deployable state, but deployment is manual. Continuous Deployment means every change that passes tests is automatically deployed to production. A question might state: 'A team merges code to the main branch, which triggers automated tests, but a human must approve the deployment to production. This is an example of...' The correct answer is Continuous Delivery. The trap is choosing Continuous Integration because merging is mentioned, but the manual approval is the key detail.
Benefits of CI/CD: Expect a question like 'Which benefit does a CI/CD pipeline provide for network automation?' The correct answer is consistent, repeatable deployments that reduce human error. A trap answer might be 'increases the speed of manual configuration', which is wrong because manual configuration is exactly what CI/CD eliminates.
Network-specific Integration: You will see questions about testing network changes in a sandbox before production. The exam expects you to know that Cisco Modeling Labs (CML) or virtual routers in a lab environment are used for the Test or Stage phases. A question might show a pipeline with a 'Deploy to CML' step and ask which stage is that. The answer is Test or Staging, not Production.
Key definitions to memorise:
Version Control: A system that records changes to files (e.g., Git).
Build: Compiling or packaging code; for network automation, it often means syntax checking.
Test: Automated verification (unit tests, integration tests).
Release: The artifact produced after testing that is ready for deployment.
Deploy: The act of applying the release to an environment.
Rollback: Reverting to a previous version if deployment fails.
Exam traps to avoid:
Confusing 'Continuous Delivery' with 'Continuous Deployment' — remember the manual approval gate.
Thinking that CI/CD applies only to software, not network configurations. The exam explicitly tests that network automation uses the same principles.
Assuming that all pipelines are fully automated. Some stages, like production deployment, may require manual approval for compliance reasons.
Forgetting that version control is the foundation of CI/CD. Without Git, there is no trigger for the pipeline.
Overlooking the importance of automated testing. The exam emphasises that testing is not optional — it is the core of CI.
Study the exam blueprint objective 4.2 carefully. It states: 'Describe CI/CD pipeline stages, tools, and integration with network automation'. This means you must explain each stage, name popular tools (Jenkins, GitLab CI, GitHub Actions, Ansible, Docker, CML), and describe how these tools integrate with network devices. You do not need deep hands-on experience, but you must know the concepts.
CI/CD stands for Continuous Integration (automatically merging and testing changes) and Continuous Delivery/Continuous Deployment (automating the release and deployment process).
A CI/CD pipeline consists of sequential stages: Source, Build, Test, Stage, and Deploy, with each stage acting as a gate that prevents errors from moving forward.
Version control (like Git) is the foundation of CI/CD; every change must be tracked and committed to a shared repository to trigger the pipeline.
Automated testing is non-negotiable in CI/CD; without tests, there is no way to verify that changes work together, making the pipeline pointless.
Network engineers use CI/CD pipelines to deploy configuration changes to routers and switches, treating network configurations as code.
Tools like Jenkins or GitLab CI orchestrate the pipeline, while tools like Ansible or Terraform execute the actual configuration changes on devices.
Continuous Delivery means the code is always ready for deployment but requires manual approval, whereas Continuous Deployment automatically deploys every change that passes testing.
Cisco Modeling Labs (CML) is often used in the Test stage to simulate network devices and validate configuration changes in a risk-free environment.
These come up on the exam all the time. Here's how to tell them apart.
Continuous Integration (CI)
Focuses on automatically merging code changes into a shared repository multiple times a day.
Runs automated tests to verify that the merged code works correctly together.
Does not include the deployment step; the output is a verified artifact.
Continuous Delivery (CD)
Starts where CI ends; it ensures the verified artifact is always ready for deployment.
Includes a manual approval gate before deploying to production.
The goal is to have a release candidate that can be deployed at any time with minimal effort.
Jenkins
A continuous integration and delivery server that orchestrates the pipeline stages.
Can trigger builds, run tests, and manage deployment workflows across multiple tools.
Not designed to directly configure network devices; it calls other tools to do that.
Ansible
An automation tool specifically for configuring servers, network devices, and applications.
Uses YAML playbooks to define desired states and applies them via SSH or APIs.
Can be integrated into a Jenkins pipeline as a step to actually push configurations to devices.
Staging Environment
A near-identical copy of the production environment used for final testing before go-live.
Changes can be applied and tested without risk to real users or services.
Often smaller scale but mirrors production network topology and device types.
Production Environment
The live environment that serves real users and handles business-critical traffic.
Changes are deployed here only after passing all tests and approvals.
Any misconfiguration here can cause outages, data loss, or revenue impact.
Rollback
Reverting the environment to the previous known-good state (e.g., restoring a previous configuration).
Typically done by reapplying an older configuration version stored in Git.
Fast to execute but may require infrastructure to support versioned states.
Rollforward
Applying a new fix or patch to address the issue rather than reverting to an older state.
Useful when the older state itself was flawed or when rollback is complicated.
Requires a rapid development cycle to create, test, and deploy the fix.
Mistake
CI/CD is only for software developers, not for network engineers.
Correct
CI/CD is equally relevant for network automation. Network configurations can be treated as code, stored in Git, tested in virtual labs, and deployed via pipelines. Cisco's DevNet certification specifically highlights this integration.
Many beginners come from traditional networking backgrounds where changes were manual. They assume CI/CD is a software-only concept because they have never seen it applied to routers or switches.
Mistake
A CI/CD pipeline is just a script that runs automatically.
Correct
A pipeline is a structured, multi-stage workflow with defined stages (source, build, test, stage, deploy) and gates between them. It is more than a script; it includes version control, automated testing, approval workflows, and rollback capabilities.
People hear 'automation' and think of a simple shell script. They do not realise the complexity of orchestration, environment separation, and failure handling that a proper pipeline provides.
Mistake
Once a pipeline is set up, you never need to intervene; it is fully autonomous.
Correct
Pipelines often include manual gates, especially for production deployment. Regulatory compliance, security reviews, or manager approval may require human intervention. Additionally, pipelines need maintenance as code and infrastructure evolve.
The word 'Continuous' implies non-stop, leading beginners to believe it runs without human oversight. In practice, organisations balance automation with control, and manual approvals are common.
Mistake
Testing in a CI/CD pipeline is optional; you can skip it if you are confident.
Correct
Testing is the core of Continuous Integration. Without automated tests, CI is meaningless because you cannot guarantee that changes work together. Skipping tests defeats the purpose of the pipeline and reintroduces the same risk as manual changes.
Beginners think testing adds time and overhead. They do not appreciate that the cost of a production outage far exceeds the time saved by skipping tests. The exam emphasises that testing is not optional.
Mistake
CI/CD pipelines are only for code, not for configuration files like YAML or JSON.
Correct
Pipelines can handle any type of file. Network automation relies heavily on YAML and JSON configuration files. Pipelines lint these files, validate their structure, and apply them to devices, just like they would for software code.
People associate pipelines with compiled languages like Java or C++. They do not realise that configuration-as-code is a core principle of DevOps, and pipelines are language-agnostic.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Continuous Delivery means the software or configuration is always in a deployable state, but a human must manually approve the deployment to production. Continuous Deployment automates that final step, so every change that passes testing goes straight to production.
You need to understand what Jenkins does (it orchestrates CI/CD pipelines), but you will not be asked to configure or build a Jenkins job. The exam focuses on concepts and tool purposes, not hands-on configuration.
It allows network engineers to treat configuration files as code, store them in Git, automatically test them in simulated environments, and deploy them safely. This reduces human error, speeds up changes, and provides an audit trail.
A gate is a condition that must be met before the pipeline can proceed to the next stage. Examples include passing all tests, receiving a manual approval, or completing a security scan. Gates prevent faulty changes from reaching production.
Yes. Many pipelines are configured to monitor health checks after deployment. If the checks fail, the pipeline can automatically revert to the previous configuration version stored in Git, restoring normal operation without human intervention.
Absolutely. The pipeline is triggered by changes stored in version control (usually Git). Without a central, versioned repository, there is no way to track changes, trigger automation, or revert to a previous state.
You've finished CI/CD Pipelines and Automation for Network Applications. Continue through the 200-901 study guide to build a complete picture of the exam.
Done with this chapter?