Spring Boot interview questions

What a strong answer covers

• Define auto-configuration as Spring Boot's mechanism to automatically configure the application based on classpath dependencies and defined beans.
• Explain that it reduces boilerplate code and promotes 'convention over configuration'.
• Provide examples, such as configuring an embedded Tomcat server when `spring-boot-starter-web` is present.
• Mention `@EnableAutoConfiguration` (part of `@SpringBootApplication`) as the enabler.

Where people lose the point

• ×Confusing auto-configuration with component scanning; they are distinct concepts.
• ×Failing to explain *how* it works (e.g., through conditional annotations like `@ConditionalOnClass`).
• ×Not providing concrete examples of what gets auto-configured.

What a strong answer covers

• Define Dependency Injection (DI) as a design pattern where objects receive their dependencies rather than creating them.
• List benefits such as loose coupling, improved testability (easy mocking), and enhanced maintainability.
• Explain how it promotes modularity and reusability of components.
• Mention how Spring's IoC container manages the lifecycle and injection of these dependencies.

Where people lose the point

• ×Simply stating 'it's good' without explaining *why* or providing concrete benefits.
• ×Confusing DI with the Inversion of Control (IoC) container itself.
• ×Not mentioning how it aids in unit testing.

What a strong answer covers

• Identify `@RestController` as the primary annotation, explaining it combines `@Controller` and `@ResponseBody`.
• List HTTP method mapping annotations: `@GetMapping`, `@PostMapping`, `@PutMapping`, `@DeleteMapping`, `@PatchMapping`.
• Explain `@RequestMapping` for broader path mapping at class or method level.
• Mention `@PathVariable` for URI template variables and `@RequestBody` for deserializing request bodies.

Where people lose the point

• ×Forgetting `@RestController` or not explaining its composite nature.
• ×Listing only one or two HTTP method annotations.
• ×Confusing `@RequestParam` with `@PathVariable`.

What a strong answer covers

• Explain that `application.properties` or `application.yml` are the primary files for configuration.
• Describe how to define properties within these files (key-value pairs).
• Mention `@Value` annotation for injecting individual properties into beans.
• Discuss `@ConfigurationProperties` for binding related properties to a Java object.
• Briefly touch upon externalized configuration sources like environment variables and command-line arguments.

Where people lose the point

• ×Only mentioning `application.properties` and not `application.yml`.
• ×Not explaining how to *use* the properties within the code (e.g., `@Value`).
• ×Ignoring the hierarchy of property sources.

What a strong answer covers

• Define Spring Boot Starters as a set of convenient dependency descriptors that you can include in your application.
• Explain that they bundle common dependencies required for a particular feature (e.g., web, data JPA, test).
• Highlight their usefulness in simplifying build configuration and ensuring compatible versions of libraries.
• Provide examples like `spring-boot-starter-web` or `spring-boot-starter-data-jpa`.

Where people lose the point

• ×Confusing starters with individual libraries or just 'dependencies'.
• ×Not explaining the 'convenience' aspect or how they manage transitive dependencies.
• ×Failing to mention version compatibility benefits.

What a strong answer covers

• Describe `@ComponentScan` as the mechanism by which Spring discovers components (beans) in your application.
• Explain that it scans specified packages for classes annotated with `@Component`, `@Service`, `@Repository`, `@Controller`, etc.
• Mention that `@SpringBootApplication` implicitly includes `@ComponentScan` and defaults to scanning the package of the main application class and its sub-packages.
• Discuss how to customize the scan base packages if needed.

Where people lose the point

• ×Confusing component scanning with auto-configuration.
• ×Not explaining *what* it scans for (i.e., specific annotations).
• ×Failing to mention the default behavior when used with `@SpringBootApplication`.

What a strong answer covers

• Outline the key stages: instantiation, population of properties (dependency injection), initialization, and destruction.
• Explain the role of `BeanPostProcessor` interfaces for custom logic before/after initialization.
• Mention `InitializingBean` (afterPropertiesSet) and `@PostConstruct` for initialization callbacks.
• Discuss `DisposableBean` (destroy) and `@PreDestroy` for destruction callbacks.
• Explain how the IoC container manages these stages.

Where people lose the point

• ×Omitting key lifecycle stages or mixing up the order.
• ×Not mentioning the role of `BeanPostProcessor` or `BeanFactoryPostProcessor`.
• ×Forgetting about destruction callbacks or how they are triggered.

What a strong answer covers

• Explain that `@Controller` is a general-purpose annotation for Spring MVC controllers, typically used for traditional web applications returning views.
• Describe `@RestController` as a specialized version of `@Controller` that automatically includes `@ResponseBody`.
• Clarify that `@ResponseBody` serializes the return value of a method directly into the HTTP response body (e.g., JSON, XML).
• Conclude that `@RestController` is ideal for building RESTful web services, while `@Controller` is for server-side rendered UIs.

Where people lose the point

• ×Stating they are interchangeable or not understanding the role of `@ResponseBody`.
• ×Failing to mention the primary use case for each (REST vs. MVC views).
• ×Not explaining that `@RestController` is a convenience annotation.

What a strong answer covers

• Explain that traditional JPA requires writing boilerplate code for common CRUD operations and query implementations.
• Describe how Spring Data JPA provides interfaces like `JpaRepository` that automatically generate implementations for basic CRUD methods.
• Highlight the ability to define custom queries by simply declaring method names following specific conventions (e.g., `findByLastName`).
• Mention the `@Query` annotation for more complex custom JPQL or native SQL queries, still without needing to write implementation code.
• Emphasize the reduction in boilerplate, increased productivity, and improved maintainability.

