Spring Boot Interview Questions and Answers for Experienced Developers

Spring Boot is the default way most Java teams bootstrap web applications, batch jobs, and microservices. Interviewers are not checking whether you memorized every starter artifact—they want proof you can build and operate Spring applications.

Typical skill layers:

Spring Framework is the core inversion-of-control container: beans, AOP, MVC, transaction abstraction, and integration modules. You can build apps with plain Spring, but you assemble a lot manually—XML or Java config, embedded server setup, dependency versions.

Spring Boot sits on top and optimizes for convention over configuration:

Spring Boot does not replace Spring concepts—you still need to understand beans, @Transactional, and MVC. Boot removes boilerplate so you focus on business code.

Loops vary by company (product, bank, consultancy, startup), but experienced Java Spring Boot patterns often look like this:

For 10 years experienced roles, expect more architecture and operability—how you roll out config changes, handle schema migrations, and observe services in Kubernetes or VM fleets.

Treat prep as one reference application you can explain aloud—not fifty disconnected flashcards.

Review Maven BOM imports if interviewers ask how Spring Boot aligns dependency versions.

@SpringBootApplication is a composed annotation that combines three important switches:

@SpringBootApplication
public class OrderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
}

Under the hood it typically includes:

SpringApplication.run bootstraps the context, starts the embedded web server (if spring-boot-starter-web is present), and registers shutdown hooks.

Common follow-up: How do you exclude an auto-configuration? Use @SpringBootApplication(exclude = SomeAutoConfiguration.class) or spring.autoconfigure.exclude in properties.

A strong answer is:

@SpringBootApplication enables component scanning and auto-configuration from my main class package downward, and SpringApplication.run starts the embedded container and refreshes the application context.

Auto-configuration is conditional bean registration. Spring Boot loads candidate configuration classes listed in:

• META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (Boot 3.x)
• Older Boot 2.x used spring.factories

Each auto-config class uses @ConditionalOn* annotations, for example:

Example flow for JPA:

1. Classpath has spring-boot-starter-data-jpa and a JDBC driver.
2. DataSourceAutoConfiguration creates a DataSource if you did not define one.
3. HibernateJpaAutoConfiguration sets up EntityManagerFactory when JPA is on the classpath.

You override by defining your own @Bean or setting properties (spring.datasource.url, etc.). In interviews, mention you can inspect what applied via the conditions report (/actuator/conditions when exposed).

A strong answer is:

Auto-configuration registers beans only when classpath and properties match, and backs off when I define my own bean—so defaults are safe to start with but fully overridable.

Starters are dependency bundles that pull in libraries plus matching auto-configuration. They keep your pom.xml or build.gradle readable.

Starters are not magic—they are curated Maven coordinates. Custom starters follow the same pattern for internal platforms.

Interview tip: connect starters to the Spring Boot BOM imported by spring-boot-starter-parent or spring-boot-dependencies so versions stay aligned—see Maven interview questions.

A strong answer is:

Starters group dependencies that work together and trigger the right auto-configuration, so I add one coordinate instead of juggling ten JAR versions manually.

All are stereotypes of @Component—they mark classes for component scanning and register them as Spring beans.

Layering interviewers expect:

@RestController → @Service → @Repository / JpaRepository

Keep controllers thin—validation and HTTP mapping only; business rules in services.

A strong answer is:

Stereotypes are all discoverable beans; the names document layer intent, and @Repository adds persistence exception translation while @RestController is the REST entry point.

Spring creates objects (beans) and wires dependencies through the container.

Common injection styles:

@Autowired resolves by type; use @Qualifier when multiple beans share a type.

Scopes matter in experienced loops:

Circular dependencies: constructor injection between two singletons fails at startup—fix by redesigning boundaries or using @Lazy sparingly.

A strong answer is:

I use constructor injection so dependencies are explicit and required at startup; Spring resolves beans from the context by type and honors scope and qualifier metadata.

Use @Configuration classes when you need programmatic bean setup—third-party classes you cannot annotate, conditional beans, or complex factory logic.

@Configuration
public class JacksonConfig {

