Q: What does @SpringBootApplication do, and how does component scanning decide what to pick up?

It's a convenience annotation that combines three: - @SpringBootConfiguration: a specialized @Configuration, so the class can declare @Bean methods - @EnableAutoConfiguration: turns on Boot's auto-configuration - @ComponentScan: scans for @Component and its stereotypes Component scanning starts from the package of the annotated class and covers all its sub-packages. That's why the main class belongs in a root package like com.acme.shop. A controller in a sibling package such as com.acme.web is silently not found, and you get a 404 or a missing-bean error. You can widen it with scanBasePackages, but restructuring packages is usually cleaner. To turn off one auto-configuration, use exclude = DataSourceAutoConfiguration.class or the spring.autoconfigure.exclude property. SpringApplication.run(...) then creates the ApplicationContext, applies auto-configuration, starts the embedded server and calls any runners.

Q: What is the difference between @Component, @Service, @Repository and @Controller?

All four mark a class as a bean for component scanning; @Service, @Repository and @Controller are themselves meta-annotated with @Component. The differences are mostly semantic, with a little behavior: - @Component: a generic bean - @Service: the business-logic layer. It adds no behavior today, but it documents intent and is a handy target for aspects - @Repository: the data-access layer. It enables exception translation, so technology-specific persistence exceptions are converted into Spring's unchecked DataAccessException hierarchy - @Controller: the web layer. Spring MVC detects it as a request handler; its methods return view names unless they're @ResponseBody Using the right stereotype makes the layering readable and lets aspects or test slices target a layer. Note that Spring Data repository interfaces don't need @Repository: Spring Data creates and registers their implementations for you.

Question 1

What is Spring Boot, and what does it add on top of the Spring Framework?

Accepted Answer

Spring Boot is an opinionated layer on top of the Spring Framework for building stand-alone, production-ready applications quickly. Spring itself gives you the IoC container, MVC, transactions and data access, but you wire and configure most of it yourself. Boot adds:

Auto-configuration: it inspects the classpath, your beans and your properties, then configures sensible defaults, like a DataSource when a JDBC driver is present
Starters: curated dependency sets such as spring-boot-starter-web, with versions managed by Boot's dependency BOM
Embedded server: Tomcat, Jetty or Netty inside an executable jar, so you just run java -jar app.jar
Externalized configuration: application.properties or YAML, profiles, environment variables
Production features through Actuator: health checks, metrics, info

Boot doesn't replace Spring; it's still Spring underneath, with the boilerplate removed and every default overridable. Spring Boot 3 requires Java 17 and moved from javax.* to the Jakarta EE jakarta.* packages.

Question 2

What are Inversion of Control and dependency injection in Spring?

Accepted Answer

Inversion of Control means your objects don't create or look up their own dependencies; the framework does. In Spring, the container (the ApplicationContext) reads configuration metadata such as annotations and @Bean methods, creates the objects, called beans, wires them together and manages their lifecycle. Dependency injection is how Spring implements IoC: a class declares what it needs through constructor parameters, setters or fields, and the container supplies matching beans. Why it matters: - Loose coupling: a service depends on an interface, not a concrete class - Testability: in a unit test you pass a mock through the constructor, no container needed - Central configuration: swapping an implementation is a config change, not a code change - Cross-cutting concerns: because Spring owns the objects, it can wrap them in proxies for transactions, security and caching BeanFactory is the basic container; ApplicationContext extends it with events, i18n, resource loading and eager creation of singletons.

Question 3

Constructor, setter or field injection: which do you use, and why?

Accepted Answer

I default to constructor injection, which is also what the Spring team recommends. Dependencies are passed in when the object is created, so: - fields can be final, making the bean immutable and safe to share between threads - the object can never exist half-built with a null dependency - it's trivially unit-testable: new OrderService(mockRepo), no reflection, no Spring - a constructor with eight parameters is a visible smell that the class does too much Since Spring 4.3, a class with a single constructor doesn't even need @Autowired. Setter injection is for genuinely optional dependencies that have a sensible default. Field injection (@Autowired on a private field) is concise but hides dependencies, rules out final, and forces tests to use reflection or a Spring context. I avoid it outside test classes. A side effect of constructor injection is that circular dependencies fail fast at startup, which is usually what you want.

Question 4

What does @SpringBootApplication do, and how does component scanning decide what to pick up?

Accepted Answer

It's a convenience annotation that combines three:

@SpringBootConfiguration: a specialized @Configuration, so the class can declare @Bean methods
@EnableAutoConfiguration: turns on Boot's auto-configuration
@ComponentScan: scans for @Component and its stereotypes

Component scanning starts from the package of the annotated class and covers all its sub-packages. That's why the main class belongs in a root package like com.acme.shop. A controller in a sibling package such as com.acme.web is silently not found, and you get a 404 or a missing-bean error.

You can widen it with scanBasePackages, but restructuring packages is usually cleaner. To turn off one auto-configuration, use exclude = DataSourceAutoConfiguration.class or the spring.autoconfigure.exclude property.

SpringApplication.run(...) then creates the ApplicationContext, applies auto-configuration, starts the embedded server and calls any runners.

Question 5

How does Spring Boot auto-configuration work under the hood?

Accepted Answer

@EnableAutoConfiguration loads the candidate auto-configuration classes listed in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports in every jar on the classpath. (Older Boot 2 versions used spring.factories for this.) Each one is an ordinary configuration class, annotated @AutoConfiguration, guarded by conditions: - @ConditionalOnClass: only if a class, for example a JDBC driver or DataSource, is on the classpath - @ConditionalOnMissingBean: only if you haven't defined that bean yourself - @ConditionalOnProperty: only if a property has a given value Auto-configurations are processed after your own bean definitions, so @ConditionalOnMissingBean lets them back off: define your own DataSource and Boot's default disappears. That's the core idea: sensible defaults that yield to explicit configuration. To see what was applied and why, start the app with --debug to print the condition evaluation report, or look at the Actuator conditions endpoint.

Question 6

What is the difference between @Component, @Service, @Repository and @Controller?

Accepted Answer

