10 Spring Boot Interview Questions with Answers and Code

A useful Spring Boot interview answer explains what happens at runtime, shows a small example, and names a failure case. Memorizing annotation names is only the first step.

These ten questions move from application setup to transactions, tests, and production diagnosis. The Java snippets illustrate individual components; imports, repository implementations, and application-specific error handling are omitted. Match dependencies and test annotations to the Spring Boot version used by your project.

1. How is Spring Boot different from Spring Framework?

Spring Framework provides the container, dependency injection, web framework, transaction support, and other building blocks. Spring Boot assembles those pieces with dependency starters, conditional configuration, executable application packaging, and operational conventions.

Boot does not replace Spring. A strong answer distinguishes a library you depend on, a bean in the application context, and configuration that creates that bean. Adding a dependency does not prove that a particular bean exists.

Practice explaining the distinction without jargon in Compare Spring and Spring Boot.

2. What does auto-configuration actually do?

Auto-configuration evaluates conditions such as available classes, existing beans, and configuration properties. It supplies a suitable default when those conditions match. Your own bean can cause a default configuration to back off; that behavior depends on the particular configuration's conditions.

When a bean is missing, inspect the condition evaluation report, the active profiles, and the package scan boundary before adding annotations at random. Spring Boot's auto-configuration reference explains the conditions report and how to replace defaults.

Follow-up: Why might the same application start locally but fail in CI? Check the dependency graph, environment properties, profiles, and services required by startup code. “Boot is broken” is not a diagnosis.

3. What is a starter, and what does it not guarantee?

A starter is a dependency grouping for a capability. It saves you from assembling a compatible set of supporting libraries individually. Auto-configuration is the separate mechanism that examines the application's environment and registers configuration.

Keep these concepts separate during an interview:

This is also why copying a starter from a different major Boot version can create confusing failures. Confirm the supported dependency arrangement for the version in the exercise.

4. Why prefer constructor injection?

Constructor injection makes required dependencies explicit and supports plain unit tests. A dependency can be held in a final field, so a service cannot be created through that constructor without supplying it.

@Service
public class GreetingService {
    private final Clock clock;

    public GreetingService(Clock clock) {
        this.clock = clock;
    }

    public String greeting() {
        return "Hello on " + LocalDate.now(clock);
    }
}

@Configuration
class TimeConfiguration {
    @Bean
    Clock clock() {
        return Clock.systemUTC();
    }
}

The service needs no Spring context for a basic unit test: instantiate it with a fixed clock and assert the greeting. That test is deterministic because it does not depend on today's date.

Follow-up: What if two Clock beans exist? Explain how an explicit qualifier or primary candidate resolves ambiguity. Do not hide an accidental dependency choice behind field injection.

5. How would you organize a REST endpoint?

Keep HTTP parsing and response mapping in a controller, business rules in a service, and persistence behind a repository. The useful boundary is responsibility, not a requirement to add an interface to every class.

@RestController
@RequestMapping("/greetings")
public class GreetingController {
    private final GreetingService greetings;

    public GreetingController(GreetingService greetings) {
        this.greetings = greetings;
    }

    @GetMapping
    public Map<String, String> getGreeting() {
        return Map.of("message", greetings.greeting());
    }
}

For a write endpoint, discuss request validation, authentication and authorization, response codes, and duplicate requests. A successful JSON response does not prove that the underlying operation is safe to retry.

Try building Spring Boot POST, PUT, and GET endpoints, then explain which checks belong in each layer. Verify the expected behavior for missing records and invalid input as carefully as the happy path.

6. How should configuration differ between environments?

Keep deploy-specific values outside business logic. Use typed configuration for related settings, validate required values at startup, and document which values may safely have defaults.

A profile is useful for selecting a configuration group, but it is not a secret store. Do not put credentials in committed profile files. For an interview exercise, explain how you would obtain a database URL or API credential from the deployment environment and fail clearly if it were absent.

When settings appear to be ignored, investigate precedence. A value supplied by the deployment can override a value in a file. Describe the observed value and its source rather than assuming the file you edited is authoritative.

For a deeper debugging exercise, read Spring Boot interview questions for Java engineers.

7. What does @Transactional guarantee?

With Spring's usual proxy-based transaction management, an eligible method call through the proxy starts or joins a transaction according to its configuration. That boundary covers work managed by the selected transaction manager; it does not make an external HTTP request part of a database transaction.

@Service
public class OrderService {
    private final OrderRepository orders;

    public OrderService(OrderRepository orders) {
        this.orders = orders;
    }

    @Transactional
    public void create(Order order) {
        orders.save(order);
        // More database work in the same transaction belongs here.
    }
}

Do not promise rollback for every exception. The default rollback rules distinguish unchecked exceptions from checked exceptions, and configuration can change those rules. State the rule you intend and test it. The transaction annotation reference documents these boundaries.

8. Why can a transactional method appear to do nothing?

A common cause is self-invocation: one method calls another method on the same instance, bypassing the proxy. In the usual proxy mode, the called method's transaction annotation is not newly intercepted.

Other possibilities include an object constructed outside Spring, an incompatible method/proxy arrangement, or an exception caught before it reaches the transaction interceptor. An existing outer transaction can still be active, so “the annotation was bypassed” does not always mean “there was no transaction.”

Explain the call path before suggesting a fix. Moving the transaction boundary to an appropriately designed service method is often clearer than adding more annotations. Avoid long network calls while holding a database transaction open.

9. Which tests would you write?

Choose the smallest test that proves the behavior, then add integration coverage for boundaries a unit test cannot exercise.

Spring Boot's testing reference describes full-context and focused test support. Use a database representative of production when dialect differences or constraints matter.

For the fixed-clock service above, a unit test can pass a clock created with Clock.fixed(Instant.parse("2026-01-02T00:00:00Z"), ZoneOffset.UTC) and expect Hello on 2026-01-02. A separate application test should prove the intended Clock bean is wired.

10. How would you investigate a slow or failing application?

Start with the symptom and a time window. Is startup failing, one endpoint slow, all requests waiting for connections, or a downstream service timing out? Read the exception chain and correlate logs with request traces and resource metrics.

A useful investigation sequence is:

1. Reproduce one failing request with the smallest relevant input.
2. Check the failing boundary: validation, service, database, or external dependency.
3. Measure latency and resource saturation before changing pool sizes or adding caching.
4. Verify configuration and dependency changes around the first failure.
5. Add a regression test for the confirmed cause.

Operational endpoints and logs can expose sensitive details. Restrict access and avoid recording secrets or full private request bodies. A health endpoint alone is not an authorization policy.

Apply this approach to the Spring Boot movie-search debugging question. Explain each failing rule, make the smallest correction, and check that the other rules still hold.

A focused practice session

Spend ten minutes answering questions 1–4 out loud, twenty minutes implementing a small endpoint, and ten minutes investigating a transaction or configuration failure. Finish by writing one test that would have caught it.

For each answer, name the runtime mechanism, demonstrate it, and explain one limitation. That is a stronger signal than a longer list of annotations.

Keep practicing

• Compare Spring and Spring Boot
• Build Spring Boot REST endpoints
• Spring Boot interview questions for Java engineers