Spring Boot Interview Questions for Backend Engineers

Spring Boot interviews for backend engineers concentrate on nine topics: dependency injection, auto-configuration, configuration and profiles, REST endpoints, data access with JPA and transactions, testing, security, Actuator, and production behavior. Junior candidates are usually tested on the first four. Senior candidates are expected to explain how each feature works internally and where it fails in production, especially transactions, the N+1 query problem, and thread and connection limits.

The questions below are the ones that come up most often. Each answer is written at the length an interviewer expects in a live conversation, which is usually three to six sentences, with a short code example where code makes the point faster than prose. The article ends with a table that maps each topic to the seniority level where it is typically asked, and a preparation plan.

What do Spring Boot interviews test?

A Spring Boot interview rarely asks you to recite annotations. It checks whether you understand what the framework does on your behalf, because every convenience in Spring Boot is a decision someone made for you. An engineer who knows which decision was made can change it safely when production needs something different.

Most interviewers therefore ask a question in two layers. The first layer is "what does this annotation do?", and the second layer is "what happens when it goes wrong?". For example, a candidate who says that @Transactional starts a transaction is answering the first layer. A candidate who adds that it does nothing when one method calls another method in the same class is answering the second layer, and that second answer is what separates a mid-level engineer from a senior one.

Core concepts and dependency injection

1. What is Spring Boot, and how is it different from the Spring Framework?

The Spring Framework provides the core container that creates objects and connects them to each other, plus modules for web, data, and security. Spring Boot is a layer on top of Spring that removes most of the setup work. It adds sensible default configuration (auto-configuration), curated dependency bundles (starters), an embedded web server, and production features such as health checks and metrics. In short, Spring is the engine, and Boot is the set of defaults that lets you start it with almost no configuration. A deeper comparison is in Spring vs Spring Boot: What Boot Actually Adds.

2. What is dependency injection, and why is constructor injection preferred?

Dependency injection means that an object receives the other objects it needs from the outside, instead of creating them itself. In Spring, the container (the application context) creates these objects, which it calls beans, and passes them in. There are three ways to inject a dependency: through the constructor, through a setter method, or directly into a field.

Constructor injection is preferred for three reasons. The dependencies can be declared final, so they cannot change after the object is built. The object can never exist in a half-built state with a missing dependency. A unit test can also create the class with plain new and pass in test doubles, without starting Spring at all.

@Service
public class OrderService {
    private final PaymentClient paymentClient;
    private final OrderRepository orders;

    public OrderService(PaymentClient paymentClient, OrderRepository orders) {
        this.paymentClient = paymentClient;
        this.orders = orders;
    }
}
Copy

When a class has a single constructor, Spring uses it automatically, so no @Autowired annotation is needed.

3. What is the difference between @Component, @Service, @Repository and @Controller?

All four annotations mark a class as a bean that component scanning should find and register. The @Component annotation is the generic version, and the other three are specializations that state the role of the class. The @Repository annotation adds one real behavior: Spring translates database-specific exceptions from that class into its own DataAccessException hierarchy. The @Controller annotation marks a class whose methods handle web requests. The @Service annotation adds no extra behavior today, but it documents that the class holds business logic.

4. What are bean scopes?

A scope controls how many instances of a bean the container creates. The default scope is singleton, which means one shared instance per application context. Prototype creates a new instance every time the bean is requested. Web applications also have request scope, with one instance per HTTP request, and session scope, with one instance per user session.

A common follow-up asks what happens when a singleton depends on a prototype bean. The prototype is injected only once, when the singleton is created, so the singleton keeps the same instance forever. The fix is to inject an ObjectProvider and call getObject() whenever a fresh instance is needed.

5. What is the lifecycle of a Spring bean?

The container creates the bean, injects its dependencies, and then runs any initialization callbacks. A method annotated with @PostConstruct runs after injection is complete, which makes it a safe place to validate configuration. Before the context closes, a method annotated with @PreDestroy runs, which is where connections and thread pools should be released. Between those two points, BeanPostProcessor implementations can wrap the bean, and this wrapping is how Spring adds proxies for transactions, caching, and security.

6. How do you choose between two beans of the same type?

If two beans implement the same interface, Spring cannot decide which one to inject and fails at startup with a NoUniqueBeanDefinitionException. There are two standard fixes. Mark one bean with @Primary to make it the default choice, or put @Qualifier("name") on the injection point to request a specific bean by name. You can also inject a List of the interface type to receive every implementation, which is useful for plugin-style designs such as a list of validation rules.