All four mark a class as a bean for component scanning; @Service, @Repository and @Controller are themselves meta-annotated with @Component. The differences are mostly semantic, with a little behavior:

@Component: a generic bean
@Service: the business-logic layer. It adds no behavior today, but it documents intent and is a handy target for aspects
@Repository: the data-access layer. It enables exception translation, so technology-specific persistence exceptions are converted into Spring's unchecked DataAccessException hierarchy
@Controller: the web layer. Spring MVC detects it as a request handler; its methods return view names unless they're @ResponseBody

Using the right stereotype makes the layering readable and lets aspects or test slices target a layer. Note that Spring Data repository interfaces don't need @Repository: Spring Data creates and registers their implementations for you.

Question 7

What is the difference between @RestController and @Controller?

Accepted Answer

@RestController is @Controller plus @ResponseBody applied to every handler method. With plain @Controller, a method's return value is treated as a view name: return "orders" and a view resolver renders a template, say Thymeleaf's orders.html, with the model. That's for server-side rendered pages. With @RestController, the return value is written straight to the response body. An HttpMessageConverter serializes it, typically to JSON with Jackson, based on content negotiation with the request's Accept header. That's what you use for REST APIs. You can mix the two: a @Controller can annotate individual methods with @ResponseBody, or return a ResponseEntity, which is also written to the body. In practice I use @RestController for APIs and @Controller only when rendering HTML.

Question 8

What bean scopes does Spring support, and which is the default?

Accepted Answer

The default is singleton: one instance per bean definition per container. It isn't the GoF singleton; you can define two beans of the same class, and each context gets its own instances. - prototype: a new instance every time the bean is requested or injected. Spring creates and initializes it, then forgets it, so destruction callbacks such as @PreDestroy are not called. - Web-aware scopes: request (one per HTTP request), session (one per HTTP session), application (one per ServletContext) and websocket. Because a singleton is shared by all request threads, it should be stateless or hold only thread-safe state; a mutable field on a service is a classic concurrency bug. A common trap is injecting a prototype or request-scoped bean into a singleton: injection happens once, so you keep reusing the same instance. Fix it with ObjectProvider<T>, @Lookup method injection, or a scoped proxy.

Question 9

How does @Transactional work, and what are its default settings?

Accepted Answer

@Transactional is declarative transaction management built on AOP proxies. Spring wraps the bean in a proxy; a call through it asks the PlatformTransactionManager (for JPA, JpaTransactionManager) to start or join a transaction, invokes your method, then commits, or rolls back if the method throws. Defaults: - propagation REQUIRED: join the current transaction or start a new one - isolation DEFAULT: the database's own default level - read-write, and a timeout of the underlying system's default - rollback on RuntimeException and Error only: a checked exception commits unless you add rollbackFor = Exception.class I put it on service methods, which define the unit of work, rather than on controllers or repositories. Boot auto-configures transaction management, so @EnableTransactionManagement isn't needed. And because it's proxy-based, only calls that come in through the proxy are transactional.

Question 10

Why does @Transactional sometimes have no effect? Explain the self-invocation problem in this code.

Accepted Answer

Spring applies @Transactional through a proxy in front of the bean, and only calls that come through the proxy are intercepted. When placeAll calls this.place(...), it's an ordinary Java call on the target object, so no transaction is started even though place is annotated. Other reasons it silently does nothing: - the method is private or final, which a class-based proxy can't override (since Spring 6, protected and package-private methods work with class-based proxies) - the object isn't a Spring bean, for example it was created with new - the exception is checked, so it commits, or you swallow it inside the method - it's called from @PostConstruct, before the proxy is fully usable Fixes: move the transactional method to another bean (cleanest), inject the bean's own proxy lazily, use TransactionTemplate for programmatic control, or switch to AspectJ weaving. The same pitfall applies to @Async, @Cacheable and method security.

Question 11

What are Spring Boot starters, and how does Boot manage dependency versions?

Accepted Answer

A starter is a dependency descriptor: a mostly empty jar whose POM pulls in everything needed for one capability. spring-boot-starter-web brings Spring MVC, Jackson and embedded Tomcat; spring-boot-starter-data-jpa brings Spring Data JPA, Hibernate and the HikariCP pool; spring-boot-starter-test brings JUnit Jupiter, Mockito, AssertJ and Spring's test support. Bean Validation is its own starter, spring-boot-starter-validation.

Versions come from Boot's dependency management: the spring-boot-starter-parent POM or the spring-boot-dependencies BOM in Maven, or the Boot Gradle plugin. You declare starters without versions and get a set of library versions that were tested together; you can still override one through its version property.

Starters and auto-configuration are separate ideas: the starter puts libraries on the classpath, and auto-configuration reacts to what it finds. Official starters are named spring-boot-starter-*; a third-party one should be acme-spring-boot-starter. Boot 4 splits some starters more finely, for example spring-boot-starter-webmvc.

Question 12

When would you use @Configuration with @Bean instead of @Component, and what does proxyBeanMethods change?

Accepted Answer

@Component is for your own classes: annotate the class and scanning finds it. @Bean methods are for when you build the object yourself: third-party classes you can't annotate, objects that need construction logic, or several differently configured beans of the same type. The method's return value becomes a bean, named after the method by default. In a @Configuration class, Spring by default subclasses the class with CGLIB (full mode, proxyBeanMethods = true). If one @Bean method calls another, the call is intercepted and returns the existing singleton instead of creating a second instance. With proxyBeanMethods = false, or with @Bean methods in a plain @Component (lite mode), there's no interception: calling another @Bean method is a normal Java call that creates a new object. Lite mode avoids the CGLIB subclass, which is why Boot's own auto-configurations use it. The safe habit in any mode is to declare dependencies as method parameters rather than calling other bean methods.

Question 13

What is the difference between @PathVariable and @RequestParam, and when do you use each?

Accepted Answer

