What Spring Boot is, its features, advantages and key components, why teams prefer it over plain Spring, how it works internally, starters, application startup, @SpringBootApplication, Spring Initializr, beans and autowiring.
Published September 25, 2026
Spring Boot questions for freshers circle around one idea: auto-configuration. If you can explain how Boot decides what to configure (starters on the classpath → conditional auto-configuration classes → beans), most of these questions answer themselves.
Short answer: Spring Boot is an opinionated extension of the Spring Framework for building production-ready, standalone applications with minimal setup. It auto-configures beans based on what's on the classpath, bundles an embedded server, so the app runs as java -jar app.jar, and adds production features such as health checks and metrics.
Key points to cover:
jakarta.*) namespaces.Learn it in depth → What Is Spring Boot
Short answer:
@SpringBootTest and test slices.Short answer:
Key points to cover:
--debug condition report, or the /actuator/conditions endpoint) when something is configured unexpectedly.Short answer:
@Configuration classes.SpringApplication: the bootstrap class that creates the context and starts the server.application.yml, @ConfigurationProperties).Short answer: With plain Spring, you choose and align library versions, configure the DispatcherServlet, data sources, transaction managers and JSON converters yourself, and deploy a WAR file to an external server. Boot does all of that from sensible defaults, and still lets you override any part.
| Task | Plain Spring | Spring Boot |
|---|---|---|
| Web setup | Configure DispatcherServlet, message converters | Add spring-boot-starter-web |
| DataSource + JPA | Define DataSource, EntityManagerFactory, TransactionManager beans | Set spring.datasource.url; beans are auto-configured |
| Run | Build a WAR, install Tomcat, deploy | java -jar app.jar |
Learn it in depth → Auto-Configuration Mechanism
Short answer: SpringApplication.run() does the following:
ApplicationContext.META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. Each one is guarded by conditions such as:
@ConditionalOnClass: is Tomcat or Hibernate on the classpath?@ConditionalOnMissingBean: has the user already defined this bean?@ConditionalOnProperty.@AutoConfiguration
@ConditionalOnClass(DataSource.class)
class SimplifiedDataSourceAutoConfiguration {
@Bean
@ConditionalOnMissingBean // backs off if you defined your own DataSource
DataSource dataSource(DataSourceProperties props) { return props.initializeDataSourceBuilder().build(); }
}
Key points to cover:
spring.factories.Learn it in depth → Auto-Configuration Mechanism
Short answer: Starters are dependency descriptors that pull in a tested, compatible set of libraries for a feature, and trigger the matching auto-configuration. Examples:
spring-boot-starter-web: Spring MVC, embedded Tomcat, Jackson.spring-boot-starter-data-jpa: Hibernate, Spring Data JPA, HikariCP.spring-boot-starter-security.spring-boot-starter-test: JUnit 5, Mockito, AssertJ, Spring Test.spring-boot-starter-actuator.Key points to cover:
Short answer: The main method calls SpringApplication.run(App.class, args). That:
ApplicationContext (servlet, reactive or none).CommandLineRunner/ApplicationRunner beans.ApplicationReadyEvent.@SpringBootApplication
public class ShopApplication {
public static void main(String[] args) {
SpringApplication.run(ShopApplication.class, args);
}
}
@SpringBootApplication do internally?Short answer: It's a shortcut for three annotations:
@SpringBootConfiguration: a specialised @Configuration.@EnableAutoConfiguration: imports the conditional auto-configuration classes.@ComponentScan: scans the annotated class's package and its sub-packages.Common trap: putting the main class in a sub-package, such as com.shop.app, while your components live in com.shop.orders. They're outside the scan, so they're never found. Keep the main class in the root package.
Short answer: A project generator, at start.spring.io, which is also built into IntelliJ, VS Code and the Spring CLI. You pick the build tool, language, Boot version, Java version and dependencies, and it generates a ready-to-run project skeleton with the correct parent POM or plugins, the main class, and a test.
Short answer: An object created and managed by the Spring container, with its dependencies injected and its lifecycle handled by Spring. In Boot, beans come from component scanning (@Component, @Service, @Repository, @RestController), your @Bean methods, and auto-configuration (the DataSource, ObjectMapper, RestClient.Builder, …).
Learn it in depth → Bean Lifecycle in Detail
Short answer: Autowiring is Spring automatically resolving and injecting a bean's dependencies, by type first, and then by name or qualifier to resolve ambiguity. In modern code it happens implicitly through constructor injection. @Autowired is needed only on fields, setters, or when there are several constructors.
Key points to cover:
Optional<T>, ObjectProvider<T> or @Autowired(required = false).byName, byType, constructor) still exist, but annotations replaced them.Learn it in depth → Spring Dependency Injection
Q: How do you see which auto-configurations were applied, and why?
A: Start with --debug (or debug=true) to print the conditions evaluation report, or expose the /actuator/conditions endpoint. Each entry shows whether an auto-configuration matched, and which condition decided it.
Q: How do you override an auto-configured bean?
A: Define your own bean of the same type. @ConditionalOnMissingBean makes the auto-configuration back off. Or tune it with properties, for example spring.jackson.* or spring.datasource.hikari.*.
Q: What is spring-boot-maven-plugin for?
A: It repackages the application into an executable "fat" JAR (with nested dependencies and a launcher), runs the app (mvn spring-boot:run), and can build OCI container images with buildpacks (mvn spring-boot:build-image).
Q: Can Spring Boot build native executables?
A: Yes. With GraalVM Native Image and Boot's AOT processing (mvn -Pnative native:compile), you get fast startup and a low memory footprint. The cost is longer builds, and limits on dynamic reflection.