JNCIS-DevOps flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

CALMS framework

Five DevOps pillars: Culture, Automation, Lean, Measurement, Sharing. Culture is listed first because tooling adoption fails without trust, collaboration, and shared ownership between development and operations teams.

DORA four key metrics

Lead time for changes, deployment frequency, change failure rate, and time to restore service. The first two measure throughput; the last two measure stability of the delivery process.

Three Ways of DevOps

Flow (optimize work moving dev to ops), feedback (amplify fast feedback loops from right to left), and continual learning (experiment, learn from failure, repeat).

Error budget

The allowed amount of unreliability, computed as 1 minus the SLO. When the budget is exhausted, teams prioritize reliability work over shipping new features.

Blameless postmortem

A review after an incident focused on contributing system conditions and process gaps rather than punishing individuals, producing owned, dated action items to prevent recurrence.

Toil

Manual, repetitive, automatable, tactical work that scales linearly with service growth and produces no enduring value. SRE practice caps it near half of operational time.

Idempotence

A property where applying the same operation repeatedly produces the same end state. It is the core reason declarative configuration management is safe to run on a schedule.

Configuration drift

Any divergence between the declared desired state and the actual state of a system, usually caused by manual changes. Detected by periodic enforcement runs or plan diffs.

Push versus pull configuration

Push tools (Ansible over SSH) need no agent and are easy to bootstrap. Pull tools (Puppet, Chef agents) scale better and self-correct drift on a schedule.

Ansible handler

A task triggered only when a notifying task reports changed. It delivers restart-on-change behavior, avoiding unconditional service restarts on every playbook run.

Immutable infrastructure

A model where servers are replaced rather than modified in place. Configuration is baked into the image at build time, eliminating runtime drift and simplifying rollback.

Secrets management rule

Credentials must live in a vault or encrypted store and be injected at deploy time. Secrets committed to git remain in history even after the file is deleted.

Continuous integration

A practice where every commit to shared trunk triggers an automated build and test run, keeping integration problems small and detected within minutes rather than weeks.

Delivery versus deployment

Continuous delivery keeps trunk always deployable with a manual release decision. Continuous deployment removes that gate and releases every passing change automatically.

Build once, promote

Build the artifact a single time and promote that identical artifact through environments. Rebuilding per environment invalidates test evidence gathered earlier in the pipeline.

Trunk-based development

Short-lived branches merged frequently into a single trunk, with incomplete work hidden behind feature flags. Associated with higher delivery performance than long-lived branches.

Test pyramid

Many fast unit tests, fewer service or contract tests, and fewest UI end-to-end tests. An inverted pyramid produces slow, flaky pipelines that teams stop trusting.

Reproducible build

A build where identical source and pinned dependency versions produce an identical artifact. Unpinned dependencies and floating tags break reproducibility and rollback confidence.

Blue-green deployment

Two identical environments where traffic switches from the live (blue) to the updated (green) stack. Rollback is a fast traffic switch back to the previous environment.

Canary release

Routing a small percentage of traffic to a new version while monitoring error rate and latency, then progressively increasing traffic or aborting automatically on degradation.

Terraform state file

A mapping between declared resources and real infrastructure objects. Stored remotely with locking so concurrent applies cannot corrupt or overwrite each other.

terraform plan

A dry-run that diffs desired configuration against current state and real infrastructure, showing proposed creates, updates, and destroys before any change is applied.

Declarative versus imperative IaC

Declarative describes the desired end state and lets the tool compute steps (Terraform). Imperative describes the steps to execute, typically a script, and is not self-correcting.

NETCONF transport

A network configuration protocol carried over SSH on TCP port 830, encoding YANG-modeled data as XML for retrieving and editing device configuration.

RESTCONF

A protocol mapping YANG data models onto HTTP methods and URIs, returning JSON or XML. It offers REST-style programmability for devices that support YANG models.

gNMI streaming telemetry

A gRPC-based interface for model-driven configuration and continuous streaming of device telemetry, providing finer granularity and lower latency than periodic SNMP polling.

Template plus data pattern

Generating device or infrastructure configuration by rendering a Jinja2 template with structured data from a YAML or JSON inventory, keeping configs consistent and reviewable.

Three pillars of observability

Metrics (aggregated numeric time series), logs (discrete timestamped events), and traces (request paths across services). Together they let you answer previously unasked questions.

Four golden signals

Latency, traffic, errors, and saturation. These are the four metrics recommended for monitoring a user-facing service and setting meaningful alerts.

SLI, SLO, SLA

SLI is the measured indicator, SLO is the internal target for it, and SLA is the contractual commitment with consequences. The SLO should be stricter than the SLA.

Multi-window burn-rate alert

An alert that fires when the error budget is consumed faster than a threshold over both a short and a long window, reducing noise compared with static threshold alerts.

Distributed tracing

Correlating a request across services using a propagated trace ID and per-hop spans, revealing where latency accumulates in a multi-service call path.