operations
Centralized Configuration
Manage config for all services in one place (with versioning, audit, per-env overrides) — instead of redeploying every service to change a value.
When configuration is baked into each service's deployment, changing a single value — a feature flag, a downstream URL, a timeout — means rebuilding and redeploying that service, and keeping settings consistent across dozens of services and several environments becomes a sprawling, error-prone chore. Centralized configuration pulls all of that into one managed place, so config is versioned, audited, environment-aware, and changeable without a redeploy.
A building's central thermostat: you adjust the temperature in one place and every room responds, instead of walking around resetting each radiator.
Key Concepts
1
A configuration server or store (Spring Cloud Config backed by Git, HashiCorp Consul or Vault, or a cloud provider's parameter/secret store) holds the settings for every service, organised by service and environment. Services fetch their configuration at startup, and many setups support refreshing values at runtime so a change propagates without restarting anything. Backing the store with version control gives you history, diffs, and rollback — you can see who changed what and revert a bad value — and per-environment overrides let the same service pull dev, staging, or production settings from one source of truth. Secrets get special treatment: rather than sitting in plaintext config, credentials and keys live in a dedicated secrets manager (like Vault) that encrypts them, controls access, and can rotate them, keeping them out of source control entirely.
2
The benefits interviewers look for are consistency, auditability, and the ability to change behaviour — especially toggling feature flags — without a deployment, which is also what enables techniques like progressive rollouts and kill switches. The risks to acknowledge are that the config server becomes a critical dependency and potential single point of failure, so services should cache the last known-good configuration and degrade gracefully if it is unreachable, and that runtime config changes are powerful enough to cause an outage, so they deserve the same review, staging, and rollback discipline as code changes.