DevNet Professional common mistakes
DevNet Professional · Understand the traps and how to avoid them.
Treating YANG models as if every leaf is settable, so candidates build edit-config payloads that include operational/read-only leaves (config false) and then cannot explain why the device rejects or silently ignores them.
Candidates memorise 'NETCONF uses YANG' but study model structure only at the tree-diagram level, never checking the config true/false distinction, mandatory nodes, or choice/case constraints before writing payloads.
What to do instead
For each model you use, read the module header and annotate each node as config or state, note mandatory and default values, and practise building a minimal edit-config that touches only config-true leaves. Test against a real or simulated device and read the rpc-error entries rather than assuming success.
Using RESTCONF the same way as NETCONF: sending a full replacement body with PUT when only one field should change, or forgetting the Content-Type and Accept headers that select the encoding.
Candidates learn HTTP verbs generically and do not connect PATCH versus PUT to YANG semantics, nor do they realise RESTCONF requires application/yang-data+json (or +xml) rather than application/json.
What to do instead
Memorise the mapping: GET reads, POST creates, PUT replaces the target resource, PATCH merges, DELETE removes. Practise a PATCH with a partial body and confirm unchanged siblings survive, and always set both Accept and Content-Type to the yang-data media type.
Answering questions about idempotency and declarative intent by describing a script that re-runs imperative CLI commands and calls it idempotent because 'it ends in the same state'.
Candidates conflate 'converges eventually' with idempotency and have not contrasted an imperative show-and-parse loop against a declarative model-driven push.
What to do instead
Define idempotency precisely: applying the same desired state twice produces no additional change and no error. Be ready to explain how a declarative tool diffs current versus intended state, and to identify which parts of a given workflow (discovery, diff, apply, verify) are read-only versus mutating.
Assuming a Cisco DNA Center or Meraki API call works with only an API key or only a token, and hard-coding the base URL or version path without checking the platform's documented authentication and versioning scheme.
Candidates generalise from one platform they have used and skip the authentication section of the API docs; token lifetimes, header names (X-Auth-Token versus Authorization: Bearer versus X-Cisco-Meraki-API-Key) and version prefixes differ per platform.
What to do instead
For each platform you study, write a one-page card: base URL, auth mechanism and header, token lifetime and refresh, pagination style, rate limits, and error body shape. Then make one authenticated read call per platform in a sandbox so the header names and version path are memorised from practice, not assumption.
Ignoring pagination and rate limiting on list endpoints, then concluding the API is broken when only the first page of results is returned or a 429 appears during a bulk run.
Candidates test with small tenants where the first page covers everything, so offset/limit or cursor handling and backoff logic never get exercised.
What to do instead
Always implement and test the loop: read the total count or next-page cursor, iterate until exhausted, and add exponential backoff with jitter on 429 and 5xx. Practise by lowering the page size parameter so multiple pages are forced, and verify record counts match the reported total.
Mixing platform SDKs and raw HTTP without understanding the object model, for example treating a Cisco SD-WAN or ACI object as a flat dictionary and sending a payload missing required parent containers or attributes.
Candidates copy a sample payload from documentation and change values without understanding which fields are class identifiers, which are required relations, and which are server-generated.
What to do instead
Before writing code, fetch an existing object of the same type, study its full structure, and use that as the template. Identify which fields the server generates (IDs, timestamps, status) and strip them from create payloads. Validate payloads against the platform's schema or model where one is published.
Writing pipeline stages that run tests but never fail the build, because test commands are chained with a shell construct that swallows the non-zero exit code, or because unit tests are skipped in the CI job.
Candidates focus on getting a green pipeline rather than a truthful one, and copy stage snippets without checking how the runner propagates exit codes.
What to do instead
Practise a deliberately failing test and confirm the pipeline goes red. Avoid constructs that mask exit status; run linters and tests as separate stages; add a gate that blocks merge on failure. Verify by inspecting the job log for the actual test summary, not just the stage badge.
Storing credentials, API keys, and device passwords in the repository or in plain pipeline variables, and being unable to explain how a secret reaches the automation at runtime.
Candidates prioritise a working demo over hygiene and have not used a secret store or environment-scoped variables, so the secure path feels unfamiliar under exam pressure.
What to do instead
Use the platform's secret store or a vault, inject secrets as environment variables or short-lived tokens at runtime, and reference them by name in code. Add a pre-commit secret scanner and a .gitignore for local env files. Be able to describe the full path from secret store to process memory and why the secret never appears in logs.
Describing a CI/CD design with no artefact or environment promotion story: tests run against production, or the same untested branch is deployed everywhere, and rollback is 're-run the old job'.
Candidates learn pipeline syntax but not the deployment model, so branching strategy, artefact versioning, environment gates and rollback are treated as afterthoughts.
What to do instead
Be able to sketch: commit triggers lint and unit tests, a build produces a versioned artefact, that same artefact is promoted through staging to production behind manual approval, and rollback redeploys the previous artefact version. Explain what is tested at each gate and why the artefact, not the source branch, is what moves.
Designing automation with no verification or rollback step, treating a successful API response or CLI exit code as proof the network is in the intended state, and having no plan for partial failure across many devices.
Candidates equate 'the call returned 200' with 'the change worked' and do not consider convergence time, per-device divergence, or what happens when device seven of twenty fails.
What to do instead
Design every change as discover, plan/diff, apply, verify, with an explicit post-change state check (routes present, interfaces up, config matches intent) and a defined rollback trigger. Address partial failure explicitly: continue-and-report versus stop-and-revert, how to identify which devices changed, and how to re-run safely given idempotency.