350-401 Automation Practice Question
A DevOps team is implementing a CI/CD pipeline that automates network configuration changes. Which design principle is most important to ensure that a failed deployment does not cause prolonged outages?
⚠ Common exam trap
Cisco often tests the distinction between 'preventing errors' (idempotency, single source of truth) and 'recovering from errors' (rollback), and the trap here is that candidates confuse idempotency with rollback, thinking that re-running a script will fix a failure, when in fact idempotency only ensures consistency, not recovery from a broken state.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Ensure the automation framework supports rollback to a known good state
In a CI/CD pipeline for network automation, the ability to roll back to a known good state is the most critical design principle for minimizing downtime. If a deployment fails (e.g., a misapplied ACL or BGP configuration), the automation framework must be able to revert the network device to its previous stable configuration—often by reapplying a saved startup config or using a tool like Ansible's `network_backup` role or Cisco NSO's rollback mechanism. Without this, a failed deployment could leave the network in a broken state until manual intervention, causing prolonged outages.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a single source of truth for all configurations
Why it's wrong here
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.
- ✓
Ensure the automation framework supports rollback to a known good state
Why this is correct
Rollback to a known good state is the critical safety net in a CI/CD pipeline because it directly addresses the recovery-time objective after a failed deployment. The automation framework should preserve the last-known-good configuration (e.g., a snapshot, a config replace file, or a rollback token) and be able to reapply it automatically or on-demand when health checks fail. This minimizes mean time to recovery and is the only option that actively restores service rather than merely preventing or mitigating the impact of a failure.
- ✗
Implement idempotent configuration scripts
Why it's wrong here
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 it's wrong here
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.
Visual reference
Go deeper
Related to this question
Learn chapter
Wireless Deployment Models and Security
Key term
Cisco DNA Center Automation
Cisco DNA Center Automation is a centralized software platform that simplifies network management by automatically configuring, monitoring, and troubleshooting Cisco devices using policy-driven intent and software tools.
About these practice questions
This 350-401 question is part of Courseiva's 1,923-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 350-401 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 350-401 exam.