DEVPREP CODEX · #23

Spring Boot Interview Questions

150 curated questions graded from Foundations (Easy) to Practical Patterns (Medium) and Internals & Architecture (Hard).

TOTAL QUESTIONS

150

THEORY QUESTIONS

150

IMPLEMENTATION FOLIOS

FREE QUESTIONS

5 / Level

Easy Level·50 Questions Total

Foundations & Core Concepts

Open Full Easy List

Q1What is Spring Boot and how does it differ from plain Spring?

Opinionated framework removing Spring's configuration burden: auto-configuration, starter dependencies, embedded servers (Tomcat/Jetty), production features (Actuator).
Plain Spring requires explicit XML/Java config for every bean; Boot infers from classpath ("found H2 + JPA → configure datasource").
Result: java -jar app.jar runnable microservice in minutes vs days of wiring.

Q2What is auto-configuration and how do you debug or disable it?

Boot inspects classpath, beans, properties at startup; @EnableAutoConfiguration loads conditionally-defined configurations (@ConditionalOnClass, @ConditionalOnMissingBean).
Debug with --debug flag printing the CONDITIONS EVALUATION REPORT (matched/not-matched).
Exclude via @SpringBootApplication(exclude=DataSourceAutoConfiguration.class) or property. Your bean ALWAYS wins over auto-config (@ConditionalOnMissingBean backs off) — the key extension principle.

Q3What are starters?

Curated dependency descriptors: spring-boot-starter-web pulls Spring MVC+Jackson+Tomcat coherently versioned.
Kill transitive-dependency guesswork; Boot's BOM manages compatible versions across the ecosystem.
Common set to name: web, data-jpa, security, validation, actuator, test, data-redis.

Q4Walk through @SpringBootApplication annotations.

Composite of three:

@Configuration — class is a bean-definition source.
@ComponentScan — pick up @Component/@Service/@Repository/@Controller under package (root scan covers sub-packages — why main class sits at root).
@EnableAutoConfiguration — activates conditional config machinery.

Q5What is the IoC container / ApplicationContext?

Inversion of Control: the framework creates and wires objects (beans) instead of classes instantiating their own dependencies.
ApplicationContext is the advanced container — lifecycle callbacks, events, i18n, resource loading on top of bean factory.
Beans defined via stereotype annotations, @Bean methods, or imports; retrieved by type mostly — coding to interfaces becomes natural.

45 More Easy Questions Locked

Unlock the complete Spring Boot Easy question bank

Get instant access to all 50 questions, in-depth model answers, code sandboxes, and all 27+ technologies for a single one-time payment.

Unlock All — One-time payment · Lifetime access

Medium Level·50 Questions Total

Mechanisms & Practical Patterns

Open Full Medium List

Q1Explain bean lifecycle hooks you can use.

Instantiation → populate properties → Aware interfaces (BeanNameAware...) → BeanPostProcessor.before → @PostConstruct/InitializingBean.afterPropertiesSet/initMethod → ready → @PreDestroy on shutdown.
BeanPostProcessor power: proxies (transactions, async, caching) wrap here — explains annotation self-invocation failures. Ordering knowledge separates debugging heroes from sufferers.

Q2How does proxy-based AOP work and what are its limits?

JDK dynamic proxies (interfaces) or CGLIB subclassing weave advice around beans: @Transactional, @Cacheable, @Async, custom aspects.
Limits: self-invocation bypasses proxy (internal call misses transaction); final methods/classes defeat CGLIB; private methods never advised. Fixes: split beans, self-injection via ObjectProvider, or AspectJ weaving for exotic cases.

Q3Explain propagation behaviors with real scenarios.

Key ones:

REQUIRED (default): join or create.
REQUIRES_NEW: suspend outer, fresh tx — audit log must survive outer rollback.
NESTED: savepoint inside outer — partial rollback possible.
NOT_SUPPORTED/MANDATORY/NEVER: suspension/assertions for special flows. Scenario drill: batch processing where per-row failure shouldn't sink whole batch → REQUIRES_NEW per row + collect errors.

Q4What isolation levels does Spring expose and which anomalies do they prevent?

