Topic 11.5
Configuration Management
In one line
Config that changes without redeploys: externalized, versioned, and environment-aware.
Think of it like this
The settings menu on your phone, kept separate from the phone's actual software. You can change your Wi-Fi password or ringtone without reinstalling the operating system.
Key ideas
- 01
Config should be code-adjacent, not code: externalized to a config source (Spring Cloud Config, Vault, env, K8s ConfigMap).
- 02
Secrets are not config: passwords/tokens in Vault (encrypted), NEVER in git.
- 03
Feature flags merge into config: kill-switches and canary toggles without a deploy (Phase 12.26).
- 04
Configuration progression: env vars → ConfigMap → Config Server → feature-flag platform (LaunchDarkly).
- 05
Refresh without restart: /actuator/refresh, events, or Config Server watch — config changes stream to running beans.
- 06
Interview: 'config externalized, secrets in Vault, flags for progressive delivery — and a kill switch per feature'.
Java / Spring map
- →
spring-cloud-config-client + @RefreshScope; @ConfigurationProperties binding; Vault transit for secrets.
Explain without notes
Why is a secret in a config file a different failure class from a wrong feature flag? Name the blast radius of each.
Practice
Specify config categories (static, env, secrets, flags) and the refresh mechanism per category.
Trade-offs
- ↔
External config servers = one more dependency + availability requirement; env vars are cruder but free.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I separate config from secrets and give every feature a flag + kill switch.