Spring Boot Interview Questions & Answers (2026)

Tip: always wire your health checks and readiness probe into the platform. Orchestration without good health checks is guesswork.

Scenario-Based Spring Boot Interview Questions

Experienced candidates are rarely asked "what is @Transactional?" They are asked what they would do when something breaks. A strong answer follows the same shape every time: how you would confirm the problem, the likely causes in order, the fix, and how you would prevent it from coming back.

Scenario 1: Your Spring Boot service is slow under load. How do you find the bottleneck?

Measure before you change anything: find out whether time is spent waiting (on the database, a downstream service, or a pool) or computing (CPU, garbage collection), then fix the biggest wait first.

1. Confirm and locate: look at p95/p99 latency in http.server.requests per endpoint, and at a few distributed traces for slow requests. Traces show immediately whether time is spent in SQL, an HTTP call, or your own code.

2. Check saturation: hikaricp.connections.pending above zero means requests are queuing for a database connection (HikariCP's default pool size is 10). Also check busy web server threads (Tomcat's default maximum is 200), CPU, and GC pause times. Take a thread dump from /actuator/threaddump: if most threads are waiting in the same place, you have found the bottleneck.

3. Usual culprits: N+1 queries or missing indexes; connections held too long (open-in-view, or remote calls made inside a @Transactional method); downstream calls without timeouts; synchronous work that could be cached or made asynchronous; excessive logging or large JSON payloads.

4. Fix and verify: apply one change at a time and re-run a load test (Gatling, JMeter, or k6) against a production-like environment to prove the improvement.

Always set explicit timeouts on outbound calls. A missing timeout is the most common reason one slow dependency makes the whole service slow:

@Bean
RestClient inventoryClient(RestClient.Builder builder) {
  var factory = new SimpleClientHttpRequestFactory();
  factory.setConnectTimeout(Duration.ofSeconds(2));
  factory.setReadTimeout(Duration.ofSeconds(3));
  return builder
      .baseUrl("http://inventory-service")
      .requestFactory(factory)
      .build();
}

What not to say: "I would increase the thread pool and the connection pool." Bigger pools often move the bottleneck to the database and make things worse. Explain that you would size pools based on measurements.

Scenario 2: A bean isn't being injected. How do you debug it?

Read the startup failure message first. Spring Boot's failure analyzer usually tells you exactly which constructor parameter could not be satisfied, and the cause is almost always one of a handful of issues.

• NoSuchBeanDefinitionException ("required a bean of type ... that could not be found"):

  • The class is outside the component-scan base package (the package of your @SpringBootApplication class and its sub-packages).

  • The class is missing a stereotype annotation (@Service, @Component) or @Bean method.

  • A condition did not match: the bean is behind @Profile, @ConditionalOnProperty, or an auto-configuration that backed off. Run with --debug or check /actuator/conditions.

  • In a test slice (@WebMvcTest), services are intentionally not loaded; mock them with @MockitoBean.

• NoUniqueBeanDefinitionException: two beans of the same type exist. Mark one @Primary, or inject by @Qualifier.

• Field is null at runtime: the object was created with new, so Spring never managed it, or you are using field injection in a class Spring does not own.

• Circular dependency error: two beans need each other through their constructors. Refactor responsibilities instead of re-enabling circular references.

@Configuration
public class PaymentConfig {

  @Bean
  @Primary
  PaymentGateway stripeGateway() { return new StripeGateway(); }

  @Bean
  PaymentGateway fallbackGateway() { return new ManualReviewGateway(); }
}

@Service
public class RefundService {
  private final PaymentGateway gateway;

  public RefundService(@Qualifier("fallbackGateway") PaymentGateway gateway) {
    this.gateway = gateway;
  }
}

/actuator/beans lists every bean in the context, which confirms whether your bean exists at all.

Scenario 3: @Transactional isn't rolling back. What went wrong?

Check three things in order: whether the call actually went through the Spring proxy, whether the exception type triggers a rollback, and whether the exception was swallowed.

@Service
public class TransferService {

  public void transferAll(List<Transfer> transfers) {
    transfers.forEach(this::transfer); // self-invocation: proxy bypassed, NO transaction
  }

