How do you manage configuration changes for your Dockerized Spring Boot application across different environments (development, testing, production)?

Question

Accepted Answer

Configuration for a Dockerized Spring Boot application is best managed through environment variables injected at container runtime, keeping environment-specific and sensitive values out of the packaged image entirely.

Key Points:
• Spring Boot automatically maps environment variables to matching relaxed-binding property names, such as SPRING_DATASOURCE_URL for spring.datasource.url.
• Environment variables can be set in docker-compose.yml, a Kubernetes ConfigMap/Secret, or passed via docker run -e.
• Sensitive values like credentials should come from a secrets manager or Docker secrets rather than being baked into the image.
• Spring profiles can still be combined with environment variables, activating a profile via SPRING_PROFILES_ACTIVE.
• This approach lets the same image be promoted unchanged from dev through staging to production.

Example:
The same Docker image is deployed with SPRING_PROFILES_ACTIVE=prod and SPRING_DATASOURCE_URL pointing at the production database in one environment, and different values in staging, without rebuilding the image at all.

Code Example:
```
services:
  app:
    image: myapp:1.0
    environment:
      SPRING_PROFILES_ACTIVE: prod
      SPRING_DATASOURCE_URL: jdbc:postgresql://prod-db:5432/app
      SPRING_DATASOURCE_PASSWORD: ${DB_PASSWORD}
```

Interview Tip:
A concise interview answer is:

"I keep configuration out of the image and inject it as environment variables at container runtime, through docker-compose or Kubernetes ConfigMaps and Secrets. Spring Boot's relaxed binding maps those variables straight onto properties, so the same image gets promoted across environments unchanged, and secrets never live in the codebase."