@PathVariable binds a segment of the URI template: /orders/{id} called as /orders/42 gives id = 42. @RequestParam binds a query parameter or form field: /orders?status=PAID&page=2. The REST convention: path variables identify a resource (/users/7/orders/42); request params filter, sort or paginate a collection and are often optional. Details worth knowing: - @RequestParam is required by default; a missing one gives a 400. Use required = false, Optional<T>, or defaultValue, which makes it optional implicitly. - Type conversion is automatic, and a value that can't be converted, like /orders/abc for a Long, also gives a 400. - @RequestBody is the third option: it deserializes the JSON body into an object for POST or PUT payloads. - Names are inferred from parameter names only when code is compiled with -parameters; Boot's Maven parent and Gradle plugin enable that, otherwise write @PathVariable("id").

Question 14

How do you handle exceptions globally in a Spring Boot REST API?

Accepted Answer

I use a @RestControllerAdvice class (@ControllerAdvice plus @ResponseBody) with @ExceptionHandler methods. Spring MVC routes an exception thrown by any controller to the most specific matching handler, and I turn it into a consistent error response with the right status: 404 for a not-found domain exception, 400 for validation failures, 409 for conflicts. For the body, Spring 6 supports ProblemDetail, the RFC 9457 "problem details" format, served as application/problem+json with type, title, status, detail and instance, plus any custom properties. Two useful pieces: - extend ResponseEntityExceptionHandler to get ProblemDetail responses for Spring MVC's own exceptions, or in Boot simply set spring.mvc.problemdetails.enabled=true - an @ExceptionHandler inside a controller applies only to that controller and takes precedence over the global advice I also keep a catch-all handler that logs the error and returns a generic 500 without leaking stack traces.

Question 15

What is the N+1 select problem in JPA, and how do you fix it?

Accepted Answer

You run one query to load N parent rows, then JPA fires one extra query per parent as soon as you touch a lazy association. Here, 100 orders means 101 round trips. The code looks innocent, which is why it's so common; the SQL log (spring.jpa.show-sql or Hibernate's SQL logger) gives it away.

Fixes, in the order I reach for them:

Fetch join in JPQL: select o from Order o join fetch o.items loads orders and items in one query
Entity graph: @EntityGraph(attributePaths = "items") on a repository method, the same effect without writing JPQL
Batch fetching: Hibernate's @BatchSize or hibernate.default_batch_fetch_size loads the collections for many parents with one IN query, so N+1 becomes 1 + N/batch size
DTO projections when you only need a few columns

Switching the association to EAGER is not a fix: it still issues extra queries and loads data you often don't need. Also be careful combining a collection fetch join with pagination, because Hibernate then paginates in memory.

Question 16

Walk me through the lifecycle of a Spring bean.

Accepted Answer

For a singleton, the container roughly does this:

Instantiate the bean by calling its constructor; constructor injection happens here
Populate properties: setter and field injection
Aware callbacks such as BeanNameAware and ApplicationContextAware
BeanPostProcessor.postProcessBeforeInitialization from every post-processor
Initialization: @PostConstruct, then InitializingBean.afterPropertiesSet(), then a custom init method
postProcessAfterInitialization, which is typically where AOP proxies are created, so other beans may receive a proxy rather than the raw object
The bean is in use
On context shutdown: @PreDestroy, then DisposableBean.destroy(), then a custom destroy method

Prototype beans are initialized but never get destruction callbacks.

In practice I use @PostConstruct and @PreDestroy (from jakarta.annotation in Boot 3), which the Spring docs recommend over the Spring-specific interfaces. I don't rely on transactional behavior inside @PostConstruct; an ApplicationRunner or an ApplicationReadyEvent listener is safer for startup work.

Question 17

What are Spring profiles, and how do you use them to configure different environments?

Accepted Answer

A profile is a named set of configuration and beans that's active only in some environments, like dev, test or prod.

Property files: application-prod.yml is loaded on top of application.yml when prod is active, overriding matching keys. In one multi-document YAML file, each document can use spring.config.activate.on-profile.
Beans: @Profile("dev") on a component or @Bean method registers it only for that profile; @Profile("!prod") negates.
Activation: SPRING_PROFILES_ACTIVE=prod as an environment variable, --spring.profiles.active=prod on the command line, or the property itself. With nothing active, the default profile applies.
Groups: spring.profiles.group.prod=proddb,prodmq activates several profiles at once.

You can't set spring.profiles.active inside a profile-specific document. My rule of thumb: use profiles for structural differences, like a stub client versus a real one, and inject real secrets and URLs from the environment rather than committed profile files.

Question 18

What is the difference between @Value and @ConfigurationProperties, and which do you prefer?

Accepted Answer

@Value("${app.timeout}") injects a single property into a field or parameter. It supports defaults like ${app.timeout:5s} and SpEL expressions, but keys become strings scattered through the code, there's no real validation, and relaxed binding is limited. @ConfigurationProperties(prefix = "app.payments") binds a whole tree of properties to a type-safe object, ideally an immutable record: - relaxed binding: app.payments.retry-count, retryCount and the env var APP_PAYMENTS_RETRYCOUNT all bind to the same field - conversion to Duration, DataSize, lists, maps and nested objects - validation with @Validated and Bean Validation constraints, failing fast at startup - IDE auto-completion from metadata generated by spring-boot-configuration-processor Register it with @EnableConfigurationProperties or @ConfigurationPropertiesScan; a record with a single constructor uses constructor binding automatically. I use @ConfigurationProperties for any group of related settings and keep @Value for a one-off value or when I genuinely need SpEL.

Question 19

Explain transaction propagation. How do REQUIRED, REQUIRES_NEW and NESTED differ?

Accepted Answer

Propagation decides what a transactional method does when a transaction may already be running.

REQUIRED (default): join the existing transaction, or start one. All participants share one physical transaction. If an inner method throws and marks it rollback-only, everything rolls back; if the outer method catches that exception and tries to commit anyway, Spring throws UnexpectedRollbackException.
REQUIRES_NEW: suspend the outer transaction and run in an independent one that commits or rolls back on its own. Good for an audit record that must survive a business rollback. It holds a second connection while the outer one waits, so it can exhaust the pool under load.
NESTED: one physical transaction with a savepoint; the inner part can roll back to the savepoint while the outer continues. It's meant for JDBC's DataSourceTransactionManager; JPA has no nested transactions, and JpaTransactionManager disallows them by default.

