Spring Ecosystem Interview Prep

Spring Core interview questions test whether you understand the framework underneath Spring Boot — the IoC container, dependency injection (constructor vs setter vs field), bean lifecycles and scopes, the BeanFactory vs ApplicationContext, AOP fundamentals (proxies, advices, pointcuts), and the @Transactional internals interviewers love to probe. This page covers the conceptual layer that lets you debug a real Spring app instead of just write one. Pair this page with the Spring Boot page (auto-configuration, starters, profiles), Spring Data JPA / Hibernate, Spring Security, Spring WebFlux, and Spring Batch.

Spring Core in three layers:

1. 1
   IoC container — BeanDefinition → BeanFactory → ApplicationContext.
2. 2
   Lifecycle — instantiate → populate → aware → BPP-before → @PostConstruct → BPP-after → ready.
3. 3
   Cross-cutting — AOP proxies (JDK or CGLIB), @Transactional, events.

Senior questions probe the proxy boundary: same-bean self-invocation skips the aspect; this is where 80% of @Transactional bugs live.

The interview surface for this module breaks into these focus areas:

• Aop — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Bean lifecycle — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Custom components — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Dependency injection — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Spring events — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Spring internals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Constructor injection > setter > field — because final, fail-fast cycles, easy testing.
• `@Transactional` self-invocation doesn't go through the proxy — readiness fact.
• `@Configuration` proxyBeanMethods — true → CGLIB, inter-@Bean calls return singletons; false → faster start, no inter-call guarantee.
• Circular deps — constructor cycles fail fast; setter cycles use early references.
• `@Primary` vs `@Qualifier` — default vs explicit disambiguation.

"I'd register this as a `@Component` / `@Configuration` `@Bean`, prefer constructor injection so , and apply <`@Transactional` / `@Async` / aspect> via the proxy — knowing the proxy boundary means I'd avoid same-bean self-invocation and split the responsibility into + ."

Spring Boot interview questions are the single most asked Spring topic — auto-configuration internals, the starter system, application.properties/yml + profiles, Actuator endpoints and security, embedded servers, configuration binding, graceful shutdown, scheduled tasks, layered Docker images, and the troubleshooting questions interviewers pull from real production incidents. This page covers the questions that test whether you have actually shipped Spring Boot to production, not just used start.spring.io. For lower-level Spring concepts (IoC, AOP, transaction internals) see Spring Core; for persistence see Spring Data JPA / Hibernate.

Boot = Spring + opinionated auto-configuration + an embedded server + starter dependencies.

• @SpringBootApplication = @Configuration + @EnableAutoConfiguration + @ComponentScan.
• `spring.factories` / `AutoConfiguration.imports` — how starters register their config.
• `@ConditionalOnX` — what makes auto-config opt-in.
• `application.properties` / yml + profiles — environment-aware config.
• Actuator — /actuator/health, /info, /metrics, /env (secured!).

The interview surface for this module breaks into these focus areas:

• Actuator — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Auto configuration — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Configuration management — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Embedded servers — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Profiles and properties — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Starters — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Testing — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Troubleshooting — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Disable an auto-config — @SpringBootApplication(exclude = ...) or spring.autoconfigure.exclude=.
• `@ConfigurationProperties` vs `@Value` — typed binding vs single-key SpEL; prefer the former.
• Profiles — comma-separated; @Profile("!prod") works; never hardcode secrets.
• Graceful shutdown — server.shutdown=graceful + spring.lifecycle.timeout-per-shutdown-phase.
• Layered jars / jib — Docker-friendly, faster cache hits.

"In Spring Boot I'd lean on the , override via `application-.yml`, expose behind , and ship a layered Docker image so dependency layers stay cached. For startup tuning I'd profile with the conditions report and disable unused auto-configs."

Database persistence is the backbone of every business application, and interviewers use JPA/Hibernate questions to test whether you understand what is happening beneath Spring Data's magic repository methods. The N+1 problem, LazyInitializationException, and @Transactional misuse are the three most cited production bugs in Java applications — freshers who understand them stand out immediately. Knowing the difference between JPA (specification) and Hibernate (implementation) also signals architecture awareness.

