Spring Boot Interview Questions

A curated set of Spring Boot interview questions, focused on what Boot adds on top of the core Spring Framework.

Q: How does Spring Boot's auto-configuration mechanism actually work?#

At startup, @EnableAutoConfiguration triggers Spring Boot to evaluate a large set of @Configuration classes bundled in its auto-configure JARs, each guarded by conditional annotations like @ConditionalOnClass (is a particular library on the classpath?), @ConditionalOnMissingBean (has the developer already defined this bean themselves?), and @ConditionalOnProperty (is a specific property set?). Only the configurations whose conditions are satisfied actually register beans — for example, DataSourceAutoConfiguration only activates if a JDBC driver and DataSource-related properties are present. Any bean you define yourself takes precedence over the auto-configured equivalent, because most auto-configuration is conditioned on that bean not already existing.

Q: What are Spring Boot starters, and why do they matter?#

A starter is a dependency descriptor with no code of its own — just a curated set of transitive dependencies known to work together at compatible versions, managed centrally by the Spring Boot BOM (bill of materials). spring-boot-starter-web pulls in Spring MVC, an embedded Tomcat, and Jackson in one step, instead of the developer hunting down and version-matching each library individually. This removes an entire category of "works locally, breaks in CI because of a library version mismatch" problems.

Q: What three annotations does @SpringBootApplication compose, and what does each do?#

It composes @SpringBootConfiguration (marks the class as a Spring @Configuration class), @EnableAutoConfiguration (activates Spring Boot's auto-configuration mechanism), and @ComponentScan (scans the annotated class's package and sub-packages for stereotype-annotated beans). Together they mean a single annotation on the main class is enough to bootstrap the entire application — which is also why that main class is conventionally placed at the application's root package, so component scanning covers everything beneath it.

Q: What's the difference between using an embedded server and deploying to an external servlet container?#

With an embedded server (Tomcat, Jetty, or Undertow, bundled by the relevant starter), the application packages the server inside its own executable JAR — java -jar app.jar is a complete, self-contained running application, with nothing else to install on the host. Deploying to an external container instead means building a WAR file and installing it into a separately managed Tomcat/JBoss instance, where the container's version and configuration are managed independently of the application. Spring Boot defaults to the embedded model because it makes each application self-contained and trivially deployable as a single artifact — the standard fit for containerized deployments (Docker, Kubernetes) — while still supporting the WAR/external-container model for organizations that require it.

Q: Why would you add Spring Boot Actuator to a production service?#

Actuator exposes ready-made operational endpoints — /actuator/health for liveness/readiness checks that a load balancer or orchestrator can poll, and /actuator/metrics for request latency, JVM memory, and other runtime metrics — without writing any of that plumbing by hand. In production, this is how an orchestrator knows to stop routing traffic to (or restart) an unhealthy instance, and how metrics dashboards and alerting get populated automatically rather than through custom instrumentation.

Q: What's the difference between @WebMvcTest, @DataJpaTest, and @SpringBootTest?#

@WebMvcTest loads only the web layer — controllers, @ControllerAdvice, and related infrastructure — leaving service/repository beans to be supplied as @MockBeans, and is used with MockMvc to simulate HTTP requests without a real server. @DataJpaTest loads only JPA-related beans and swaps in an embedded test database by default, wrapping each test in a transaction that's rolled back automatically, and is used to verify repository queries against a real (if embedded) database. @SpringBootTest loads the entire application context exactly as production would, which is the most realistic but also the slowest option, reserved for genuine end-to-end tests or verifying that multiple layers are wired together correctly.

Q: Why are Spring Boot executable JARs organized into layers, and how does that help with Docker?#

A Spring Boot fat JAR is internally split into layers — dependencies, spring-boot-loader, snapshot-dependencies, and application — ordered from least to most frequently changing. A multi-stage Dockerfile can extract these layers and COPY each one as its own Docker image layer; since Docker caches and reuses layers whose inputs haven't changed, an ordinary code change only invalidates the small application layer, while the much larger dependencies layer is reused straight from cache. Without this layering, a naive Dockerfile that copies the whole fat JAR as one layer re-uploads every dependency on every single code change.

Q: How would you secure Actuator endpoints in a production deployment?#

Two complementary approaches are typical: running management endpoints on a separate port (management.server.port) so they're only reachable from an internal network rather than alongside the public API, and explicitly authorizing actuator paths in the SecurityFilterChain (e.g. requiring an OPS role for /actuator/** beyond the public /health//info). Highly sensitive endpoints like /actuator/env and /actuator/heapdump can leak secrets or memory contents and should never be left open with management.endpoints.web.exposure.include: "*" on an internet-facing service.

Q: What is Micrometer, and how does it relate to /actuator/metrics?#

Micrometer is Spring Boot's vendor-neutral metrics facade — application code (and Spring Boot's own auto-instrumentation) records counters, timers, and gauges against Micrometer's API, and Micrometer's registries translate that into whatever monitoring backend is configured (Prometheus, Datadog, and others). /actuator/metrics is Actuator's own HTTP view onto this same data, letting you inspect a specific metric (like http.server.requests) directly, though in practice it's far more commonly scraped on an interval by a monitoring system than queried by hand.