Spring Boot Interview Questions and Answers for Java Developers

Most Spring Boot interviews follow a predictable arc: a few warm-up questions on what the framework actually does, then steadily harder ones on auto-configuration, dependency injection, data access, and how you'd run the thing in production. If you can explain *why* Spring Boot makes a decision for you - not just which annotation triggers it - you'll handle most of what a Java interviewer throws at you.

This guide collects the spring boot interview questions that come up most, grouped beginner to advanced, with crisp answers you can actually study from. Each answer is short enough to memorize and accurate enough to defend in a follow-up. Here's the map:

• Core concepts - what Spring Boot is, starters, auto-configuration, @SpringBootApplication
• Dependency injection and beans - the IoC container, injection styles, bean scopes
• Data access - Spring Data JPA, repositories, transactions
• REST APIs - controllers, request mapping, exception handling
• Production topics - Actuator, configuration, testing, microservices

Work through them in order or jump to the section a recruiter told you to focus on.

Core Spring Boot concepts

These are the questions that open almost every interview. Get them right and the interviewer relaxes; fumble them and you spend the next 20 minutes on the defensive.

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

Spring Boot is a layer on top of the Spring Framework that removes most of the boilerplate setup. The Spring Framework itself is an application framework and inversion-of-control container for Java; Spring Boot is its convention-over-configuration extension for building "stand-alone, production-grade Spring-based applications that you can just run." The practical difference: with plain Spring you wire up XML or Java config, a servlet container, and dependency versions by hand. Spring Boot gives you an embedded server, sane defaults, and dependency management out of the box.

What is a Spring Boot starter?

A starter is a curated set of dependencies you add as a single line. Instead of hunting for compatible versions of Jackson, Tomcat, and validation libraries, you add spring-boot-starter-web and get a tested, version-aligned bundle. According to the official Spring Boot reference, a typical starter also carries the auto-configuration code for that technology, so adding the dependency is often all the setup you need.

What does `@SpringBootApplication` do?

It's a convenience annotation that combines three others:

You put it on your main class, and that single annotation bootstraps the whole application context.

How does auto-configuration actually work?

Auto-configuration inspects the jars on your classpath and configures beans accordingly. Per the Spring Boot documentation, if HSQLDB is on the classpath and you haven't defined a DataSource yourself, Spring Boot configures an in-memory database for you. It's non-invasive - the moment you define your own bean, your version wins. You can also exclude a class explicitly:

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

A strong follow-up answer: run the app with --debug and Spring Boot prints a report of which auto-configurations were applied and which were skipped, and why.

Dependency injection and the IoC container

This block separates people who memorized annotations from people who understand the container. Expect at least one "why" question here.

What is dependency injection, and why does Spring use it?

Dependency injection means an object doesn't create its own collaborators - the container supplies them. Spring's IoC container instantiates your beans, resolves their dependencies, and hands them over. The payoff is testability and loose coupling: you can swap a real database repository for a mock without touching the class that uses it.

Which injection style should you use - constructor, setter, or field?

Constructor injection. The official Spring guidance recommends constructor injection because it makes dependencies explicit, supports final fields, and guarantees the object is fully initialized before use. Field injection (@Autowired on a private field) is the most concise but the hardest to test and the easiest to abuse. A clean answer names the trade-off rather than just reciting the rule.

@Service
public class OrderService {
    private final PaymentClient payments;

    public OrderService(PaymentClient payments) {
        this.payments = payments;
    }
}

What's the difference between `@Component`, `@Service`, `@Repository`, and `@Controller`?

Functionally they're all @Component - the container treats them as beans. The difference is intent and a few extras:

What are bean scopes?

The default scope is singleton - one instance per container. prototype creates a new instance on every request. In web apps you also get request, session, and application scopes. The mistake to avoid: injecting a prototype bean into a singleton expecting a fresh copy each call - it gets created once at injection time unless you use a provider.

Spring Data JPA and persistence

Data-layer questions reward candidates who know what the framework generates for them versus what they write.

What does Spring Data JPA give you over plain JPA?

It generates repository implementations from interfaces. You declare an interface extending JpaRepository<User, Long> and get CRUD methods for free - no implementation class. The Spring Data JPA module provides data access on top of the Java Persistence API, and the auto-configuration even scans for your entities and repositories starting from the package of your @EnableAutoConfiguration class.

How do derived query methods work?

You name a method following a convention and Spring Data writes the query. findByEmailAndActiveTrue(String email) becomes a query selecting where email matches and active is true. For anything complex, drop to @Query with JPQL or native SQL.

public interface UserRepository extends JpaRepository<User, Long> {
    List<User> findByLastNameOrderByFirstNameAsc(String lastName);

    @Query("SELECT u FROM User u WHERE u.active = true")
    List<User> findActiveUsers();
}

What does `@Transactional` do, and where should it go?

It wraps a method in a database transaction - commit on success, roll back on a runtime exception. Put it on the service layer, not the repository, so a single business operation spanning multiple repository calls commits or rolls back as one unit. A common gotcha worth mentioning: @Transactional works through Spring's proxy, so calling a transactional method from another method *in the same class* bypasses the proxy and the transaction doesn't apply.

