Interview Questions
Spring Boot Interview Questions and Answers
Spring Boot interview questions tend to focus less on syntax and more on understanding what the framework is doing for you automatically. These cover the questions that come up most, with working examples.
Example: A minimal Spring Boot REST controller
Java@RestController
@RequestMapping("/api/books")
public class BookController {
private final BookRepository bookRepository;
public BookController(BookRepository bookRepository) {
this.bookRepository = bookRepository;
}
@GetMapping("/{id}")
public ResponseEntity<Book> getBook(@PathVariable Long id) {
return bookRepository.findById(id)
.map(ResponseEntity::ok)
.orElse(ResponseEntity.notFound().build());
}
@PostMapping
public ResponseEntity<Book> createBook(@RequestBody Book book) {
Book saved = bookRepository.save(book);
return ResponseEntity.status(HttpStatus.CREATED).body(saved);
}
}Frequently Asked Questions
It's a convenience annotation that combines three separate ones: @Configuration (marks the class as a source of bean definitions), @EnableAutoConfiguration (turns on Spring Boot's auto-configuration based on your classpath), and @ComponentScan (scans the current package and sub-packages for components). You could apply all three individually -- @SpringBootApplication just saves the boilerplate.
Auto-configuration inspects what's on your classpath and configures beans accordingly -- if it sees spring-boot-starter-web plus Tomcat on the classpath, it configures an embedded Tomcat server; if it sees a JDBC driver plus spring-boot-starter-data-jpa, it configures a DataSource and EntityManagerFactory. Each auto-configuration class is annotated with conditions like @ConditionalOnClass or @ConditionalOnMissingBean, so it only activates when appropriate, and backs off if you've defined your own bean of that type.
Functionally, all four register a class as a Spring-managed bean -- @Service, @Repository, and @Controller are specializations of @Component with added meaning. @Repository additionally enables automatic translation of persistence-layer exceptions into Spring's DataAccessException hierarchy. @Controller marks a class as a Spring MVC controller (returning views); @RestController combines @Controller with @ResponseBody so every method's return value is serialized directly to the response body.
Profiles let you have different configuration for different environments -- application-dev.properties vs application-prod.properties, for example. You activate one via spring.profiles.active, and beans can be scoped to a profile with @Profile("dev"). It's how the same codebase can point at a local database in development and a production database in production without code changes.
Actuator adds production-ready monitoring endpoints to your app -- /actuator/health for health checks, /actuator/metrics for application metrics, /actuator/env for environment properties, and more. It's what load balancers and monitoring tools typically poll to know if an instance is healthy. Most endpoints beyond /health are disabled by default and need explicit exposure via management.endpoints.web.exposure.include.
@PathVariable extracts a value from the URL path itself (e.g. the {id} in /books/{id}). @RequestParam extracts a value from the query string (e.g. ?status=active) or form data. Use @PathVariable when the value identifies the resource; use @RequestParam for optional filters, pagination, or search parameters.
Spring manages a container of beans and wires their dependencies together automatically. Constructor injection (shown in the example above) is the recommended approach -- Spring sees the constructor's parameters and supplies matching beans from the container. Field injection with @Autowired on a field works too, but constructor injection makes dependencies explicit and lets you mark fields final, which is generally considered better practice.
Spring Boot ships an embedded servlet container (Tomcat by default, or Jetty/Undertow as alternatives) directly inside the executable JAR -- you run it with java -jar, no separate server install needed. This differs from the older model of deploying a WAR file to an externally-installed Tomcat instance, which requires managing that server's install and lifecycle separately from your application.