Spring Boot Interview Questions

Spring's default bean scope is singleton. When you annotate a class with @Component (or @Service, @Repository, etc.) and do not specify a scope, the container instantiates one instance per application context and serves that same instance wherever the bean is injected.

@PostConstruct is a standard lifecycle annotation (JSR-250) that Spring honors. The container calls the annotated method after all dependencies have been injected and before the bean is made available for use, making it the correct place for initialization logic.

@Component is a stereotype annotation placed on a class so that Spring's component scanner discovers it and registers a bean definition in the application context. @Bean is a method-level annotation used inside @Configuration classes, @Autowired declares an injection point rather than a bean definition, and @Configuration marks a class as a source of bean declarations, not the bean itself.

The default bean scope in Spring is singleton, meaning the application context creates and caches exactly one instance of the bean and returns that same instance for every injection point. prototype creates a new instance each time, while request and session are web-scoped and must be declared explicitly.

ApplicationContext is the primary IoC container interface in Spring Boot; it extends BeanFactory and adds enterprise features such as event publication, internationalization, and resource loading. BeanFactory is the more minimal root interface but is not the container Spring Boot boots by default. DispatcherServlet handles HTTP requests, and Environment provides property and profile information.

Resilience4j requires the fallback method to accept the same parameters as the original method (optionally followed by a Throwable). processPayment takes a String orderId, but fallback() on line 9 takes no parameters. The fix is public String fallback(String orderId) {. At runtime Resilience4j throws an IllegalArgumentException because it cannot find a compatible fallback method matching the original method's parameter types.

On line 4 the fallbackMethod attribute is set to "getDefualtInventory" — a typo. The actual method on line 9 is named getDefaultInventory. Resilience4j resolves the fallback by the exact name supplied in the annotation; since no method named getDefualtInventory exists, startup fails with an IllegalArgumentException. The fallback method's signature itself (same first parameter String sku plus an Exception trailing parameter, matching return type List<Item>) is correct, so the only defect is the misspelled name on line 4.

Spring instantiates a bean by calling its constructor, which is when constructor-injected dependencies are resolved. Only after the object exists can Spring populate @Autowired fields and call setters during the property-population phase. Once all injection is complete, Spring invokes @PostConstruct. The bean is then fully initialized and ready for use.

Spring starts creating Bean A, but its constructor requires Bean B. It pauses A and tries to create B, whose constructor requires Bean A. Because A is not yet constructed (no early reference is available for constructor injection, unlike field injection), Spring detects the deadlock and throws BeanCurrentlyInCreationException. This is why constructor injection prevents circular dependencies.

When no @Scope annotation is present, the Spring container creates a single shared instance of the bean per application context (per bean name). This is the singleton scope, which is the default for all beans registered via stereotype annotations or @Bean methods.

@PostConstruct is invoked by the container after the bean's dependencies have been injected, making it the standard place for init logic. @PreDestroy is invoked before the bean is destroyed, allowing resource cleanup. Both are from jakarta.annotation (formerly javax.annotation) and are supported natively by Spring's CommonAnnotationBeanPostProcessor.

A Resilience4j circuit breaker uses a three-state machine. It starts in CLOSED, where all calls are permitted and outcomes are recorded in a sliding window. Once the failure rate crosses the configured threshold (default 50%), the breaker trips to OPEN and immediately rejects calls by throwing a CallNotPermittedException. It remains OPEN for the configured wait-duration-in-open-state before transitioning toward HALF_OPEN.

The @CircuitBreaker annotation (from io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker) is the declarative way to wrap a method in a circuit breaker. Its fallbackMethod attribute names a method (same signature, optionally accepting the original exception) that Resilience4j invokes when the call is short-circuited or throws. Spring Boot auto-configures the underlying registry when the resilience4j-spring-boot2 / resilience4j-spring-boot3 starter is on the classpath.

Spring fully completes dependency injection (field and setter injection via @Autowired) before any initialization callbacks fire. @PostConstruct is triggered by CommonAnnotationBeanPostProcessor.postProcessBeforeInitialization, which runs after injection but before the InitializingBean.afterPropertiesSet() callback and any custom init-method.

When a prototype bean is injected into a singleton at wiring time, Spring creates the prototype instance once and caches the reference in the singleton — it is never recreated for subsequent calls. @Lookup (a form of method injection) solves this: Spring generates a CGLIB subclass that overrides the annotated method to return a fresh prototype bean from the context on each invocation.

Singleton beans are eagerly instantiated at refresh time unless annotated with @Lazy, so the statement that singleton-scoped beans are eagerly instantiated by default when the ApplicationContext is refreshed is true. Prototype-scoped beans are instantiated on every call to getBean or injection, so the statement that prototype-scoped beans are created each time they are requested from the container is true. The container does NOT manage the full lifecycle of prototype beans — it creates, configures, and hands them off but never calls @PreDestroy or destroy methods on them, so the statement that the container calls @PreDestroy lifecycle methods on prototype-scoped beans when the ApplicationContext is closed is false. Request-scoped (and session-scoped) beans are web-specific and require a web-aware ApplicationContext, so the statement that request-scoped beans require a web-aware ApplicationContext is true.

Constructor injection sets dependencies before the object is fully constructed, so fields can be marked final — the statement about constructor injection allowing final fields is true. When multiple candidates of the same type exist, @Autowired does NOT always throw; it attempts to narrow by matching the field/parameter name to a bean name before failing, so the claim that field injection with @Autowired will always throw NoUniqueBeanDefinitionException is false. @Qualifier explicitly narrows the candidate set and can be used alongside @Autowired — the statement about combining @Qualifier with @Autowired is true. Field injection uses reflection to set private fields directly, with no setter or constructor parameter required — the statement about field injection using reflection without requiring a setter or constructor parameter is true. Constructor injection (not setter injection) is the recommended approach for mandatory dependencies, because it enforces them at construction time and allows immutability — the claim that setter injection is recommended for mandatory dependencies is false.

With field injection, Spring's bean lifecycle proceeds in three phases: (1) instantiate the bean by calling its no-arg constructor, (2) inject dependencies into fields, then (3) call @PostConstruct. When Spring creates Worker, it first calls the constructor — at that point @Autowired fields are still null, so 'Worker constructor: printer=null' is printed. After construction, Spring injects the Printer bean (which it creates first, printing 'Printer created'), then calls onStart(), where printer is now non-null. The complete output is:

Printer created Worker constructor: printer=null Worker onStart: printer=injected

This tests senior-level understanding that scope only governs creation, not re-injection. The singleton is created once, so its prototype collaborator is resolved once. The two solutions — ObjectProvider/Provider injection vs scoped-proxy or @Lookup method override — are the canonical Spring mechanisms for breaking this stale-reference problem.

This tests the distinction between the two extension points at the definition vs instance level, and the infrastructure-first bootstrapping constraint that Spring enforces for BeanFactoryPostProcessor — a senior-level lifecycle detail that explains why placeholder configurers and similar processors behave differently from regular @PostConstruct-style callbacks.

This tests a frequently-misunderstood lifecycle asymmetry: the container's responsibility for a prototype ends at hand-off. Seniors must know that destruction callbacks are singleton-only by design, and that the ownership of cleanup transfers to the client — a common source of resource leaks when prototype scope is chosen naively.

Spring invokes bean lifecycle initialization callbacks in a fixed order: first @PostConstruct (JSR-250), then InitializingBean.afterPropertiesSet(), and finally the custom init method named in @Bean(initMethod = ...). All three are called if all three are present — Spring does not skip any of them, so the claim that Spring skips the custom initMethod when the bean implements InitializingBean is false. The claim that @PostConstruct is invoked before setter-based dependency injection is false because all initialization callbacks run only after dependency injection (both constructor and setter/field injection) is fully complete, not before it. The statement that @PostConstruct is invoked before afterPropertiesSet() is true because @PostConstruct always precedes afterPropertiesSet(). The statement that the custom init method declared via @Bean(initMethod = "customInit") is invoked after afterPropertiesSet() is true because the custom initMethod always runs last in the sequence, after afterPropertiesSet().

Foo uses field injection for bar (@Autowired on the field). Spring constructs the Foo instance first by calling its no-arg constructor — at that point field injection has NOT yet occurred, so bar is null. The constructor therefore sets value = "none". After construction completes, Spring injects bar via reflection. When run() calls foo.getValue(), the expression evaluates to value + ":" + bar.getName() = "none" + ":" + "bar" = "none:bar". This illustrates the core disadvantage of field injection: the dependency is unavailable during construction, so any logic in the constructor that needs it silently sees null.

Setter/field-injection circular dependencies are resolved via Spring's three-level singleton cache: when bean A is being created, an ObjectFactory that can return A's early reference is stored in singletonFactories before A's properties are populated. When B (which A depends on) is then created and tries to inject A, it retrieves A's early reference from that cache, breaking the cycle. With constructor injection, the instance does not exist until the constructor returns, so there is nothing to expose as an early reference, and Spring detects the unresolvable cycle and throws BeanCurrentlyInCreationException. Annotating a constructor parameter with @Lazy causes Spring to inject a proxy stub instead of eagerly creating the real bean, which defers actual creation and breaks the cycle.

Spring resolves the single constructor of OrderProcessor automatically (Spring 4.3+), instantiates the bean, and only THEN performs field injection via AutowiredAnnotationBeanPostProcessor. During constructor execution the auditLogger field is still null, so the call on line 11 throws an NPE. The paymentGateway is safe because it is constructor-injected. The fix is to move auditLogger into the constructor (preferred for final-field immutability) or relocate the log call to a @PostConstruct method, which runs after both constructor and field injection are complete.