    @Bean
    @ConditionalOnProperty(name = "app.json.pretty", havingValue = "true")
    ObjectMapper objectMapper() {
        return JsonMapper.builder()
            .enable(SerializationFeature.INDENT_OUTPUT)
            .build();
    }
}

@Configuration classes are proxied so @Bean methods stay singleton-safe when they call each other.

A strong answer is:

I put my own business types on @Service/@Repository, and use @Configuration + @Bean when I integrate libraries or need conditional factory methods the framework cannot guess.

Both feed the same Environment abstraction. Spring Boot loads, in order of precedence (higher wins):

1. Command-line args
2. SPRING_APPLICATION_JSON
3. Servlet config / JNDI (legacy)
4. OS environment variables
5. application-{profile}.properties|yml
6. application.properties|yml

Example profile file: application-prod.yml activated with spring.profiles.active=prod.

Relaxed binding maps spring.datasource.url ↔ SPRING_DATASOURCE_URL in environment variables—important for Kubernetes and cloud deployment interviews.

A strong answer is:

I pick YAML when configuration is nested and repeated prefixes would clutter properties; either way I keep secrets out of git and override with environment-specific files or env vars in production.

Profiles label beans and configuration for environments—dev, test, staging, prod.

Ways to activate:

spring.profiles.active=dev,local

Or @Profile("dev") on a @Configuration or @Bean:

@Configuration
@Profile("dev")
public class DevDataSourceConfig { /* in-memory H2 */ }

Avoid profile explosion—prefer externalized config (URLs, feature flags) over duplicating entire @Configuration classes per environment.

A strong answer is:

Profiles switch which beans and property files load per environment; I use them for environment-specific infrastructure while keeping business code identical across profiles.

Never commit secrets to git. Common patterns:

Spring Boot 2.4+ supports:

spring.config.import=optional:vault://

Operational practices interviewers like:

• Rotate credentials without redeploying code
• Least-privilege DB users per service
• No secrets in Actuator env dump exposed publicly

A strong answer is:

Secrets live in the platform secret store or environment injection, referenced by property placeholders at runtime—never hard-coded and never logged by my application.

@ConfigurationProperties(prefix = "app.pagination")
public record PaginationProps(int pageSize, int maxPageSize) {}

Enable with @EnableConfigurationProperties(PaginationProps.class) or @ConfigurationPropertiesScan.

Use @Value for one-off toggles; use @ConfigurationProperties for structured config you pass around as a bean.

A strong answer is:

I use @ConfigurationProperties for grouped, validated settings with clear prefixes, and reserve @Value for simple single-property injection.

Spring Boot 3 requires Java 17+ and migrates javax.* enterprise APIs to jakarta.* (Servlet, JPA, Validation, etc.).

Migration interview talking points:

• Update imports in entities and controllers
• Confirm third-party libs support Jakarta
• Re-run integration tests and security config

Pair with Java part 2 for records and virtual threads on modern JDKs.

A strong answer is:

Boot 3 moves the ecosystem to Jakarta namespaces and Java 17+, and adds first-class observability and native compilation paths—I plan migrations by dependency compatibility and regression tests, not search-and-replace alone.

Spring Data JPA generates repository implementations from interfaces—you declare queries by method name, @Query, or specifications.

public interface OrderRepository extends JpaRepository<Order, Long> {

    List<Order> findByStatusOrderByCreatedAtDesc(OrderStatus status);

    @Query("select o from Order o join fetch o.customer where o.id = :id")
    Optional<Order> findWithCustomer(@Param("id") Long id);
}

Under the hood: Spring Data creates a JDK proxy that delegates to EntityManager. You still need to understand JPA mapping, flush timing, and SQL—see SQL interviews for index and join depth.

A strong answer is:

Spring Data JPA removes boilerplate DAO code; I use repositories for query declaration but still own entity design, fetch strategy, and transaction boundaries in the service layer.

N+1 happens when you load N parent rows, then trigger one extra query per row for a lazy association—classic with OneToMany or ManyToOne defaults.

Symptoms:

• API looks fine in dev with little data
• Production list endpoint fires hundreds of SQL statements
• DB CPU spikes; latency grows with page size

