How do you handle configuration management across microservices?
Learn how to manage microservices configuration with centralized config servers, secrets managers, environment layering and dynamic refresh, with examples.
Expected Interview Answer
You externalize configuration out of each service and serve it from a centralized, versioned source (a config server, key-value store, or platform-native ConfigMaps and Secrets) so every service reads its settings at startup or on refresh rather than hardcoding them.
Configuration is layered by environment (dev, staging, prod) and by scope (global defaults plus per-service overrides), kept in version control for auditability, and injected at runtime through environment variables, mounted files, or a client that pulls from a server like Spring Cloud Config, Consul, etcd, or AWS AppConfig. Sensitive values are stored separately in a secrets manager (Vault, AWS Secrets Manager) with encryption and access control, and dynamic refresh lets services pick up changes without a redeploy.
- One source of truth instead of scattered config files
- Environment promotion without code changes
- Auditable, version-controlled history of changes
- Secrets kept out of source code and images
- Dynamic refresh avoids full redeploys
- Consistent behavior across many service instances
AI Mentor Explanation
Think of a national cricket board that keeps one central rulebook, pitch guidelines, and playing conditions rather than letting every ground print its own. Each match venue pulls the current conditions before play, so a rule tweak reaches every stadium at once instead of some grounds using stale, contradictory versions that cause disputes mid-game.
Step-by-Step Explanation
Step 1
Externalize config
Remove hardcoded values from code and images; read them from environment variables, mounted files, or a config client.
Step 2
Centralize the source
Store configuration in a versioned server or key-value store (Spring Cloud Config, Consul, etcd, AppConfig) as the single source of truth.
Step 3
Layer by environment and scope
Define global defaults plus per-service and per-environment overrides so promotion between dev, staging, and prod needs no code change.
Step 4
Separate secrets
Keep credentials and keys in a secrets manager like Vault or AWS Secrets Manager with encryption and least-privilege access.
Step 5
Enable dynamic refresh
Let services subscribe to changes or expose a refresh endpoint so updates apply without a full redeploy.
Step 6
Audit and version
Track every change in version control and require review, so config changes are traceable and reversible.
What Interviewer Expects
- Understanding of externalized, centralized configuration
- Awareness of secrets management versus plain config
- Environment layering and override strategy
- Knowledge of concrete tools (Consul, Vault, ConfigMaps, AppConfig)
- Dynamic refresh versus redeploy trade-offs
- Auditing and version control of config
Common Mistakes
- Hardcoding config or secrets inside code or Docker images
- Storing passwords in plain ConfigMaps instead of a secrets manager
- Duplicating the same values in every service with no single source
- Ignoring per-environment overrides and rebuilding images per stage
- No audit trail or versioning for config changes
Best Answer (HR Friendly)
“Instead of each small service keeping its own settings buried in code, we keep all settings in one central, controlled place and let every service read from it. That way we change something once and it safely applies everywhere, with passwords kept in a locked, separate vault.”
Code Example
apiVersion: v1
kind: ConfigMap
metadata:
name: orders-config
data:
LOG_LEVEL: "info"
PAYMENT_TIMEOUT_MS: "3000"
---
apiVersion: v1
kind: Secret
metadata:
name: orders-secrets
type: Opaque
stringData:
DB_PASSWORD: "from-secrets-manager"
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
template:
spec:
containers:
- name: orders
image: registry/orders:1.4.2
envFrom:
- configMapRef:
name: orders-config
- secretRef:
name: orders-secretsFollow-up Questions
- How do you rotate secrets without downtime across services?
- What is the difference between a ConfigMap and a Secret in Kubernetes?
- How does Spring Cloud Config push refreshed values to clients?
- How do you prevent a bad config change from taking down all services?
- How do you handle configuration for hundreds of service instances?
MCQ Practice
1. Where should database passwords for microservices be stored?
Credentials belong in a dedicated secrets manager with encryption and access control, not in code, images, or plain config.
2. What is the main benefit of a centralized config server?
A centralized, versioned config server gives every service one authoritative, auditable source instead of scattered files.
3. Dynamic configuration refresh lets you do what?
Refresh mechanisms let services pick up updated values without rebuilding or redeploying the whole service.
Flash Cards
What does externalizing config mean? — Keeping settings outside code and images, injected at runtime via env vars, files, or a config client.
Config vs secrets? — Non-sensitive settings go in config stores; credentials and keys go in an encrypted secrets manager.
Why version control config? — It provides an auditable, reversible history of every change across environments.
What enables config change without redeploy? — Dynamic refresh: services subscribe to changes or expose a refresh endpoint.