JNCIS-MistAI-Wired common mistakes
JNCIS-MistAI-Wired · Understand the traps and how to avoid them.
Treating Mist Wired Assurance as a standalone product and answering configuration questions as if switch settings were managed directly on the switch CLI or on a separate on-prem controller, rather than through the Mist cloud UI, site templates, and switch templates.
Candidates with a traditional campus-switching background assume configuration lives on the device or in a legacy management appliance, so they misplace where SLE settings, port profiles, and firmware policies are actually defined in a Mist deployment.
What to do instead
Rehearse the Mist hierarchy explicitly: organization > site > switch template > switch, and identify which objects (site settings, switch templates, port profiles, device profiles) are inherited versus overridden. For each configuration task, state where the setting lives before answering.
Confusing Mist's cloud-managed switch onboarding path with a manual SSH-based adoption flow, and selecting answers that require pre-staging credentials or console access on the switch.
Many candidates learned switch provisioning through serial console and manual IP assignment, so they overlook the zero-touch claim-code and DHCP/cloud-redirect model Mist uses for supported switches.
What to do instead
Map the onboarding sequence end to end: claim code or activation code in the Mist org, DHCP and DNS reachability to the Mist cloud, automatic device registration, then site assignment and template application. Practice describing what happens at each hop without console access.
Answering wired SLE questions by quoting wireless SLE names and thresholds (for example coverage or roaming) instead of the wired-specific classifiers such as switch health, port health, and wired client experience.
Most Mist study material and lab time is wireless-centric, so candidates pattern-match to familiar WLAN SLE terminology and miss the wired classifier set entirely.
What to do instead
Build a one-page reference listing each wired SLE, its classifier inputs, and what a drop in that SLE points to (for example a port flap versus a PoE fault versus a DHCP failure). Recite the list from memory before attempting operations questions.
Misreading port profile and PoE behavior questions by assuming a single global PoE setting applies, instead of recognizing per-port and per-profile overrides and the interaction with 802.1X and dynamic VLAN assignment.
PoE budget and port configuration are often taught as static switch-wide settings, so candidates miss the layered override logic and how authentication results can change VLAN and port state at runtime.
What to do instead
Practice tracing a packet and a powered device through the full port decision chain: physical profile, PoE class and budget, authentication outcome, then VLAN assignment. Draw the override order and verify which layer wins when settings conflict.
Choosing answers that describe reactive troubleshooting (log into the switch after a complaint) when the scenario is asking for Mist AI-driven proactive detection, or the reverse: forcing an AI/marvis answer onto a purely local Layer 2 problem that requires switch-side verification.
The exam blends AIOps framing with hands-on switching, and candidates overcorrect in one direction, either dismissing marvis and SLEs as marketing or treating every fault as solvable from the cloud dashboard alone.
What to do instead
For each troubleshooting scenario, decide first whether the fault is visible in telemetry (SLE classifier, marvis action, alarm) or only on the device (spanning tree topology change, interface error counters). Then justify the tool choice in one sentence before selecting.
Skipping the distinction between organization-level and site-level settings when answering deployment questions, and assuming a change made at one level automatically propagates everywhere.
The Mist UI presents org and site scopes in similar-looking screens, and candidates who have not built a multi-site lab miss how inheritance and override precedence work in practice.
What to do instead
Create a small mental model: list three settings that are org-wide (for example admin accounts, some WLAN or template libraries) and three that are site-scoped (site SLE thresholds, site variables). Test your model by predicting what a new site inherits by default.
Treating Mist webhooks, REST API calls, and third-party integrations as interchangeable, and selecting an integration method without matching the direction of data flow and the triggering event.
Automation questions ask about specific outcomes (alerting a ticketing system, pushing config, pulling statistics), and candidates who have only read about APIs conflate outbound webhooks with inbound API calls.
What to do instead
Classify each integration by direction and trigger: outbound event-driven (webhooks/alarms), inbound on-demand (REST API calls for config or stats), and streaming (syslog or similar). For each exam scenario, name the direction first, then the mechanism.
Ignoring Layer 2 loop-prevention and spanning-tree specifics when answering wired assurance questions, and assuming Mist AI will identify a loop without any supporting protocol configuration.
Candidates focus on cloud features and forget that loop detection depends on switch-side protocols and that topology data is only as good as what the switches report.
What to do instead
Review the loop-prevention mechanisms available on the switch platform and how their events surface as alarms or SLE impacts. Be able to explain what telemetry a loop produces and which dashboard view would confirm it.
Answering firmware upgrade and configuration-audit questions with generic best practices instead of the Mist-specific upgrade workflow, including upgrade schedules, site-level versus device-level targeting, and rollback considerations.
Firmware management is usually studied superficially, so candidates default to vague answers about testing before upgrading rather than the concrete scheduling and targeting mechanics the exam tests.
What to do instead
Walk through a firmware upgrade plan step by step: choose target version, scope the upgrade to a site or device set, schedule a window, monitor progress, and define rollback. Note where compliance or configuration-audit status is checked before and after.
Failing to convert marvis conversational output into a concrete next action, and instead selecting answers that restate the symptom or describe escalation without any diagnostic step.
Candidates treat marvis as a search box and pick the answer that sounds most like the question, rather than the one that names the specific verification or remediation the assistant is recommending.
What to do instead
Practice reading marvis responses and extracting three things: the identified root cause, the affected scope (client, port, switch, site), and the recommended action. Answer questions by matching all three, not just the symptom wording.