• ORM = maps Java class fields to database table columns; you work with objects, the ORM generates SQL
• JPA = the specification (javax/jakarta.persistence); Hibernate = the most popular JPA implementation
• EntityManager = the JPA interface for CRUD operations; Spring wraps this behind JpaRepository
• Persistence Context = a first-level cache that tracks entity state within a transaction
• Entity states = Transient (new, not tracked) → Persistent (tracked by context) → Detached (was tracked, tx ended) → Removed (marked for delete)
• @OneToMany / mappedBy = the mappedBy side is NOT the owner; the owning side holds the foreign key column
• LAZY = load related data only when accessed; EAGER = load immediately with the parent query
• N+1 problem = 1 query to load N parents, then N queries to load each parent's children — fetch join or @EntityGraph solves it
• @Transactional = wraps a method in a database transaction; REQUIRED propagation joins an existing tx or starts a new one

• jpa-basics-and-orm-concepts — drill: ORM benefit, entity states and what triggers each transition, EntityManager vs Spring Data repository
• entity-mapping-annotations — drill: @Entity + @Id is minimum, @GeneratedValue strategies (IDENTITY is most common for MySQL/PostgreSQL), @Column nullable/unique
• jpa-relationships — drill: @OneToMany with mappedBy on the non-owner side; @ManyToOne on the child is the owning side; cascade ALL vs specific types
• spring-data-repositories — drill: JpaRepository extends PagingAndSortingRepository extends CrudRepository; derived query naming rules
• jpql-and-derived-queries — drill: JPQL uses entity/field names not table/column names; Pageable for pagination
• transactions-basics — drill: @Transactional default propagation = REQUIRED; checked exceptions do NOT trigger rollback by default
• lazy-vs-eager-loading — drill: @OneToMany default = LAZY; @ManyToOne default = EAGER; LazyInitializationException = access after tx closed
• comparisons — drill: JPA vs Hibernate, JPQL vs SQL, LAZY vs EAGER with N+1 implications
• scenario-based — drill: fix LazyInitializationException (open session in view or @EntityGraph or DTO projection), N+1 fix

• "What is the difference between JPA and Hibernate?" → JPA is the specification; Hibernate is the implementation; Spring Boot auto-configures Hibernate as the JPA provider
• "What is the N+1 problem?" → Loading 100 orders then triggering 100 separate queries for each order's items — fix with JOIN FETCH or @EntityGraph
• "What is LazyInitializationException?" → Accessing a LAZY collection after the persistence context (transaction) is closed; fix: extend tx scope, use DTO projection, or @EntityGraph
• "Which side owns a @OneToMany relationship?" → The @ManyToOne side (child, holds the FK column) owns it; @OneToMany with mappedBy is the inverse side
• "What is @Transactional default propagation?" → REQUIRED — joins existing transaction if one exists, starts a new one if not

"In my Spring Boot projects I use Spring Data JPA with Hibernate as the JPA provider. I annotate entity classes with @Entity and @Id, map relationships with @OneToMany and @ManyToOne, and write queries using derived method names or @Query JPQL. I'm careful about LAZY vs EAGER loading — I keep collections LAZY and use @EntityGraph or JOIN FETCH when I need the related data in a specific query to avoid the N+1 problem. I annotate service methods with @Transactional to ensure that operations run atomically and roll back on failure."

Spring Security interview questions cover the auth layer that protects every modern Java backend — the SecurityFilterChain, authentication providers, password encoding, session vs stateless (JWT) auth, OAuth2 and OpenID Connect, method-level security (@PreAuthorize, @PostAuthorize), CORS and CSRF, and the common pitfalls interviewers love to surface (storing JWTs in localStorage, missing audit fields, leaking principal in logs). This page covers Spring Security with Spring Boot 3, including the modern config-by-bean style and the migration patterns from the older WebSecurityConfigurerAdapter approach.

Spring Security is a chain of filters, then method security on top:

• `SecurityFilterChain` — request-level rules, AuthN, session strategy.
• `AuthenticationManager` + providers — DAO, LDAP, OAuth2, JWT.
• Method security — @PreAuthorize, @PostAuthorize, SpEL.
• Cross-cutting — CORS, CSRF, headers, password encoders (BCryptPasswordEncoder).

