Interview Prep Zoneby CuriouserLabs

Question 1 of 5 · senior level

Explain Spring Boot's property source precedence. Why does it exist, and which layers matter in practice?

🎤 Say this first

Boot resolves each property from an ordered stack — higher wins: command-line args → OS environment variables → profile-specific files (application-prod.yml) → application.yml inside the jar → defaults. The design principle: the closer to the runtime environment, the higher the priority — so one immutable artifact runs everywhere, configured from outside (12-factor). In containerized practice, four layers do the work: packaged defaults, profile files, environment variables (K8s/App platform), and occasionally command-line overrides for debugging.

The full picture

  • Relaxed binding makes env vars work: SPRING_DATASOURCE_URL ↔ spring.datasource.url — same property, per-medium naming conventions.
  • Profile files beat the base file (application-prod.yml > application.yml), and external files beat packaged ones (./config/application.yml next to the jar) — the on-host override escape hatch.
  • Debugging precedence: don't guess — hit actuator /env (secured!): it lists every PropertySource in order and which one won for a key. Add spring.config.import and cloud sources (Config Server, K8s ConfigMaps via files) into the same mental stack.
  • Anti-pattern: baking env-specific values into the jar per environment (a build per env) — breaks the 'same artifact promoted through stages' guarantee your deploy pipeline depends on.
One artifact, many environments
# application.yml            (packaged: sane defaults, dev-friendly)
spring.datasource.url: jdbc:postgresql://localhost:5432/app

# application-prod.yml       (packaged: prod SHAPE, no secrets)
spring.datasource.hikari.maximum-pool-size: 30

# K8s deployment             (environment: values + secrets)
env:
  - name: SPRING_PROFILES_ACTIVE
    value: prod
  - name: SPRING_DATASOURCE_URL
    valueFrom: { secretKeyRef: { name: db, key: url } }   # wins over both files

🔄 Likely follow-up questions

  • Where do @TestPropertySource and @DynamicPropertySource sit in the order?
  • How does spring.config.import work for vault/configserver/k8s?
  • What changed in the config-data processing rewrite (Boot 2.4) that bit people?