securityAnswer last reviewed July 2026

Walk me through how you handle secrets in a Node service. Where do they live, how do they get rotated, and what do you do when one leaks?

Strong answers treat secrets as a whole lifecycle, injection, rotation, revocation, blast radius, and go well past 'put them in .env and gitignore it'.

What an AI-prepared candidate might say

So the rule is you never hardcode secrets or commit them, database passwords, API keys, any of that. The standard thing is environment variables, so in development you'd have a .env file that's listed in .gitignore so it never gets committed. Then in production you inject them through the environment, or you use a secrets manager, like Vault or whatever secret store your cloud provider has. You rotate secrets periodically, and immediately if one gets exposed. Access should be least privilege, so only the services that actually need a secret can read it. You also want to make sure you're not logging secrets by accident, since logs can leak them. If one is compromised you rotate it and revoke the old one. A proper secrets manager gives you centralized control, auditing, and rotation support instead of credentials scattered across config files.

Senior
Locked

Where secrets actually enter the process, why .env belongs in local development and nowhere near production, and what rotation demands from the app itself.

Unlock the depth
Staff
Locked

The leak runbook, revoke first, then rotate, then audit the blast radius, plus how you design so a rotation never forces the whole fleet to restart at once.

Unlock the depth
Follow-up chain
Walk me through how you handle secrets in a Node service. Where do they live, how do they get rotated, and what do you do when one leaks? | NodeBook