How should you manage configuration between dev, test, prod?

• A. Use environment-specific settings, feature flags, and avoid hard-coded environment values in code.
• B. Keep the same settings across dev, test, and prod to reduce complexity.
• C. Store all config in a single global variable.
• D. Require manual changes in the database for each environment.

Answer: (A)

Managing configuration across environments means keeping environment-specific settings separate from the code and controlling how features behave without changing the code itself. The best approach uses environment-specific settings so each environment (development, test, production) can have its own database URLs, endpoints, credentials, and other values without touching the codebase. This lets the same code deploy safely everywhere, simply by supplying the right configuration at deploy time.

Using feature flags adds another layer of control. They let you turn features on or off per environment, test new functionality in production without a full rollout, and gradually expose changes to users. This keeps risk low while you verify behavior in a real environment.

Avoiding hard-coded environment values in code is essential. If credentials, URLs, or environment-specific logic are baked into the source, moving between environments becomes brittle and error-prone. Externalizing configuration—through environment variables, per-environment config files, or a config service—keeps code clean and portable, and makes automated deployments reliable. This aligns with practices like the 12-factor app, where config is separate from code and supplied at runtime.

The other approaches fall short because they either force the same settings across all environments (creating mismatches and risk), rely on a single global variable (which becomes a tangled, hard-to-manage source of truth), or require manual database changes for each environment (prone to human error and slow).