Cisco 350-901 DEVCOR/AUTOCOR key terms

An HTTP interface that exposes resources at URLs and uses standard methods such as GET, POST, PUT, and DELETE to read or change them, usually exchanging JSON.

A property of an operation where repeating the identical request produces the same end state as sending it once, so retries are safe. GET, PUT, and DELETE are conventionally idempotent; POST usually is not.

A three-digit number in a response that summarizes the outcome, grouped into 1xx informational, 2xx success, 3xx redirect, 4xx client error, and 5xx server error classes that clients branch on.

Splitting a large collection response into smaller pages using limit and offset parameters or opaque cursors, letting a client walk all records without overloading the server or the network.

A server-side control that caps how many requests a client may make in a time window, typically signaling the limit through response headers and a 429 status when exceeded.

Client logic that re-sends a failed request after an increasing delay, often with random jitter, so transient errors clear without hammering a struggling service.

A callback where a service pushes an HTTP POST to a URL you register when an event occurs, replacing the need to poll for changes.

An authorization framework where a client obtains a scoped access token from an authorization server, often on a user's behalf, and presents it to call protected APIs without sharing passwords.

A compact, URL-safe token of header, payload, and signature segments that carries claims such as issuer, subject, and expiry, and whose signature lets a receiver verify it was not altered.

A long random string issued to identify a calling application, sent in a header or query parameter. It authenticates the app but usually carries no user identity or fine-grained scope.

Storing and distributing credentials such as passwords, tokens, and keys in a controlled vault or environment variable system rather than hardcoding them in source code or images.

A free hosted environment providing reserved or always-on access to Cisco platforms such as DNA Center, Meraki, and Webex, used to test API calls without owning hardware.

Cisco's intent-based network controller for campus and branch, offering REST APIs to manage sites, devices, templates, and assurance data, and to push configuration intent.

A REST interface to Cisco Meraki cloud-managed networking that lets scripts read and change organizations, networks, devices, and wireless settings through authenticated HTTPS calls.

A family of REST APIs for Cisco Webex messaging, meetings, and calling that lets applications create spaces, post messages, and manage users with OAuth tokens or bot tokens.

An XML-based network management protocol that runs over SSH, uses YANG models to describe device data, and supports candidate configurations and commit operations.

A protocol that exposes YANG-modeled device data and operations through HTTP methods, giving REST-style programmatic access to network configuration and state.

A data modeling language that defines the structure, types, and constraints of configuration and operational data on network devices, consumed by NETCONF and RESTCONF tooling.

A streaming mechanism where network devices push structured operational data at a set interval or on change, using YANG paths, instead of relying on repeated SNMP polling.

A YAML file describing an ordered set of tasks applied to inventory hosts, using idempotent modules so repeated runs converge the target to the declared state.

Managing networks and servers through version-controlled definition files and automation rather than manual console changes, enabling review, repeatability, and rollback.

Generating device or system configuration by rendering a parameterized template with per-device variables, so many devices share one reviewed source of truth.

An automated sequence that builds, tests, and deploys code or configuration on each change, catching defects early and making releases repeatable.

An immutable, layered filesystem bundle plus metadata that a container runtime starts as an isolated process, giving consistent behavior across environments.

A container orchestration platform that schedules workloads across a cluster, restarts failed pods, and exposes services through declarative manifests rather than imperative commands.

A set of design practices for portable services, including externalized configuration, stateless processes, and logs treated as event streams.

An architecture that splits an application into small independently deployable services communicating over networks, each owning its data and scaling separately.

A design structure separating an application into a model holding data and rules, a view rendering it, and a controller handling input and coordinating the two.

An automated check that exercises one small unit of code in isolation, using mocks or stubs for dependencies, to verify behavior and guard against regressions.

A workflow where a developer writes a failing test first, then the minimum code to pass it, then refactors, producing well-scoped code with tests as a byproduct.

A structured peer examination of proposed changes before merge, catching defects, spreading knowledge, and enforcing style and security standards.

A system such as Git that records file history as commits, supports branching and merging, and lets teams trace who changed what and why.

A vendor-supplied library that wraps an API's HTTP calls in language-native functions, handling authentication, serialization, and errors so developers write less boilerplate.

The client-side check that a server's certificate chains to a trusted authority, matches the hostname, and is unexpired. Disabling it to silence errors exposes traffic to interception.

Granting an identity only the permissions needed for its task, such as a read-only API token for a monitoring script, to limit damage from misuse or compromise.

The ability to infer a system's internal state from its outputs, combining logs, metrics, and traces so failures can be diagnosed without guessing.