Fixes:

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

Detect with spring.jpa.show-sql=true in dev, Hibernate statistics, or APM traces.

A strong answer is:

N+1 is lazy loading multiplied by row count; I fix it with explicit fetch joins or projections and verify with SQL logging or metrics—not by blindly switching everything to EAGER.

@Transactional defines a unit of work bound to a persistence context (for JPA) and database connection.

Common propagation values:

Rollback rules:

• Unchecked exceptions roll back by default
• Checked exceptions commit unless you set rollbackFor
• Self-invocation (this.save()) bypasses the proxy—call through another bean or refactor

@Transactional(rollbackFor = Exception.class)
public void placeOrder(PlaceOrderCommand cmd) { /* ... */ }

A strong answer is:

I put @Transactional on the service layer with explicit rollback rules, understand propagation when calling external systems, and avoid self-invocation traps that skip the transactional proxy.

Default rule: prefer LAZY; fetch intentionally in queries for each use case.

EAGER on OneToMany is a common production incident—large joins and memory pressure.

For read-heavy screens, prefer read models: DTO queries, materialized views, or CQRS-style separation instead of tuning fetch types globally.

A strong answer is:

I keep associations lazy by default and fetch exactly what each endpoint needs with join fetch or projections—never global EAGER to paper over design gaps.

Entities map to database tables and carry JPA annotations, lazy associations, and lifecycle concerns. DTOs shape what crosses the API boundary.

Reasons to separate:

Java records make immutable DTOs concise:

public class RecordDtoDemo {
    public record OrderResponse(Long id, String status, java.time.Instant createdAt) {}

    public static void main(String[] args) {
        var order = new OrderResponse(42L, "PAID", java.time.Instant.parse("2026-06-27T10:00:00Z"));
        System.out.println(order.id() + " " + order.status());
    }
}

When you click Run, you should see 42 PAID on one line—the record exposes accessors without boilerplate getters.

Map with MapStruct, manual mappers, or Spring's mapping helpers—avoid exposing JpaRepository entities directly from controllers.

A strong answer is:

Entities model persistence; DTOs model contracts—I map between them so API evolution, security, and fetch strategy stay under my control.

Flyway and Liquibase version schema changes alongside application code.

Flyway example on classpath:

src/main/resources/db/migration/V1__create_orders.sql
src/main/resources/db/migration/V2__add_order_index.sql

spring.flyway.enabled=true
spring.jpa.hibernate.ddl-auto=validate

Interview scenario: blue/green deploy with backward-compatible migrations (expand-contract pattern)—add column nullable first, deploy code, backfill, add constraint later.

A strong answer is:

I treat schema as code—Flyway migrations in the repo, ddl-auto=validate in production, and backward-compatible steps so rolling deploys never break old instances.

Use Pageable and return Page<T> or Slice<T>:

@GetMapping("/orders")
public Page<OrderResponse> list(@RequestParam(defaultValue = "0") int page,
                                @RequestParam(defaultValue = "20") int size,
                                Pageable pageable) {
    return orderService.findOrders(pageable);
}

Sort: ?sort=createdAt,desc. Cap size in validation to prevent abuse.

For very large tables, prefer keyset pagination over deep OFFSET—see SQL interviews.

A strong answer is:

I expose page and size with sensible caps, use Page when totals matter and Slice or keyset when OFFSET becomes expensive at scale.

Spring Security is a chain of servlet filters that run before your dispatcher servlet.

Simplified order:

1. Security context persistence
2. Logout / anonymous / session management
3. Authentication filters (form login, Basic, Bearer token, etc.)
4. Authorization (access rules, method security)
5. Exception translation to 401/403

In Spring Boot 3, configure with a SecurityFilterChain bean:

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

Stateless REST APIs typically disable CSRF and use token auth; session-based apps keep CSRF protection.

A strong answer is:

Requests pass through ordered security filters that authenticate credentials and enforce authorization before they reach my controller—I configure one SecurityFilterChain bean per security domain.

Typical stateless JWT flow:

Spring Boot setup:

