Your application behaves differently in development and production environments. How would you use Spring profiles to manage these differences?

Spring profiles let a single application maintain separate configuration sets for different environments, so behavior that differs between development and production, like database URLs or logging levels, can be switched without changing code.

Key Points: • Environment-specific settings live in files like application-dev.properties and application-prod.properties. • The active profile is chosen via spring.profiles.active, a command-line flag, or an environment variable. • @Profile on beans selectively loads environment-specific components, such as a mock email sender in dev and a real one in prod. • Profile-specific properties override the base application.properties for matching keys. • Multiple profiles can be active simultaneously, letting cross-cutting profiles like "logging-verbose" combine with an environment profile.

Example: application-dev.properties points spring.datasource.url at a local H2 instance and enables verbose logging, while application-prod.properties points at the production database and sets logging to WARN; deploying with -Dspring.profiles.active=prod picks the right file automatically.

Code Example:

# application-prod.properties
spring.datasource.url=jdbc:postgresql://prod-db:5432/app
logging.level.root=WARN

Interview Tip: A concise interview answer is:

"I isolate environment differences using Spring profiles, with separate application-dev and application-prod property files and @Profile-annotated beans where the implementation itself needs to differ, like a mock versus real payment gateway. Activating spring.profiles.active at deploy time switches the whole configuration set."