CloudVision Automation and Provisioning Workflows
The workflow, end to end
CloudVision provisioning follows a consistent sequence that questions will test out of order:
- Onboard the device - the device must be reachable and running TerminAttr, authenticated to the CloudVision cluster.
- Place the device in a container - containers are the hierarchy that determines which configlets apply.
- Attach configlets - configlets are snippets of EOS config attached to containers or devices.
- Build a change control - CloudVision computes the diff between running config and intended config, presents it for review, and requires approval before execution.
- Execute and verify - the change is pushed, and telemetry confirms compliance.
Traps
- Change control is the gate, not the action. Approving a change control does not by itself push config; execution does. Questions often conflate the two.
- Configlet inheritance. A device inherits configlets from every ancestor container. If a configlet is attached to a parent container, every descendant device gets it.
- Compliance vs. drift. CloudVision flags a device as non-compliant when its running config differs from the intended config (configlets + container assignment). "Drift" is the same idea described operationally.
- Provisioning configlets vs. regular configlets. Provisioning configlets are used during onboarding/ZTP; regular configlets apply after the device is managed.
- Tags and device labels drive dynamic assignment; a question may ask how a device gets into a container automatically.
Rule of thumb
When a question describes "the device shows a diff but nothing changed," the answer is almost always that the change control was built but not executed, or the configlet was attached but the change control was never approved. Intended config only becomes running config through an executed change control.