DEFAULT→DB; READ_UNCOMMITTED (dirty reads), READ_COMMITTED (default PG), REPEATABLE_READ (MySQL default), SERIALIZABLE.
Anomalies ladder: dirty → non-repeatable → phantom; serialization prevents all incl. write-skew (PG SSI). Practical guidance: raise level only for the critical section; pair with retries on serialization failures.

Q5How do JPA persistence contexts interact with transactions in services?

One EntityManager per transaction via shared proxy; entities loaded become managed — changes auto-flushed at commit (dirty checking).
Read-only hint (@Transactional(readOnly=true)) enables flush-mode manual/Hibernate optimizations + replica routing hints.
Detached entity pitfalls: modifying after context close silently lost; merging copies state into new managed instance.

45 More Medium Questions Locked

Unlock the complete Spring Boot Medium question bank

Get instant access to all 50 questions, in-depth model answers, code sandboxes, and all 27+ technologies for a single one-time payment.

Unlock All — One-time payment · Lifetime access

Hard Level·50 Questions Total

Internals & System Architecture

Open Full Hard List

Q1How does the Spring context startup actually sequence, and what breaks it?

Scan/parse bean definitions → BeanFactoryPostProcessors (property placeholders, config class parsing — CGLIB enhancement of @Configuration enforcing proxyBeanMethods semantics) → instantiate non-lazy singletons in dependency order → BeanPostProcessors wrap proxies → SmartLifecycle.start().
Breakers: circular deps (now fatal by default; allow-circular-references escape hatch), eager @PostConstruct doing IO, static initializers touching beans.
Lazy init defers but shifts failures to request time — trade-off articulation expected.

Q2Explain @Configuration(proxyBeanMethods) semantics and the cglib interlude.

Full mode (default): config class is CGLIB-subclassed so internal @Bean calls intercept, returning the SAME singleton instead of invoking method — preserves container semantics.
lite mode (proxyBeanMethods=false / @Bean on non-@Configuration classes): methods execute literally → new instance per call; allowed when no intra-config references; faster startup, used heavily in native/AOT guidance. Bug signature: two "singletons" unequal — explain mechanism to ace this.

Q3What is the transaction synchronization + JPA flush ordering dance in services?

Within tx: Hibernate flushes BEFORE query execution touching affected tables (FlushMode.AUTO queries flush pending changes to keep results consistent), and always at commit.
@TransactionalEventListener(AFTER_COMMIT) sees committed state but detached entities — must pass ids/data explicitly, not managed graphs.
Pitfall: enqueueing message inside tx reading uncommitted rows elsewhere → phantom reads for consumer; design consumers idempotent or move reads post-commit.

Q4How does Hibernate batch writes and what settings unlock it?

Requires: hibernate.jdbc.batch_size=50, ordered inserts (order_inserts=true), IDENTITY generation DISABLES batching for inserts (use SEQUENCE w/ pooled optimizer hi-lo style).
Versioned data enables batched updates; statement rewrites via reWriteBatchedInserts=true (MySQL/pgjdbc) collapsing multi-values.
Verify: datasource-proxy/sql statement count metrics before/after — prove the win numerically.

Q5What are the concurrency semantics of @Transactional across threads/reactive boundaries?

Transaction bound to thread via ThreadLocal (DataSourceTransactionManager) — spawning threads inside a tx method runs code OUTSIDE it silently.
Reactive: ReactiveTransactionManager propagates via Reactor context; mixing JDBC (blocking) inside reactive chains needs schedulers bounding blocking work.
Async bridging patterns: pre-load ids inside tx, process outside, final update tx with optimistic checks.

45 More Hard Questions Locked

Unlock the complete Spring Boot Hard question bank

Get instant access to all 50 questions, in-depth model answers, code sandboxes, and all 27+ technologies for a single one-time payment.

Unlock All — One-time payment · Lifetime access

DEDICATED LEVEL PAGES

Browse All Spring Boot Questions by Difficulty

Easy50 Questions

Core concepts, definitions, basic syntax, and first principles expected in round 1 screening.

VIEW FULL LIST

Medium50 Questions

