Spring Boot externalizes configuration so the same jar runs in every environment. You put settings in application.yml (or .properties), read them into your code, and switch behavior per environment with profiles.
application.yml and @Value
Spring Boot externalizes configuration so the same jar runs in every environment. You put settings in application.yml (or .properties), read them into your code, and switch behavior per environment with profiles.
@Component
public class SearchService {
// Inject a single property; :20 is the fallback if it is missing.
@Value("${app.page-size:20}")
private int pageSize;
}
For anything beyond one or two values, bind a typed object instead of scattering @Value:
@Component
@ConfigurationProperties(prefix = "app") // binds app.* into these fields
public class AppProps {
private int pageSize;
private Map<String, Boolean> featureFlags;
// getters/setters — Boot relaxed-binds page-size -> pageSize
}
This gives you type safety, IDE auto-complete, and validation (add @Validated + constraints).
spring:
config:
activate:
on-profile: prod # only when 'prod' is active
server:
port: 80
Files like application-dev.yml and application-prod.yml layer on top of the base. Activate one with --spring.profiles.active=prod or the SPRING_PROFILES_ACTIVE env var. Order of precedence matters: command-line args and environment variables override files, so secrets stay out of the jar.
The interviewer is checking you can ship one artifact across dev/staging/prod without rebuilding. Mentioning @ConfigurationProperties over scattered @Value, and env-vars overriding files for secrets, shows you have run Boot apps in production, not just locally.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate