200-901 Infrastructure and Automation Practice Question
In a CI/CD pipeline for network changes, which practice best ensures that a configuration push does not disrupt production traffic?
⚠ Common exam trap
Cisco often tests the misconception that 'push all changes at once' is efficient and safe, but the trap here is that it ignores the principle of incremental risk reduction, which is fundamental to CI/CD best practices for network automation.
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
✓
Canary deployment
Canary deployment is the correct practice because it gradually introduces the configuration change to a small subset of devices or traffic before full rollout. This allows monitoring for adverse effects and automatic rollback if issues arise, minimizing the risk of production disruption. In a CI/CD pipeline for network changes, this approach aligns with incremental validation and risk mitigation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable rollback
Why it's wrong here
Disabling rollback removes the mechanism that reverts a device to its last known-good configuration when a push causes disruption, leaving production traffic broken until manual repair. It is tempting to avoid the storage and automation overhead, but rollback is correctly omitted only where changes are non-disruptive and trivially reversible.
- ✓
Canary deployment
Why this is correct
Canary deployment pushes the configuration to a small subset of devices first, allowing traffic impact to be observed before fleet-wide rollout. This limits blast radius, satisfying the requirement that a configuration push does not disrupt production traffic.
- ✗
Push all changes at once
Why it's wrong here
Pushing every change simultaneously removes the staged rollout that limits blast radius, so a faulty configuration reaches all production devices before any canary or phased deployment reveals the fault. It is tempting as a fast bulk-apply method, yet it is correct only for isolated lab or maintenance-window changes where no live traffic exists.
- ✗
Skip validation
Why it's wrong here
Skipping validation lets syntactically or logically broken configurations reach production, since no pre-deployment check catches errors before the push. It is tempting when changes appear trivial or time is short, but validation is correctly omitted only in throwaway sandbox environments where no production traffic can be affected.
Go deeper
Related to this question
About these practice questions
This 200-901 question is part of Courseiva's 975-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 200-901 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 200-901 exam.