Real-world mechanisms, state management, edge cases, performance trade-offs, and practical coding.

VIEW FULL LIST

Hard50 Questions

Deep runtime internals, memory models, distributed design, concurrency failure modes, and architectural decisions.

VIEW FULL LIST

INTERNAL LINKING & DEPENDENCIES

Related Technologies to Spring Boot

CAREER PATHWAYS

Spring Boot is a key requirement for these engineering roles:

Backend Engineer Guide

DEVPREP CODEX · #23

Spring Boot Interview Questions

150 curated questions graded from Foundations (Easy) to Practical Patterns (Medium) and Internals & Architecture (Hard).

TOTAL QUESTIONS

150

THEORY QUESTIONS

150

IMPLEMENTATION FOLIOS

FREE QUESTIONS

5 / Level

Easy Level·50 Questions Total

Foundations & Core Concepts

Open Full Easy List

Q1What is Spring Boot and how does it differ from plain Spring?

Opinionated framework removing Spring's configuration burden: auto-configuration, starter dependencies, embedded servers (Tomcat/Jetty), production features (Actuator).
Plain Spring requires explicit XML/Java config for every bean; Boot infers from classpath ("found H2 + JPA → configure datasource").
Result: java -jar app.jar runnable microservice in minutes vs days of wiring.

Q2What is auto-configuration and how do you debug or disable it?

Boot inspects classpath, beans, properties at startup; @EnableAutoConfiguration loads conditionally-defined configurations (@ConditionalOnClass, @ConditionalOnMissingBean).
Debug with --debug flag printing the CONDITIONS EVALUATION REPORT (matched/not-matched).
Exclude via @SpringBootApplication(exclude=DataSourceAutoConfiguration.class) or property. Your bean ALWAYS wins over auto-config (@ConditionalOnMissingBean backs off) — the key extension principle.

Q3What are starters?

Curated dependency descriptors: spring-boot-starter-web pulls Spring MVC+Jackson+Tomcat coherently versioned.
Kill transitive-dependency guesswork; Boot's BOM manages compatible versions across the ecosystem.
Common set to name: web, data-jpa, security, validation, actuator, test, data-redis.

Q4Walk through @SpringBootApplication annotations.

Composite of three:

@Configuration — class is a bean-definition source.
@ComponentScan — pick up @Component/@Service/@Repository/@Controller under package (root scan covers sub-packages — why main class sits at root).
@EnableAutoConfiguration — activates conditional config machinery.

Q5What is the IoC container / ApplicationContext?

Inversion of Control: the framework creates and wires objects (beans) instead of classes instantiating their own dependencies.
ApplicationContext is the advanced container — lifecycle callbacks, events, i18n, resource loading on top of bean factory.
Beans defined via stereotype annotations, @Bean methods, or imports; retrieved by type mostly — coding to interfaces becomes natural.

45 More Easy Questions Locked

Unlock the complete Spring Boot Easy question bank

Get instant access to all 50 questions, in-depth model answers, code sandboxes, and all 27+ technologies for a single one-time payment.

Unlock All — One-time payment · Lifetime access

Medium Level·50 Questions Total

Mechanisms & Practical Patterns

Open Full Medium List

Q1Explain bean lifecycle hooks you can use.

Instantiation → populate properties → Aware interfaces (BeanNameAware...) → BeanPostProcessor.before → @PostConstruct/InitializingBean.afterPropertiesSet/initMethod → ready → @PreDestroy on shutdown.
BeanPostProcessor power: proxies (transactions, async, caching) wrap here — explains annotation self-invocation failures. Ordering knowledge separates debugging heroes from sufferers.

Q2How does proxy-based AOP work and what are its limits?

JDK dynamic proxies (interfaces) or CGLIB subclassing weave advice around beans: @Transactional, @Cacheable, @Async, custom aspects.
Limits: self-invocation bypasses proxy (internal call misses transaction); final methods/classes defeat CGLIB; private methods never advised. Fixes: split beans, self-injection via ObjectProvider, or AspectJ weaving for exotic cases.

Q3Explain propagation behaviors with real scenarios.

Key ones:

