Configuration Management
Configuration is everything needed to run the same artifact in different contexts: service endpoints, feature flags, resource limits, credentials, policy choices, and environment names. A deployable artifact should not contain production-only configuration baked into its bytes.
Separation and Control
Good configuration is explicit, typed where possible, validated at startup, and observable in safe form. The dangerous pattern is invisible configuration: defaults buried in code, undocumented environment variables, and secrets copied through chat. Configuration should have ownership, review paths, and rollback behavior.
Secrets need stronger handling than ordinary configuration. They should be stored in a secret manager, scoped narrowly, rotated, audited, and injected at runtime. A secret in Git history must be treated as exposed even after deletion.
Environment Differences
Development, staging, and production will differ, but the differences should be intentional. If staging has a different database engine, no traffic, weaker identity rules, and mocked dependencies, it is not a convincing rehearsal for production.
Exercise
List the configuration keys for a service and classify each as public config, sensitive secret, operational limit, or policy decision. Anything unclassified is probably tribal knowledge.
Configuration Shape
Configuration should have a schema. A service that accepts arbitrary environment variables with undocumented defaults becomes difficult to operate because nobody can tell which values are required, which are deprecated, and which are dangerous. Validation at startup should fail fast with a clear message when required configuration is missing or malformed.
Typed configuration also helps platform teams. A deployment template can check that memory limits are numbers, URLs are valid, feature flags have owners, and production secrets are referenced from approved stores. This turns configuration mistakes into early feedback rather than incident triggers.
Secrets Lifecycle
Secrets have a lifecycle: creation, distribution, use, rotation, revocation, and audit. Long-lived shared secrets are operational debt. If ten services use the same database password, rotating it becomes a risky coordinated deployment. If each workload has a narrow identity or separate credential, rotation and compromise response become easier.
Secret scanning is necessary because mistakes happen. It should run in local hooks where possible, in CI for every change, and across repository history when a leak is suspected. A leaked secret should be revoked; deleting the line is not enough.
Example: Environment Parity
Suppose staging has PAYMENTS_ENABLED=false and production has PAYMENTS_ENABLED=true. Staging can no longer validate checkout behavior. A better design may use a sandbox payment provider in staging, with the same code path and safer credentials. Environment differences should reduce harm, not erase the behavior under test.
Study Task
Create a configuration inventory for one service. Include key name, type, default, owner, source, whether it is secret, rotation requirement, and whether changing it requires restart. This inventory often reveals hidden production dependencies.
Operational Review
Configuration should be reviewed whenever environments diverge. Some differences are necessary, such as credentials and scale. Others invalidate testing, such as disabled integrations, different database engines, or missing policy checks. The review should identify which differences reduce harm and which hide risk.
The review should include change mechanics. Who can change production configuration? Is the change versioned? Does it require restart? Is rollback obvious? Are secret rotations rehearsed? Configuration changes can cause incidents as easily as code changes, so they deserve comparable evidence.
A mature configuration system makes the current state inspectable without exposing secrets. Operators should know which version of configuration is active and where it came from.