JNCIA-DevOps common mistakes
JNCIA-DevOps · Understand the traps and how to avoid them.
When asked to retrieve or change device state through the Junos REST API, the candidate sends requests to the wrong endpoint or port, or forgets the Accept header, and then cannot explain why the response is HTML or a 404 instead of XML/JSON.
Candidates memorize that 'Junos has a REST API' but never practice the concrete details: the REST service must be enabled with set system services rest, it listens on port 3000 by default, the rpc URL path is /rpc/, and the Accept header (application/xml or application/json) drives the response format. Without hands-on use they conflate it with NETCONF on port 830 or with J-Web on 443.
What to do instead
Build a lab checklist and run it end to end: enable rest, confirm with show configuration system services, then issue a GET to https://:3000/rpc/get-software-information with an explicit Accept header and authenticate. Repeat using POST for an operational command and for a configuration load. Record which port, path, method, and header each task needs so the mapping is automatic on exam day.
The candidate writes PyEZ code that calls a method or uses an import from memory (for example mixing up Device versus Device.rpc versus Config) and cannot predict what the object returns, so they pick an answer that looks syntactically plausible but is behaviorally wrong.
PyEZ is usually studied by reading snippets rather than running them. Candidates learn that 'Device opens a connection' but not that you must use a context manager or call open()/close(), that rpc.get_* methods return lxml elements, and that configuration changes go through Config with lock, load, commit_check, and commit. The result is guessing on questions that hinge on exact object behavior.
What to do instead
Write and execute at least five small scripts: connect with Device(host=..., user=..., password=...) inside a with block, run an operational RPC, load configuration in merge and replace modes, use commit_check before commit, and diff with pdiff. Type them by hand rather than pasting, and note the return type of each call.
Given a JSON or YAML data structure, the candidate misreads nesting or type (for example treating a list as a dictionary, or missing that a value is a string 'true' rather than boolean true) and then selects an automation script output that would never be produced.
Candidates from a CLI background often skim structured data and rely on visual pattern matching. They have not internalized that YAML indentation defines hierarchy, that JSON requires quoted keys, and that Jinja2 or Python will fail or behave differently when a list is indexed by key. Exam questions deliberately probe these distinctions.
What to do instead
Practice parsing real outputs: take show configuration | display json and a YAML inventory, load them with Python's json and yaml modules, and print the type of each nested element. Write a Jinja2 template that loops over a list of interfaces and confirm what happens when you pass a dict instead. Do this until you can predict the error before running it.
The candidate treats Infrastructure as Code as 'store a config file in Git' and cannot distinguish declarative intent from imperative scripts, or idempotence from mere re-execution, when evaluating a scenario.
The IaC domain rewards conceptual precision, but candidates prepare by memorizing tool names. They miss that idempotence means applying the same desired state twice yields no additional change, that declarative models describe the end state while imperative models describe steps, and that drift detection depends on comparing actual state to the declared source of truth.
What to do instead
For each tool you study, write one sentence stating what is declared, what enforces it, and how drift is detected. Then construct a concrete example: apply the same interface description twice and show the second run produces no diff. Contrast that with a script that appends a statement each run. Use these examples to answer scenario questions.
When asked about configuration management on Junos, the candidate confuses commit-time behavior with load-time behavior, or assumes a commit always succeeds, and therefore picks answers that ignore commit confirm, rollback, or candidate configuration semantics.
Candidates learn commit as a single verb. They do not practice commit check to validate syntax without applying, commit confirmed for safety with automatic rollback, or rollback 1 to revert. They also forget that changes go to a candidate config and only take effect on commit, which changes what an automation script must do to be safe.
What to do instead
In a lab, deliberately introduce a syntax error and run commit check to see it rejected, then commit confirmed 1 and let it roll back automatically, then commit and use rollback 1. Script the sequence with PyEZ Config and observe each stage. Memorize the order: lock, load, commit check, commit (or commit confirmed), then unlock.
The candidate describes a CI/CD pipeline as 'build then deploy' and cannot place where testing, artifact storage, or approval gates belong, or explain why a failed stage should stop the pipeline.
CI/CD questions test the purpose of each stage, not tool syntax. Candidates who have not seen a pipeline file often do not know that CI produces a tested artifact, that CD promotes that same artifact through environments, and that gates and rollback are what make frequent delivery safe.
What to do instead
Write a pipeline definition for a small network automation repo with explicit stages: lint, unit test, build artifact, deploy to lab, integration test, manual approval, deploy to production. For each stage, write one line on what failure means and what happens next. Be able to justify why the artifact is built once and promoted rather than rebuilt.
The candidate answers DevOps culture questions with tool answers, for example responding to a question about blameless postmortems or feedback loops by naming a CI server or a version control system.
The culture domain uses vocabulary that sounds soft, so candidates skip it and over-index on tooling. They then miss that blameless postmortems focus on systemic causes, that small batch sizes and fast feedback reduce risk, and that shared ownership replaces handoffs between siloed teams.
What to do instead
Build a one-page glossary of culture terms with a concrete example each: blameless postmortem, feedback loop, small batch, shift-left testing, shared ownership, and toil. For each, write a sentence on what it changes in practice. Practice answering 'what would you change in this scenario' using those terms rather than product names.
The candidate cannot read a Junos configuration hierarchy well enough to predict the effect of a set or delete command, especially with inheritance and apply-groups, and so misjudges what an automation script will produce.
Automation questions often hinge on configuration structure. Candidates who only memorize individual commands do not see that interfaces, protocols, and routing-options are separate hierarchies, that deactivate leaves a statement present but inactive, and that apply-groups inject inherited statements that do not appear where expected.
What to do instead
Practice by writing set commands for a small topology, then render the result with show configuration | display set and compare to the hierarchical view. Deactivate a statement and observe the inactive tag. Create an apply-group and confirm where the inherited configuration appears. Do this until you can predict the diff before committing.
The candidate assumes every automation task needs a full device connection and does not consider alternatives such as NETCONF, REST, or on-box scripting with SLAX or Python, so they choose an approach that does not match the constraints in the question.
Candidates learn one method, usually CLI screen scraping or a single library, and apply it everywhere. They miss that NETCONF over SSH on port 830 is suited to structured configuration, that REST fits lightweight HTTP clients, and that on-box scripts run where the device is and avoid network dependencies.
What to do instead
Make a comparison table with columns for transport, port, data format, configuration capability, and best use case, and fill it for CLI, NETCONF, REST, and on-box scripting. Then answer practice scenarios by first identifying the constraint (no external server, HTTP-only client, structured data needed) and selecting from the table.
The candidate skims the question stem for a keyword and answers from memory without checking the scenario's constraints, such as a requirement for idempotence, rollback safety, or no downtime.
The exam is scenario-heavy, and many distractors are true statements that do not satisfy the stated constraint. Candidates under time pressure pattern-match on words like 'commit' or 'REST' and select a technically correct but contextually wrong option.
What to do instead
Adopt a fixed reading routine: identify the constraint words first, restate the goal in one sentence, then eliminate any option that violates a stated constraint even if it is otherwise true. Practice on scenario questions by writing the constraint next to each option before choosing.