Lesson 14 of 30

Environment Variables & Config Management

Q: How would you manage an API key that needs different values across development, staging, and production, without hardcoding or leaking it?

A strong answer covers: Environment variables supplied per-environment (.env files, hosting platform config), not hardcoded in source; Client-side frameworks require an explicit public prefix (NEXT_PUBLIC_/VITE_) for anything baked into the client bundle — real secrets must never use it; .env files with real values are gitignored; .env.example documents required variables without real values.

The same code needs a different API URL in development, staging, and production — environment variables are how that value moves from 'hardcoded and wrong somewhere' to 'injected at build or run time.'

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A secret database password is stored in an env var named `NEXT_PUBLIC_DB_PASSWORD`. Is this safe?

No — the NEXT_PUBLIC_ prefix bakes the value into the client bundle, visible to anyoneYes, because .env files are never included in the deployed buildYes, as long as the value is base64-encoded first

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Environment Variables & Config Management

What interviewers actually ask about this, and what a strong answer has to cover.

How would you manage an API key that needs different values across development, staging, and production, without hardcoding or leaking it?

A strong answer covers

Environment variables supplied per-environment (.env files, hosting platform config), not hardcoded in source
Client-side frameworks require an explicit public prefix (NEXT_PUBLIC_/VITE_) for anything baked into the client bundle — real secrets must never use it
.env files with real values are gitignored; .env.example documents required variables without real values

Likely follow-ups

What's the practical difference between a build-time and a runtime environment variable in a framework like Next.js?
Why does changing a server-only env var typically require a restart, while a client-side one requires a full rebuild?
How would you rotate a leaked secret that was accidentally committed?

Practice these with the AI interviewer →

The plain-language idea

An environment variable is a value supplied outside your source code — by the shell, a .env file, or your hosting platform — so the same code can behave differently per environment without an if (isProd) scattered everywhere:

# .env.production
API_URL=https://api.example.com

# .env.development
API_URL=http://localhost:4000

fetch(`${process.env.API_URL}/users`);

Environment config: same code, different values per environmentStep 1 of 3

const apiKey = 'sk-live-abc123' hardcoded in source — now it's in git history forever, identical across every environment.

What people usually miss

Watch out

A NEXT_PUBLIC_/VITE_-prefixed variable is visible to anyone who opens dev tools. It's compiled directly into the shipped JavaScript — never put a real secret (an API key with write access, a database password) behind this prefix; it's genuinely public the moment it's in the bundle.
.env files should never be committed to git — .env.example (with placeholder values, no real secrets) is the standard way to document what variables are needed without leaking the actual values; the real .env belongs in .gitignore.
Changing an unprefixed (server-only) env var typically requires a server restart to take effect — unlike the client-side prefixed ones, which are baked in at build time and require a full rebuild instead.

Why this matters in interviews

"How would you handle an API key that different environments need different values for, without hardcoding it or leaking it?" is a practical, common question — knowing the build-time-vs-runtime distinction and the public/private prefix boundary is what separates "I know env vars exist" from actually having shipped with them safely.