REQUIRED (default): join or create.
REQUIRES_NEW: suspend outer, fresh tx — audit log must survive outer rollback.
NESTED: savepoint inside outer — partial rollback possible.
NOT_SUPPORTED/MANDATORY/NEVER: suspension/assertions for special flows. Scenario drill: batch processing where per-row failure shouldn't sink whole batch → REQUIRES_NEW per row + collect errors.

Q4What isolation levels does Spring expose and which anomalies do they prevent?

DEFAULT→DB; READ_UNCOMMITTED (dirty reads), READ_COMMITTED (default PG), REPEATABLE_READ (MySQL default), SERIALIZABLE.
Anomalies ladder: dirty → non-repeatable → phantom; serialization prevents all incl. write-skew (PG SSI). Practical guidance: raise level only for the critical section; pair with retries on serialization failures.

Q5How do JPA persistence contexts interact with transactions in services?

One EntityManager per transaction via shared proxy; entities loaded become managed — changes auto-flushed at commit (dirty checking).
Read-only hint (@Transactional(readOnly=true)) enables flush-mode manual/Hibernate optimizations + replica routing hints.
Detached entity pitfalls: modifying after context close silently lost; merging copies state into new managed instance.

45 More Medium Questions Locked

Unlock the complete Spring Boot Medium question bank

Get instant access to all 50 questions, in-depth model answers, code sandboxes, and all 27+ technologies for a single one-time payment.

Unlock All — One-time payment · Lifetime access

Hard Level·50 Questions Total

Internals & System Architecture

Open Full Hard List

Q1How does the Spring context startup actually sequence, and what breaks it?

Scan/parse bean definitions → BeanFactoryPostProcessors (property placeholders, config class parsing — CGLIB enhancement of @Configuration enforcing proxyBeanMethods semantics) → instantiate non-lazy singletons in dependency order → BeanPostProcessors wrap proxies → SmartLifecycle.start().
Breakers: circular deps (now fatal by default; allow-circular-references escape hatch), eager @PostConstruct doing IO, static initializers touching beans.
Lazy init defers but shifts failures to request time — trade-off articulation expected.

Q2Explain @Configuration(proxyBeanMethods) semantics and the cglib interlude.

Full mode (default): config class is CGLIB-subclassed so internal @Bean calls intercept, returning the SAME singleton instead of invoking method — preserves container semantics.
lite mode (proxyBeanMethods=false / @Bean on non-@Configuration classes): methods execute literally → new instance per call; allowed when no intra-config references; faster startup, used heavily in native/AOT guidance. Bug signature: two "singletons" unequal — explain mechanism to ace this.

Q3What is the transaction synchronization + JPA flush ordering dance in services?

Within tx: Hibernate flushes BEFORE query execution touching affected tables (FlushMode.AUTO queries flush pending changes to keep results consistent), and always at commit.
@TransactionalEventListener(AFTER_COMMIT) sees committed state but detached entities — must pass ids/data explicitly, not managed graphs.
Pitfall: enqueueing message inside tx reading uncommitted rows elsewhere → phantom reads for consumer; design consumers idempotent or move reads post-commit.

Q4How does Hibernate batch writes and what settings unlock it?

Requires: hibernate.jdbc.batch_size=50, ordered inserts (order_inserts=true), IDENTITY generation DISABLES batching for inserts (use SEQUENCE w/ pooled optimizer hi-lo style).
Versioned data enables batched updates; statement rewrites via reWriteBatchedInserts=true (MySQL/pgjdbc) collapsing multi-values.
Verify: datasource-proxy/sql statement count metrics before/after — prove the win numerically.

Q5What are the concurrency semantics of @Transactional across threads/reactive boundaries?

Transaction bound to thread via ThreadLocal (DataSourceTransactionManager) — spawning threads inside a tx method runs code OUTSIDE it silently.
Reactive: ReactiveTransactionManager propagates via Reactor context; mixing JDBC (blocking) inside reactive chains needs schedulers bounding blocking work.
Async bridging patterns: pre-load ids inside tx, process outside, final update tx with optimistic checks.

45 More Hard Questions Locked