Arista EOS and CloudVision Fundamentals
The architecture you must be able to draw from memory
Arista EOS is a single-binary, Linux-hosted network operating system. Because it runs on standard Linux, EOS exposes Sysdb (a state database that is the source of truth for running configuration and operational state), a full bash shell, and open APIs. Candidates should know that Sysdb is read-mostly for operators - you inspect it, but you change intent through configuration (CLI, eAPI, or CloudVision), not by writing into Sysdb directly.
CloudVision is the management plane: a cluster of CVP nodes backed by a datastore, fronted by a web UI and REST/gRPC APIs, that collects streaming telemetry and state from EOS devices via the TerminAttr agent. TerminAttr is the on-switch daemon that publishes state and telemetry to CloudVision and pulls configuration/provisioning instructions back. A device appears in CloudVision as streaming only after TerminAttr is running and authenticated.
Traps to watch
- Change control vs. configlet push. CloudVision change control (the review/approve/execute workflow) is not the same as a configlet push; questions often blur "approve a change" with "deploy a configlet."
- ZTP is not CloudVision provisioning. Zero Touch Provisioning boots a device and applies a startup config/bootstrap; CloudVision provisioning (e.g., via a provisioning configlet or device onboarding) assigns the device to a container and applies intent afterward.
- Containers are hierarchical. A device inherits configlets from every ancestor container; a common trap is assuming only the directly-assigned container matters.
- eAPI is on-box. eAPI is an HTTP/HTTPS JSON-RPC interface to EOS itself; it works with or without CloudVision.
Rule of thumb
If a question asks "where does the intent live?" the answer is CloudVision (the management plane). If it asks "where is state read from on the box?" the answer is Sysdb/streaming telemetry via TerminAttr.