Managing configuration across environments means externalizing environment-specific values from the application code, so the same build artifact can run correctly in dev, staging, and production without modification.
Key Points: • Spring Boot supports profile-specific files like application-dev.yml and application-prod.yml, activated by the spring.profiles.active property. • Environment variables and Docker/Kubernetes ConfigMaps let you inject configuration at deployment time without rebuilding the image. • Spring Cloud Config centralizes configuration in a separate service, allowing dynamic updates without redeploying every instance. • Secrets (API keys, database passwords) should be kept separate from regular config, using a secret manager rather than plain files. • This separation means the exact same Docker image is promoted through environments, with only its configuration changing, which reduces "it worked in staging" surprises.
Example: The same application JAR is deployed to staging and production, but application-staging.yml points to a staging database while application-prod.yml points to the production one, selected purely by setting SPRING_PROFILES_ACTIVE at deploy time.
Code Example:
# application-prod.yml
spring:
datasource:
url: jdbc:mysql://prod-db:3306/app
username: ${DB_USER}
password: ${DB_PASSWORD}Interview Tip: A concise interview answer is:
"I externalize configuration using Spring profiles like application-dev.yml and application-prod.yml, combined with environment variables or Kubernetes ConfigMaps injected at deploy time. That way the exact same build artifact is promoted through every environment, with only its config changing."