  @Transactional
  public void transfer(Transfer t) throws InsufficientFundsException {
    debit(t);
    credit(t);
    // A checked exception here does NOT roll back by default
  }
}

• Self-invocation: calls through this skip the proxy. Move the transactional method to another bean, or put @Transactional on the outer public method.

• Checked exceptions: use @Transactional(rollbackFor = Exception.class) or throw an unchecked exception.

• Swallowed exceptions: a try/catch that logs and continues means the transaction commits.

• Other causes: private methods, a method called on an object not created by Spring, or a table using a non-transactional storage engine.

Scenario 4: How would you secure this REST API?

Walk through it in layers: who is calling (authentication), what they may do (authorization), what they send (input validation), and what the platform exposes (transport and operational hardening).

1. Authentication: accept OAuth2 access tokens (JWTs) from your identity provider through oauth2ResourceServer().jwt(), with a stateless session policy (see the Security section for the full configuration).

2. Authorization: coarse URL rules in the SecurityFilterChain, plus @PreAuthorize on service or controller methods for fine-grained checks. Also check ownership ("can this user see this order?"), because role checks alone do not prevent broken object-level authorization.

3. Input: validate every request DTO with Bean Validation, use parameterized queries (Spring Data does this for you), and never bind request bodies directly to entities.

4. Transport and defaults: HTTPS only, strict CORS, security headers on, CSRF disabled only because no cookies are used.

5. Operations: expose only health publicly, keep secrets in a secrets manager, add rate limiting at the gateway, log authentication failures, and scan dependencies for known vulnerabilities.

@Service
public class OrderQueryService {

  private final OrderRepository orders;

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

  @PreAuthorize("hasAuthority('SCOPE_orders.read')")
  public OrderDto findForCurrentUser(Long orderId, Jwt jwt) {
    Order order = orders.findById(orderId).orElseThrow(OrderNotFoundException::new);
    if (!order.getCustomerId().equals(jwt.getSubject())) {
      throw new OrderNotFoundException(); // do not reveal that the order exists
    }
    return OrderDto.from(order);
  }
}

Scenario 5: How do you manage configuration across dev, staging, and production?

Keep one artifact and change only configuration: shared defaults in application.yml, environment differences in profiles or environment variables, typed and validated binding with @ConfigurationProperties, and secrets injected at runtime.

# application.yml
app:
  payments:
    base-url: http://localhost:8089
    timeout: 3s
---
spring:
  config:
    activate:
      on-profile: prod
app:
  payments:
    base-url: https://payments.internal.example.com
    timeout: 2s

@Validated
@ConfigurationProperties(prefix = "app.payments")
public record PaymentsProperties(
    @NotBlank String baseUrl,
    @NotNull Duration timeout) {}

• Activate the profile from outside the artifact: SPRING_PROFILES_ACTIVE=prod.

• Override without rebuilding: environment variables and command-line arguments take precedence over packaged files, so APP_PAYMENTS_BASEURL overrides app.payments.base-url.

• Secrets: never in Git. Inject them from Vault, a cloud secrets manager, or Kubernetes Secrets.

• Fail fast: @Validated properties stop the app at startup when a required value is missing, instead of failing on the first real request.

• Many services: centralize with Spring Cloud Config or Kubernetes ConfigMaps so a change does not require editing every repository.

Scenario 6: A downstream service keeps timing out and is taking your service down with it. What do you do?

Contain the failure: short timeouts so threads are released, a circuit breaker so you stop calling a dependency that is already failing, a bulkhead so one dependency cannot use every thread, and a fallback so users get a degraded answer instead of an error.

• Immediate: add or tighten timeouts on the client (see Scenario 1).

• Circuit breaker: Resilience4j @CircuitBreaker with a fallback, as shown in the Microservices section.

• Bulkhead: limit concurrent calls to that dependency (Resilience4j @Bulkhead) so the rest of the service keeps working.

• Retries with care: only for idempotent calls, few attempts, exponential backoff with jitter.

• Longer term: cache results that can be slightly stale, or move the interaction to asynchronous messaging if the caller does not need an immediate answer.