Auto-configuration and starters

7. What does @SpringBootApplication do?

@SpringBootApplication combines three annotations. The @SpringBootConfiguration part marks the class as a source of bean definitions. The @EnableAutoConfiguration part turns on auto-configuration. The @ComponentScan part scans the package of the class and all of its subpackages for components. This is why the main class is normally placed in the root package of the project, because components in a package outside that root are not found.

8. How does auto-configuration work?

Auto-configuration is a set of ordinary configuration classes that Spring Boot ships with, each guarded by conditions. At startup, Boot reads the list of candidate classes from a file named META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports inside each JAR. It then evaluates each candidate's conditions and applies only the ones that match.

The most common conditions are @ConditionalOnClass, which checks whether a library is on the classpath, @ConditionalOnProperty, which checks a configuration value, and @ConditionalOnMissingBean, which checks that you have not already defined a bean of that type. That last condition is the important one: it means your own bean always replaces the default one, so you can override any piece of auto-configuration by declaring a bean yourself.

9. What is a starter?

A starter is a dependency that contains almost no code and exists to pull in a tested set of libraries for one purpose. For example, spring-boot-starter-web brings in Spring MVC, an embedded Tomcat server, and Jackson for JSON. The versions of all these libraries are managed by Spring Boot's dependency management, so you do not specify a version for each one, and the versions are known to work together.

10. How do you find out which auto-configurations were applied?

Start the application with the --debug flag, or set debug=true in the configuration file. Spring Boot then prints the condition evaluation report, which lists every auto-configuration class that matched, every one that did not, and the condition that decided each result. In a running application with Actuator enabled, the conditions endpoint returns the same report. This report is the first thing to check when a bean you expected is missing or a bean you did not want appears.

11. How do you turn off a specific auto-configuration?

Use the exclude attribute on the main annotation, or set the spring.autoconfigure.exclude property. Excluding is useful when a library is on the classpath for another reason but you do not want Boot to configure it, for example when a data source library is present but the service does not use a database.

@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)
public class ReportingApplication { }
Copy

Configuration and profiles

12. Should you use application.properties or application.yml?

Both files are read the same way and support the same features, so the choice is about readability. YAML is easier to read for deeply nested settings and lists. Properties files are flatter and avoid indentation mistakes, which in YAML can silently change the meaning of a value. Most teams pick one format and use it across all services.

13. In what order does Spring Boot read configuration values?

Spring Boot reads values from many sources and gives later, more specific sources a higher priority. From lower to higher priority, a simplified order is: the default application.properties inside the JAR, then profile-specific files such as application-prod.properties, then files outside the JAR, then environment variables, and finally command-line arguments. The practical rule is that the value closest to the running process wins. This order is what lets the same JAR run in every environment, with only environment variables changing between staging and production.

14. What is the difference between @Value and @ConfigurationProperties?

@Value("${payment.timeout}") injects a single value into a field or constructor parameter. By contrast, @ConfigurationProperties(prefix = "payment") binds a whole group of related settings to a typed class, and it supports validation, nested objects, lists, and durations written as 5s. For anything beyond one or two values, @ConfigurationProperties is the better choice, because the settings are grouped, type-checked at startup, and easy to test.

@ConfigurationProperties(prefix = "payment")
public record PaymentProperties(Duration timeout, int maxRetries, URI baseUrl) { }
Copy

15. What are profiles, and when should you use them?

A profile is a named set of configuration and beans that is active only in some environments. You activate it with spring.profiles.active=prod, and Spring then loads application-prod.properties and any bean marked @Profile("prod"). Profiles work well for differences in configuration values. They should be used carefully for differences in code, because every profile-only bean is a code path that may never run in testing.

16. How do you keep secrets out of configuration files?

Secrets such as database passwords should never be committed in configuration files. The standard approach is to reference them as placeholders, such as ${DB_PASSWORD}, and supply the real value through environment variables or a secret manager at runtime. Spring Cloud Vault and similar integrations can load secrets directly into the environment, and Kubernetes can mount secrets as environment variables or files.

Web and REST

17. What is the difference between @Controller and @RestController?

@Controller is used for classes whose methods usually return the name of a view, such as an HTML template. The @RestController annotation combines @Controller with @ResponseBody, so the return value of every method is written directly into the response body, usually as JSON. Backend services that expose APIs almost always use @RestController.

18. What happens when an HTTP request reaches a Spring Boot application?

The embedded server, which is Tomcat by default, accepts the connection and passes the request through the servlet filter chain, where Spring Security runs its checks. The request then reaches the DispatcherServlet, which is the single entry point for Spring MVC. The dispatcher finds the controller method that matches the path and HTTP method, converts the request body into a Java object with an HTTP message converter, and calls the method. The return value is then converted back into JSON and written to the response.

19. How do you handle errors in one place?

Create a class annotated with @RestControllerAdvice and add methods annotated with @ExceptionHandler for each exception type. This keeps error handling out of individual controllers and makes every endpoint return errors in the same shape. Recent Spring versions support ProblemDetail, a standard error format defined in RFC 9457, so clients receive a consistent body with a type, title, status, and detail.

@RestControllerAdvice
public class ApiErrors {
    @ExceptionHandler(OrderNotFoundException.class)
    ProblemDetail notFound(OrderNotFoundException ex) {
        return ProblemDetail.forStatusAndDetail(HttpStatus.NOT_FOUND, ex.getMessage());
    }
}
Copy

20. How do you validate a request body?

Add Bean Validation annotations, such as @NotBlank, @Positive, and @Email, to the fields of the request class, and annotate the controller parameter with @Valid. Spring then validates the object before calling the method and returns a 400 response if any rule fails. Since Spring Boot 3, these annotations come from the jakarta.validation package rather than javax.validation, which is a common source of compile errors during upgrades.

21. Which web server does Spring Boot use, and can you change it?

Spring Boot uses embedded Tomcat by default when spring-boot-starter-web is on the classpath. You can replace it with Jetty by excluding the Tomcat starter and adding the Jetty starter. For reactive applications built with WebFlux, the default server is Reactor Netty, which uses a small number of event-loop threads instead of one thread per request.

Preparing for a backend interview that goes deep on Spring? The course Grokking Spring Boot: Build and Understand Spring Services builds one service step by step and explains what the framework does at each step, which is the level of understanding these questions test.

Data access, JPA and transactions

22. How do Spring Data JPA repositories work?

You declare an interface that extends JpaRepository<Order, Long>, and Spring creates the implementation at startup. Common operations such as save, findById, and deleteById are already provided. Spring also builds queries from method names, so findByCustomerIdAndStatus(Long customerId, Status status) becomes a query with two conditions. For anything complex, the @Query annotation lets you write the query in JPQL or native SQL.

23. How does @Transactional work, and when does it fail?

@Transactional works through a proxy. Spring wraps the bean in a proxy object, and when another bean calls a transactional method, the proxy starts a transaction, calls the real method, and then commits or rolls back. This design creates three behaviors that interviewers ask about often:

• Self-invocation is not transactional. If a method in a class calls another method of the same class, the call does not pass through the proxy, so the annotation on the second method is ignored.
• Checked exceptions do not roll back by default. Only unchecked exceptions and errors trigger a rollback. Use @Transactional(rollbackFor = Exception.class) if a checked exception should also roll back.
• Private methods are not proxied. The annotation has no effect on a private method.

24. What is transaction propagation?

Propagation decides what happens when a transactional method is called while a transaction is already running. The default, REQUIRED, joins the existing transaction, so both methods commit or roll back together. The REQUIRES_NEW option suspends the outer transaction and starts an independent one. That option is useful for audit records that must be saved even when the main operation fails, but it uses a second database connection, so heavy use can empty the connection pool.

25. What is the N+1 query problem, and how do you fix it?

The N+1 problem happens when code loads a list of N entities with one query and then triggers one additional query per entity to load a related collection. Loading 100 orders and then reading each order's items produces 101 queries instead of one or two. It usually appears with lazy associations inside a loop, and it is easy to miss in development because the test data is small.

There are three common fixes. A JOIN FETCH in a JPQL query loads the parent and its children together. An @EntityGraph on the repository method states which associations to load with the parent. Setting hibernate.default_batch_fetch_size makes Hibernate load lazy collections in batches, so 100 orders need about two extra queries instead of 100.

@Query("select o from Order o join fetch o.items where o.customerId = :customerId")
List<Order> findWithItems(@Param("customerId") Long customerId);
Copy

26. What is open session in view, and should you disable it?

Spring Boot enables spring.jpa.open-in-view by default and logs a warning about it at startup. This setting keeps the database session open until the HTTP response has been written, so lazy associations can still load while the response is being rendered. The convenience hides N+1 queries and holds a database connection for the whole request. Many teams set it to false so that every query happens inside the service layer, where it is visible and testable.

Testing

27. What is the difference between @SpringBootTest and test slices?

