Module 15 key terms

A property of an operation where repeating it produces the same end state as running it once, so retries and reruns are safe without duplicating side effects.

The declared target configuration an operator or system should maintain, expressed as data rather than as a sequence of manual steps.

An approach where you describe the end result you want and let a tool determine the steps, as opposed to scripting each step yourself.

An approach where you issue explicit commands in order, so the outcome depends on the current state and on every prior step succeeding.

A continuous control process that compares observed state against desired state and takes corrective action whenever the two diverge.

A software component that watches resource state and drives the system toward the declared target by creating, updating, or deleting objects.

The divergence between the configuration actually deployed and the configuration recorded as intended, often caused by manual hotfixes or out-of-band changes.

An approved, versioned snapshot of settings used as the reference for comparison, auditing, and rollback decisions.

A model in which servers or components are replaced rather than modified in place, so every change produces a fresh, reproducible artifact.

A pre-built, tested machine or container template used as the starting point for new instances to guarantee consistent configuration.

A system that records every change to files with authorship and timestamps, enabling review, comparison, and rollback of configuration and code.

Managing servers, networks, and platform resources through machine-readable definition files stored and reviewed like application source code.

The act of creating and allocating the underlying resources, such as compute, storage, and network, that a workload needs before it can run.

Coordinated automation that sequences and supervises many provisioning or deployment tasks across multiple systems and dependencies.

An automated sequence of build, test, and deployment stages that moves a change from commit to production with consistent, repeatable steps.

A practice where every validated change is kept in a releasable state and can be deployed to production on demand with low risk.

A release technique that runs two identical environments and switches traffic from the old to the new one, allowing instant reversal.

Gradually routing a small share of live traffic to a new version while monitoring health, then expanding exposure only if metrics stay acceptable.

Restoring the previously known-good version or configuration after a failed change, ideally as an automated and rehearsed procedure.

The governed process for requesting, reviewing, approving, and recording modifications so that risk is understood before production impact.

A tamper-evident chronological record of who changed what and when, used for investigation, compliance evidence, and accountability.

Granting identities only the minimum permissions needed for their function, reducing blast radius if credentials are misused or compromised.

An authorization model that assigns permissions to roles and then binds users or services to those roles rather than granting rights individually.

Storing and distributing credentials, keys, and tokens in a controlled vault with rotation and access logging instead of hardcoding them in files.

The degree to which internal system state can be inferred from emitted telemetry, principally logs, metrics, and traces, without new instrumentation.

The automated collection and transmission of measurements and events from running systems to a backend for analysis and alerting.

A numeric measurement sampled over time, such as request rate or error ratio, aggregated into time series for dashboards and threshold evaluation.

A method of following a single request across service boundaries by propagating a shared identifier and recording per-hop timing spans.

A quantitative measure of service behavior, such as the proportion of requests served under a latency threshold, chosen to represent user experience.

A target range for a service level indicator over a defined window, used to decide when reliability work takes priority over new features.

The amount of unreliability a service may tolerate within a period, derived from its objective and consumed by incidents and failed requests.

Desensitization caused by excessive or low-value alerts, leading responders to ignore or delay reaction to genuine incidents.

A documented, step-by-step procedure for diagnosing and resolving a specific operational condition, kept current and linked from alerts.

A blameless review after an incident that reconstructs the timeline, identifies contributing causes, and assigns concrete preventive follow-up actions.

A structured investigation that traces a failure back to the underlying condition or conditions rather than stopping at the proximate trigger.

The scope of systems, users, or data affected when a component fails or a change goes wrong, used to reason about containment strategy.

Documenting which components rely on which others so that impact, startup order, and failure propagation can be predicted and tested.

Estimating future demand for compute, storage, and network resources and sizing the system so that growth does not degrade service.

A probe that reports whether an instance can serve traffic, used by load balancers and orchestrators to route or replace instances automatically.