You open a new Spring project and somehow it already has a web server, JSON support, logging, and a sensible app structure without you wiring every bean by hand. That is the Spring Boot trick: it starts from opinionated defaults, then lets you override the parts you actually care about.
If you are coming from Scala, think of Spring Boot as the difference between writing every module wiring manually and starting from a well-stocked application template. You still control the pieces, but the framework does the boring setup work first.
The Problem / Context
Plain Spring is powerful, but it can feel like a lot of ceremony for a small service. You often need to decide which dependencies to include, how to wire the application, how to configure embedded servers, and where to keep environment-specific settings.
Spring Boot solves that by:
- guessing sensible defaults from the classpath,
- wiring common infrastructure automatically,
- giving you a single entry point for startup,
- and letting you override defaults only when needed.
Key Concepts
| Concept | What it does | Why it matters |
|---|---|---|
@SpringBootApplication |
Combines several core Spring Boot annotations | Gives you a clean application entry point |
| Auto-configuration | Creates beans based on what is on the classpath | Removes repetitive setup code |
| Starter dependencies | Curated dependency bundles like web, test, JPA | Avoids version and dependency sprawl |
application.properties / application.yml |
Externalised configuration | Keeps settings out of code |
@ConfigurationProperties |
Binds configuration to typed objects | Safer than scattering @Value everywhere |
| Auto-configuration overrides | Exclude or replace Boot defaults | Lets you customize when defaults are not enough |
The Solution / Implementation
At the center of every Boot app is the main class:
@SpringBootApplication
public class SpringBootBasicsApplication {
public static void main(String[] args) {
SpringApplication.run(SpringBootBasicsApplication.class, args);
}
}
@SpringBootApplication is a convenience annotation. It combines:
@Configuration@ComponentScan@EnableAutoConfiguration
That last one is the important part. It tells Spring Boot to inspect the classpath and create common beans automatically. If Spring MVC is present, Boot configures web infrastructure. If Jackson is present, Boot configures JSON support. If you add a data module, Boot starts looking for repository support.
Here is the basic idea in code:
@RestController
@RequestMapping("/api/hello")
public class HelloController {
@GetMapping
public Map<String, String> hello() {
return Map.of("message", "Hello from Spring Boot");
}
}
You do not configure the dispatcher servlet, JSON mapper, or embedded server manually. Boot does that for you as long as the right starter dependency is present.
A Small Real Configuration Example
The same Boot idea shows up in a tiny application: one @SpringBootApplication class, one controller, and one typed configuration object.
@SpringBootApplication
public class SpringBootBasicsApplication {
public static void main(String[] args) {
SpringApplication.run(SpringBootBasicsApplication.class, args);
}
}
@RestController
@RequestMapping("/api/greeting")
public class GreetingController {
private final AppProperties properties;
public GreetingController(AppProperties properties) {
this.properties = properties;
}
@GetMapping
public Map<String, String> greeting() {
return Map.of("message", properties.greeting());
}
}
@ConfigurationProperties(prefix = "app")
public record AppProperties(String greeting) {
}
Auto-Configuration in Practice
Auto-configuration is not magic. It is a set of conditional configuration classes that activate when certain classes, beans, or properties are present.
@Configuration(proxyBeanMethods = false)
public class CustomGreetingConfig {
@Bean
public GreetingService greetingService() {
return new GreetingService("Spring Boot developer");
}
}
Boot will keep out of the way when you define your own bean. That is the usual rule: Boot provides a default only when you do not already have one.
If you want to change a default, you typically do one of three things:
- define your own bean,
- set a property in
application.propertiesorapplication.yml, - or exclude an auto-configuration class.
Example:
@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)
public class ApplicationWithoutDatabaseAutoConfig {
}
That is useful when a starter brings in a feature you do not want yet.
Another common pattern is overriding a Boot-managed bean with your own implementation:
@Configuration
public class JsonMessageConfig {
@Bean
public ObjectMapper objectMapper() {
return JsonMapper.builder()
.findAndAddModules()
.build();
}
}
When Spring Boot sees this bean, it uses it instead of creating its own default mapper.
Externalised Configuration
Spring Boot makes configuration a first-class feature. Instead of hard-coding values, keep them in property files:
server.port=8081
app.greeting=Hello, Scala developer
spring.profiles.active=dev
Then bind them into a type-safe object:
@ConfigurationProperties(prefix = "app")
public record AppProperties(String greeting) {
}
This is usually better than scattering @Value across a codebase. It groups related settings together and gives you a clearer shape to validate and test.
Interview Q&A
What is Spring Boot?
What does auto-configuration do?
What does @SpringBootApplication include?
Conclusion
Spring Boot does not replace Spring; it makes Spring easier to start and easier to operate. If you remember one thing, remember this: Boot gives you defaults, but you still control the final wiring when the defaults are not right.
Code Samples
All examples in this post are runnable in the repository:
This is part of our Spring Framework Interview Preparation Guide - Master the Framework.