@SpringBootTest starts the full application context, which makes it the right choice for integration tests that need every layer. It is also slow, because it creates every bean. Test slices start only one layer: @WebMvcTest loads controllers and the web configuration, and @DataJpaTest loads repositories with an embedded or test database. Slices run much faster, so a well-structured test suite uses many slice tests and a smaller number of full context tests.

28. How do you replace a bean with a mock in a test?

Annotate a test field with @MockitoBean, and Spring replaces the real bean with a Mockito mock in the test context. This annotation comes from the Spring Framework itself. The older @MockBean annotation from Spring Boot was deprecated in Spring Boot 3.4 in favor of @MockitoBean, so new code should use the newer one.

29. How do you test against a real database?

Use Testcontainers, a library that starts a real database such as PostgreSQL in a Docker container for the test run. Since Spring Boot 3.1, the @ServiceConnection annotation reads the container's address and credentials and configures the data source automatically. Testing against the same database engine as production catches problems that an in-memory database hides, such as differences in SQL syntax and locking behavior.

Security

30. How do you configure Spring Security in a current Spring Boot application?

You define a SecurityFilterChain bean and describe the rules with a builder. The older approach of extending WebSecurityConfigurerAdapter was removed in Spring Security 6, which is the version Spring Boot 3 uses, so interviewers often ask this to check whether a candidate's knowledge is current.

@Bean
SecurityFilterChain api(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(auth -> auth
            .requestMatchers("/actuator/health").permitAll()
            .anyRequest().authenticated())
        .oauth2ResourceServer(oauth -> oauth.jwt(Customizer.withDefaults()));
    return http.build();
}
Copy

31. How do you secure a stateless REST API with tokens?

Add spring-boot-starter-oauth2-resource-server and configure the issuer URL of your identity provider. Spring then validates the JSON Web Token (JWT) on every request: it checks the signature with the provider's public keys, then checks the expiry and the issuer. The service stores no session, so any instance can handle any request, which makes horizontal scaling simple.

32. When is it safe to disable CSRF protection?

Cross-site request forgery (CSRF) is an attack in which another website causes the user's browser to send a request that carries the user's cookies. CSRF protection matters when authentication relies on cookies that the browser sends automatically. A stateless API that reads a token from the Authorization header is not exposed to this attack in the same way, so disabling CSRF there is a common and accepted choice. Interviewers expect you to explain that reason rather than disable it by habit.

Actuator and observability

33. What is Spring Boot Actuator, and what does it expose by default?

Actuator adds operational endpoints to the application, such as health, metrics, info, env, and loggers. For security reasons, only the health endpoint is exposed over HTTP by default. You expose others with management.endpoints.web.exposure.include. Endpoints such as env and heapdump can reveal secrets, so they should be protected or kept on a separate management port that only internal systems can reach.

34. What are liveness and readiness probes?

Kubernetes uses two kinds of health checks. A liveness probe answers "is this process still working?", and a failed check makes Kubernetes restart the container. A readiness probe answers "can this instance receive traffic right now?", and a failed check removes the instance from the load balancer without restarting it. Actuator provides both at /actuator/health/liveness and /actuator/health/readiness. A database outage should normally affect readiness, not liveness, because restarting the container will not repair the database.

35. How do you collect metrics and traces?

Spring Boot uses Micrometer, a metrics library that works with many monitoring systems in the same way that SLF4J works with many logging libraries. Adding a registry such as micrometer-registry-prometheus exposes request counts, latency percentiles, JVM memory, and connection pool usage at /actuator/prometheus. Micrometer Tracing adds trace and span identifiers to each request and to the logs, so one request can be followed across several services.

Production and performance

36. How do virtual threads change a Spring Boot service?

Virtual threads are lightweight threads managed by the Java runtime instead of the operating system, available from Java 21. Since Spring Boot 3.2, setting spring.threads.virtual.enabled=true on Java 21 makes the embedded server handle each request on a virtual thread. A service that spends most of its time waiting on databases and other services can then handle many more concurrent requests without a larger thread pool.

Virtual threads do not create more database connections, however. If a pool has 20 connections, at most 20 requests can use the database at once, and the rest wait for a connection. Interviewers ask this follow-up to check whether a candidate understands where the real limit is.

37. How do you shut a service down without dropping requests?

With graceful shutdown, the server stops accepting new requests when it receives a termination signal and lets requests that are already running finish within a time limit. You control the limit with spring.lifecycle.timeout-per-shutdown-phase, for example 30s. Recent Spring Boot versions enable graceful shutdown by default, and older versions need server.shutdown=graceful. In Kubernetes, the readiness probe should fail first, so the load balancer stops sending traffic before the shutdown begins.