The rest: SUPPORTS joins if present, NOT_SUPPORTED suspends, MANDATORY requires an existing one and NEVER forbids one. And propagation only applies to calls through the proxy, so the inner method must live on another bean.

Question 20

How does Spring Security work in a servlet application? Describe the filter chain.

Accepted Answer

Spring Security is built on servlet filters, so it runs before a request ever reaches the DispatcherServlet. - The servlet container calls a DelegatingFilterProxy, which bridges into the Spring context and delegates to the FilterChainProxy bean. - FilterChainProxy holds one or more SecurityFilterChains, each with a request matcher. Only the first matching chain handles the request, so specific chains like /api/** must come before general ones. - Each chain is an ordered list of filters: CSRF protection, authentication filters (form login, HTTP Basic, bearer tokens), then ExceptionTranslationFilter and AuthorizationFilter near the end. - Authentication filters produce an Authentication and store it in the SecurityContextHolder, which is thread-local by default. - On a denial, ExceptionTranslationFilter sends unauthenticated users to the AuthenticationEntryPoint (a 401 or login redirect) and authenticated ones to the AccessDeniedHandler (a 403). In Spring Security 6 you configure all this by declaring SecurityFilterChain beans; WebSecurityConfigurerAdapter has been removed.

Question 21

How do Spring Data JPA repositories work, and what are derived query methods?

Accepted Answer

You declare an interface such as OrderRepository extends JpaRepository<Order, Long> and Spring Data generates the implementation at runtime: a proxy backed by SimpleJpaRepository. You get save, findById, findAll, deleteById, count, paging and sorting for free. Derived queries are parsed from the method name: findByCustomerEmailAndStatus(String email, OrderStatus status) becomes a JPQL query that joins through customer. Keywords like GreaterThan, Between, Like, In, OrderBy, First or Top3, plus existsBy, countBy and deleteBy, are supported. The name is checked when the repository is created, usually at startup, so a typo in a property name fails fast. The hierarchy: CrudRepository (returns Iterable), ListCrudRepository (returns List), PagingAndSortingRepository (adds Sort and Pageable), and JpaRepository, which combines them with JPA extras like flush, saveAllAndFlush and getReferenceById. Since Spring Data 3, PagingAndSortingRepository no longer extends CrudRepository. When a method name gets long and unreadable, I switch to @Query.

Question 22

What are the main changes in Spring Boot 3 compared with Spring Boot 2?

Accepted Answer

- Java 17 baseline and Spring Framework 6 - Jakarta EE namespace: javax.persistence, javax.servlet and javax.validation become jakarta.*. This is the biggest migration effort, because third-party libraries also need Jakarta-compatible versions - Hibernate 6 as the JPA provider - Spring Security 6: WebSecurityConfigurerAdapter is gone; you declare SecurityFilterChain beans and use authorizeHttpRequests with requestMatchers - Observability through Micrometer Observation and Micrometer Tracing, replacing Spring Cloud Sleuth - GraalVM native images and ahead-of-time processing as a supported option - ProblemDetail error responses and declarative HTTP interface clients (@HttpExchange) - auto-configurations registered in AutoConfiguration.imports instead of spring.factories - trailing-slash matching off by default, so /orders/ no longer matches /orders Later 3.x releases added @ServiceConnection for Testcontainers (3.1), virtual threads and RestClient (3.2), and structured logging plus graceful shutdown by default (3.4). For migrating, spring-boot-properties-migrator reports renamed properties at startup, and OpenRewrite recipes automate much of the javax to jakarta change.

Question 23

How do you validate request payloads in a Spring Boot REST API?

Accepted Answer

With Bean Validation (Jakarta Validation, implemented by Hibernate Validator), added through spring-boot-starter-validation. - Put constraints on the request DTO: @NotBlank, @Email, @Size, @Positive, @Past, @Pattern, and @Valid on nested objects you want validated too. - Annotate the controller parameter with @Valid (or Spring's @Validated, which also supports validation groups). On failure, Spring throws MethodArgumentNotValidException, which becomes a 400. - Constraints placed directly on @RequestParam or @PathVariable parameters, like @Min(1) int page, trigger Spring MVC's built-in method validation (Spring 6.1+), which raises HandlerMethodValidationException. - Handle both in a @RestControllerAdvice to return field-level errors, ideally as a ProblemDetail. For rules that span several fields, I write a custom constraint with @Constraint(validatedBy = ...). Rules that need the database, like "email already registered", belong in the service layer: DTO validation checks shape, the domain checks business rules.

Question 24

What is the difference between lazy and eager fetching in JPA, and what causes a LazyInitializationException?

Accepted Answer

Eager loads an association together with the entity; lazy loads it on first access, through a proxy or a persistent collection wrapper. The JPA defaults: @ManyToOne and @OneToOne are EAGER, @OneToMany and @ManyToMany are LAZY. My rule is to make everything lazy, including @ManyToOne(fetch = FetchType.LAZY), and fetch what each use case needs explicitly with a fetch join, an entity graph or a DTO projection. An eager mapping can't be switched off per query, so it loads data you don't need and causes extra queries when you load lists. LazyInitializationException happens when you touch a lazy association after the persistence context has closed, typically outside the transaction; a classic case is Jackson serializing an entity in the controller. The fixes are to load what you need inside the transactional service method, map to a DTO there, or use a fetch join. Making things EAGER or relying on open-session-in-view just hides the problem.

Question 25

What is Spring Boot Actuator, and how do you use it for health checks?

Accepted Answer

Actuator adds production-ready endpoints under /actuator: health, info, metrics, env, loggers, threaddump, prometheus (with the Micrometer Prometheus registry) and more. By default only health is exposed over HTTP; you opt in with management.endpoints.web.exposure.include.

/actuator/health aggregates the HealthIndicators Boot auto-configures for what you use, such as the database, disk space or Redis, into a status like UP or DOWN. Details are hidden by default (show-details is never); when-authorized is a sensible production setting.

For Kubernetes there are liveness and readiness groups at /actuator/health/liveness and /actuator/health/readiness. Boot 3 enables them automatically when it detects Kubernetes, or anywhere with management.endpoint.health.probes.enabled=true. Keep external systems like the database out of liveness, or a database outage restarts every pod.

You can add a custom HealthIndicator bean. Endpoints like env and heapdump are sensitive, so I expose them sparingly, secure them, or move management to its own port with management.server.port.

Question 26

Walk me through what happens when an HTTP request hits a Spring MVC application.

Accepted Answer

- The embedded server (Tomcat by default) accepts the request and runs it through the servlet filter chain: Spring Security, CORS, logging filters. - It reaches the DispatcherServlet, Spring MVC's front controller. - A HandlerMapping (RequestMappingHandlerMapping for annotated controllers) finds the controller method matching the path, HTTP method, headers and media types, along with any HandlerInterceptors, whose preHandle runs. - A HandlerAdapter invokes the method. Argument resolvers fill in @PathVariable, @RequestParam and @RequestBody, the last through an HttpMessageConverter such as Jackson, and validation runs. - The return value is handled: for @ResponseBody or ResponseEntity, a message converter writes the body; for a view name, a ViewResolver renders a template. - Interceptors' postHandle and afterCompletion run. - If anything throws, the HandlerExceptionResolvers take over, which is how @ExceptionHandler and @ControllerAdvice get invoked. The whole request is handled on one container thread, unless you use async request processing.

Question 27

What is Spring AOP, and how does it use proxies?

Accepted Answer

AOP applies cross-cutting concerns, like transactions, security, caching, logging or metrics, without putting that code in every method. An aspect combines advice, the code to run (@Before, @AfterReturning, @AfterThrowing, @After or @Around), with a pointcut saying where, such as execution(* com.acme.service..*(..)) or @annotation(com.acme.Timed). Spring AOP is proxy-based and works at runtime. When a bean matches a pointcut, the container hands out a proxy instead of the raw object: - a JDK dynamic proxy when proxying through interfaces - a CGLIB proxy, a generated subclass, when proxying the class; Spring Boot uses class-based proxies by default (spring.aop.proxy-target-class=true) The consequences: only method executions on Spring beans can be advised; calls must come through the proxy, so self-invocation isn't intercepted; and CGLIB can't override final or private methods or subclass final classes. For anything beyond that, such as advising constructors or non-Spring objects, you need full AspectJ weaving.

Question 28

What is the difference between @SpringBootTest, @WebMvcTest and @DataJpaTest?

Accepted Answer

- @SpringBootTest loads the full application context: all your beans plus auto-configuration. By default it uses a mock web environment with no real server; webEnvironment = RANDOM_PORT starts the embedded server for true end-to-end HTTP tests. The most realistic and the slowest. - @WebMvcTest(OrderController.class) is a slice: only the MVC layer, meaning controllers, @ControllerAdvice, filters, converters and JSON support, with MockMvc auto-configured. Services and repositories aren't loaded, so you replace them with @MockitoBean. Ideal for routing, validation, status codes and JSON shape. - @DataJpaTest loads only JPA: entities, repositories and a TestEntityManager. Each test is transactional and rolled back, and it swaps in an embedded database by default; @AutoConfigureTestDatabase(replace = Replace.NONE) keeps your real one, for example a Testcontainers database. Slices keep tests fast and focused. I write many unit and slice tests and fewer @SpringBootTest integration tests. Spring caches contexts between test classes with the same configuration, so needlessly varying mocks and properties slows the suite down.

Question 29

How would you secure a stateless REST API with JWTs using Spring Security?

Accepted Answer

In a stateless API every request carries a bearer token in the Authorization header and the server keeps no session. Instead of hand-writing a JWT filter, I use Spring Security's OAuth2 Resource Server support:

add spring-boot-starter-oauth2-resource-server and set spring.security.oauth2.resourceserver.jwt.issuer-uri, so Spring discovers the issuer's public keys (the JWK set)
enable oauth2ResourceServer(o -> o.jwt(...)): each request's token is checked for a valid signature, exp and nbf, and the issuer, and scope claims become SCOPE_ authorities
use SessionCreationPolicy.STATELESS and disable CSRF, since no cookies carry credentials
authorize with requestMatchers or @PreAuthorize("hasAuthority('SCOPE_orders:write')")

Design points: keep access tokens short-lived with refresh tokens, because a JWT can't easily be revoked before it expires. Don't put secrets in the payload; it's encoded, not encrypted. Prefer asymmetric signatures so services only hold the public key. And let a dedicated authorization server, such as Keycloak or Spring Authorization Server, issue tokens.

Question 30

What happens when two beans of the same type are candidates for injection, and how do you resolve it?

Accepted Answer

If a dependency matches more than one bean and Spring can't narrow it down, startup fails with NoUniqueBeanDefinitionException. Ways to resolve it:

@Primary on one bean makes it the default whenever there's ambiguity
@Qualifier("stripe") at the injection point picks a specific bean by qualifier or bean name, and it takes precedence over @Primary
Parameter-name fallback: if the parameter name matches a bean name, Spring uses that bean, but a rename silently breaks it
Inject them all: List<PaymentGateway>, or Map<String, PaymentGateway> keyed by bean name, for strategy-style code that chooses at runtime

I use @Primary for "the normal implementation plus a special case", @Qualifier (often via a custom qualifier annotation) when callers must choose explicitly, and a Map of strategies when the choice depends on request data.

Question 31

What is ResponseEntity, and when would you return it instead of the body object?

Accepted Answer

ResponseEntity<T> represents the whole HTTP response: status code, headers and body. Returning a plain object from a @RestController always gives a 200 with that body (unless @ResponseStatus says otherwise); ResponseEntity lets you decide per request. Typical uses: - 201 Created with a Location header after a POST: ResponseEntity.created(uri).body(dto) - 204 No Content after a DELETE: ResponseEntity.noContent().build() - 404 for a missing resource: ResponseEntity.notFound().build(), or ResponseEntity.of(optional) - custom headers such as ETag, Cache-Control or Content-Disposition for downloads For errors I usually prefer throwing a domain exception and mapping it centrally in a @ControllerAdvice rather than building error responses in every controller. So my controllers return ResponseEntity for successful responses that aren't a plain 200, and bare DTOs otherwise.

Question 32

What is the difference between application.properties and application.yml?

Accepted Answer

Both are Boot's default configuration files, loaded from the classpath root (and config/ locations) into the same Environment; the difference is syntax.

.properties: flat key=value lines that repeat the prefix: spring.datasource.url=..., spring.datasource.username=.... Lists use indexes like app.hosts[0]=....
.yml: hierarchical, which is more readable for nested settings and lists, and one file can hold several documents separated by ---, for example one per profile.

Trade-offs: YAML is whitespace-sensitive, so a bad indent can silently move a key under the wrong parent, and YAML files can't be loaded with @PropertySource. Properties files are harder to get wrong. If both formats exist in the same location, .properties takes precedence.

Either way, environment variables and command-line arguments override the same keys, which is how you change settings per deployment without rebuilding.

Question 33

When do you use @Query in Spring Data JPA, and what does @Modifying do?

Accepted Answer

@Query lets you write the query yourself when a derived method name would be unreadable, or when you need joins, aggregates, a fetch join or a DTO projection. It takes JPQL by default, written against entity and field names rather than tables, or native SQL with nativeQuery = true for database-specific features. JPQL here is checked at startup; native SQL isn't. Bind values with named parameters (:status plus @Param) or positional ones (?1); never concatenate user input into the string. For bulk updates and deletes add @Modifying. Two things to know: - the query needs a transaction, either the caller's or @Transactional on the method, because declared queries get no transaction configuration of their own - a bulk JPQL statement goes straight to the database and bypasses the persistence context, so managed entities already loaded are now stale. @Modifying(clearAutomatically = true) clears the context afterwards, and flushAutomatically = true flushes pending changes first.

Question 34

How do you implement pagination and sorting with Spring Data, and what is the difference between Page and Slice?

Accepted Answer

Add a Pageable parameter to a repository method, like Page findByStatus(OrderStatus status, Pageable pageable), and Spring Data applies the limit, offset and sort. Build one with PageRequest.of(0, 20, Sort.by("createdAt").descending()). In a controller, Spring Data's web support resolves a Pageable parameter straight from ?page=0&size=20&sort=createdAt,desc; page numbers are zero-based. - Page runs an extra count query, so it knows the total number of elements and pages. Useful for "page 3 of 12" UIs, but the count can be expensive on large tables. - Slice skips the count; it fetches one extra row just to know whether there's a next slice. Good for "load more" and infinite scroll. - A List return type with a Pageable just applies the limit, with no metadata. Offset pagination slows down on deep pages, because the database still walks the skipped rows, and it can skip or repeat rows when data changes. For large or fast-moving tables I prefer keyset pagination, where id > :lastId order by id, which recent Spring Data versions support through the Window and ScrollPosition scrolling API.

Question 35

Why shouldn't you expose JPA entities directly from REST controllers, and how do you use DTOs instead?

Accepted Answer

Returning entities couples your API contract to your database schema, and causes practical problems: - Lazy loading: Jackson touches lazy associations while serializing, which throws LazyInitializationException or fires surprise queries - Infinite recursion with bidirectional relationships: order, items, order, items... - Over-exposure: internal fields such as password hashes or audit columns leak unless you remember to hide each one - Mass assignment: binding a request body onto an entity lets a client set fields like role or id - every schema refactor becomes a breaking API change So I use DTOs, usually Java records, with separate request and response types per use case and validation annotations on the request types. Mapping happens in the service layer, inside the transaction, by hand for small cases or with a mapper like MapStruct for larger ones. For read-heavy endpoints, Spring Data projections (interface projections, or records populated by a JPQL constructor expression) fetch only the columns you need. The cost is some mapping code; the payoff is an API that can evolve independently of the schema.

Question 36

What is a circular dependency in Spring, and how do you fix one?

Accepted Answer

It's when bean A needs B and B needs A, directly or through a longer chain. With constructor injection neither can be created first, so startup fails with BeanCurrentlyInCreationException, and Boot's failure analyzer prints the cycle.

Spring can technically resolve a cycle between singletons that use setter or field injection, by handing one bean an early reference to the other before it's fully initialized. But since Spring Boot 2.6, circular references are prohibited by default, so those fail too unless you set spring.main.allow-circular-references=true, which should be a last resort.

A cycle usually signals a design problem, so the real fixes are:

extract the shared logic into a third bean that both depend on
decouple with an interface or with application events (ApplicationEventPublisher plus @EventListener)
merge the two classes if they're really one responsibility

As a stopgap, @Lazy on one injection point injects a lazy proxy, which breaks the cycle at startup without changing the design.

Question 37

What is the difference between a servlet Filter and a Spring HandlerInterceptor?

Accepted Answer

A servlet Filter belongs to the Servlet API and wraps the whole request before it reaches the DispatcherServlet. It sees every request, including static resources and error dispatches, can wrap or replace the request and response, and knows nothing about which controller will run. Spring Security, CORS, request logging and compression live here. In Boot, a Filter bean is registered automatically; use FilterRegistrationBean to control URL patterns and order, and extend OncePerRequestFilter so it runs once per request. A HandlerInterceptor is Spring MVC's hook and runs inside the DispatcherServlet, after the handler has been chosen: - preHandle: before the controller; returning false stops processing - postHandle: after the controller, before view rendering; of limited use with @ResponseBody, since the response is already written by then - afterCompletion: after everything, even on exceptions; good for cleanup and timing Because it knows the HandlerMethod, an interceptor can read the controller's annotations. Register it through WebMvcConfigurer.addInterceptors. Rule of thumb: generic HTTP concerns go in filters, MVC-aware ones in interceptors.

Question 38

How does Spring Boot run with an embedded server, and how would you change or configure it?

Accepted Answer

With the web starter, Boot puts Tomcat on the classpath and starts it programmatically inside your application, instead of you deploying a WAR into an external server. The Boot build plugin packages an executable "fat" jar containing your code, its dependencies and the server, so you run it with java -jar app.jar, which suits containers well. - Configure it with properties: server.port (0 picks a random free port), server.servlet.context-path, server.ssl.*, compression, and Tomcat thread and connection limits under server.tomcat.*. - To switch to Jetty, exclude spring-boot-starter-tomcat and add spring-boot-starter-jetty. WebFlux apps use Reactor Netty by default. Undertow was an option in Boot 3 but was dropped in Boot 4. - For programmatic tweaks, register a WebServerFactoryCustomizer bean. - You can still build a WAR for an external container by extending SpringBootServletInitializer. On Java 21 with Boot 3.2 or later, spring.threads.virtual.enabled=true makes Tomcat handle requests on virtual threads.

Question 39

What is the difference between authentication and authorization in Spring Security?

Accepted Answer

Authentication answers "who are you?"; authorization answers "are you allowed to do this?". In Spring Security, authentication filters extract credentials, such as a username and password, a bearer token or a session, and hand them to the AuthenticationManager. Usually a ProviderManager delegates to AuthenticationProviders; for passwords, DaoAuthenticationProvider loads the user through your UserDetailsService and checks the password with the PasswordEncoder. The resulting Authentication, holding the principal and its GrantedAuthoritys, is stored in the SecurityContextHolder. Authorization then uses those authorities: URL rules in authorizeHttpRequests, or method security such as @PreAuthorize("hasRole('ADMIN')"). Note that hasRole('ADMIN') checks for the authority ROLE_ADMIN, while hasAuthority matches the exact string. The HTTP status codes map onto the two: 401 Unauthorized really means "not authenticated", and 403 Forbidden means authenticated but not permitted.

Question 40

How should passwords be stored in a Spring Security application?

Accepted Answer

Never in plain text, and never with a fast hash like MD5 or plain SHA-256. Use an adaptive, salted one-way function through a PasswordEncoder: bcrypt, scrypt, Argon2 or PBKDF2. They're deliberately slow and tunable, and each hash includes a random salt, so identical passwords produce different hashes.

The usual setup is the DelegatingPasswordEncoder from PasswordEncoderFactories.createDelegatingPasswordEncoder(). It stores hashes with an id prefix, like {bcrypt}$2a$10$..., encodes new passwords with bcrypt, and can still verify the other supported formats. That makes migrating algorithms possible: verify with the old one, then re-encode with the new one on the next successful login.

Rules: call encode when a user registers, matches(raw, stored) when checking, and never compare hashes yourself. Tune the work factor so a verification takes a noticeable amount of time on your hardware (Spring's docs suggest around one second), balanced against login throughput. NoOpPasswordEncoder and {noop} are for demos only.

Question 41

Which HTTP clients does Spring offer for calling other services, and which would you choose today?

Accepted Answer

- RestTemplate: the classic synchronous, template-style client. Still common, but in maintenance mode; RestClient is its modern replacement. - WebClient: the reactive, non-blocking client from WebFlux, returning Mono and Flux. The right choice in a WebFlux app or for streaming. It works from MVC too, but calling .block() everywhere defeats the point. - RestClient (Spring Framework 6.1, Boot 3.2+): a synchronous client with a fluent API similar to WebClient, built on the same infrastructure as RestTemplate. My default in a blocking MVC service. - HTTP interface clients: you declare a Java interface with @GetExchange or @PostExchange methods, and Spring generates the implementation on top of RestClient or WebClient, a built-in alternative to OpenFeign. Whichever I use, I build it from the Boot-provided builder, like the auto-configured RestClient.Builder, so message converters and observability are applied. And I always set connect and read timeouts, because an unbounded call to a slow dependency is how thread pools get exhausted.

Question 42

What is CSRF, how does Spring Security protect against it, and when is it safe to disable?

Accepted Answer

Cross-Site Request Forgery tricks a logged-in user's browser into sending a state-changing request to your site from a malicious page. The browser attaches the session cookie automatically, so without protection the server can't tell the forged request from a real one. Spring Security enables CSRF protection by default for unsafe methods (POST, PUT, PATCH, DELETE). It requires a secret CSRF token, which a cross-site page can't read, in a form field or header, and compares it with the copy stored server-side, in the HTTP session by default. Since Spring Security 6 the token is randomized on each request to mitigate BREACH attacks. For single-page apps, CookieCsrfTokenRepository puts the token in a cookie the frontend reads and echoes back as a header. It's reasonable to disable it for a stateless API authenticated only by a bearer token in the Authorization header, because browsers don't attach that automatically. If the API authenticates with cookies, including a JWT stored in a cookie, keep CSRF on. SameSite cookies help, but as defense in depth, not a replacement.

Question 43

How does caching with @Cacheable work in Spring Boot, and what pitfalls should you watch for?

Accepted Answer

Enable it with @EnableCaching on a configuration class. Boot then auto-configures a CacheManager for the provider it finds, such as Caffeine, Redis, Hazelcast or JCache, falling back to a simple ConcurrentHashMap that isn't meant for production. - @Cacheable: on a hit, returns the cached value without calling the method; on a miss, calls it and stores the result - @CachePut: always runs the method and updates the entry - @CacheEvict: removes an entry, or everything with allEntries = true The default key comes from the parameters: none gives SimpleKey.EMPTY, one gives that value, several give a SimpleKey of all of them. Customize with SpEL (key = "#id"), and use condition or unless to control what's cached. Pitfalls: - it's proxy-based, so self-invocation skips the cache - keys need correct equals and hashCode - local caches aren't shared between instances and go stale; set TTLs and size limits, or use Redis - concurrent misses can stampede the backend; sync = true lets only one thread compute the value

Question 44

How does @Async work in Spring, and what are its common pitfalls?

Accepted Answer

@Async makes a method run on another thread: the caller returns immediately and the work is submitted to a TaskExecutor. Enable it with @EnableAsync. Boot auto-configures an executor named applicationTaskExecutor, a ThreadPoolTaskExecutor by default or a virtual-thread executor when spring.threads.virtual.enabled=true; tune the pool with spring.task.execution.pool.*. Return void for fire-and-forget, or CompletableFuture<T> so callers can compose or wait on the result. Pitfalls: - it's proxy-based: a self-invoked @Async method simply runs synchronously - exceptions from void methods never reach the caller; they go to an AsyncUncaughtExceptionHandler, which by default just logs them - the new thread doesn't inherit the caller's transaction, and thread-local context like the SecurityContext or logging MDC isn't propagated unless you configure it, for example with a TaskDecorator - the default pool's queue is unbounded, so a burst of work piles up in memory; set a queue capacity and rejection policy for heavy use For background work that must survive a restart, I'd use a message queue instead.

Question 45

How do you run scheduled tasks in Spring Boot with @Scheduled?

Accepted Answer

Add @EnableScheduling to a configuration class, then annotate a no-argument bean method: - fixedRate: run every N milliseconds, measured from the start of the previous run - fixedDelay: wait N milliseconds after the previous run finishes - initialDelay: wait before the first run - cron: Spring's cron format has six fields, starting with seconds, so 0 0 2 * * * means 2 AM every day; add zone to pin the time zone Values can come from properties, for example cron = "${jobs.cleanup.cron}". Gotchas: Boot's default scheduler has a single thread, so one slow job delays the others; raise spring.task.scheduling.pool.size if needed. An exception in a repeating task is logged and the schedule carries on. Most importantly, in a multi-instance deployment every instance runs the job. For exactly-one-node semantics, use a distributed lock (ShedLock is a popular library), a Kubernetes CronJob, or a clustered scheduler like Quartz.

Question 46

Spring MVC or Spring WebFlux: how do they differ, and when would you choose WebFlux?

Accepted Answer

Spring MVC is built on the Servlet API with a thread-per-request model: each request holds a pool thread for its whole duration, including while it blocks on the database or a remote call. It's simple to write, debug and profile, and it works with the whole blocking ecosystem: JDBC, JPA and most client libraries. Spring WebFlux is non-blocking and built on Project Reactor. A small, fixed number of event-loop threads (on Reactor Netty by default) serve many concurrent requests, because no thread waits on I/O. You return Mono and Flux, and you get back-pressure and streaming. The catch: every layer must be non-blocking, such as R2DBC instead of JDBC and WebClient instead of blocking clients. One blocking call on an event-loop thread stalls every request that thread serves. I'd pick WebFlux for high-concurrency, I/O-bound services like gateways, streaming, or fan-out to many slow backends. For a typical CRUD service on a relational database, MVC is the better fit, and on Java 21 virtual threads give MVC much of the scalability with a blocking style.

Question 47

How do you test a controller with MockMvc and mock its dependencies?

Accepted Answer

With @WebMvcTest(OrderController.class), Spring loads only the web layer and auto-configures MockMvc, which drives the real Spring MVC pipeline (routing, argument binding, validation, message conversion, exception handlers) without starting a server. Anything the controller depends on must be supplied, usually as a mock declared with @MockitoBean, which replaces or adds that bean in the test context. @MockitoBean and @MockitoSpyBean come from Spring Framework 6.2. Boot's older @MockBean and @SpyBean were deprecated in Boot 3.4 and removed in Boot 4. Then you stub with Mockito, perform a request, and assert on the status, headers and JSON with jsonPath. With a full @SpringBootTest you add @AutoConfigureMockMvc to get a MockMvc; for a real HTTP round trip, use RANDOM_PORT with an HTTP client instead. Recent versions also offer MockMvcTester for AssertJ-style assertions.

Question 48

How do you write integration tests against a real database with Testcontainers in Spring Boot?

Accepted Answer

Testcontainers starts real services, like PostgreSQL, Kafka or Redis, in throwaway Docker containers from your JUnit tests, so you test against the same engine as production instead of H2, which differs in SQL dialect, types and locking behavior.

The setup:

@Testcontainers on the class and a static @Container field, so the container starts once for the class
@ServiceConnection (Boot 3.1+) on that field: Boot takes the host, port and credentials from the running container and creates the connection details, so the DataSource points at it with no properties at all
before 3.1, or for extra settings, @DynamicPropertySource registers properties such as spring.datasource.url from the container
with @DataJpaTest, add @AutoConfigureTestDatabase(replace = Replace.NONE) so Boot doesn't swap in an embedded database

To keep the suite fast, share containers across test classes, for example through a common base class or @ImportTestcontainers, so Spring's context cache keeps working. Boot can also reuse the same container definitions at development time.

Question 49

What are the JPA entity lifecycle states, and what is the difference between persist and merge?

Accepted Answer

An entity is in one of four states relative to a persistence context:

New (transient): just created with new, unknown to JPA, no row yet
Managed: attached to the persistence context, after persist, find or a query. Changes are tracked by dirty checking and flushed automatically at commit, with no save call needed
Detached: it was managed, but the context closed (the transaction ended) or it was cleared or evicted; changes are no longer tracked
Removed: scheduled for deletion by remove, deleted at flush

persist(entity) makes a new instance managed; the object you passed is the managed one. merge(entity) copies the state of a detached or new object onto a managed instance and returns that copy; the argument itself stays detached, which is a classic bug when code keeps using it.

Spring Data's save() calls persist if the entity looks new (a null id or null version, or Persistable.isNew()) and merge otherwise, and returns the managed instance, so always use the return value. Inside a transaction, an already-managed entity doesn't need save() at all.

Question 50

In what order does Spring Boot resolve configuration properties from different sources?

Accepted Answer

Boot builds the Environment from many property sources, and later sources override earlier ones. From lowest to highest precedence, the main ones are: - default properties set on SpringApplication - @PropertySource on configuration classes - config data files: application.properties and application.yml - OS environment variables - Java system properties (-Dkey=value) - SPRING_APPLICATION_JSON - command-line arguments such as --server.port=9090 - test sources such as @SpringBootTest(properties = ...), @DynamicPropertySource and @TestPropertySource, at the very top Among config files, profile-specific files beat plain ones, and files outside the jar (the current directory or ./config/) beat those packaged inside. So a config/application-prod.yml next to the jar overrides the packaged defaults. @PropertySource sits near the bottom and is added too late to affect early settings like logging.*. Environment variables map through relaxed binding: SPRING_DATASOURCE_URL sets spring.datasource.url.

Spring Boot interview questions & answers

Top 63 Spring Boot interview questions most asked first