Advanced topics & system design (senior-level)

Senior interviews expect system-level thinking: resilience patterns, observability, scaling strategies, and trade-offs for distributed systems. For the design round itself, see our guide to system design interviews for senior engineers.

Designing resilient microservices

Design resilient microservices with timeouts, retries with backoff, circuit breakers, bulkheads, and graceful degradation.

Short explanation:

• Timeouts: Set sensible request timeouts to avoid resource exhaustion.

• Retries with jitter/backoff: Retry transient errors only; avoid thundering herds.

• Circuit breakers: Fail fast when a downstream is unhealthy and provide fallbacks.

• Bulkheads: Partition resources (thread pools, semaphores) per downstream to prevent cascading failures.

• Idempotency: Accept an idempotency key on write endpoints so client retries do not create duplicates.

• Graceful degradation: Return cached or reduced functionality when dependencies fail.

Design note: discuss trade-offs (user experience vs complexity) and where each pattern belongs: client-side, in the gateway, or in the service.

Observability: tracing, correlation IDs, OpenTelemetry

Combine traces, logs, and metrics, linked by trace IDs, so you can follow one request across services.

Short explanation:

• Correlation: with Micrometer Tracing, the W3C traceparent header is propagated automatically and trace IDs appear in logs. For systems outside tracing, pass a request ID header (for example X-Request-ID) and log it.

• Tracing: export spans through OpenTelemetry (OTLP) or Zipkin; choose a sampling rate that balances cost and visibility.

• Metrics: emit business and system metrics with Micrometer and scrape them with Prometheus or push them through OTLP.

• Why: observability is how you troubleshoot latency and errors in production instead of guessing.

Multi-tenant strategies & DB scaling

Choose shared schema, schema-per-tenant, or database-per-tenant based on isolation needs, scale, and operational cost.

Options:

• Single DB, shared schema: Easiest to manage; use a tenant_id column on every table; lowest isolation, so every query must filter by tenant.

• Schema per tenant: Better isolation, manageable with migration tooling (Flyway or Liquibase run per schema); a good middle ground.

• DB per tenant: Highest isolation; highest operational cost; best for strict compliance needs.

• DB scaling tips: read replicas for read-heavy traffic, partitioning and sharding for large tables, caching (Redis) for hot data, and connection pools sized per instance so the total across all instances stays below the database's connection limit.

Coding tasks & whiteboard prompts (practical)

Many Spring Boot interviews include a take-home or live-coding task. Know what "done" looks like before you start.

Small REST API implementation task (acceptance criteria)

Task: Implement a simple Task Manager REST API with endpoints to create, get, update, and list tasks.
Acceptance criteria:

• POST /api/tasks creates a task and returns 201 with its id. The title must not be empty.

• GET /api/tasks/{id} returns 200 with the task or 404 if not found.

• PUT /api/tasks/{id} updates title and description and returns 200.

• GET /api/tasks supports pagination (page, size) and an optional status filter.

• Use @Valid for input validation, correct status codes, and a @RestControllerAdvice for errors.

• Include 3 unit tests for service logic and 2 MockMvc tests for controller endpoints.

Evaluation focus: API correctness, DTOs, validation, transaction handling, tests, and a clear README with run instructions.

Debugging a stacktrace - guided exercise

Diagnose a failing call by reading the stacktrace, identifying the root cause (for example LazyInitializationException or NullPointerException), and proposing a fix and a test.

Example stacktrace (shortened):

org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: com.example.Post.comments: could not initialize proxy - no Session
  at org.hibernate.collection.spi.AbstractPersistentCollection.throwLazyInitializationException(...)
  ...
  at com.example.controller.PostController.getPost(PostController.java:45)

Debug steps:

1. Read the exception: a lazy collection was accessed after the persistence context closed.

2. Find the code line: PostController.getPost reads post.getComments(), or Jackson serializes the entity after the transaction ended.

3. Fix options:

   • Use a fetch join in the repository (findByIdWithComments) or @EntityGraph.

   • Initialize what you need inside a @Transactional service method.

   • Map to a DTO in the service layer and return that instead of the entity.

