Configuration & Profiles

Spring Boot reads configuration from many sources in a defined precedence order — command-line arguments, environment variables, application.properties or application.yml, and profile-specific files — with later sources overriding earlier ones, so an environment variable can override a baked-in default without a rebuild. You bind values into beans either with @Value("${...}") for a single property or, better for grouped settings, with @ConfigurationProperties, which maps a whole tree of properties onto a typed object and supports validation. Profiles handle environment-specific variation: activating a profile (via spring.profiles.active) loads application-{profile}.yml and enables any beans annotated @Profile("..."), so you can have a real mail sender in production and a no-op in tests, or different datasource settings per environment, all selected at startup rather than compiled in.

The themes worth raising are keeping secrets out of source control — externalising them to environment variables or a secrets manager rather than committing credentials — and preferring typed @ConfigurationProperties over scattered @Value injections because it groups related settings, validates them, and documents the configuration surface in one class. Understanding the precedence order is the practical key: it is what lets the same build behave correctly across every environment and what you reason about when a property "isn't taking effect."

1. "What is the property resolution order?" *Probing:* the practical knowledge. *Stalls:* "The file." *Moves up:* command line, then environment variables, then profile-specific files, then the base application file — later sources are overridden by earlier ones.

2. "What is a profile for?" *Probing:* the purpose. *Stalls:* "Environments." *Moves up:* activating a set of properties and beans per environment or feature, with @Profile on beans that should only exist in some.

3. "What is the risk of profile-conditional beans?" *Probing:* the honest caution. *Stalls:* "None." *Moves up:* a bean present only in production means the path is never exercised in test — which is where surprises come from.

4. "How do you bind a group of properties?" *Probing:* the mechanism. *Stalls:* "@Value." *Moves up:* @ConfigurationProperties on a typed record or class, which gives validation and IDE support rather than scattered @Value strings.