Spring Boot Auto Configuration Interview Questions and Answers

Auto-configuration is the feature that makes Spring Boot feel like magic — add a dependency, and beans appear. Interviewers ask about it precisely to check that it is not magic to you: that you can explain how the classpath drives configuration, how conditional annotations gate each piece, and how to debug what applied. Answering "it just works" is a fail; explaining the imports file and the back-off rule is a pass.

What is auto-configuration and how does it work?

Auto-configuration is a set of @Configuration classes that Spring Boot conditionally applies at startup based on what's on the classpath, what beans already exist, and what properties are set. Each class is guarded by @Conditional annotations, so it contributes beans only when its conditions are met.

The mechanism has two halves: a list of candidate configuration classes, and conditions that decide which ones actually run. When you add spring-boot-starter-data-jpa, the JPA classes land on the classpath, and @ConditionalOnClass(EntityManager.class) on the relevant auto-configuration flips true, so Spring wires a DataSource, an EntityManagerFactory and a transaction manager for you. Remove the dependency and those conditions go false and the beans never appear.

Interview note: Trap: "is auto-configuration the same as component scanning?" No. Component scanning finds your @Component/@Service classes in your packages. Auto-configuration loads framework-provided configuration classes listed in a special imports file, gated by conditions. They are separate mechanisms that both feed the same application context.

What does @SpringBootApplication actually combine?

It is a meta-annotation bundling three: @SpringBootConfiguration (a @Configuration), @EnableAutoConfiguration (triggers auto-configuration loading), and @ComponentScan (scans the current package and below for your beans).

Knowing the breakdown matters because you sometimes need to tune one part — narrowing the component scan base packages, or excluding a specific auto-configuration — and you can only do that if you know which sub-annotation owns which behavior.

@SpringBootApplication  // = @SpringBootConfiguration + @EnableAutoConfiguration + @ComponentScan
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

Interview note: Follow-up: "where does Spring start component scanning from?" The package of the class annotated with @SpringBootApplication. That's why the main class conventionally sits in the root package — beans in sibling packages above it are never scanned.

How does Spring Boot 3 discover the list of auto-configuration classes?

From META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports — a newline-separated list of fully-qualified class names on the classpath. @EnableAutoConfiguration reads every such file across all jars and treats each listed class as a configuration candidate.

This is a favorite dating question. In Spring Boot 2.7 the imports file was introduced; in 3.x it is the only mechanism. Before 2.7, the list lived under the org.springframework.boot.autoconfigure.EnableAutoConfiguration key in META-INF/spring.factories. If a candidate says spring.factories for auto-configuration in a Boot 3 context, the interviewer knows the knowledge is a few years stale.

# src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
com.codebegun.notify.EmailAutoConfiguration

Interview note: Trap: "does spring.factories still exist in Boot 3?" Yes — it still hosts other extension points (like FailureAnalyzer registrations), but not auto-configuration class discovery. Only the auto-configuration list moved.

What do the @Conditional annotations do?

They are the gates on each auto-configuration. @ConditionalOnClass applies only if a type is on the classpath; @ConditionalOnMissingBean applies only if no such bean is already defined; @ConditionalOnProperty applies only when a property has a given value; @ConditionalOnBean requires a bean to exist. @Conditional is the general form they're all built on.

The two you must be fluent in are @ConditionalOnClass and @ConditionalOnMissingBean, because together they express the whole philosophy: "configure this if the library is present, but get out of the way the moment the developer defines their own." That is why Spring Boot feels both automatic and non-intrusive.

@AutoConfiguration
@ConditionalOnClass(JavaMailSender.class)
public class EmailAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean          // back off if the app defines its own
    @ConditionalOnProperty(prefix = "notify.email", name = "enabled",
                           havingValue = "true", matchIfMissing = true)
    public EmailService emailService(JavaMailSender sender) {
        return new SmtpEmailService(sender);
    }
}

Interview note: Follow-up: "what does matchIfMissing = true mean on @ConditionalOnProperty?" The condition passes when the property is absent, so the bean is on by default and a user has to explicitly set enabled=false to turn it off. It's the standard opt-out pattern for starter defaults.

How do you override or exclude an auto-configuration?

To override a specific bean, just define your own — @ConditionalOnMissingBean makes Spring back off. To disable an entire auto-configuration, exclude it via @SpringBootApplication(exclude = ...) or the spring.autoconfigure.exclude property.

The distinction matters. Overriding one bean is surgical and preferred. Excluding a whole auto-configuration is a bigger hammer — you use it when the auto-configuration itself is unwanted, for example excluding DataSourceAutoConfiguration in a service that has no database but pulled JPA in transitively.

