A certificate deployment can fail even when the leaf certificate looks correct. The key may match, the subject alternative name may be present, and the expiration date may be acceptable, but a client still needs a chain from that leaf to a trust anchor. The intermediate certificate is the piece most often missed when a service package, load balancer, or secret contains only the leaf certificate.

OpenSSL’s verify command gives that problem a small, offline test boundary. This guide builds a disposable three-certificate hierarchy, proves that a leaf without its intermediate fails, and then supplies the intermediate explicitly to prove that the same leaf can be validated from the chosen root. The successful result is a repeatable pre-deployment check: missing chain material returns a nonzero status, while the complete chain reports OK.

A service unit can look harmless in a change review: a new ExecStart path, a dependency on a target, or one hardening directive. The failure often arrives after someone has copied the file into the system unit directory and run systemctl daemon-reload. At that point the change is mixed with every other unit file the manager discovers, and an operator has to decide whether the diagnostic belongs to the proposed service or to an older file already on the host.

A Terraform variable declaration is often treated as a convenience for making a module reusable. It is also an input boundary. A value can have the right HCL syntax and still be unsuitable for the module: a replica count of zero, a fractional capacity, or a string where an API expects a number. If that condition is left to a resource argument or a provider API, the failure can arrive after Terraform has initialized providers, read state, or started to construct a larger plan.

A Helm chart can render successfully for its default values.yaml and still fail at the point where a deployment pipeline supplies its environment-specific override. That is where an unquoted number becomes a string, a required image tag is omitted, or a nested value is given the wrong shape. Template review alone does not make that boundary explicit. The chart needs a contract for the values that operators and CI are allowed to provide.

A Prometheus configuration change can be small enough to look safe in a review: a new scrape job, a shorter interval, or one target list. The process that consumes it has stricter rules than YAML alone. A file can be valid YAML and still be rejected because a duration is malformed, a job has no name, or the scrape timeout exceeds the interval. Finding that after a reload turns a routine monitoring change into an incident response task.

A deployment policy can look restrictive in a pull request while one small edit quietly removes the condition that made it safe. That is especially easy to miss in a short Rego rule. An approval requirement, environment check, or immutable artifact check is often one expression among several. Reading the policy is necessary, but it is not a substitute for asking the policy engine whether the requests that must be refused are still refused.

An etcd upgrade check should prove more than that a daemon starts. Operators need to know that the version of etcdctl in the release can commit a request to the endpoint and that the backup procedure still produces an inspectable snapshot. Those are separate checks. A listener can answer a TCP connection while a client request fails, and a snapshot file can exist without the tool used to examine it being present where the runbook expects it.

A policy file can be valid HCL and still grant the wrong access. The more useful test is not whether the file can be uploaded, but whether a token made from it can read the one path it needs and is refused everywhere else. That distinction is easy to miss when a policy change is reviewed as a few lines of text and then applied directly to a shared OpenBao cluster.

A systemd service can start reliably while having almost no containment. That is easy to miss when a unit file is short: an ExecStart line, perhaps a restart policy, and nothing visibly wrong. If the process is later compromised, its ability to read host paths, create sockets, load devices, or gain privileges is determined by the unit’s service settings as well as by the application itself.

This guide uses systemd-analyze security --offline=yes to establish a repeatable before-and-after review for a unit file without starting the service. The completed check takes a candidate unit, records the analyzer’s exposure result, adds restrictions that fit the service, and records the remaining findings for review. In an isolated Linux AMD64 test using systemd 257.13, a minimal Type=oneshot unit scored 9.4, UNSAFE. Adding a deliberately restricted set of filesystem, privilege, device, and socket controls reduced it to 6.3, MEDIUM. The result is not a claim that the service is safe; it is evidence that the proposed sandbox changed the boundaries that systemd can measure.

An SBOM is only useful if it describes the directory or image that the release process is about to publish. Generating one after an artifact has moved to another job, registry, or environment can leave a gap: the report may be well formed, but it may no longer identify the bytes that deployment will use.

This guide uses Syft 1.51.0 to scan a local build directory, write both CycloneDX JSON and SPDX JSON, and check the resulting inventory before a later CI step uploads the artifact. The completed result is a small fail-closed shell boundary: it verifies the downloaded Syft archive, generates two machine-readable SBOM formats from a named directory, and stops if the expected package is absent. The example scans a disposable directory on the runner. It does not contact a registry, Docker daemon, cluster, or production system.