• spring-boot-starter-oauth2-resource-server
• spring.security.oauth2.resourceserver.jwt.issuer-uri pointing to IdP metadata

Validate: clock skew, key rotation (JWKS endpoint), never log full tokens.

A strong answer is:

The client presents a Bearer JWT; Spring's resource server validates issuer and signature, maps claims to authorities, and my authorization rules run before business logic executes.

A Spring Boot API is usually a resource server. A backend-for-frontend might be both client (to downstream APIs) and resource server (to the browser).

Confuse these in interviews and you will mix up redirect URIs with JWT issuer configuration.

A strong answer is:

My REST API is a resource server that validates tokens; if it must call Google or a partner API with user consent, I add OAuth2 client support for the outbound leg.

CSRF protects cookie-based sessions from cross-site form posts. For stateless JWT in Authorization header, CSRF risk is lower because browsers do not attach custom headers cross-origin without CORS.

If you store JWT in HttpOnly cookies from a SPA, CSRF matters again—see full stack interviews for cookie vs header trade-offs.

A strong answer is:

I enable CSRF when authentication relies on session cookies; for header-based JWT APIs I disable CSRF but still enforce CORS and never move tokens into cookies without a CSRF strategy.

Enable with @EnableMethodSecurity. Annotate service or controller methods:

@PreAuthorize("hasRole('ADMIN') or #order.customerId == authentication.principal.id")
public OrderDto getOrder(Long orderId, Order order) { /* ... */ }

Spring evaluates SpEL expressions after authentication. authentication.principal is your UserDetails or JWT claims adapter.

Prefer service-layer enforcement so all entry points (REST, messaging, scheduler) share rules.

A strong answer is:

Method security applies SpEL checks on top of URL rules—I centralize authorization on services with @PreAuthorize so every caller path respects the same policy.

Keep controllers thin:

@RestController
@RequestMapping("/api/v1/orders")
@RequiredArgsConstructor
public class OrderController {
    private final OrderService orderService;

    @PostMapping
    ResponseEntity<OrderResponse> create(@Valid @RequestBody CreateOrderRequest req) {
        OrderResponse created = orderService.create(req);
        URI location = URI.create("/api/v1/orders/" + created.id());
        return ResponseEntity.created(location).body(created);
    }
}

Document with springdoc-openapi or Spring REST Docs for consumer contracts.

A strong answer is:

I model resources with clear HTTP semantics, return correct status codes and DTOs, version intentionally, and document the API so frontend and mobile teams integrate without guesswork.

Add spring-boot-starter-validation and annotate DTOs:

public record CreateOrderRequest(
    @NotNull Long customerId,
    @NotEmpty @Size(max = 50) List<@NotNull @Positive Integer> itemIds
) {}

Controller:

@PostMapping
public OrderResponse create(@Valid @RequestBody CreateOrderRequest req) { /* ... */ }

Validation runs before your method body; failures throw MethodArgumentNotValidException—handle globally (next question).

Custom constraints: @interface + ConstraintValidator for domain rules (e.g. valid SKU format).

A strong answer is:

I validate at the boundary with JSR-303 annotations on DTOs, add custom validators for domain rules, and return consistent 400 responses with field-level errors.

@ControllerAdvice centralizes exception mapping to HTTP responses:

@RestControllerAdvice
public class ApiExceptionHandler {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    ResponseEntity<ProblemDetail> handleValidation(MethodArgumentNotValidException ex) {
        ProblemDetail problem = ProblemDetail.forStatus(HttpStatus.BAD_REQUEST);
        problem.setTitle("Validation failed");
        // map field errors to problem properties
        return ResponseEntity.badRequest().body(problem);
    }

    @ExceptionHandler(OrderNotFoundException.class)
    ResponseEntity<ProblemDetail> handleNotFound(OrderNotFoundException ex) {
        return ResponseEntity.status(HttpStatus.NOT_FOUND)
            .body(ProblemDetail.forStatusAndDetail(HttpStatus.NOT_FOUND, ex.getMessage()));
    }
}

Prefer RFC 7807 Problem Details (ProblemDetail in Spring 6) over ad-hoc JSON error shapes.