4. Test: add an integration test that loads the entity through the service and asserts the comments are present.

5. Explain trade-offs: a fetch join on a collection complicates pagination; DTOs avoid entity lifecycle issues entirely. Turning on open-in-view hides the error but does not fix the design.

Study plan & cheat sheet (30/60/90 days)

Structured study: fundamentals first (30 days), then mid-level topics and testing (60 days), then system design, microservices, and mock interviews (90 days). If your interview is sooner, compress each block but keep the order.

30 / 60 / 90 breakdown (daily topics)

30 days - Fundamentals (about 1 hour a day)

• Week 1: Spring Boot basics, IoC and DI, @SpringBootApplication, starters, running apps.

• Week 2: Controllers, REST, validation, exception handling. Build a small API.

• Week 3: JPA basics, repositories, transactions, pagination.

• Week 4: Testing basics: unit tests + @WebMvcTest.

60 days - Intermediate (about 1 to 1.5 hours a day)

• Week 5: Spring Security 6, OAuth2 resource server, and JWT flows.

• Week 6: Microservices basics, RestClient and WebClient, Spring Cloud concepts.

• Week 7: Observability: Actuator, Micrometer, tracing.

• Week 8: Deployment: Docker, a basic CI pipeline, and GitHub Actions.

90 days - Advanced (about 1 to 2 hours a day)

• Week 9: Resilience patterns: circuit breaker, retries, bulkheads.

• Week 10: Spring Boot 3 specifics: Jakarta migration, virtual threads, native images.

• Week 11: Performance tuning and troubleshooting (N+1, connection pools, the scenarios above).

• Week 12: System design, mock interviews, whiteboard tasks, and a final cheat-sheet review.

Common pitfalls & quick fixes (Do's & Don'ts)

Prevent common mistakes by fixing these anti-patterns in your own projects before the interview. Interviewers reward clarity: present the issue, the fix, and the test you would write.

Do's

• Do use constructor injection (avoid field injection).

• Do validate inputs with @Valid and handle errors centrally.

• Do set timeouts on every outbound call.

• Do write small, focused tests: unit first, slices second.

• Do explain trade-offs when choosing tools and patterns.

Don'ts

• Don't put heavy logic in controllers.

• Don't rely on @Transactional for private methods or self-invocation.

• Don't block reactive stacks (avoid blocking calls in WebFlux).

• Don't expose Actuator endpoints publicly without protection.

• Don't return JPA entities directly from controllers.

1-page checklist: "Fix these before your interview"

• Use constructor injection for beans.

• Use DTOs for external API models; do not expose internal entities.

• Add @Valid and test invalid payloads.

• Add Actuator health and a secured Prometheus endpoint.

• Add unit tests for key service methods.

• Avoid LazyInitializationException by using DTOs or fetch strategies.

• Build a small, multi-stage Docker image.

• Write a README that explains how to run the app and the tests.

Quick-Fire Spring Boot Questions (Rapid Review)

Short answers for last-minute revision. Each is covered in more depth above.

• How is Spring Boot different from Spring MVC? Spring MVC is the web framework for controllers and views; Spring Boot is the opinionated layer that packages and auto-configures Spring apps, including Spring MVC.

• How do I validate request input in controllers? Use @Valid on @RequestBody DTOs and annotate fields with Jakarta Bean Validation constraints like @NotBlank and @Email.

• How do I handle exceptions globally? Use @RestControllerAdvice with @ExceptionHandler methods that return ProblemDetail or a structured error body.

• How do I test controllers? Use @WebMvcTest + MockMvc for controller slice tests and @SpringBootTest for end-to-end tests.

• Should I use RestTemplate, RestClient, or WebClient? RestClient for new blocking code, WebClient for reactive or streaming, RestTemplate only in existing code.

• Which Actuator endpoints should I expose? health, plus info, metrics, or prometheus behind authentication or on an internal port.

• What is Spring Data JPA? Repository abstractions over JPA that provide CRUD, paging, sorting, and derived queries.

• How do I prevent leaking DB credentials? Inject them at runtime from Vault, a secrets manager, or platform secrets; never commit them.

