What is Twelve-Factor's config recommendation for CI/CD and scalability?
Tests Factor III and CI/CD scaling implications. Strong answer: config lives in env vars, never in code, so one build promotes across stages and new instances start with correct context immediately. Red flag: config files checked into version control.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
A team following Twelve-Factor Factor III stores configuration in environment variables. What operational benefit does this provide for CI/CD and scalability?
- a.One build artifact can be promoted across environments and new instances start with the correct context immediately.Correct
- b.The application can bundle all settings inside the deployed artifact to remain self-contained.
- c.Each environment can use its own Git branch to manage configuration independently.
- d.Only secrets are kept outside source code while non-secret settings remain hard-coded.
Why? this is the answer
Storing config in environment variables keeps the codebase identical across stages, enabling a single artifact to be promoted through CI/CD and allowing new instances to read the correct settings at startup for horizontal scaling. The distractor about keeping only secrets in env vars is wrong because Factor III applies to all deployment-specific configuration, not just sensitive data.
Just read this? Test yourself on what you have been reading.
Read the original → 12factor.net
- #twelve-factor
- #configuration
- #cicd
- #scalability
- #environment-variables
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles