What they're testing
Whether you separate the artifact from the environment — the basis of every trustworthy deploy pipeline.
The short answer~30 seconds
In environment variables, with ONE build that runs in all three. If you must rebuild to deploy to production, the thing you tested in staging isn't the thing you're running — and every guarantee the test round gave you evaporates. The Twelve-Factor litmus test: could you open-source the repo right now without leaking anything? If not, config is in the wrong place.
The long answer
The blurry boundary: config that varies per ENVIRONMENT (database URL, API keys) belongs in the environment, while config that expresses the PRODUCT (tax bracket tables, the order of steps in a flow) belongs in code — it needs review, history and tests. Pushing everything into environment variables creates a configuration layer nobody can read and nothing can test, and it breaks at 2am over one typo'd variable.
The practice worth adopting is validating configuration at STARTUP rather than at use: parse every environment variable through a schema as the process boots, and exit immediately with a clear message if something is missing. Otherwise a missing variable only surfaces when someone clicks the feature that uses it — possibly three days after the deploy, when nobody connects the two any more.
What they'll ask next
?What about .env files?
Fine for a dev machine, and not how production should receive configuration — that should come from the platform or a secret store. Commit .env.example to document which variables exist; never .env itself.
These lose points
if (env === 'production')scattered through business logic. The production path differs from the tested one, so you never tested what's running.