Never leak stack traces to clients in production; log server-side with correlation IDs.

A strong answer is:

@ControllerAdvice maps domain and validation exceptions to stable Problem Details responses while full diagnostics go to structured logs.

Use domain exceptions mapped in @ControllerAdvice so controllers stay clean.

A strong answer is:

I map business outcomes to intentional status codes—404 for missing entities, 409 for conflicts, 400 for bad input—and reserve 500 for truly unexpected exceptions we alert on.

Spring example for partial update:

@PatchMapping("/{id}")
public OrderResponse patch(@PathVariable Long id,
                           @RequestBody Map<String, Object> updates) {
    return orderService.applyPatch(id, updates);
}

Production services often use explicit patch DTOs instead of open maps—type safety and validation.

Concurrency: use ETags or version columns (@Version) to prevent lost updates—return 409 on conflict.

A strong answer is:

PUT replaces the whole resource; PATCH applies a controlled partial update with validation and optimistic locking when multiple clients edit the same row.

Rule: test narrow by default, widen when integration risk appears.

@SpringBootTest(webEnvironment = RANDOM_PORT) + TestRestTemplate or WebTestClient for full HTTP stack.

A strong answer is:

I use slice tests for fast feedback on controllers and repositories, and a small set of @SpringBootTest or Testcontainers tests to prove the wiring that slices mock away.

@WebMvcTest (example):

@WebMvcTest(OrderController.class)
@Import(OrderService.class) // or @MockBean OrderService
class OrderControllerTest {

    @Autowired MockMvc mockMvc;
    @MockBean OrderRepository orderRepository;

    @Test
    void returns404WhenMissing() throws Exception {
        when(orderRepository.findById(1L)).thenReturn(Optional.empty());
        mockMvc.perform(get("/api/v1/orders/1"))
            .andExpect(status().isNotFound());
    }
}

Only MVC infrastructure starts—no full database.

@DataJpaTest:

@DataJpaTest
class OrderRepositoryTest {
    @Autowired OrderRepository orders;
    @Autowired TestEntityManager em;

    @Test
    void findsByStatus() { /* persist + query */ }
}

Uses @Transactional rollback by default; add Testcontainers for dialect-specific SQL.

A strong answer is:

@WebMvcTest exercises HTTP contracts with mocked collaborators; @DataJpaTest proves queries against a real persistence context without booting the entire application.

Testcontainers spins real PostgreSQL, Kafka, Redis, etc. in Docker during tests.

@SpringBootTest
@Testcontainers
class OrderApiIT {

    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:16");

    @DynamicPropertySource
    static void registerProps(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
        registry.add("spring.datasource.username", postgres::getUsername);
        registry.add("spring.datasource.password", postgres::getPassword);
    }
}

Benefits:

• Catch SQL dialect and constraint issues H2 hides
• Test Flyway migrations realistically
• Reproducible CI with Docker available

Trade-off: slower than in-memory DB—keep the suite small and tagged.

A strong answer is:

Testcontainers gives me production-like dependencies in CI—I use it for migration and integration paths that H2 cannot represent faithfully.

Actuator exposes operational endpoints over HTTP or JMX:

Secure aggressively:

management.endpoints.web.exposure.include=health,info,prometheus
management.endpoint.health.show-details=when_authorized

Custom health indicators implement HealthIndicator for downstream dependencies (DB, queue).

A strong answer is:

Actuator is how operators check health and scrape metrics—I expose the minimum endpoints, protect them with auth/network policy, and add custom health checks for critical dependencies.

Spring Boot 3 uses Micrometer Observation to correlate logs, metrics, and traces.

Practices:

management.tracing.sampling.probability=1.0

In incidents, you pivot from user report → trace ID → slow SQL span—interviewers want that workflow, not just "we use logs."

A strong answer is:

I emit structured logs and traces with shared correlation IDs so I can follow one request from gateway through controller, service, and database query during an outage.

Spring Boot supports modular monoliths and microservices equally well—the question is operational cost.

Extract a service when you need independent scaling, deployment, or team ownership—not because the monolith hit arbitrary line count.

