Secrets Management — Never Hardcode Credentials
Fast recall
Quick revision
Core answer
.gitignore as a forward-only safeguard — it doesn't remove already-committed history.Whether the candidate understands the lifecycle risk of hardcoded secrets and knows production-grade secrets management patterns.
Moving secrets to application.properties files and still committing them to git, or using .gitignore without understanding it doesn't remove already-committed history.
Discuss secret rotation, least-privilege IAM roles for cloud secrets access, scanning git history for leaked secrets with tools like truffleHog, and the 12-factor app principle of environment-based config.
Interview-ready guide
Interview answer
Why `application.properties` is risky
- Almost always committed to version control
- Even
application-local.propertiesin.gitignoreis accidentally committed regularly - Once committed, the secret is in git history — permanently
- Deleting the file does not remove from history
Safe approaches
Environment variables
SPRING_DATASOURCE_PASSWORD=secret- Injected by Docker, K8s secrets, or CI platform
- Never in source code
Kubernetes Secrets
- Mounted as env vars or files
- Encrypted at rest with KMS
- Not committed to app repo
HashiCorp Vault + Spring Cloud Vault
- Secrets fetched from Vault at startup
@Valueand@ConfigurationPropertieswork transparently- Secrets rotate without code changes
- Dynamic short-lived DB credentials
AWS Secrets Manager / GCP Secret Manager
- Cloud-native
- IAM controls which service identities can read which secrets
- Lambda-based automatic rotation
In application code
@Value("${db.password}")reads from environment — safe if value comes from env var or Vault- Log sanitization: ensure logging frameworks don't capture
application.propertiesvalues
Audit and detection
git log --all -S 'password'on any repo before open-sourcing- truffleHog / Gitleaks in CI
- GitHub secret scanning (free for public repos)
Incident response
- Rotate at source first
- Clean git history (
git filter-repo, BFG) - Audit secret-source access logs
- Force-push cleaned history; reclone everywhere
Secrets Management — Never Hardcode Credentials
Direct Answer
Hardcoding credentials exposes them in version control history, build artifacts, and logs — even after removal, they live in git history forever. Spring Boot apps should read secrets from environment variables, Spring Cloud Config Server, or a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Kubernetes Secrets). The principle: secrets never appear in source control at any point. Use IAM roles instead of API keys where possible, rotate on suspected compromise, scan git history with truffleHog/Gitleaks, and treat .gitignore as a forward-only safeguard — it doesn't remove already-committed history.
Common Mistakes & Pitfalls
Moving secrets to application.properties files and still committing them to git, or using .gitignore without understanding it doesn't remove already-committed history.
Check your understanding
Answer these without looking back at the article.
- How would you handle secret rotation without restarting a Spring Boot application?
- What is the difference between using environment variables versus a secrets manager like AWS Secrets Manager?
- How would you secure secrets in a local development environment while keeping the setup simple for the team?
- What is the response plan when you discover a credential has been committed to a public repo?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.