JCPA common mistakes
JCPA · Understand the traps and how to avoid them.
Treating Junos PyEZ as a screen-scraper: calling dev.cli() or sending 'show configuration | display set' and parsing text for routine config reads instead of using structured RPCs.
Candidates with CLI/Expect backgrounds default to command output and text parsing, and are unaware that PyEZ exposes structured XML/JSON through rpc.get_config() and Table/View definitions, so they miss structured-data questions and write fragile solutions.
What to do instead
Practice retrieving configuration with rpc.get_config() and operational data with rpc.get_* methods or prebuilt Tables; reserve dev.cli() for genuinely unstructured output and be able to explain why structured RPCs are preferred (idempotent parsing, schema-aware fields, less breakage on Junos upgrades).
Forgetting to open a configuration session or to lock/commit/unlock when changing configuration with Junos PyEZ, leaving changes uncommitted or leaving the candidate locked out.
The candidate knows the Junos CLI workflow (configure, commit) but not the PyEZ API equivalent, so they assume loading configuration is enough or that commit happens implicitly, and they skip the 'with dev.cu as cu' context manager that handles lock, commit, and unlock.
What to do instead
Memorize the load/commit lifecycle: open a Config or use 'with dev.cu as cu', lock, load via cu.load(path=..., format='text' or 'set'), cu.commit(), and rely on the context manager to unlock on exit; be able to state what happens if commit fails and why explicit unlock matters.
Confusing NETCONF operations and their roles: using <edit-config> where <get-config> is required, mixing up merge/replace/create/delete default-operation values, or assuming <copy-config> and <edit-config> are interchangeable.
Candidates learn the operation names as a list without mapping each to its purpose, and RFC 6241 semantics (target vs source, default-operation inheritance, operation attributes on individual elements) are easy to blur under exam pressure.
What to do instead
Build a one-page mapping of each NETCONF operation to its intent and required parameters, and practice reading a raw message to identify the operation, target datastore, and default-operation; note that per-element operation attributes override the message-level default-operation.
Assuming NETCONF and RESTCONF are interchangeable transports over the same data with the same paths and encoding, e.g. sending XML bodies to a RESTCONF endpoint or expecting datastore concepts like candidate/running to behave identically.
Both are YANG-driven and both appear in automation discussions, so candidates collapse them into one mental model and miss the HTTP-method mapping (GET/POST/PUT/PATCH/DELETE), media types, and the fact that RESTCONF is defined over HTTP with its own resource URI conventions.
What to do instead
Contrast them explicitly: NETCONF over SSH with XML RPCs and named datastores; RESTCONF over HTTPS with JSON or XML, HTTP verbs mapped to create/read/update/delete, and data resource paths derived from the YANG module. Practice converting one intent (e.g. add a static route) into both a NETCONF edit-config and a RESTCONF PATCH.
Treating YANG as documentation rather than a schema: failing to use leaf, leaf-list, list, container, key, mandatory, and choice/type constraints when constructing payloads, and guessing element names instead of reading the model.
Candidates skim YANG trees for field names and ignore constraints, so they produce payloads with wrong nesting, missing keys, or values outside a type's range, and they cannot answer questions about what a model permits.
What to do instead
Practice reading a YANG module and deriving the exact JSON/XML payload shape, including list keys and container nesting; check types (e.g. inet:ipv4-address), mandatory leaves, and defaults before sending. Be able to explain what 'config false' means for a node and why it cannot be set.
Writing Python automation that concatenates strings to build JSON or XML instead of using json.dumps/loads or an XML library, and not handling HTTP status codes or JSON decode errors from API responses.
String-building feels faster for small examples and works in demos, but it breaks on quoting, escaping, and nested structures; candidates also forget that a 200 response body may not be the expected schema or may be empty.
What to do instead
Always serialize with the json module (or an XML library) and parse responses defensively: check status codes, handle empty bodies, and validate keys before indexing. Practice converting a nested dict to JSON and back, and reading a RESTCONF response into a dict to extract a specific leaf.
Misjudging idempotency and change detection in configuration management: writing Jinja2 templates or Ansible tasks that reapply the entire configuration every run, or using 'replace' semantics when merge was intended, without checking for drift.
Candidates equate 'the playbook ran successfully' with 'the device is correct and unchanged', and they do not distinguish template rendering from device-side merge/replace behavior, so they miss questions about idempotency, diffs, and safe rollback.
What to do instead
For each tool, state the default merge behavior and how to request replace or a diff; compare intended vs actual config before committing, and prefer targeted changes over full-config pushes. Practice rendering a Jinja2 template and predicting exactly which lines change on a second run.
Confusing streaming telemetry with SNMP polling, and not knowing the roles of the collector, the sensor/path subscription, and the transport (gRPC/UDP), or how event-driven automation differs from scheduled polling.
SNMP is the older, more familiar model, so candidates describe telemetry as 'faster SNMP' and cannot answer questions about subscription-based push, encoding (e.g. GPB/JSON), or what triggers an event-driven action.
What to do instead
Draw the pipeline: sensor path subscribed on the device, data pushed to a collector over a streaming transport, then stored/alerted. Contrast push vs pull, and describe an event-driven flow (event policy or on-box trigger invoking an action) versus a polling loop with a threshold check.
Treating version control and CI/CD as afterthoughts: committing secrets or device credentials to the repo, editing directly on the automation server, or having no validation stage before deployment.
Candidates focus on making the automation work once and skip the workflow, so they cannot reason about branch/merge, review, or pipeline stages, and they underestimate how secrets in Git become permanent history.
What to do instead
Describe the standard flow: feature branch, review/merge, pipeline stages of lint/syntax check, template render, dry-run or diff against the device, then deploy with rollback. Keep credentials in a vault or environment-injected secrets, never in the repo, and be able to explain why a failed validation stage must block deployment.
Assuming automation credentials should be the same as interactive admin accounts with full permissions, and not distinguishing authentication from authorization or accounting in an automation design.
Candidates reuse a personal login because it is convenient, and they treat 'it authenticated' as 'it is allowed', missing least-privilege service accounts, role separation, and auditability of automated changes.
What to do instead
Design for a dedicated automation account with only the permissions the job needs, separate read-only versus change-capable roles, and log every automated change with the job identity. Be able to explain AAA concepts and why a shared superuser credential undermines both security and audit trails.