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 = ...)
3
What the interviewer is probing.
What the interviewer is probing.
4
1. "How does auto-configuration decide what to configure?" *Probing:* the mechanism. *Stalls:*
"Magic." *Moves up:* conditional classes registered in the imports file, evaluated against what is
on the classpath, what beans exist and what properties are set.
1. "How does auto-configuration decide what to configure?"
5
2. "How do you override an auto-configured bean?" *Probing:* the practical skill. *Stalls:*
"Edit it." *Moves up:* define your own — most are annotated @ConditionalOnMissingBean, so yours
wins.
2. "How do you override an auto-configured bean?"
6
3. "How do you find out what was configured and why?" *Probing:* the debugging. *Stalls:* "Read
the source." *Moves up:* the condition evaluation report, with --debug or the actuator conditions
endpoint, which lists matched and unmatched conditions.
3. "How do you find out what was configured and why?"
7
4. "What is a starter?" *Probing:* the vocabulary. *Stalls:* "A library." *Moves up:* a
dependency aggregator bringing a coherent set of libraries plus the auto-configuration for them — it
contains almost no code itself.
4. "What is a starter?"