Arista ACE-S Automation (Foundations) common mistakes
Arista ACE-S Automation (Foundations) · Understand the traps and how to avoid them.
Treating CloudVision as a single monolithic product and assuming every change goes through Change Control, rather than distinguishing the CVaaS/CVP control-plane services (configlet/container management, Change Control, Studios, dashboards) from the streaming telemetry and state-aggregation functions.
Candidates memorize feature names in isolation and never build a mental model of which CloudVision service owns which workflow, so questions that ask 'where does this action happen' get answered with the most familiar-sounding feature.
What to do instead
Build a one-page map of CloudVision services: device inventory/onboarding, configlet and container management, Change Control (change approval and rollback), Studios (template-driven intent), and telemetry/state dashboards. For each, write one sentence on inputs, outputs, and what it does NOT do.
Confusing EOS CLI configuration modes and the effect of 'configure session' versus 'configure terminal' when planning how an automation tool will push changes.
Hands-on experience is often limited to running config, so the candidate assumes every CLI push is immediately live and cannot reason about session-based staged configuration or commit/abort semantics.
What to do instead
Practice on a lab EOS device: enter configure session, stage a change, run 'show session-config', then diff, commit, and abort. Note which commands are session-aware and how a tool's CLI transport interacts with pending sessions.
Assuming eAPI is a separate daemon that must be installed and managed, or that it is enabled by default, instead of recognizing it as an EOS management API that must be explicitly enabled and reached over HTTPS/HTTP with the right transport and credentials.
Candidates learn 'eAPI = JSON over HTTP' as a slogan without lab exposure to enabling it, testing it with curl, or troubleshooting certificate and auth failures.
What to do instead
In a lab, enable eAPI, exercise it with curl using both JSON-RPC 'runCmds' and the REST-style resource paths, and deliberately break it (wrong credentials, disabled service) to learn the error responses.
Treating the JSON-RPC 'runCmds' call as returning raw CLI text, and then trying to parse it as structured data, rather than requesting structured output with the appropriate format parameter and handling the version/result envelope.
Most candidates first see eAPI output as strings and never internalize the request envelope (jsonrpc, method, params, id) or the response envelope (result array, error object), so they misread questions about output formats.
What to do instead
Write a minimal Python script that sends runCmds with format 'json' and one with 'text', print both responses, and annotate the envelope fields. Confirm how errors surface in the 'error' object versus inside 'result'.
Writing pyeapi or requests-based scripts that hardcode credentials and ignore connection reuse or error handling, then being unable to explain how the script behaves when a device is unreachable or returns a CLI error.
Candidates focus on getting a working happy-path script and skip the failure semantics, which is exactly what scenario questions probe.
What to do instead
Add explicit handling for connection errors, HTTP status codes, and eAPI 'error' responses to one lab script, and practice reading a traceback to identify whether the failure was transport, auth, or CLI-level.
Conflating CloudVision configlets with Studios, assuming a configlet is a template with variables and that Studios are just grouped configlets.
Both push configuration, so the distinction blurs without hands-on use; candidates then pick the wrong construct for questions about reusable, input-driven intent versus static configuration snippets.
What to do instead
Create a static configlet and a Studio in a lab, note where variables/inputs live in each, how each is attached to devices or containers, and how each surfaces in Change Control. Write a two-column comparison.
Assuming a change pushed through CloudVision is applied immediately, ignoring that Change Control creates a pending change that must be reviewed, approved, and executed, and that rollback depends on the captured pre-change state.
Candidates who only use CLI expect push-and-done behavior; the approval workflow and its states are easy to memorize superficially but hard to reason about under scenario wording.
What to do instead
Walk a configlet change end-to-end in a lab: create the change, inspect the pending state and diff, approve, execute, then perform a rollback. Record the state transitions and what is captured for rollback.
Mixing up device-level and container-level assignment when building CloudVision hierarchies, expecting a configlet attached to a container to apply to devices that were never moved into that container.
The hierarchy is conceptual and easy to skim; candidates assume inheritance is automatic for all managed devices rather than following the built topology.
What to do instead
Build a three-level container hierarchy in a lab, attach a configlet at the middle level, and verify which devices receive it. Move one device between containers and observe the resulting change.
Treating streaming telemetry as equivalent to SNMP polling, and therefore assuming telemetry data is pulled on a schedule by the collector rather than pushed by the device on a subscription.
SNMP is the familiar monitoring model, so candidates map new terminology onto the old push/pull model and misanswer questions about subscription behavior and latency.
What to do instead
Configure a telemetry subscription on a lab device to a collector, verify the push cadence, then stop the collector and observe device-side behavior. Contrast this explicitly with an SNMP poll interval.
Reading CloudVision dashboards as raw device counters, without accounting for how telemetry state is aggregated and normalized across devices and time windows, leading to wrong conclusions about what a graph represents.
Candidates look at a chart and assume it is a direct counter plot; the aggregation and normalization layer is invisible unless you have built or inspected a dashboard.
What to do instead
In a lab, build a dashboard from telemetry data, change the time window and aggregation, and note how the same underlying data renders differently. Practice stating precisely what a given panel measures.