Where people lose the point

• ×Not clearly articulating the 'boilerplate' problem that Spring Data JPA solves.
• ×Failing to mention the convention-based query methods.
• ×Confusing Spring Data JPA with JPA itself.

What a strong answer covers

• Define Spring Profiles as a mechanism to provide environment-specific configurations for an application.
• Explain how different beans or configuration properties can be active only when a specific profile is enabled.
• Provide a use case, such as having different database configurations for `dev`, `test`, and `prod` environments.
• Mention how to activate profiles (e.g., `spring.profiles.active` property, command-line argument, environment variable) and how to define profile-specific properties (e.g., `application-dev.properties`).

Where people lose the point

• ×Not providing a concrete, relatable use case.
• ×Confusing profiles with externalized configuration in general.
• ×Failing to explain *how* to activate or define profiles.

What a strong answer covers

• Define Spring Boot Actuator as a sub-project that adds production-ready features to Spring Boot applications.
• Explain that it provides endpoints to monitor and manage the application, such as health checks, metrics, info, and environment details.
• Discuss problems it solves: gaining insights into a running application, monitoring performance, troubleshooting issues, and managing application state without custom code.
• Mention common endpoints like `/health`, `/metrics`, `/info`.

Where people lose the point

• ×Simply listing features without explaining the 'problems solved' aspect.
• ×Not mentioning specific types of information Actuator provides (e.g., health, metrics).
• ×Confusing Actuator with general logging or monitoring tools.

What a strong answer covers

• Define transaction management as ensuring data integrity and consistency in database operations.
• Explain that Spring provides declarative transaction management, primarily through the `@Transactional` annotation.
• Describe how `@Transactional` can be applied to methods or classes, making the method's execution atomic (all or nothing).
• Discuss key attributes like `propagation` (how transactions interact), `isolation` (level of data visibility), and `rollbackFor` (exceptions that trigger rollback).
• Mention how Spring Boot auto-configures a transaction manager (e.g., `JpaTransactionManager`) based on dependencies.

Where people lose the point

• ×Not explaining the ACID properties or the core purpose of transactions.
• ×Failing to mention important `@Transactional` attributes like `propagation` or `rollbackFor`.
• ×Confusing declarative transaction management with programmatic transaction management.

What a strong answer covers

• Explain that Spring Security is the de-facto standard for security in Spring applications, easily integrated with Spring Boot starters.
• Describe basic authentication using `spring-boot-starter-security`, which provides default in-memory user details and HTTP Basic authentication.
• Discuss how to customize user details (e.g., from a database) by implementing `UserDetailsService` and configuring a `PasswordEncoder`.
• Explain authorization using method-level annotations like `@PreAuthorize` or URL-based authorization in a `WebSecurityConfigurerAdapter` (or `SecurityFilterChain` in newer versions).
• Mention configuring security rules for different endpoints (e.g., `/admin` requires `ROLE_ADMIN`).

Where people lose the point

• ×Not mentioning Spring Security as the framework.
• ×Failing to differentiate between authentication (who are you?) and authorization (what can you do?).
• ×Overlooking the need for a `PasswordEncoder` when customizing user details.

What a strong answer covers

• Define Unit Testing: testing individual components in isolation, typically without Spring context, using mock objects (e.g., Mockito).
• Define Integration Testing: testing the interaction between multiple components, often with a partial or full Spring context, using `@SpringBootTest`.
• Explain Slice Testing: testing specific layers of the application (e.g., web layer with `@WebMvcTest`, data layer with `@DataJpaTest`) with a minimal Spring context.
• Discuss the benefits of each strategy (speed, coverage, confidence) and when to use them.
• Mention common testing annotations and utilities like `TestRestTemplate`, `MockMvc`, and H2 database for in-memory testing.

Where people lose the point

• ×Confusing unit and integration tests, or not understanding the scope of each.
• ×Not mentioning slice testing or its benefits for faster integration tests.
• ×Failing to provide specific Spring Boot testing annotations or tools.

What a strong answer covers

• Define embedded servers (e.g., Tomcat, Jetty, Undertow) as web servers that are packaged directly within the Spring Boot application's JAR file.
• Explain that this eliminates the need for a separate application server installation and deployment (e.g., WAR files to external Tomcat).
• List advantages: simplified deployment (just run the JAR), self-contained applications, easier development and testing, and consistent runtime environments.
• Mention how Spring Boot auto-configures the embedded server based on the `spring-boot-starter-web` dependency.
• Discuss how to switch between different embedded servers or configure them.

Where people lose the point

• ×Not clearly explaining *what* an embedded server is or how it differs from traditional deployment.
• ×Failing to list the key advantages, especially simplified deployment.
• ×Not mentioning the common embedded server options.

What a strong answer covers

• Explain the purpose of a custom starter: to provide a reusable, opinionated set of dependencies and auto-configurations for a specific library or feature.
• Outline the two main components: the 'starter' module (e.g., `my-library-spring-boot-starter`) and the 'auto-configure' module (e.g., `my-library-spring-boot-autoconfigure`).
• Describe the auto-configure module's role in defining `@Configuration` classes with conditional logic (`@ConditionalOnClass`, `@ConditionalOnMissingBean`) to provide default beans.
• Explain the `spring.factories` file in `META-INF` to register the auto-configuration classes.
• Detail the starter module's role in simply providing the necessary transitive dependencies, including the auto-configure module.

Where people lose the point

• ×Confusing the starter module with the auto-configure module.
• ×Forgetting the `spring.factories` file or its purpose.
• ×Not explaining the role of conditional annotations in the auto-configure module.