38. How do you reduce startup time and memory use?

There are three main options, in increasing order of effort. Lazy initialization (spring.main.lazy-initialization=true) creates beans only when they are first used, which shortens startup but moves errors from startup to the first request. Class Data Sharing stores preloaded class data in a file that later starts can reuse. A GraalVM native image compiles the application ahead of time into a standalone executable that starts in tens of milliseconds and uses much less memory, at the cost of longer builds and limits on reflection.

Spring Boot 3 and 4 changes worth knowing

Interviewers often check whether a candidate's knowledge matches the current versions. Four changes come up most often:

• Java 17 baseline. Spring Boot 3 requires Java 17 or later, and Spring Boot 4 keeps that minimum while working best on Java 21 and newer.
• The jakarta namespace. Spring Boot 3 moved from the javax.* packages to jakarta.*, so imports such as javax.persistence.Entity became jakarta.persistence.Entity.
• Spring Boot 4 platform. Spring Boot 4 is built on Spring Framework 7 and Jakarta EE 11, and it moves JSON support to Jackson 3.
• Virtual threads. Available since Spring Boot 3.2 on Java 21, controlled by one property.

Spring Boot topics by seniority level

The table shows where each topic is typically asked. The levels are approximate, because companies differ, but the pattern is consistent: junior questions ask what a feature does, and senior questions ask how it fails and what it costs.

How to prepare for a Spring Boot interview

A focused preparation plan of about three weeks works for most backend engineers who already use Spring at work. The plan below assumes about one hour per day.

1. Week one: build one small service yourself. Create a REST API with two entities, validation, global error handling, and a PostgreSQL database. Building it once teaches more than reading about each annotation separately.
2. Week two: break it on purpose. Add a lazy association and count the queries in the logs to see N+1 happen. Call a transactional method from the same class and confirm that no transaction starts. Throw a checked exception and confirm that nothing rolls back. Each experiment turns a memorized fact into something you have observed.
3. Week three: production topics. Add Actuator, Prometheus metrics, liveness and readiness probes, a security filter chain, and Testcontainers tests. Then practice explaining each choice out loud in two or three minutes.

Senior candidates should add one more step. They should be ready to discuss a production incident from their own experience, such as a connection pool that ran out or a slow startup, and explain how they found the cause and what they changed. Interviews for backend roles often move from Spring itself into system design, so it also helps to connect these answers to topics such as caching, messaging, and service boundaries.

Frequently asked questions

What are the most common Spring Boot interview questions? The most common questions cover the difference between Spring and Spring Boot, how auto-configuration works, dependency injection and bean scopes, @Transactional behavior, the N+1 query problem, and how to handle errors in a REST API. Senior interviews add production topics such as Actuator, thread and connection limits, and graceful shutdown.

What Spring Boot questions are asked of experienced engineers? Experienced engineers are asked how features fail rather than what they do. Typical examples are why @Transactional is ignored on self-invocation, how to find and fix N+1 queries, how propagation affects connection use, and how virtual threads interact with a fixed connection pool.

Is Spring Boot enough for a backend interview? Usually not. Most backend interviews also include a coding round and a system design round. Spring Boot questions test whether you can build and operate a service, while the other rounds test algorithms and the design of larger systems.

Do I need to know Spring Boot 3 and 4 differences? You should know the main ones: the Java 17 baseline, the move from javax to jakarta packages, the security configuration based on SecurityFilterChain, and virtual threads. Interviewers use these questions to check whether your knowledge is current.

How should I answer a Spring Boot question I am unsure about? State what you know, then explain how you would check the rest, for example by reading the condition evaluation report or enabling SQL logging. Interviewers value a clear method more than a guess stated with confidence.

How long does it take to prepare for a Spring Boot interview? An engineer who already uses Spring daily can usually prepare in about three weeks at one hour per day. Someone new to Spring should plan for six to eight weeks and start by building a small service.

Related reading

• Spring vs Spring Boot: What Boot Actually Adds
• Kafka vs RabbitMQ: Log vs Queue, and How to Choose
• Event-Driven Architecture: Patterns, Diagrams, and When to Use It Over Request-Response
• Low-Level Design Interview Guide

Want to understand Spring Boot well enough to explain every answer above? Grokking Spring Boot: Build and Understand Spring Services teaches the framework by building a real service, one decision at a time.