Configuration is one of those things that just quietly exists in every system. Connection strings, feature flags, environment settings — most of the time you define them, set them, and move on. The problems don’t usually appear when configuration is created. They appear later. When something changes in one environment but not another. When a value is tweaked directly in a portal to fix an issue. When nobody is quite sure when or why something was changed. I’ve seen teams lose days chasing “bugs” that turned out to be nothing more than configuration drift. Over time, I’ve realised that configuration itself isn’t the problem. It’s how configuration is managed that causes the real issues.
Configuration Rarely Breaks on Day One
Most configuration starts out clean. Someone defines a set of values, commits them, and the product behaves exactly as expected. The first environment runs fine. The second environment runs fine. Then the first urgent change happens — and that’s when drift begins.
This is the part nobody plans for:
- A value is hot-fixed in a portal to unblock a release.
- A test environment gets a tweak so a demo will work.
- Production is adjusted during an incident, then nobody records it.
You don’t notice the impact straight away. It only becomes visible when a system behaves differently in different environments and nobody can explain why.
Where the Line Is Drawn
The nuance is important. Developers and platforms both own parts of configuration, but they own different parts.
Developers own:
- What configuration exists
- Defaults
- Behaviour
- Validation
Platform owns:
- Storage
- Promotion between environments
- Versioning
- Audit and rollback
- Preventing click-ops
Configuration belongs to the application.
Configuration management belongs to the platform.
That distinction is the whole point of this post. You can design good configuration, but if the platform cannot manage it safely, it will eventually become a source of risk — no matter how well the application is written.
Why Configuration Management Becomes an Infrastructure Concern
Configuration is not just data. It changes runtime behaviour. It evolves independently of deployments. It often lives outside the application lifecycle and is frequently modified under time pressure.
That combination makes it an infrastructure concern:
- It affects stability in the same way as infrastructure changes do.
- It must be promoted and tracked across environments in the same way releases are.
- It needs rollback and audit in the same way infrastructure does.
Once you accept that, the answer stops being better documentation and starts being systems that make drift hard by design.
A Simple Example: Configuration Drift in the Real World
Here’s a scenario I’ve seen more than once.
A product has a configuration value that enables certain API capabilities. It is not a feature flag, just a product-specific setting that changes which endpoints or behaviours are available.
In development, it is enabled so the team can build and test. In test and product, it’s disabled still. The UI is published to test and sent to the customers to start their UAT.
The UI team starts getting bug reports that the application isn’t working as expected. They investigate, check code, check the releases and everything looks fine. The UI and API are both up to date, but the behaviour is different in production.
Eventually someone realises the API config is different in each environment. There was no easy way to check, no visibility of history, and no audit trail to understand why it diverged. The UI team spent days investigating a problem that was not in their code at all.
The problem was not the configuration value. The problem was unmanaged promotion and invisible change.
Treating Configuration Management as Infrastructure
This is where the tooling comes in, but the mindset comes first. Treat configuration management as infrastructure.
At a high level, that means:
- Centralised configuration store
- Clear environment labelling
- Versioned configuration in Git
- Pipeline-driven promotion
- No manual portal edits
If you want the concrete implementation, I’ve already written it up in more detail in Azure Config as Code. The reusable template and example repo are here: https://github.com/MThomas564/azure-config-as-code 🔗.
I’m not rehashing it here — this post is about the why, not the implementation.
What Changes When You Do This
When configuration is managed like infrastructure, the impact is immediate:
- Fewer “works in dev” incidents
- PR-reviewed changes instead of portal tweaks
- Clear ownership and accountability
- Audit trails for every change
- Safer rollout of features and behaviour changes
It also makes debugging faster. You can see what changed, where, and when — and the guesswork disappears.
When This Is Overkill
Not every project needs full configuration management discipline from day one. It can be overkill for:
- A small internal tool
- A short-lived proof of concept
- A single-environment system
- Truly static configuration that never changes
But if you have multiple environments, or if configuration changes under pressure, you will eventually need this.
Closing Thoughts
Boring systems are good systems, and configuration should be one of the most boring parts of your platform. If your configuration surprises you, it will eventually surprise your users. When the stakes are uptime and trust, predictability beats flexibility.
The goal isn’t control. It’s predictability, traceability, and confidence that you know what’s running where. When you achieve that, teams spend less time chasing ghosts and more time building features that matter.