CloudVision Change Control Blocked by Drift on a Single Leaf
A network team manages 60 Arista switches through CloudVision. They build a Change Control to push an updated ACL to all 60 leaf switches. During the pre-change compliance check, CloudVision flags that leaf-37 has configuration drift: an engineer manually added two permit lines to a different ACL three weeks ago and never committed them back to CloudVision. The team is under a maintenance window of 90 minutes. The ACL being pushed is unrelated to the drifted ACL. If they proceed, CloudVision will overwrite leaf-37's running config with the intended state, removing the manual lines. The engineer who made the change is on PTO; no one knows why the lines were added.
1. Describe what CloudVision's Change Control will do to leaf-37 if the team proceeds as-is, and identify the risk.
Read the worked answer
CloudVision's Change Control reconciles each device to the intended configuration derived from the container/studio state, not just the delta of the change being pushed. When leaf-37 is included in the Change Control, the reconciliation will bring the device to the full intended state - which does not contain the two manual permit lines. Those lines will be removed, even though the ACL being changed is unrelated. The risk: the manual permits may be load-bearing (e.g., an emergency exception for a specific host or a vendor support tunnel). Removing them silently could break production traffic with no documented reason and no owner available to explain. This is exactly the scenario Change Control is designed to surface.
2. Recommend a course of action that respects the 90-minute window while managing the drift risk. Justify the tradeoffs.
Read the worked answer
Do not blanket-proceed. Recommended sequence:
- Exclude leaf-37 from the Change Control (or scope the change to the other 59 leaves). This gets 59/60 done within the window without touching the drifted device.
- Capture the drift - export leaf-37's running config / diff and the two permit lines to a ticket so the change is documented and recoverable.
- Investigate the manual lines (what they permit, whether traffic still uses them) before the next window, with the original engineer's input.
- Reconcile deliberately: either backport the lines into the intended config (if still needed) or remove them with a rollback plan, then re-run Change Control for leaf-37.
Tradeoffs: excluding leaf-37 leaves one device temporarily out of compliance and creates a small config skew - acceptable because it is visible and tracked, versus the alternative of an undocumented, unattended removal of unknown rules during a time-boxed window. The 90-minute constraint argues for scoping, not for speed-running a destructive reconcile.