Spring Boot powers most modern Java backends, so it dominates Java interviews. This guide collects 40 Spring Boot interview questions with detailed, code-backed answers — the kind a strong senior engineer would actually give. The questions are grouped by theme (auto-configuration, starters, Actuator, profiles & config, the embedded server, testing, and Spring Boot 3 / Jakarta) and roughly ordered from junior fundamentals to senior depth.
Everything here is written for 2026: Spring Boot 3.x on Spring Framework 6, the jakarta.* namespace, Java 17+ baselines, and the modern testing slices. Where the difference between Boot 2 and Boot 3 matters in an interview, we call it out explicitly.
Read the answers, then prove you actually know them. Don't just memorize — go drill the same concepts interactively in our free practice questions and you'll retain far more than from passive reading.
How to use these questions
Work top to bottom. The early auto-configuration and starter questions are junior-friendly warm-ups; the later sections (testing, Boot 3 / Jakarta) are where senior candidates separate themselves. For each question, try to answer out loud before reading our answer — interviews are verbal, so practice verbalizing.
When a question clicks, lock it in with a quick interactive rep on /practice (free, no signup to start). If you're also chasing the Spring Professional certification, pair this with our exam guide, which maps the same topics to the official exam weighting.
Auto-configuration Interview Questions
1. What is Spring Boot auto-configuration?
Auto-configuration is Spring Boot's mechanism for automatically configuring beans based on what it finds on the classpath, in the environment, and in existing bean definitions. If spring-boot-starter-web is present, Boot configures Tomcat, Spring MVC, a DispatcherServlet, and Jackson for you — without a line of XML or @Bean code.
It is "opinionated but overridable": Boot applies sensible defaults, and the moment you define your own bean, your definition wins. This is the single biggest reason a Spring Boot app needs so little boilerplate.
2. How does Spring Boot actually find auto-configuration classes?
In Spring Boot 3, auto-configuration classes are listed in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports — a plain text file, one fully-qualified class name per line.
com.acme.MyServiceAutoConfigurationIn an interview: mention the Boot 2 vs Boot 3 change. In Spring Boot 2.x, these classes were registered under the
org.springframework.boot.autoconfigure.EnableAutoConfigurationkey inMETA-INF/spring.factories. Boot 2.7 deprecated that approach and Boot 3 dropped it for the new.importsfile. Knowing this immediately signals you've actually worked with Boot 3.
3. What does @EnableAutoConfiguration do, and where does it come from?
@EnableAutoConfiguration tells Boot to attempt to auto-configure the application context based on the classpath and the beans you've already defined. It triggers the import of all the candidate auto-configuration classes, each guarded by conditions so only the relevant ones actually apply.
You rarely write @EnableAutoConfiguration directly because it's already inside @SpringBootApplication.
4. What three annotations does @SpringBootApplication combine?
@SpringBootApplication is a convenience meta-annotation composed of:
@SpringBootConfiguration // a specialized @Configuration
@EnableAutoConfiguration // turn on auto-configuration
@ComponentScan // scan the package of the annotated class + sub-packages
public @interface SpringBootApplication { }A common follow-up: which package does it scan? The package of the annotated class and everything below it — which is why your main class normally sits in the root package of the project.
5. How do the @ConditionalOn... annotations drive auto-configuration?
Auto-configuration classes use @Conditional annotations so a bean is only created when it makes sense. The ones worth knowing cold:
@ConditionalOnClass/@ConditionalOnMissingClass— based on a class being (or not being) on the classpath.@ConditionalOnBean/@ConditionalOnMissingBean— based on an existing bean.@ConditionalOnMissingBeanis the key to "user-defined beans override Boot's defaults."@ConditionalOnProperty— based on a configuration property's value.@ConditionalOnWebApplication/@ConditionalOnMissingWebApplication.
@Bean
@ConditionalOnMissingBean
public ObjectMapper objectMapper() {
return new ObjectMapper(); // only created if you didn't define your own
}We go deeper on this mechanism in our auto-configuration explainer.
6. How do you exclude or disable a specific auto-configuration class?
The cleanest way is the exclude attribute on @SpringBootApplication (or @EnableAutoConfiguration):
@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })
public class MyApp { }You can also exclude by class name with excludeName, or set the spring.autoconfigure.exclude property. Classic use case: you pulled in a JDBC starter transitively but you don't want Boot trying to configure a DataSource.
7. How would you write your own auto-configuration for a shared library?
Create an @AutoConfiguration class (use @AutoConfiguration in Boot 3, not plain @Configuration), guard your beans with @ConditionalOn..., and register the class in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports.
@AutoConfiguration
@ConditionalOnClass(GreetingService.class)
public class GreetingAutoConfiguration {
@Bean
@ConditionalOnMissingBean
public GreetingService greetingService() {
return new DefaultGreetingService();
}
}In an interview: stress
@ConditionalOnMissingBeanso consumers of your library can override your defaults, and@ConditionalOnClassso your config silently no-ops when the optional dependency isn't present.
8. How can you debug what auto-configuration applied (and what didn't)?
Run with --debug (or set debug=true) to print the auto-configuration report, which lists "Positive matches" and "Negative matches" with the reason each condition passed or failed. The /actuator/conditions endpoint exposes the same information at runtime. This is the answer that shows you've actually troubleshot a misbehaving Boot app.
Starters Interview Questions
9. What is a Spring Boot starter?
A starter is a curated dependency descriptor — a small POM that aggregates a coherent set of dependencies for a use case. Instead of hand-picking Spring MVC, Tomcat, Jackson, and validation and getting their versions to agree, you add one line:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>Starters reduce dependency boilerplate and, crucially, guarantee version compatibility across the libraries they bundle.
10. Why can you usually omit version numbers in a Spring Boot project?
Because spring-boot-starter-parent (or the spring-boot-dependencies BOM imported as a managed dependency) supplies a curated dependencyManagement section. It pins consistent, tested versions for hundreds of libraries, so you declare what you need, not which version.
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>3.3.0</version>
</parent>If you can't use the parent (you already have a corporate parent POM), import the BOM with <scope>import</scope> in dependencyManagement instead.
11. Name a few starters you reach for and what each adds.
spring-boot-starter-web— Spring MVC + embedded Tomcat + Jackson (REST and MVC apps).spring-boot-starter-data-jpa— Spring Data JPA + Hibernate.spring-boot-starter-security— Spring Security auto-configuration.spring-boot-starter-actuator— production-ready monitoring endpoints.spring-boot-starter-test— JUnit 5, Mockito, AssertJ, Spring Test, JSONassert.spring-boot-starter-validation— Bean Validation (nowjakarta.validation) with Hibernate Validator.
12. What does spring-boot-devtools give you and what's the catch?
spring-boot-devtools enables automatic restart when classpath files change, a LiveReload server, and sensible dev-time property defaults (e.g. disabling template caching). The restart is fast because it uses two classloaders — one for your changing code, one for stable library jars.
The catch: devtools is automatically disabled when running a fully packaged application (e.g. launched via java -jar) and is excluded from the repackaged archive, so it never ships to production.
Actuator Interview Questions
13. What is Spring Boot Actuator?
Actuator adds production-ready management and monitoring to a Boot app: HTTP (and JMX) endpoints exposing health, metrics, environment, configuration properties, loggers, mappings, thread dumps, and more — all without you writing code. Operations teams use it for health checks, and monitoring systems scrape it for metrics. Add it via spring-boot-starter-actuator.
14. Which Actuator endpoints are exposed over HTTP by default?
This is a favorite trap. Adding the starter does not expose everything. By default only /actuator/health is exposed over HTTP. (/info is also exposed in some versions but is empty unless you populate it.) All other endpoints are enabled but not exposed until you opt in:
management.endpoints.web.exposure.include=health,info,metrics,loggers
# or, never do this in prod without securing it:
management.endpoints.web.exposure.include=*Our Actuator exam guide drills the full default-exposure matrix.
15. What's the difference between an endpoint being "enabled" and "exposed"?
Enabled means the endpoint exists and its bean is created. Exposed means it's reachable over a transport (web or JMX). An endpoint can be enabled but not exposed (the default for almost everything). You control enablement with management.endpoint.<id>.enabled and exposure with management.endpoints.web.exposure.include/exclude. Mixing up these two is the most common Actuator mistake.
16. How does the /health endpoint aggregate status, and what are the statuses?
Health is computed by composing all registered HealthIndicator beans (db, disk space, ping, etc.). The out-of-the-box statuses are UP, DOWN, OUT_OF_SERVICE, and UNKNOWN. The aggregate status is the most severe one reported, and severity order is DOWN > OUT_OF_SERVICE > UP > UNKNOWN by default (customizable). DOWN and OUT_OF_SERVICE map to HTTP 503; UP maps to 200.
By default the response only shows the overall status. Set management.endpoint.health.show-details=always (or when-authorized) to see per-indicator detail.
17. How do you write a custom health indicator?
Implement HealthIndicator and return a Health object:
@Component
public class QueueHealthIndicator implements HealthIndicator {
@Override
public Health health() {
long depth = queue.depth();
if (depth > 10_000) {
return Health.down().withDetail("depth", depth).build();
}
return Health.up().withDetail("depth", depth).build();
}
}The bean name (minus the HealthIndicator suffix) becomes the key in the aggregated health JSON — here, queue.
18. What is Micrometer and how does it relate to Actuator metrics?
Micrometer is a vendor-neutral metrics facade — "SLF4J for metrics." Actuator's /metrics and /prometheus endpoints are built on it. You instrument your code once against the Micrometer API (counters, timers, gauges), and Micrometer exports to whatever backend you wire up: Prometheus, Datadog, New Relic, CloudWatch, and so on.
Timer.builder("orders.process")
.register(meterRegistry)
.record(() -> processOrder());19. How do you secure Actuator endpoints in production?
Never expose sensitive endpoints (/env, /configprops, /heapdump, /threaddump, /shutdown) openly. Typical approach: expose a minimal set, move management to a separate port (management.server.port), and protect the /actuator/** path with Spring Security. In Boot 3 that means a SecurityFilterChain bean using EndpointRequest:
@Bean
SecurityFilterChain actuatorChain(HttpSecurity http) throws Exception {
http.securityMatcher(EndpointRequest.toAnyEndpoint())
.authorizeHttpRequests(auth -> auth.anyRequest().hasRole("ADMIN"))
.httpBasic(Customizer.withDefaults());
return http.build();
}Security comes up in almost every Spring Boot interview — for a dedicated set, see our Spring Security interview questions.
Profiles & Configuration Interview Questions
20. What are Spring profiles and how do you activate one?
A profile is a named logical grouping of beans and configuration, used to vary behavior per environment (dev, test, prod). You activate profiles many ways, in increasing precedence:
# command line (highest priority of these)
java -jar app.jar --spring.profiles.active=prod
# environment variable
export SPRING_PROFILES_ACTIVE=prod
# in application.properties (lowest)
spring.profiles.active=dev@Profile("prod") on a @Component/@Bean makes it eligible only when that profile is active.
21. How do profile-specific property files work?
The convention is application-{profile}.properties (or .yml) — note the order; dev-application.properties is wrong. When the dev profile is active, application-dev.properties is loaded on top of the base application.properties, overriding overlapping keys. application-default.* is loaded only when no profile is active.
22. What is Spring Boot's externalized configuration order of precedence?
Boot reads configuration from many sources and a higher-priority source overrides a lower one. From high to low (abbreviated): command-line args → SPRING_APPLICATION_JSON → OS environment variables / system properties → profile-specific config outside the jar → config outside the jar → profile-specific config inside the jar → config inside the jar → @PropertySource → defaults.
In an interview: the headline rule is "external beats internal, profile-specific beats general, command-line beats everything." Reciting all 17 levels isn't expected; demonstrating you understand the layering is.
23. What's the difference between @Value and @ConfigurationProperties?
@Value("${server.port}") injects a single property and is fine for one-offs. @ConfigurationProperties binds a whole group of properties to a typed bean by prefix — type-safe, relaxed-binding aware, and validatable.
@ConfigurationProperties("app.mail")
public class MailProps {
private String host; // app.mail.host
private int port; // app.mail.port
// getters/setters
}Activate it with @EnableConfigurationProperties(MailProps.class) or @ConfigurationPropertiesScan. For more than two or three related properties, @ConfigurationProperties is the senior choice.
24. What is relaxed binding?
@ConfigurationProperties binding is tolerant of naming styles, so app.mailHost, app.mail-host, app.mail_host, and APP_MAILHOST (env var) all bind to the same mailHost field. This is why environment variables (kebab-case impossible there) map cleanly onto properties — essential knowledge for containerized/12-factor deployments.
25. application.properties vs application.yml — does it matter, and what's the YAML gotcha?
Both are supported and equivalent in capability; pick one for consistency. YAML is nicer for nested/hierarchical config and lists. The classic gotcha: YAML is whitespace-sensitive and can't directly express the same multi-document overrides as cleanly in every Boot version — and historically YAML wasn't supported for @PropertySource. Otherwise it's a stylistic choice.
Embedded Server Interview Questions
26. What is the embedded server and which one is the default?
Boot bundles a servlet container inside the application, so you ship a single self-contained jar and run java -jar — no external Tomcat to install. The default with spring-boot-starter-web is embedded Apache Tomcat. Spring also supports embedded Jetty and Undertow as drop-in alternatives.
27. How do you switch from Tomcat to Jetty or Undertow?
Exclude the Tomcat starter and add the one you want:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-undertow</artifactId>
</dependency>28. How do you change the server port, and what does server.port=0 do?
Set server.port in your config (or --server.port=9090 on the command line). Setting server.port=0 tells the container to bind to a random free port — handy in tests so parallel runs don't collide.
server:
port: 808129. How do you deploy a Spring Boot app as a WAR to an external container?
Three steps: set war packaging, extend SpringBootServletInitializer (overriding configure), and mark the embedded server provided so it isn't bundled.
@SpringBootApplication
public class MyApp extends SpringBootServletInitializer {
@Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder b) {
return b.sources(MyApp.class);
}
}In an interview: add that the modern default is the executable jar; traditional WAR deployment to a standalone Tomcat/WildFly is mostly legacy or platform-mandated now.
30. What ApplicationContext type does Boot create, and how does it relate to the server?
It depends on the application type. For a Spring MVC web app Boot creates an AnnotationConfigServletWebServerApplicationContext (which boots the embedded servlet container); for WebFlux it's AnnotationConfigReactiveWebServerApplicationContext; for a non-web app it's a plain AnnotationConfigApplicationContext (no server started). Boot decides the type by inspecting the classpath.
Testing Interview Questions
31. What does @SpringBootTest do?
@SpringBootTest loads the full application context for integration tests — it finds your @SpringBootApplication (or you point it at a config class) and wires every bean. It's the heavyweight option: great fidelity, slower startup. Use it when you genuinely need the whole context.
32. What does the webEnvironment attribute control?
It controls whether (and how) a web environment / embedded server is started:
| Value | Embedded server? | Use |
|---|---|---|
MOCK (default) | No | Mock servlet environment; pair with MockMvc |
RANDOM_PORT | Yes | Real server on a random port |
DEFINED_PORT | Yes | Real server on the configured server.port |
NONE | No | No web environment at all |
RANDOM_PORT and DEFINED_PORT start a real embedded server; MOCK and NONE do not. With RANDOM_PORT, inject the chosen port with @LocalServerPort.
33. What are test slices, and why prefer them over @SpringBootTest?
Slices load only the part of the context relevant to one layer, so tests start fast and stay focused:
@WebMvcTest— MVC layer only (controllers, filters,MockMvc); services are mocked.@DataJpaTest— JPA repositories + an in-memory DB by default, wrapped in a rollback transaction.@JsonTest— Jackson serialization.@RestClientTest,@WebFluxTest,@JdbcTest, etc.
Reach for a slice when you're testing one layer; reserve @SpringBootTest for true end-to-end integration.
34. How do you replace a bean with a mock in a Spring Boot test?
In Boot 3.4+, use @MockitoBean (and @MockitoSpyBean) to put a Mockito mock into the test's application context, replacing the real bean:
@WebMvcTest(OrderController.class)
class OrderControllerTest {
@Autowired MockMvc mvc;
@MockitoBean OrderService orderService;
// stub orderService, then assert on mvc.perform(...)
}In an interview: note that
@MockBean/@SpyBean(fromspring-boot-test) were the standard for years and are deprecated in favor of@MockitoBean/@MockitoSpyBeanin recent Boot. Knowing the new names signals you're current.
35. What's in spring-boot-starter-test and what is @MockMvc?
The test starter bundles JUnit 5, Spring Test, AssertJ, Hamcrest, Mockito, JSONassert, and JsonPath. MockMvc lets you exercise your MVC controllers through the full Spring MVC machinery without starting a server — fast, focused controller tests:
mvc.perform(get("/orders/1"))
.andExpect(status().isOk())
.andExpect(jsonPath("$.id").value(1));See our dedicated Spring Boot testing guide and exam guide for layered testing strategy.
36. What's the difference between CommandLineRunner and ApplicationRunner?
Both run once after the context is fully started, perfect for startup logic (seeding data, warming caches). The only difference is the argument they receive: CommandLineRunner.run(String... args) gets the raw arguments, while ApplicationRunner.run(ApplicationArguments args) gets a parsed view distinguishing option args (--name=value) from non-option args. Use @Order if you have several and ordering matters.
Spring Boot 3 & Jakarta Interview Questions
37. What are the baseline requirements and headline changes in Spring Boot 3?
Spring Boot 3 sits on Spring Framework 6 and requires Java 17 as a minimum (Java 21 is fully supported and a great default). The two changes that bite during migration: the move from javax.* to the jakarta.* namespace, and first-class support for GraalVM native images and AOT processing. It also raised baselines for Hibernate 6, Jakarta EE 9+, and tightened observability via Micrometer.
38. Why is the javax → jakarta migration the big deal in Boot 3?
Because Jakarta EE moved the specifications out of Oracle and renamed every package from javax.* to jakarta.*. So in a Boot 3 codebase you import jakarta.persistence.Entity, jakarta.servlet.http.HttpServletRequest, and jakarta.validation.constraints.NotNull — not the javax equivalents.
import jakarta.persistence.Entity; // was javax.persistence.Entity
import jakarta.validation.constraints.Email;It's a mechanical but pervasive change; any library that touches the servlet/persistence/validation APIs had to be upgraded to a Jakarta-compatible version, which is why you can't half-migrate.
39. How has Spring Security configuration changed by Boot 3?
The old WebSecurityConfigurerAdapter is gone. You now declare a SecurityFilterChain bean (component-based configuration), and the authorization DSL uses the lambda style with authorizeHttpRequests:
@Bean
SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/public/**").permitAll()
.anyRequest().authenticated())
.httpBasic(Customizer.withDefaults());
return http.build();
}Candidates who still reach for WebSecurityConfigurerAdapter reveal they haven't touched a recent version.
40. What do AOT processing and native images give you in Spring Boot 3?
Ahead-of-Time (AOT) processing analyzes your application at build time and generates configuration (bean definitions, reflection/resource hints) so less work happens at runtime. Combined with GraalVM native image compilation (spring-boot-starter-parent + the GraalVM build plugin), you can compile a Boot app to a standalone native executable with near-instant startup and a much smaller memory footprint — ideal for serverless and scale-to-zero workloads. The trade-off is longer build times and the closed-world constraints native compilation imposes (reflection must be hinted).
Frequently Asked Questions
How should I prepare for a Spring Boot interview?
Combine breadth and depth. First, make sure you can confidently answer the fundamentals in this list — auto-configuration, starters, the embedded server, profiles, Actuator, and the Boot 3 / Jakarta changes. Then go deeper on the areas your target role emphasizes (data access for backend roles, security and observability for platform roles). Crucially, practice answering out loud, because interviews are verbal. Drilling questions interactively on /practice builds the recall speed that passive reading can't, and writing a small Boot 3 app end-to-end will surface gaps faster than anything else.
Are these real interview questions?
These are questions written in the style of real Spring Boot interviews and the Spring Professional exam, with original, detailed explanations — not leaked questions, dumps, or any "guaranteed pass" material. They reflect the topics interviewers and the certification consistently test, so practicing them prepares you for the substance you'll actually face.
How many questions are on the Spring Professional exam?
The current VMware Spring Professional Develop exam has 60 questions and a 70-minute time limit, with a passing score of roughly 76%. Spring Boot is a major slice of the blueprint (around a quarter of the questions). See our exam guide for the full topic breakdown and study plan.
Is Spring Boot knowledge enough, or do I need core Spring too?
You need both. Spring Boot builds directly on core Spring — the IoC container, dependency injection, AOP, and transactions. Interviewers routinely follow a Boot question with a core-Spring "why does that work?" For the full breakdown of what Boot adds on top of the framework, see Spring vs Spring Boot. Solidify the fundamentals alongside Boot — work through our Spring framework interview questions on IoC, beans, AOP and transactions; our exam guide covers the core topics too.
You now have 40 solid Spring Boot interview questions covering the full spectrum, from junior auto-configuration basics to senior-level Boot 3, native images, and testing strategy. The best way to convert this from "I read it" to "I can answer it under pressure" is active recall — head to our free interactive practice questions and drill these concepts until they're automatic, and if certification is your goal, work through the Spring Professional exam guide next.