What is Twelve-Factor's config recommendation for CI/CD and scalability?

WHAT THIS TESTS: Whether you know Factor III of the Twelve-Factor App methodology and can connect it to two operational concerns that matter at scale: promoting a single build through multiple environments without rebuilding, and spinning up identical processes with different contexts. The question probes whether you understand that configuration choices directly affect portability, security, and elasticity.

A GOOD ANSWER COVERS: Four points in order. First, the recommendation is to store config in environment variables, not in code or in files checked into version control. Second, this separation means the codebase remains identical across development, staging, and production deploys; only the environment changes. Third, this is crucial for CI/CD because it lets you build one artifact, run tests against it, and promote that exact artifact to production rather than rebuilding or recompiling per stage. Fourth, it is crucial for scalability because new containers or processes can start with the correct database URLs, credentials, and feature flags immediately, enabling horizontal scale-out on cloud platforms without code changes.

COMMON WRONG ANSWERS: Saying config should live in property files, YAML, or JSON that is bundled with the application. Claiming that each environment should have its own branch or build. Stating that env vars are only for secrets rather than all deployment-specific configuration. Confusing configuration with code constants that never change between deploys.

LIKELY FOLLOW-UPS: How do you manage secrets versus non-secret config in env vars? What happens when the number of variables becomes unwieldy? How do you handle configuration in serverless or Kubernetes environments where env vars are still used but may be layered with config maps? Have you ever had to migrate a legacy app from file-based config to env-based config?

ONE CONCRETE EXAMPLE: A Node.js service needs to connect to PostgreSQL. In development it uses localhost port 5432; in production it uses a managed database at a different host and port. Instead of shipping a config/production.json file inside the Docker image, the image expects DATABASE_URL as an environment variable. The CI pipeline builds one image, tags it, and deploys it to staging with a staging DATABASE_URL and to production with a production DATABASE_URL. If traffic spikes, the container orchestrator starts five more instances of the exact same image, each reading DATABASE_URL from the environment at startup.