LPI DevOps Tools Engineer key terms

A set of twelve practices for building portable services, covering codebase, dependencies, configuration, backing services, build/release/run, stateless processes, port binding, concurrency, disposability, dev/prod parity, logs, and admin processes.

A branching model where developers commit small changes frequently to a single shared mainline, using short-lived feature branches and feature flags instead of long-lived branches to reduce merge conflicts.

An automated sequence of stages (checkout, build, test, package, deploy) that takes a source change through verification and delivery, failing fast when any stage reports an error.

The practice of merging every developer change into a shared mainline several times a day, with each merge triggering an automated build and test run to detect integration problems early.

A discipline where every change that passes automated tests is kept in a deployable state, so releasing to production is a routine business decision rather than a risky event.

Managing servers, networks, and platform resources through version-controlled definition files that tools apply automatically, replacing manual console changes with repeatable, reviewable provisioning.

A property of an operation that produces the same end state no matter how many times it is applied, allowing provisioning or deployment tools to safely re-run after partial failures.

Storing application and environment settings in version-controlled files rather than editing hosts by hand, so changes are auditable, reviewable, and reproducible across environments.

A model where servers or images are never patched in place; instead a new version is built and replaces the old one, eliminating configuration drift and simplifying rollback.

A runtime switch that enables or disables functionality without redeploying code, letting teams ship incomplete work behind a toggle and release it to selected users or environments.

A versioned storage service for build outputs such as container images, packages, and binaries, which pipelines publish to and deployments pull from as a trusted source.

A release technique that runs two identical environments, switching traffic from the live blue version to the prepared green version so rollback is just a traffic switch back.

Rolling a new version out to a small subset of traffic first, watching error rates and latency, then progressively widening exposure only if the metrics stay healthy.

A read-only, layered filesystem bundle plus metadata (entrypoint, environment, labels) that a container runtime instantiates; layers are content-addressed and shared between images.

A text recipe of instructions (FROM, RUN, COPY, ENTRYPOINT) that a builder executes layer by layer to produce a container image, with each instruction cached for reuse.

A Dockerfile technique using several FROM stages so compilers and build tools stay in an early stage while only the compiled artifacts are copied into a small final runtime image.

Reuse of previously built image layers keyed by instruction and input checksums; invalidating an early layer forces all later layers to rebuild, so ordering instructions matters.

A networked service that stores and distributes container images by repository and tag, supporting push from CI and pull by container runtimes, often with vulnerability scanning.

A human-readable label such as latest or 1.4.2 pointing at an image digest; because tags can be reassigned, production deployments should pin immutable digests instead.

An image identified by its content digest and never overwritten after publication, guaranteeing that what was tested is exactly what runs in production.

The low-level software that unpacks an image, sets up namespaces and cgroups, and starts the process; examples include runc, crun, and the higher-level containerd or CRI-O.

A kernel feature that isolates what a process can see, such as PIDs, network interfaces, mounts, hostnames, and users, forming the visibility boundary of a container.

A kernel mechanism (cgroup) that limits and accounts for CPU, memory, and I/O consumed by a group of processes, enforcing the resource boundaries of a container.

The gRPC contract between Kubernetes and container runtimes, letting the kubelet drive any compliant runtime such as containerd or CRI-O without runtime-specific code.

The smallest deployable Kubernetes unit: one or more containers sharing a network namespace, IP address, and volumes, scheduled together onto a single node.

A controller that manages a ReplicaSet to keep a declared number of identical Pods running and performs rolling updates and rollbacks when the Pod template changes.

A controller ensuring a specified number of matching Pod replicas exist at any time, creating or deleting Pods as needed; usually managed indirectly through a Deployment.

A controller for workloads needing stable identity: predictable Pod names, ordered start and stop, and per-Pod persistent storage, typically used for databases and clustered systems.

A controller that runs exactly one copy of a Pod on every eligible node, or a selected subset, commonly used for log shippers, node exporters, and network agents.

A stable virtual IP and DNS name that load-balances traffic to a set of Pods chosen by label selectors, decoupling clients from changing Pod addresses.

An API object declaring HTTP host and path routing rules to backend Services, realized by an Ingress controller that configures a reverse proxy or load balancer.

Key-value metadata attached to objects, combined with selector expressions that controllers and Services use to match and group the objects they manage.

An API object holding non-secret configuration as key-value pairs or files, injected into Pods as environment variables or mounted volumes so images stay environment-agnostic.

An API object for sensitive data such as passwords and tokens, stored base64-encoded and mounted or injected into Pods; encryption at rest and RBAC must be configured separately.

A namespaced request for storage of a given size and access mode that binds to a PersistentVolume, letting Pods use durable volumes independent of node lifetime.

Per-container declarations of guaranteed and maximum CPU and memory; the scheduler uses requests for placement and the kernel enforces limits, causing throttling or OOM kills when exceeded.

A controller that adjusts the replica count of a workload based on observed metrics such as CPU utilization or custom signals compared against declared targets.

The node agent that watches assigned Pods, pulls images, starts containers through the container runtime, and reports status and resource usage to the control plane.

The distributed key-value store backing the Kubernetes control plane, holding all cluster state; it requires quorum, backups, and restricted access because it is the source of truth.

A Kubernetes authorization mechanism where Roles or ClusterRoles list permitted verbs on resources and bindings grant them to users, groups, or service accounts.

A non-human identity used by Pods to authenticate to the Kubernetes API, with permissions granted via RBAC bindings and credentials mounted into the container.

A namespaced rule set selecting Pods and declaring which ingress and egress traffic is allowed; it only takes effect when the cluster runs a policy-capable network plugin.

Pod- or container-level settings controlling privilege and isolation, including runAsUser, readOnlyRootFilesystem, capabilities, and whether privilege escalation is allowed.

A helper container running in the same Pod as the main application, sharing its network and volumes to add logging, proxying, or metrics without changing application code.

An infrastructure layer of per-Pod proxies that handles service-to-service traffic, providing mutual TLS, retries, traffic splitting, and detailed telemetry without application changes.

Mutual TLS authentication in which both client and server present certificates and verify each other, commonly used to encrypt and authenticate traffic between services in a mesh.

A pull-based monitoring system that scrapes metrics endpoints, stores samples in a time-series database, and evaluates alerting rules written in its own query language, PromQL.

The query language for selecting and aggregating Prometheus time series, using label matchers, range vectors, and functions such as rate and histogram_quantile to build dashboards and alerts.

A quantitative measure of service behavior, such as request success rate or latency percentile, from which a service level objective and error budget are derived.

Recording a single request as a tree of timed spans across services, linked by propagated trace identifiers, so latency and failures can be attributed to a specific hop.

A vendor-neutral set of APIs, SDKs, and a collector for producing and exporting traces, metrics, and logs in a common format to many observability backends.

A Deployment strategy that replaces Pods gradually, respecting maxSurge and maxUnavailable, so the service keeps serving traffic while the new version is introduced.

A periodic check whose failure removes a Pod from Service endpoints without restarting it, preventing traffic from reaching instances that are not yet able to serve.

A periodic check whose repeated failure causes the kubelet to restart the container, used to recover from deadlocks that a process cannot detect on its own.