Spring Boot Interview Questions and Answers (2026)

Spring provides the container, dependency injection and the web, data and security modules. Spring Boot removes the setup: starter dependencies that pull in compatible versions, auto-configuration that wires sensible defaults, an embedded server so the app runs as a plain JAR, and production features through Actuator. You write less configuration, but it's the same Spring underneath.

It combines three annotations: @SpringBootConfiguration (marks the class as a configuration source), @EnableAutoConfiguration (turns on auto-configuration), and @ComponentScan (scans the annotated class's package and everything below it). That last part is why a component placed in a package outside the main class's tree isn't found.

Boot loads a list of auto-configuration classes from META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports in the JARs on the classpath. Each one is guarded by conditions such as @ConditionalOnClass, @ConditionalOnMissingBean and @ConditionalOnProperty. So a DataSource is configured only if a JDBC driver is present and you haven't defined your own. Define the bean yourself and the default backs off. Run with --debug to see the conditions report.

A dependency with no code of its own that pulls in a curated, version-compatible set of libraries for one purpose. spring-boot-starter-web brings Spring MVC, Jackson and embedded Tomcat; spring-boot-starter-data-jpa brings Spring Data, Hibernate and a connection pool. Versions are managed by the Boot parent or BOM, so you rarely specify them.

Constructor injection. Dependencies can be final, the object is never half-built, tests can construct it with plain new, and a constructor with eight parameters makes it obvious the class does too much. Field injection with @Autowired hides dependencies and needs reflection or a Spring context to test. A class with a single constructor doesn't need @Autowired at all.

All four register a bean through component scanning. @Service is purely a label for business logic. @Repository also enables translation of persistence exceptions into Spring's DataAccessException hierarchy. @Controller marks a web handler, and @RestController adds @ResponseBody so return values are written as the response body.

Singleton is the default: one instance per application context. Prototype creates a new instance on every injection or lookup. Web applications add request, session and application scopes. Because singletons are shared across threads, they must not hold per-request state in fields.

It doesn't; startup fails with NoUniqueBeanDefinitionException unless you tell it. Mark one @Primary as the default, use @Qualifier("name") at the injection point, or inject a List or Map of the interface to get all of them.

@Component goes on a class you own and is discovered by scanning. @Bean goes on a method inside a @Configuration class and returns the object to register — use it for third-party classes you can't annotate, or when construction needs logic.

From several sources in a defined precedence. Roughly, from lowest to highest: application.properties or application.yml inside the JAR, profile-specific files such as application-prod.yml, the same files outside the JAR, OS environment variables, Java system properties, then command-line arguments. That's why an environment variable like SERVER_PORT overrides server.port in the packaged file without a rebuild.

@Value("${app.timeout}") injects one property and is fine for a one-off. @ConfigurationProperties(prefix = "app") binds a whole group to a typed class or record, supports nested objects and lists, relaxed name binding, and validation with @Validated. Prefer it for anything beyond a couple of values.

Named sets of configuration and beans that are active only in certain environments. Activate them with spring.profiles.active, put overrides in application-{profile}.yml, and restrict beans with @Profile("dev"). Keep secrets out of profile files — supply them through environment variables or a secrets manager.

The DispatcherServlet receives it, asks the handler mappings which controller method matches, resolves the method's arguments (@PathVariable, @RequestParam, @RequestBody via an HttpMessageConverter such as Jackson), invokes it, and converts the return value back to JSON. Servlet filters run before the DispatcherServlet; handler interceptors run around the controller call.

A class annotated with @RestControllerAdvice containing @ExceptionHandler methods that map each exception type to a status code and a consistent error body. Spring 6 and Boot 3 support the RFC 9457 problem-details format through ProblemDetail. This keeps try/catch out of controllers.

Put Bean Validation annotations (@NotBlank, @Size, @Email) on the DTO and @Valid on the controller parameter. Failures throw MethodArgumentNotValidException, which you turn into a 400 in the controller advice. This needs spring-boot-starter-validation on the classpath — without it the annotations are silently ignored.

RestTemplate is the older blocking client, now in maintenance mode. WebClient is the reactive, non-blocking client from WebFlux. RestClient, added in Spring Framework 6.1 and Boot 3.2, gives a fluent API like WebClient but blocking — the usual choice in a servlet application today. Whichever you use, set connect and read timeouts; the defaults can wait forever.

You declare an interface extending JpaRepository, and Spring generates a proxy at startup. Method names like findByEmailAndStatus are parsed into queries; @Query covers anything the naming convention can't express. Under the proxy it's still the JPA EntityManager and Hibernate.

Spring wraps the bean in a proxy that opens a transaction before the method and commits or rolls back after. The usual failures all follow from that: a method calling another @Transactional method on the same class bypasses the proxy; private methods can't be proxied; and by default only unchecked exceptions trigger rollback, so a checked exception commits unless you set rollbackFor. Catching and swallowing the exception also prevents rollback.

You load N parent entities in one query, then touching a lazy association on each fires another query — N+1 in total. Fix it by fetching what you need up front: a JOIN FETCH in JPQL, an @EntityGraph on the repository method, or batch fetching with hibernate.default_batch_fetch_size. Turn on SQL logging in development so you see it before production does.

Accessing a lazy association after the persistence context that loaded the entity has closed — typically when serialising an entity to JSON in the controller. Fix it by fetching the association inside the transaction, or better, map to a DTO in the service layer. Leaving spring.jpa.open-in-view enabled hides the problem by keeping the session open during rendering, at the cost of holding a database connection for the whole request.

By declaring a SecurityFilterChain bean and configuring HttpSecurity with the lambda DSL: which requests are permitted or authenticated, how users authenticate, and session and CSRF settings. WebSecurityConfigurerAdapter was removed in Spring Security 6. With no configuration at all, adding the security starter locks every endpoint behind a generated password.

Configure the application as an OAuth2 resource server: each request carries a bearer token, a filter validates its signature and expiry, and the claims become the Authentication. Set session creation to stateless. Disabling CSRF protection is acceptable there because the browser doesn't attach the token automatically, as it would a session cookie. Enforce authorisation with request matchers or @PreAuthorize.

@SpringBootTest loads the full application context — realistic but slow, for integration tests. @WebMvcTest loads only the web layer for the named controller and is used with MockMvc and mocked services. @DataJpaTest loads only JPA components and rolls each test back. Use slices for speed, a few full-context tests for wiring, and Testcontainers when you need the real database rather than H2.

A starter that exposes operational endpoints: /actuator/health (with liveness and readiness groups for Kubernetes probes), metrics, info, env, loggers and more. Only health is exposed over HTTP by default — you opt in to the rest with management.endpoints.web.exposure.include, and you should secure anything beyond health.

The build plugin produces an executable JAR with the dependencies and an embedded server (Tomcat by default) inside, started with java -jar. In containers, use layered JARs or bootBuildImage so dependency layers are cached, set the heap relative to the container limit, and enable server.shutdown=graceful so in-flight requests finish before the process exits.