Interview Prep Zoneby CuriouserLabs

Question 1 of 5 · senior level

How does Spring Boot auto-configuration actually work — from @SpringBootApplication to a configured DataSource?

🎤 Say this first

@SpringBootApplication includes @EnableAutoConfiguration, which imports candidates listed in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports inside the jars on your classpath. Each candidate is an ordinary @Configuration class gated by @Conditional annotations — on classes present, on beans missing, on properties. Your beans are registered first; auto-configs run last and back off (@ConditionalOnMissingBean) wherever you defined your own. Convention over configuration, with your code always winning.

The full picture

🎬 How auto-configuration decides

1 / 5
@SpringBootApplication@EnableAutoConfiguration…AutoConfiguration.importsfrom starter jars 📦DataSourceAutoConfiguration — condition gauntlet 🚦@ConditionalOnClass(DataSource)…@ConditionalOnMissingBean(DataSource)…create HikariDataSourcefrom spring.datasource.* propertiesAuto-config classes are ordinary @Configuration classes behind conditions — evaluated AFTER your beans register.

@SpringBootApplication = @Configuration + @ComponentScan + @EnableAutoConfiguration. The last one is where the magic starts.

Candidates → condition gauntlet → create or back off.
  • Condition vocabulary: @ConditionalOnClass (starter jar present?), @ConditionalOnMissingBean (did the user define one?), @ConditionalOnProperty (feature toggles), @ConditionalOnWebApplication, plus ordering (@AutoConfiguration(after = …)) so e.g. JPA config sees the DataSource config's output.
  • Properties bind the details: the auto-config creates the bean; spring.datasource.* / server.* etc. configure it via @ConfigurationProperties — the reason 'change a property' usually replaces 'write a bean'.
  • Debugging: run with --debug for the Condition Evaluation Report (matched/unmatched with reasons), or the actuator conditions endpoint. Knowing this exists is the difference between 'Boot is magic' and 'Boot is inspectable'.
  • Evaluation order caveat: user @Configuration parses before auto-config, which is what makes back-off deterministic. But @ConditionalOnBean between your own regular configs is unreliable — condition evaluation order among them isn't defined.

🔄 Likely follow-up questions

  • What replaced spring.factories for auto-config listing, and why? (dedicated imports file, Boot 2.7/3.0)
  • How does exclusion work (excludeName vs property) and when would you exclude?
  • How does AOT/native-image processing interact with conditions?