Boot 3 / Security 6 dropped WebSecurityConfigurerAdapter; everything is now bean-style.

The interview surface for this module breaks into these focus areas:

• Authentication — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Authorization — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Cors and csrf — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Jwt — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Oauth2 — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Security configuration — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Security fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Sso and saml — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Testing — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Stateless JWT — no server session, signature verification on every request; never put secrets in the JWT.
• CSRF — disable on stateless APIs only; keep enabled for cookie-session apps.
• Password storage — BCrypt (default), Argon2 if you can afford the cost.
• Method security on `@Async` — context propagation needs DelegatingSecurityContextRunnable.
• OAuth2 — Resource Server vs Authorisation Server vs Client; name the role you're playing.

"I'd configure a `SecurityFilterChain` bean, route public/private paths explicitly, choose based on , encode passwords with BCrypt, and put method-level guards on the service. CSRF stays on for cookie auth, off for stateless JWT APIs."

Spring WebFlux interview questions test whether you understand reactive programming on the JVM — Mono vs Flux, backpressure, the Project Reactor operator vocabulary, Schedulers and threading, when reactive helps versus when it just adds complexity, and the migration patterns from blocking Spring MVC. This page is small but focused: each question is one a senior interviewer actually asks when WebFlux is on your resume.

WebFlux = reactive streams (Mono/Flux) on top of Netty by default.

• Mono = 0..1, Flux = 0..N, both lazy.
• Backpressure is the request-N protocol — consumers signal demand.
• Schedulers matter — boundedElastic for blocking, parallel for CPU.
• Don't block in a reactive chain; if you must, isolate with subscribeOn(boundedElastic()).

The interview surface for this module breaks into these focus areas:

• Backpressure — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Error handling reactive — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Mono and flux — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• R2dbc reactive data — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Reactive programming basics — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Spring webflux setup — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Testing reactive — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Reactive ≠ faster — only wins on high-concurrency, IO-bound paths.
• `switchMap` vs `flatMap` — switch cancels prior, flatMap interleaves.
• R2DBC vs JPA — JPA is blocking; mixing kills the loop.
• Testing — StepVerifier for assertion, WebTestClient for HTTP.
• Virtual threads make Webflux less compelling for new projects — be ready to discuss the trade-off.

"I'd compose the pipeline as `Mono.fromX` → operators → `subscribe`, isolate any blocking call on `boundedElastic`, propagate context with `contextWrite`, and verify timing with `StepVerifier`. For new code I'd weigh WebFlux against virtual threads + plain blocking code."

Spring Batch interview questions cover the batch-processing framework that powers reconciliation, ETL and reporting jobs in every regulated Java backend — the Job/Step/Tasklet/Chunk model, ItemReader/Processor/Writer, restart and skip logic, partitioning and parallel steps, JobRepository internals, and the integration patterns that show up in finance and telco interviews. Each answer leads with the framework concept, then the operational concern interviewers really want to hear.

Batch = Job → Step → Tasklet | Chunk(reader / processor / writer).

• Chunk processing reads N, processes N, writes N — atomically per chunk.
• `JobRepository` persists status — restart picks up from the last good chunk.
• Skip / retry policies on transient errors.
• Partitioning for parallel steps; remote chunking for distributed.

The interview surface for this module breaks into these focus areas:

• Batch error handling — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Batch fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Chunk processing — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Item reader writer processor — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Job and step structure — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Job scheduling with quartz — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Partitioning and parallel steps — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scheduled tasks — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Idempotency — the same input must be safe to re-run; use natural keys + upsert.
• Restart vs rerun — restart resumes; rerun starts fresh — both are first-class.
• Reader pagination — never load everything; JpaPagingItemReader / cursor reader.
• `@StepScope` / `@JobScope` — late binding for run-time params (#{jobParameters['date']}).
• Scheduler integration — Quartz for complex cron, @Scheduled for simple.

"I'd model this as with a step (size N tuned to ), drive idempotency by , allow skip on , and partition by if the volume justifies it. The schedule sits behind ."