@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)
public class Application { }

Or via properties:

spring:
  autoconfigure:
    exclude: org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

Interview note: Trap: "you tried to exclude an auto-configuration that isn't on the classpath and got an error — why?" exclude on the annotation validates that the named class exists. If the auto-configuration might be absent, use the spring.autoconfigure.exclude property, which tolerates missing names, or reference it by string.

How do you debug which auto-configurations applied and why?

Run with --debug (or set debug=true) to print the condition evaluation report: it lists positive matches, negative matches with the reason, and exclusions. For a running app, the Actuator /actuator/conditions endpoint exposes the same report as JSON.

This is the answer that shows you've actually diagnosed a "why isn't my bean there?" problem. The report tells you, per auto-configuration, exactly which condition failed — "did not find class X", "found bean Y already defined" — which converts a guessing game into a lookup. Naming this report is a strong signal.

Negative matches:
-----------------
   DataSourceAutoConfiguration:
      Did not match:
         - @ConditionalOnClass did not find required class
           'javax.sql.DataSource' (OnClassCondition)

Interview note: Follow-up: "your custom bean isn't being created and you suspect an ordering issue — what do you check?" The conditions report plus the order of @ConditionalOnMissingBean evaluation: user configuration is processed before auto-configuration, but between two auto-configurations you may need @AutoConfigureBefore/@AutoConfigureAfter to guarantee your bean exists when another's condition checks for it.

How do you control ordering between auto-configurations?

With @AutoConfigureBefore, @AutoConfigureAfter, and @AutoConfigureOrder. They matter because @ConditionalOnBean and @ConditionalOnMissingBean are evaluated in configuration order — a condition that checks "is bean X present?" only works correctly if X's configuration ran first.

Ordering is subtle and a frequent source of "works on my machine" auto-configuration bugs. @ConditionalOnBean is inherently order-sensitive: if the auto-configuration that would create the bean hasn't run yet, the condition sees nothing and skips. This is why the Spring docs warn to use @ConditionalOnBean and @ConditionalOnMissingBean only within auto-configuration classes, whose ordering you can control, and never against user beans whose timing you can't.

@AutoConfiguration(after = DataSourceAutoConfiguration.class)
public class AuditAutoConfiguration {
    @Bean
    @ConditionalOnBean(DataSource.class)
    public AuditWriter auditWriter(DataSource ds) { return new JdbcAuditWriter(ds); }
}

Interview note: Trap: "why not just use @ConditionalOnBean everywhere instead of @ConditionalOnMissingBean?" Because @ConditionalOnBean fails silently when ordering isn't guaranteed, producing intermittent missing beans. @ConditionalOnMissingBean is safer because "no override defined" is a stable condition regardless of order.

How would you write your own auto-configuration or starter?

Create an @AutoConfiguration class with the right @ConditionalOn... guards, list it in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports, bind settings with @ConfigurationProperties, and package it. A "starter" is then just a thin dependency module that pulls in your auto-configuration module plus its transitive libraries.

The convention is two modules: acme-spring-boot-autoconfigure (the configuration and conditions) and acme-spring-boot-starter (an empty jar that depends on the autoconfigure module and the libraries it needs). Users add one starter dependency and get working defaults they can override bean-by-bean. Being able to describe this end-to-end — imports file, conditions, properties binding, back-off — is what a strong candidate demonstrates.

@AutoConfiguration
@EnableConfigurationProperties(NotifyProperties.class)
@ConditionalOnClass(EmailService.class)
public class NotifyAutoConfiguration {
    @Bean
    @ConditionalOnMissingBean
    NotifyClient notifyClient(NotifyProperties props) {
        return new NotifyClient(props.getApiUrl());
    }
}

Interview note: Follow-up: "why keep the autoconfigure and starter as separate modules?" So an application can depend on the autoconfigure module and hand-pick the underlying libraries, while most users take the convenient starter. Separating them keeps the dependency graph honest and lets advanced users opt out of transitive choices.

What interviewers really test

Auto-configuration questions are a knowledge-currency test: do you know the modern imports file, or are you still describing spring.factories? And they're a depth test — anyone can say "it configures beans automatically," but explaining the back-off rule via @ConditionalOnMissingBean, the ordering hazards of @ConditionalOnBean, and the condition evaluation report shows you've debugged real Spring Boot applications.

Solidify the mechanism by working through the Spring Boot learning path, then connect it outward: auto-configuration leans entirely on the container, so pair it with dependency injection questions and the configuration properties set, since binding external settings is half of what a good starter does. When you can trace a bean from the imports file through its conditions to the context — and back off correctly when overridden — a mock interview on this topic becomes a formality rather than a hazard.