What's the N+1 query problem?

Lazy-loaded associations trigger one query for the parent list and then one extra query per child - N+1 round trips. You fix it with a JOIN FETCH, an entity graph, or batch fetching. Naming this problem unprompted signals real JPA experience.

REST APIs in Spring Boot

If the role is backend web, this is the densest part of the interview. The questions overlap heavily with general REST API interview questions, so prep both together.

What's the difference between `@Controller` and `@RestController`?

@RestController is @Controller plus @ResponseBody on every method. With @Controller, return values are resolved as view names; with @RestController, they're serialized straight to the response body as JSON or XML. For an API, you want @RestController.

How do you map requests and read parameters?

@RequestMapping is the general form; @GetMapping, @PostMapping, @PutMapping, and @DeleteMapping are the HTTP-specific shortcuts. You read input with:

• @PathVariable - values from the URL path (/users/{id})
• @RequestParam - query-string parameters (?page=2)
• @RequestBody - the deserialized request body

How do you handle exceptions cleanly across an API?

Use @RestControllerAdvice with @ExceptionHandler methods to centralize error handling, returning a consistent error body and the right HTTP status. This beats try/catch in every controller and keeps your status codes consistent - a 404 for a missing resource, 400 for bad input, 500 only for genuine server faults.

What's the right way to return status codes?

Return a ResponseEntity<T> when you need control over the status and headers, or annotate with @ResponseStatus for a fixed code. Don't return 200 OK for everything - interviewers notice when a "created" endpoint doesn't return 201.

Production topics: Actuator, config, testing, and microservices

The senior-leaning questions live here. You don't need depth on all of them, but you should be able to hold a conversation.

What is Spring Boot Actuator?

Actuator adds production-ready endpoints for monitoring and managing a running app. Per the Spring Boot Actuator reference, you add the spring-boot-starter-actuator starter and get endpoints under /actuator. The most-used endpoints are:

Security note worth stating: only /health is exposed over HTTP by default. You opt others in with management.endpoints.web.exposure.include and put them behind authentication, because endpoints like env and beans leak internals.

How do you manage configuration across environments?

Externalize it. Use application.properties or application.yml, override per environment with Spring Profiles (application-prod.yml), and inject values with @Value or, better, a typed @ConfigurationProperties class. The principle: never hardcode environment-specific values, and let environment variables or a config server override files at deploy time.

How do you test a Spring Boot application?

There are two layers. @SpringBootTest loads the full application context for integration tests. Sliced annotations load only what you need and run faster: @WebMvcTest for the web layer with MockMvc, @DataJpaTest for the persistence layer against an embedded database. A good answer mentions choosing the narrowest slice that proves the behavior, rather than spinning up the whole context every time.

How does Spring Boot fit into a microservices architecture?

Spring Boot is the per-service runtime; the Spring Cloud ecosystem adds the cross-service pieces - service discovery, a config server, a gateway, and resilience patterns like circuit breakers. The interviewer usually wants to hear that each service owns its data, communicates over REST or messaging, and is independently deployable. For deeper coverage, the microservices interview questions and system design interview questions guides go beyond the framework into architecture trade-offs.

How to prepare beyond memorizing answers

Knowing the answers is table stakes. What actually moves an interview is connecting them to work you've done - "we hit the N+1 problem in our orders service and fixed it with an entity graph" lands harder than a textbook definition. Pull two or three stories from your own projects that map to these topics and rehearse them.

It also helps to know who's interviewing you. A platform team lead will push on Actuator, config, and observability; an application engineer will dig into JPA mappings and REST design. Reading the interviewer's background ahead of time tells you which third of this guide to over-prepare.

That's where direct research pays off. Resumes and rehearsed answers carry you to the door; a short, well-targeted conversation with the person hiring is what gets you through it. Articuler is built to find that person - semantic search across 980M+ professional profiles to surface the actual hiring manager or interviewer behind a posting, an AI meeting-prep Playbook that summarizes their background and what they care about, and AI-drafted outreach that gets roughly 8x the reply rate of a generic cold note. Walk in prepared for *that* conversation, not a generic one.

Quick reference and key takeaways

• Lead with the "why." Explaining *why* auto-configuration backs off when you define your own bean beats reciting which annotation triggers it.
• Constructor injection is the default answer on DI style - explicit, testable, final-friendly.
• Know your stereotypes. @Repository translates persistence exceptions; @RestController adds @ResponseBody. The differences are small but interviewers test them.
• JPA depth shows in the gotchas - the proxy limitation on @Transactional and the N+1 problem signal real experience.
• Actuator and config questions separate juniors from people who've actually shipped. Only /health is exposed by default for a reason.

Spring Boot interviews reward people who understand the framework's defaults rather than memorize its annotations. If you're also brushing up adjacent topics, the Java and JavaScript interview questions and broader software engineer interview questions guides round out a full backend-engineering prep set.