• DTOs or entities in controllers? DTOs, to avoid exposing internal state and lazy-loading issues.

• How do I debug LazyInitializationException? Find where the lazy association is accessed outside a transaction and load it explicitly (fetch join, entity graph) or map to a DTO.

• How do I instrument metrics? Use Micrometer counters, timers, or the Observation API, export to Prometheus or OTLP, and visualize in Grafana.

• How do I run integration tests with a real DB? Testcontainers with @ServiceConnection.

• How do I enable caching? Add @EnableCaching and annotate methods with @Cacheable; Spring Boot auto-configures a provider such as Caffeine or Redis if present.

• How do I run a method asynchronously? Add @EnableAsync and annotate a public method on another bean with @Async.

• How do I schedule a job? Add @EnableScheduling and use @Scheduled(cron = "..."); with several instances, use a distributed lock so the job runs once.

Conclusion

Spring Boot interviews reward clarity, practical examples, and the ability to explain trade-offs. Lead with the one-line answer, back it with a small code sample, and show an operational mindset (testing, security, observability, deployment). For experienced roles, practice the scenario questions out loud: that is where most candidates lose points.

Quick takeaways

• Lead with a one-line answer, then show a short example.

• Practice the common patterns: auto-configuration, controllers, JPA, security, HTTP clients.

• Know what changed in Spring Boot 3: Jakarta namespaces, Spring Security 6, Micrometer Observation, native images, and virtual threads.

• Prepare 2-3 real mini-demos (Task API, secured endpoint, a fetch-join fix).

• For 5+ years of experience, rehearse the scenarios: slow service, missing bean, failed rollback, cascading failure.

Reading answers is not the same as saying them under pressure. You can rehearse with Interview Sidekick: its AI mock interviews give you feedback on how you explain your answers, and its bank of 10,000+ real interview questions covers the behavioral and general rounds that come with most backend roles. There is a free tier, and no credit card is required.

Frequently Asked Questions

What are the most common Spring Boot interview questions?

The most common questions are what Spring Boot is and how it differs from Spring, what @SpringBootApplication does, how auto-configuration and starters work, @RestController vs @Controller, validation and global exception handling, Spring Data JPA and @Transactional, the N+1 problem, securing a REST API, Actuator, and testing with @WebMvcTest and @SpringBootTest.

What Spring Boot questions are asked for freshers?

Freshers are usually asked definitions and basics: what Spring Boot is, IoC and dependency injection, @Component vs @Bean, bean scopes, starters, auto-configuration, application.properties and profiles, @RestController, @PathVariable vs @RequestParam, and how to build a simple CRUD REST API with Spring Data JPA.

What Spring Boot questions are asked for 5 or 10 years of experience?

With around 5 years of experience, expect transactions and propagation, the N+1 problem, Spring Security configuration, testing strategy, and debugging scenarios such as a bean not being injected or a transaction not rolling back. With 10 or more years, expect microservice design, resilience patterns, observability, Spring Boot 3 migration, performance under load, and system design trade-offs.

What is new in Spring Boot 3 that interviewers ask about?

Spring Boot 3 requires Java 17, moved from javax.* to jakarta.* packages, ships Spring Security 6 and Hibernate 6, supports GraalVM native images through ahead-of-time processing, uses Micrometer Observation and Tracing for observability, supports ProblemDetail error responses, and (from 3.2 on Java 21) can run on virtual threads with spring.threads.virtual.enabled=true.

Which Spring Boot microservices questions should I prepare?

Prepare service discovery (Eureka or Kubernetes DNS), centralized configuration with Spring Cloud Config, API gateways, circuit breakers and retries with Resilience4j, synchronous vs asynchronous communication, the Saga and outbox patterns for data consistency, and distributed tracing with Micrometer Tracing.

How should I prepare for a Spring Boot interview?

Build one small but complete project (REST API, validation, JPA, security, tests, Docker), learn to explain each part in one sentence, study the Spring Boot 3 changes, and practice scenario questions out loud. Mock interviews help you find gaps in how you explain things before a real interviewer does.