core
Auto-configuration & Starters
Get sensible defaults wired up automatically based on what's on the classpath — without writing XML or manual @Bean definitions.
Auto-configuration is what makes Spring Boot feel like magic: add a dependency, and the relevant beans appear pre-wired with sensible defaults, no XML and no hand-written @Bean methods. The aim is to eliminate the boilerplate that plagued classic Spring, where wiring a datasource, transaction manager, and JPA layer meant pages of configuration, by inferring a reasonable setup from what is on the classpath.
IKEA furniture with default assembly — pieces snap together unless you choose to customize. Define your own @Bean and Boot steps aside.
Key Concepts
1
The mechanism is conditional configuration. @SpringBootApplication enables @EnableAutoConfiguration, which loads a long list of auto-configuration classes registered by starters. Each class is guarded by @Conditional annotations — @ConditionalOnClass (a type is present), @ConditionalOnMissingBean (you haven't already defined one yourself), @ConditionalOnProperty, and others. So when spring-boot-starter-data-jpa and an H2 driver are on the classpath, the JPA and datasource auto-configurations fire and create those beans — but the @ConditionalOnMissingBean guards mean that the instant you declare your own datasource, Spring backs off and uses yours. Starters themselves are curated dependency bundles: spring-boot-starter-web pulls in Spring MVC, Jackson, and an embedded Tomcat with compatible versions, so you depend on one artifact instead of assembling a dozen.
@SpringBootApplication@EnableAutoConfiguration@Conditional@ConditionalOnClass@ConditionalOnMissingBean
2
The themes interviewers look for are that auto-configuration is opt-out, not opt-in — your explicit beans and properties always win — and how to see and control it. The --debug flag prints a condition evaluation report showing which auto-configurations matched and which were skipped and why, and you can exclude specific ones via @SpringBootApplication(exclude = ...). The deeper point is that "magic" here is just ordinary beans created under well-defined conditions, fully overridable.
--debug@SpringBootApplication(exclude = ...)