JNCIS-DevOps common mistakes
JNCIS-DevOps · Understand the traps and how to avoid them.
Answering Junos PyEZ questions by assuming ncclient-style NETCONF session handling, then getting stuck on how Config, Device, and operational RPCs relate.
Candidates memorize the idea of 'NETCONF over SSH' but never run through the Junos PyEZ object model, so they confuse Device (connection/locking) with Config (candidate configuration) and with rpc.get/rpc.cli for operational data.
What to do instead
Build a mental map: Device opens the session and provides context managers (dev.rpc, dev.timeout, dev.lock), Config is obtained via dev.config() for configuration changes, and operational data comes from dev.rpc. or dev.cli(). Practise a load-merge-commit-diff workflow and an operational RPC in a lab or sandbox.
Treating Infrastructure as Code as 'run a script once' and ignoring idempotency, state, and drift when asked about provisioning network devices.
Scripting experience leads candidates to pick imperative one-shot answers; they miss that IaC tools must converge to a declared state and detect/reconcile drift.
What to do instead
For each scenario ask: 'What happens if I run this twice?' Prefer declarative, idempotent approaches (templates plus configuration management or IaC tooling), and be able to explain how state files or device configuration comparison detect drift.
Confusing CI with CD and describing a pipeline as 'build, test, deploy' without distinguishing continuous delivery from continuous deployment or where gates belong.
The terms are used loosely in blogs, so candidates collapse them and cannot answer questions about manual approval gates, artifact promotion, or environment-specific deployment.
What to do instead
Learn the definitions precisely: CI is integrating and verifying frequently; continuous delivery keeps every change releasable with a manual gate; continuous deployment automates the release to production. Map each pipeline stage to its purpose and know where quality gates and approvals sit.
Choosing 'run everything on every commit' or 'only test in production' instead of reasoning about test pyramid, pipeline feedback time, and flaky test handling.
Candidates answer from intuition about thoroughness rather than pipeline economics, and they underestimate how slow or flaky stages destroy feedback loops.
What to do instead
Study the trade-off: fast unit and lint stages early, slower integration and network-validation stages later, and quarantine or fix flaky tests rather than retrying forever. Be able to justify stage ordering by feedback time and risk.
Describing Git workflows incorrectly, such as committing directly to main in a trunk-based model, or confusing merge, rebase, and cherry-pick when asked how to keep a feature branch current.
Candidates learn a few commands but not the branching model's intent, so they pick answers that match habit rather than the stated collaboration or review requirement.
What to do instead
Learn the purpose of each model: feature branches with pull requests for review, trunk-based development with short-lived branches and feature flags, and release branches for stabilization. Know that rebase rewrites history for a private branch while merge preserves it, and cherry-pick copies a single commit.
Treating DevOps as a toolset question ('which product enables DevOps?') instead of identifying culture, feedback loops, and shared ownership in scenario items.
Vendor marketing and certification naming bias candidates toward product answers, while the exam often tests the CALMS-style principles and blameless postmortem culture.
What to do instead
For culture questions, look for answers about cross-functional teams, shared responsibility for production, small batch sizes, blameless retrospectives, and measuring lead time and change failure rate. Reject answers that just name a tool.
Mixing up the four DORA metrics or substituting vanity metrics such as lines of code or number of deploys when asked to measure delivery performance.
Candidates remember 'four keys' vaguely and cannot map each metric to what it measures, so they pick plausible-sounding but wrong indicators.
What to do instead
Memorize the pairs: lead time for changes and deployment frequency measure throughput; change failure rate and time to restore service measure stability. Be ready to say which metric a scenario is really about.
Confusing monitoring with observability, or answering an incident question with 'add more alerts' when the scenario calls for logs, metrics, and traces correlated to find an unknown failure.
Traditional operations training emphasizes threshold alerts and dashboards, so candidates default to alerting even when the problem is diagnosing a novel failure mode.
What to do instead
Frame monitoring as answering known questions with predefined checks, and observability as answering new questions from telemetry (metrics, logs, traces, events). For unknown-cause incidents, choose correlated telemetry and distributed tracing over adding thresholds.
Ignoring the human and process side of incident response: skipping blameless postmortems, or proposing punishment and individual blame after an outage.
Candidates focus on the technical root cause and treat postmortems as a formality, missing that the exam tests learning culture and systemic fixes.
What to do instead
Choose answers that run a blameless postmortem focused on contributing factors, produce tracked action items, and feed findings back into automation, tests, and runbooks. Treat human error as a symptom of a system that allowed the mistake.
Assuming configuration management equals pushing CLI commands, and failing to distinguish declarative desired-state tools from imperative scripts or agent-based versus agentless models.
Network engineers are used to CLI scripts and expect configuration management to be the same; they also conflate push and pull architectures and their trust models.
What to do instead
Learn the categories: declarative desired-state configuration management versus imperative scripting; push versus pull execution; agent-based versus agentless (SSH/NETCONF) transport. Match the model to constraints such as device support, scale, and change approval.