ENAUTO 300-435 common mistakes
ENAUTO 300-435 · Understand the traps and how to avoid them.
Writing Python that calls a REST API but never checks the HTTP status code or parses the JSON error body, then wondering why a 400/401/404 silently returns an empty result.
Candidates practice happy-path scripts against a working sandbox and never see the failure branches; requests.post() with no status check looks identical to success, and the exam deliberately tests whether you know 2xx vs 4xx/5xx handling and that error payloads are JSON too.
What to do instead
Always branch on response.status_code (or call response.raise_for_status()), inspect response.text/json for the error message, and know the meaning of 200, 201, 204, 400, 401, 403, 404, 429, 500. Practice deliberately sending a bad token and a malformed body to see the real error shapes.
Confusing authentication vs authorization and mixing up token types - using a Cisco DNA Center basic-auth call where an X-Auth-Token header is required, or sending a JWT from SD-WAN Manager to a device API.
Each controller has its own auth flow (DNA Center token from POST /dna/system/api/v1/auth/token valid ~1 hour; SD-WAN Manager JSESSIONID cookie plus X-XSRF-TOKEN; device-level basic auth or a separate token). Candidates memorize one flow and reuse it everywhere.
What to do instead
Build a small reference table per platform: endpoint, method, auth artifact, header name, expiry, and how to refresh. Practice obtaining, reusing, and refreshing each token, and note that the DNA Center token must be sent as X-Auth-Token, not Authorization.
Treating YANG models and NETCONF/RESTCONF as interchangeable with SNMP or CLI - e.g. attempting a <get-config> with a subtree filter that uses CLI-style paths, or expecting RESTCONF to accept XML only.
The exam tests data-model literacy: YANG tree structure, containers vs lists vs leaves, keys, namespaces, and the difference between operational and configuration datastores. Candidates who only know CLI assume the XML/JSON payload mirrors show command output.
What to do instead
Learn to read a YANG tree: identify the module namespace, container path, list keys, and leaf types, then construct the corresponding XML (NETCONF) or JSON (RESTCONF) body. Practice get vs get-config, edit-config operations (merge/replace/create/delete), and RESTCONF media types (application/yang-data+json).
Using the wrong HTTP verb or URL for a Cisco DNA Center intent API - for example POSTing to /dna/intent/api/v1/network-device to list devices, or confusing the intent API with the older /api/v1 flow APIs.
DNA Center exposes intent APIs, flow APIs, and integration/ITSM APIs with different versioning and semantics; candidates skim a single example and generalize the verb, path, or version.
What to do instead
Memorize the pattern: GET /dna/intent/api/v1/ for reads, POST for creation, PUT for updates, DELETE for removal, and note that some operations are asynchronous and return a taskId to poll via /dna/intent/api/v1/task/{taskId}. Verify each endpoint in the API reference rather than guessing.
Ignoring asynchronous task handling in DNA Center and SD-WAN - reading a 202 response body as the final result instead of polling the task or monitoring the operation until completion.
Many controller operations (device claim, template deploy, software image push) are long-running. Candidates test with fast lab operations that return 200 and never learn the 202 + taskId pattern.
What to do instead
Recognize HTTP 202, extract executionId/taskId, and poll the task endpoint (DNA Center /dna/intent/api/v1/task/{taskId}; SD-WAN Manager realtime/statistics endpoints) with backoff until the task reports success or failure. Know that the task response carries progress and error details.
Writing SD-WAN Manager API calls without the XSRF token or session cookie, or using the wrong base path for configuration vs monitoring endpoints (e.g. /dataservice/ vs /template/config vs /statistics).
SD-WAN Manager splits its API into distinct surfaces: configuration (/dataservice/template/...), monitoring/statistics (/dataservice/device/...), and realtime. Candidates reuse a single base URL and forget the JSESSIONID + X-XSRF-TOKEN pair required after login.
What to do instead
Practice the full login flow: POST /j_security_check with credentials, capture JSESSIONID and XSRF-TOKEN cookies, send X-XSRF-TOKEN on subsequent calls, and map the correct base path per task (device inventory, templates, alarms, statistics). Verify with a real GET before building POSTs.
Misunderstanding SD-WAN policy and template structure - treating a feature template, device template, and CLI template as the same object, or assuming a policy change applies without being attached to a site/device.
SD-WAN configuration is hierarchical (feature template -> device template -> attached device; centralized policy -> site list -> VPN/topology). Candidates who only know CLI think a template push is immediate and global.
What to do instead
Draw the hierarchy and the attachment points: feature templates define variables, device templates bind them, and centralized policies attach to sites/topologies. Know that template changes require re-attach/push and that policy changes may need a config preview and deploy step.
Ignoring idempotency and configuration drift - writing scripts that blindly POST a change every run, or assuming a device is already in the desired state because a previous run succeeded.
Automation candidates come from manual CLI habits where each command is applied once. The exam tests whether you check current state before applying, and whether you understand merge vs replace semantics in NETCONF/RESTCONF and Ansible modules.
What to do instead
Read the current configuration first (get-config / GET), compare to intent, and only apply the delta. Prefer declarative tools (Ansible with correct state, NETCONF replace) and verify after applying by re-reading state. Know which operations are idempotent and which are not.
Confusing model-driven telemetry with SNMP polling - setting up a telemetry subscription but expecting to pull data, or using the wrong encoding/transport (gRPC vs NETCONF dial-out) for the platform.
Telemetry is push-based and model-driven; candidates who learned SNMP assume a poll/response model or assume all platforms support the same transport and encoding (JSON vs GPB vs KV-GPB).
What to do instead
Learn the telemetry pieces: sensor path (YANG), subscription (periodic vs on-change), encoding (JSON, GPB, KV-GPB), and transport (gRPC dial-out, NETCONF dial-out, TCP/HTTP). Practice configuring a subscription on an IOS XE device and receiving data on a collector, and check platform support before assuming a transport.
Skipping the versioning and pagination details of controller APIs - hardcoding an API path without the version segment, or fetching only the first page of results and assuming the list is complete.
DNA Center intent APIs are versioned (/v1, /v2) and many list endpoints paginate (offset/limit) or filter by query parameters. Candidates test against small labs where one page covers everything and never see the truncation.
What to do instead
Always include the correct version in the path, read the pagination fields in the response, and loop with offset/limit until exhausted. Practice with query filters and confirm counts against the controller UI. Note deprecated versions and what replaced them.