Arista ACE-S Campus common mistakes
Arista ACE-S Campus · Understand the traps and how to avoid them.
Treating MLAG as a single control plane and expecting STP to block one of the peer links, then mis-predicting failover behaviour when a peer link or peer device fails.
Candidates carry over assumptions from traditional stacking/VSS designs where the pair behaves as one logical switch; MLAG keeps independent control planes and relies on the peer link plus peer-keepalive, so failure semantics differ.
What to do instead
Study the MLAG roles (primary/secondary), the separate peer-link and peer-keepalive paths, and what happens on peer-link failure (secondary disables its MLAG member ports) versus peer-keepalive failure. Draw the failure scenarios from memory and verify each against Arista documentation.
Assuming a spanning-tree root election is decided by the bridge with the most downstream ports or by configuration order, rather than by lowest bridge ID (priority then MAC).
Candidates conflate STP root selection with routing metrics or with 'first configured wins' mental models, and skip the deterministic priority-plus-MAC tiebreak.
What to do instead
Practice computing root bridge, root port, and designated port for small topologies by hand, explicitly applying priority then MAC. Set root priority deliberately on the intended core and confirm with show spanning-tree output.
Confusing the roles of the EOS running-config, startup-config, and the flash filesystem, and mis-predicting what survives a reload after changes are made in a session.
EOS uses a single unified configuration file and explicit copy commands rather than the implicit 'write memory' habits from other vendors, so candidates assume changes auto-persist or persist incorrectly.
What to do instead
Memorise the copy running-config startup-config workflow and the boot-config pointer. Practise reloading a lab switch after editing config without saving to observe the loss, then repeat with saving.
Assuming EOS configuration changes take effect immediately on every change, without accounting for the two-stage commit model and session-based configuration in some workflows.
Candidates apply CLI habits from vendors where every command is instantly active, then mis-answer questions about when a change becomes active or how to discard a staged change.
What to do instead
Learn the difference between immediate CLI configuration and the configure session/commit workflow. Practise staging multiple changes, reviewing the diff, and committing or aborting, and know which mode a given question implies.
Treating CloudVision as only a monitoring dashboard and missing its role as the change-management and provisioning plane (change control, configlets/studios, device onboarding).
Candidates who have only seen the telemetry views underestimate the automation surface, so questions about deploying configuration at scale or rolling back changes are answered with the wrong tool.
What to do instead
Map CloudVision capabilities into three buckets: telemetry/observability, provisioning/automation, and change control/audit. For each exam scenario, decide which bucket the task belongs to before choosing an answer.
Assuming a configuration pushed from CloudVision is instantly and uniformly applied across all devices, ignoring change-control approval steps and per-device execution results.
Candidates picture automation as a single atomic push and forget that change control can require approval and that individual devices can succeed or fail independently.
What to do instead
Study the change-control workflow end to end: build, review, approve, execute, and inspect per-device results. Practise a push where one device is unreachable and confirm how partial failure is reported and reconciled.
Mixing up which Cognitive Campus platforms are fixed versus modular and which support features like PoE budgets, stacking, or specific uplink speeds, then selecting a platform that cannot meet the stated requirement.
The platform families share branding and similar model numbers, so candidates rely on name recognition instead of matching port counts, PoE class, and form factor to the scenario.
What to do instead
Build a comparison table of the campus switch families with columns for form factor, port speeds, PoE capability, stacking, and typical use case. Answer platform-selection questions only after checking the requirement against that table.
Designing segmentation by VLAN alone and expecting it to enforce policy between users on the same VLAN, or assuming a single mechanism covers both wired and wireless endpoints.
Candidates default to VLAN-per-department thinking and forget that intra-VLAN traffic is not filtered by a VLAN boundary, and that consistent policy across wired and wireless needs a unified approach.
What to do instead
Compare VLAN-based segmentation, ACLs, and identity/group-based policy approaches, noting where each enforces traffic. For each scenario, state explicitly whether the requirement is inter-VLAN or intra-VLAN before choosing a mechanism.
Assuming enabling 802.1X authentication alone secures the port, without planning the fallback behaviours (MAB, guest VLAN, critical VLAN) and what happens when the RADIUS server is unreachable.
Candidates focus on the happy path of a successful authentication and overlook fail-open/fail-closed design decisions, which is exactly where exam scenarios probe.
What to do instead
For each port profile, define the behaviour for: successful auth, failed auth, no supplicant (MAB), and RADIUS timeout. Draw the decision tree and verify it against the intended security posture for each port type (access, voice, AP uplink).
Reading telemetry and flow data as if it were full packet capture, and drawing conclusions about application performance that the available observability data cannot support.
Candidates conflate flow records, sFlow samples, and streaming telemetry with packet-level truth, so they over-interpret sampled or aggregated data when answering troubleshooting questions.
What to do instead
Classify each observability source by what it actually provides (sampled flows, counters, streaming state, full capture) and its limitations. When a question asks what can be concluded, pick the answer that matches the granularity of the data source named.