JNCIA-DevOps key terms

A property of an operation where applying it repeatedly produces the same end state as applying it once, so reruns are safe. Configuration tools rely on it to converge devices without duplicating changes.

A style where you describe the intended end state of a system and let a tool decide the steps to reach it, rather than listing imperative commands in order.

An approach where the script specifies each step to execute in sequence. It gives precise control but requires the author to handle ordering, error checks, and repeated-run safety.

The target configuration or condition that a management system should enforce on a device or service. Tools compare actual state to this target and correct any drift.

The process by which an automation tool repeatedly brings a system closer to its desired state until no further changes are needed, then reports the system as compliant.

The condition where a device's running configuration or software state diverges from the version stored in source control or the intended template, often due to manual edits.

The authoritative repository or database that holds the intended network state, such as device inventory, IP addressing, and configuration templates. Automation reads from it rather than from ad hoc notes.

A parameterized text file containing placeholders that are filled with data at render time to produce a device-specific configuration. It keeps common structure in one maintainable place.

A Python-based templating language using expressions, filters, and control structures such as loops and conditionals. It is widely used to render network configuration from structured data.

A human-readable data serialization format using indentation and key-value pairs. It commonly stores inventories, variables, and playbooks in network automation workflows.

A lightweight text format for structured data built from objects, arrays, strings, numbers, and booleans. It is the usual encoding for REST API requests and responses.

A markup format using nested tags that can carry attributes and namespaces. Junos supports it for configuration and operational data, including NETCONF message payloads.

A general-purpose programming language with a large library ecosystem, commonly used for network scripts, API clients, and data parsing. Readability and indentation-based syntax are its hallmarks.

A reusable collection of code that provides functions or classes for a specific purpose, such as HTTP requests or device communication, so you avoid writing common logic yourself.

A Juniper Python library that provides an object-oriented interface to Junos devices over NETCONF, supporting configuration loading, operational command execution, and structured fact retrieval.

An IETF protocol that uses XML-encoded remote procedure calls over a secure transport to read and modify device configuration and retrieve operational data in a structured way.

A data modeling language that defines the structure, types, and constraints of configuration and state data exposed by a network device, forming the contract used by NETCONF and related interfaces.

An HTTP-based protocol that exposes YANG-modeled data using REST conventions such as GET, POST, PUT, PATCH, and DELETE, with resources identified by URL paths.

An interface built on HTTP where clients send requests to resource URLs and receive responses, typically encoded in JSON, with status codes indicating success or failure.

The verb in an HTTP request that states the intended action, such as GET to read, POST to create, PUT or PATCH to modify, and DELETE to remove a resource.

A three-digit number in an HTTP response indicating the outcome, for example 200 for success, 401 for authentication failure, 404 for a missing resource, and 500 for a server error.

The native Junos interface that accepts XML-encoded requests for configuration and operational commands and returns structured XML responses, usable over NETCONF or secure shell.

A PyEZ mechanism where a View maps XML fields to named columns and a Table defines which operational command to run, returning results as iterable structured records.

A Junos commit option that activates changes temporarily and automatically rolls them back unless confirmed within a set time, protecting remote sessions from losing connectivity.

A Junos configuration buffer where edits are staged before being checked and committed. Multiple users can edit it, and changes do not take effect until committed.

Restoring a device to a previously committed configuration, identified by an index such as rollback 1 for the prior version. It is a fast recovery path after a failed change.

A system that tracks changes to files over time, records who changed what and why, and enables branching, review, and reversion. Automation content and templates belong in it.

A distributed version control system where each commit records a snapshot of changes with a unique hash, and branches allow parallel work that is later merged.

A request to merge changes from one branch into another, providing a place for diff review, automated checks, and peer approval before the change is accepted.

A practice where peers examine proposed changes for correctness, style, and risk before merge. In network automation it catches errors that could disrupt production devices.

A practice where developers merge changes frequently and each merge triggers automated build, syntax, and test checks, giving fast feedback on whether the change is safe.

An extension of continuous integration where every validated change is kept in a deployable state, so release to production is a routine, low-risk decision rather than an event.

An ordered set of automated stages, such as lint, test, build, and deploy, that a change passes through. Failures stop the flow and report back to the author.

An automated check that verifies expected behavior, such as validating configuration syntax, asserting parsed output, or confirming a device reaches the intended state after deployment.

An agentless automation tool that connects over SSH or API, runs tasks described in YAML playbooks, and uses modules to enforce configuration state on managed hosts.

A YAML file in Ansible that lists ordered plays and tasks to run against defined host groups, optionally using variables, handlers, and conditionals.

Managing networks and systems through machine-readable definition files stored in version control, so environments can be reproduced, reviewed, and audited like software.

The combined practice of continuously integrating and testing changes and continuously delivering them to environments through automated pipelines, reducing manual handoffs and release risk.

A review after an incident that focuses on systemic causes and process gaps rather than punishing individuals, producing action items that reduce the chance of recurrence.

A working norm where changes are shared early for constructive feedback, documentation is valued, and knowledge spreads across the team instead of residing with one expert.