Spring tools for microservices:

• Spring Cloud OpenFeign — declarative HTTP clients
• Spring Cloud Gateway — edge routing
• Spring Cloud Config — central configuration

See full stack monolith vs micro for product-level framing.

A strong answer is:

I start with a well-bounded Spring Boot monolith and split services only when scaling or ownership forces the operational investment—not by default.

Modern deployments often replace Eureka with Kubernetes DNS and Config Server with GitOps + sealed secrets—still know the Spring Cloud abstractions for legacy enterprise stacks.

A strong answer is:

Spring Cloud centralizes config and routing; in Kubernetes I may use native ingress and ConfigMaps instead, but the problems—dynamic endpoints and environment-specific settings—stay the same.

Resilience4j implements fault tolerance patterns:

@CircuitBreaker(name = "inventory", fallbackMethod = "fallbackStock")
public StockResponse checkStock(Long skuId) {
    return inventoryClient.getStock(skuId);
}

States: CLOSED → OPEN (after failure threshold) → HALF_OPEN (probe).

Expose metrics via Micrometer; tune thresholds from production data, not guesses.

A strong answer is:

I wrap outbound calls with circuit breakers and fallbacks so cascading failures do not take down my API, and I monitor breaker state to know when dependencies recover.

Virtual threads (Project Loom) are lightweight threads scheduled on carrier platform threads—ideal for blocking I/O heavy workloads.

Enable in Spring Boot 3.2+:

spring.threads.virtual.enabled=true

Tomcat and @Async can use virtual threads for request handling when configured.

Caveats interviewers mention:

• Pinning on synchronized blocks (improving over JDK releases)
• Thread-local assumptions in libraries
• Measure—not every app needs virtual threads on day one

Connect to Java part 2 virtual threads for JVM-level detail.

A strong answer is:

On Java 21 I enable Spring Boot virtual thread support for I/O-heavy APIs, load-test against platform-thread baselines, and watch for pinning or thread-local issues in dependencies.

Spring Native / AOT compiles apps ahead-of-time for faster startup and lower memory—useful for serverless and dense Kubernetes.

Trade-offs:

Process:

• Spring AOT generates reflection/proxy config at build time
• native-maven-plugin or Gradle native build produces executable

Not every Spring app is a native candidate—validate with benchmarks before committing.

A strong answer is:

Native images trade build complexity for startup and memory wins—I use them when cold start or footprint dominates cost, after proving our Spring features and libraries are native-compatible.

Enable with @EnableCaching. Annotate read methods:

@Cacheable(value = "orders", key = "#id")
public OrderDto findById(Long id) {
    return orderRepository.findById(id).map(mapper::toDto).orElseThrow();
}

@CacheEvict(value = "orders", key = "#id")
public void delete(Long id) { orderRepository.deleteById(id); }

Providers: Caffeine (local), Redis (distributed).

A strong answer is:

I cache expensive reads with explicit keys and TTL, evict on mutations, and choose Redis when multiple instances need a shared cache.

Structured approach interviewers want:

Tools: Actuator metrics, APM (Datadog, New Relic), Hibernate SQL log (dev only), pg_stat_statements, heap dump if GC thrash.

A strong answer is:

I start with metrics and traces to see whether latency is database, downstream HTTP, or pool exhaustion, reproduce with realistic data, fix the root cause—often N+1 or missing index—and verify with load tests before full rollout.

Checklist:

• Whiteboard one service: controller → service → repo → DB + auth filter
• Explain a transaction bug you fixed (rollback, propagation, self-invocation)
• Explain a security choice (JWT resource server, roles, method security)
• Walk through testing pyramid for that service
• Two STAR stories—production incident and performance win
• Trade-off answers: monolith vs micro, cache invalidation, optimistic locking
• Java fundamentals refresh—part 1 and part 2
• Build/deploy story—Maven/Gradle, Docker, CI, health probes

A strong answer is:

I rehearse one real Spring Boot system end to end—security, data, tests, and how we run it in production—so every answer ties to something I actually shipped, not generic framework definitions.