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