DevOps / Basic: shared foundations / Lesson 6

Artifacts, configuration, and secrets

Keep release identity, environment settings, and sensitive credentials distinct while making their relationship auditable.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Classify artifacts, configuration, and credentials.
Validate settings before readiness.
Plan rotation and recovery without exposing secret values.

Separate three kinds of input

An artifact contains the software selected for release. Configuration selects environment-dependent behavior, while a secret grants access or protects confidential material. These categories interact but need different storage, review, and rotation policies. A public endpoint URL is usually configuration; a database password is a secret; a compiled application is an artifact. Do not rebuild an artifact merely to change a credential. Record which configuration and secret versions accompany the artifact without writing secret values into the release record. This separation makes promotion, recovery, and incident investigation less ambiguous.

Validate configuration before readiness

Text from an environment variable is not automatically a valid number, boolean, hostname, or file path. Define required fields, accepted formats, bounds, and precedence. Reject an absent required setting before announcing readiness rather than silently contacting a default system. The first example is a synthetic release record, and the second models a narrow configuration parser in memory. The parser accepts explicit true or false strings and a bounded integer timeout. It receives ordinary objects to avoid reading or changing a real environment, and its errors name fields without echoing values.

yaml Synthetic release association

artifact_id: lab-build-42
config_revision: lab-config-9
credential_version: lab-credential-3
schema_contract: compatible-v2
approval_record: lab-review-21

Only version identifiers are recorded. No credential value is present, and the record makes no claim that the fictional release exists.

Deliver secrets through a controlled channel

Use an approved secret facility and grant each workload only the specific access it requires. Avoid putting credentials in Git, image layers, build arguments, URLs, or diagnostic dumps. Environment injection and mounted files have different exposure and refresh behavior; neither is automatically safe. A secret can remain in a running process after the store rotates unless the application reloads or restarts according to a tested procedure. Prefer short-lived identities where the platform supports them, and distinguish the right to retrieve a secret from the right to administer the secret system.

python Harmless configuration parser

def config(values):
    flag = values.get("FEATURE", "false")
    if flag not in ("true", "false"):
        raise ValueError("Invalid FEATURE")
    text = values.get("TIMEOUT_MS", "1000")
    if not text.isascii() or not text.isdecimal() or not 1 <= int(text) <= 5000:
        raise ValueError("Invalid TIMEOUT_MS")
    return {"feature": flag == "true", "timeout_ms": int(text)}
print(config({"FEATURE": "false", "TIMEOUT_MS": "800"}))

Expected output

{'feature': False, 'timeout_ms': 800}

The false string stays false and the timeout becomes a validated integer. This Python 3 simulation has no environment, filesystem, or network access.

Rotate without creating a new outage

Plan credential replacement with the dependency owner. When supported, allow a short overlap in valid credentials, deploy or reload consumers, verify use of the replacement, and then revoke the old credential. Emergency compromise may require immediate revocation and a different availability trade-off. Test the procedure with synthetic credentials in an isolated environment. A rollback to an old artifact must not restore a revoked credential automatically. Record version identifiers and verification events, and avoid logging the old or new value as evidence that rotation happened.

Control drift and evidence

Configuration drift occurs when actual settings differ from the declared approved state. Detect it through versioned desired state and safe comparisons that expose keys and revisions rather than secret values. Distinguish an authorized emergency change from an unexplained mutation, then reconcile through the approved workflow. Recovery requires checking artifact, configuration, schema, and credential compatibility together. A deployment record with only a version label cannot answer these questions. Keep retention and access rules for diagnostic records because even nonsecret metadata can reveal internal architecture or tenant information when collected without limits.

Common errors and fixes

A secret survives deletion from Git

Why it happens: History, images, logs, or copies still contain it.
How to fix it: Revoke or rotate and assess exposure through the approved process.
Prevent it next time: Keep credentials outside source and build artifacts.

A false text flag enables a feature

Why it happens: String presence was treated as boolean parsing.
How to fix it: Accept explicit allowed values and compare content.
Prevent it next time: Test missing, empty, invalid, true, and false settings.

Rollback restores an expired credential

Why it happens: Secrets were bundled with the old release.
How to fix it: Select a compatible current credential through the secret channel.
Prevent it next time: Include credential compatibility in recovery rehearsals.

Check your understanding

1. Classify a container image, payment endpoint, and API token. What should a release record contain?

Show worked solution

They are artifact, configuration, and secret respectively. Record the immutable artifact identity, configuration revision, and secret version reference, plus compatibility evidence. Never copy the token into the record merely to make the association easy to inspect.

2. Rotation updated the store but a worker still uses the old token. What needs verification?