Spring Boot Auto-Configuration Interview Questions: The Answer Changed

The safe answer today is this: Spring Boot still discovers candidate auto-configurations, checks conditions, and registers beans, but the registration file changed. Spring Boot 2.6 and earlier commonly used META-INF/spring.factories; 2.7 introduced AutoConfiguration.imports; Spring Boot 3 removed the EnableAutoConfiguration entry from spring.factories; Spring Boot 4.1 continues with @AutoConfiguration and AutoConfiguration.imports.

How old is the Spring Boot answer in your interview notes? If it starts with “Spring Boot reads spring.factories,” it may have been correct when the notes were written. That does not make it a good answer for every version now.

This article follows the change from the old answer to the current one. It covers the mechanism, the file layout, the version boundary, and a short answer you can use when an interviewer asks about Spring Boot auto-configuration.

If this is one item on a larger preparation list, you can browse the other technical interview notes. For the Mac-specific side of interview preparation, see our guide to AI interview assistants for Mac.

The short answer interviewers actually want

Spring Boot auto-configuration is not a single file lookup. The useful mental model is a three-part pipeline:

1. Spring Boot finds candidate auto-configuration classes.
2. It applies exclusions, ordering rules, and conditional checks.
3. It registers the configurations and beans whose conditions match the application.

The version detail sits inside the first step. The old interview answer focused on spring.factories. The current answer should mention AutoConfiguration.imports, AutoConfigurationImportSelector, and the condition annotations that make the defaults back off when you provide your own beans.

Here is the version map worth remembering:

That last row is important. You do not get extra points for inventing a new Boot 4 discovery mechanism. The accurate answer is usually the less dramatic one.

What Spring Boot is doing under the hood

Start with the application class most developers have written dozens of times:

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

The annotation is a shortcut for three annotations:

@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan
public @interface SpringBootApplication {
}

@EnableAutoConfiguration is the part that starts this process. It imports AutoConfigurationImportSelector, which gathers candidate configurations from the classpath. The selector is not creating every possible bean blindly. It builds a candidate list, removes anything the application excluded, sorts what remains, and lets conditions decide what is actually applied.

The flow is easier to remember as a sentence than as a magic phrase:

@SpringBootApplication
        ↓
@EnableAutoConfiguration
        ↓
AutoConfigurationImportSelector
        ↓
candidate auto-configurations
        ↓
exclusions + ordering + conditions
        ↓
configuration classes and beans in the application context

That is the part that stays stable across the version changes. The discovery file is the part that moved.

Spring Boot 2.6 and earlier: the spring.factories answer

In older Spring Boot applications, a library registered its auto-configuration classes in this file:

META-INF/spring.factories

The entry used a key and a comma-separated list of classes:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.example.demo.autoconfigure.DemoAutoConfiguration

The configuration class itself might look like this:

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(DemoClient.class)
public class DemoAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean
    DemoService demoService() {
        return new DemoService();
    }
}

So the old interview answer was not nonsense:

@SpringBootApplication enables auto-configuration. Spring Boot reads the EnableAutoConfiguration entries in META-INF/spring.factories, loads the listed configuration classes, and uses conditional annotations to decide which beans to create.

For a Spring Boot 2.5 application, that answer is still a reasonable description of the registration path. The mistake is carrying it into a current project without naming the version.

There is another detail that often gets lost in short answers. spring.factories is a general extension mechanism, not a file invented only for auto-configuration. That is one reason the newer approach gives auto-configuration its own file. A new file makes the intent clearer and gives build-time tooling a narrower thing to inspect.

Spring Boot 2.7: the transition release

Spring Boot 2.7 introduced two pieces that changed how custom auto-configuration should be written:

• the @AutoConfiguration annotation;
• the META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports file.

The new file is deliberately plain. Put one fully qualified class name on each line:

com.example.demo.autoconfigure.DemoAutoConfiguration
com.example.demo.autoconfigure.DemoWebAutoConfiguration

The configuration class can now say what it is:

@AutoConfiguration
@ConditionalOnClass(DemoClient.class)
public class DemoAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean
    DemoService demoService() {
        return new DemoService();
    }
}

Boot 2.7 did not cut the old path off immediately. It could read both locations, which gave libraries time to support applications on both sides of the upgrade. A library that needed to work with Boot 2.7 and Boot 3 could list its auto-configuration in both files during the migration window; Boot 2.7 de-duplicated entries listed twice.

That is why “Boot 2.7 changed everything” is also too blunt. It introduced the new route, but it was intentionally a bridge between the old and new arrangements.

Spring Boot 3.x: the old key is gone

Spring Boot 3 is the clean version boundary for interview answers. The EnableAutoConfiguration key in spring.factories is no longer the way to register auto-configuration classes. Custom auto-configurations belong in:

META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

spring.factories itself did not vanish. Other extension points may still use it, including mechanisms such as EnvironmentPostProcessor, ApplicationContextInitializer, and ApplicationListener. The precise statement is:

Spring Boot 3 removed the EnableAutoConfiguration registration key from spring.factories; it did not remove spring.factories from every Spring Boot extension point.

That small qualifier is the difference between a current answer and a slogan.

This upgrade also carries a larger Java and Spring Framework boundary. Spring Boot 3 requires Java 17 and uses Spring Framework 6. Projects moving from Boot 2.x also run into the javax.* to jakarta.* package migration. Those changes are not part of auto-configuration discovery, but they are useful context when an interviewer asks what changed between Boot 2 and Boot 3.

Spring Boot 4.1: the mechanism did not move again

Spring Boot 4.1.0 is the current stable line shown in the official system requirements. It requires at least Java 17 and Spring Framework 7. The release brings substantial platform changes, including module reorganization and a Jackson 3 migration path.

For this interview question, though, the answer is pleasantly boring: Boot 4.1 still uses @AutoConfiguration and AutoConfiguration.imports for custom auto-configuration. The classpath candidates still go through ordering and exclusion rules, and conditions still decide whether a bean is created.

If your notes say “Boot 4 replaced AutoConfiguration.imports with a new file,” update the notes. That is not the change documented by the current reference.

The useful way to phrase the version progression is:

Boot 2.6 and earlier → spring.factories
Boot 2.7             → both paths, with AutoConfiguration.imports introduced
Boot 3.x             → AutoConfiguration.imports for auto-config registration
Boot 4.1             → the same auto-config entry point, on a newer platform

The conditions are half the answer

Knowing the file name is only half of Spring Boot auto-configuration. The other half is why the configuration does not get in your way.

Common conditions include:

• @ConditionalOnClass: apply the configuration when a class is on the classpath;
• @ConditionalOnMissingClass: apply it when a class is absent;
• @ConditionalOnBean: apply it when another bean already exists;
• @ConditionalOnMissingBean: provide a default only when the application has not provided one;
• @ConditionalOnProperty: apply it when a property has the expected value;
• @ConditionalOnWebApplication: apply it only to a web application.

The most interview-friendly example is @ConditionalOnMissingBean:

@Bean
@ConditionalOnMissingBean
DemoService demoService() {
    return new DemoService();
}

If the application does not define a DemoService, the starter supplies a default. If the application defines one, the auto-configuration backs off. Spring Boot is not trying to take control away from the application; it is offering a default until the application makes a choice.

That “back off” behavior is a better explanation of the design than a list of annotations. It tells the interviewer why auto-configuration is useful rather than merely naming the pieces.

It also gives you a practical way to debug a starter that “should” be working but is not. Check the dependency first: is the class named by @ConditionalOnClass actually on the runtime classpath? Then check the property conditions and look for an application bean that is making @ConditionalOnMissingBean back off. Finally, inspect the auto-configuration report or startup condition output instead of guessing from the package name. The same three questions work across Boot versions because they are about the condition pipeline, not the registration file.

This is a useful follow-up in an interview because it turns the explanation into something you have actually used. You are no longer reciting “conditional annotations”; you are showing how you would find out why a default did or did not appear.

Custom starter example for Boot 3 and 4

For a small custom starter, the important files look like this:

demo-spring-boot-autoconfigure/
└── src/main/
    ├── java/com/example/demo/autoconfigure/
    │   ├── DemoAutoConfiguration.java
    │   └── DemoProperties.java
    └── resources/META-INF/spring/
        └── org.springframework.boot.autoconfigure.AutoConfiguration.imports

The configuration can bind properties and create a default service:

@AutoConfiguration
@EnableConfigurationProperties(DemoProperties.class)
@ConditionalOnClass(DemoService.class)
public class DemoAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean
    DemoService demoService(DemoProperties properties) {
        return new DemoService(properties.name());
    }
}

Then the imports file contains one line:

com.example.demo.autoconfigure.DemoAutoConfiguration

Do not add @ComponentScan just to make the starter discover its own classes. Auto-configuration is already being loaded through the imports file. Let the classpath condition and the explicit registration do that work.

If a library must support both a late Boot 2.x line and Boot 3, the migration guide allows a compatibility period where both registration files are present. If you are writing only for Boot 3 or 4, the dedicated imports file is the straightforward choice.

A practical way to inspect a real project

When an interviewer asks why a starter did not create a bean, do not start by guessing which annotation is missing. Start with the version of Spring Boot and the version of the starter. A library built for Boot 2.x may still contain spring.factories, while a newer library may only contain the dedicated imports file. The dependency version tells you which answer is plausible before you inspect the configuration class.

The next useful check is the dependency itself. Open the starter JAR and look under META-INF/spring/. If you find org.springframework.boot.autoconfigure.AutoConfiguration.imports, read the fully qualified class names and open those classes. If you find only spring.factories, check whether it contains the EnableAutoConfiguration key or a different Spring extension point. This simple check separates a registration problem from a condition problem.

After that, inspect the condition evaluation report. A configuration can be discovered correctly and still back off because a required class is missing, a property is disabled, or the application already defines a matching bean. Exclusions are another common cause: @SpringBootApplication(exclude = ...) and spring.autoconfigure.exclude can remove a candidate before its conditions are evaluated.

This debugging sequence is useful in an interview because it connects the file-format change to real application behavior. You can explain what changed between Boot versions, then show that you know how to verify the explanation in a running project rather than relying on a remembered tutorial.

How to answer this in a Java interview

There are three answers, and the right one depends on the version named in the question.

The old answer for a Boot 2.x project

@SpringBootApplication includes @EnableAutoConfiguration. Spring Boot finds auto-configuration classes registered under the EnableAutoConfiguration key in META-INF/spring.factories, then uses conditions such as @ConditionalOnClass and @ConditionalOnMissingBean to decide which beans to register.

That is the answer to give when the interviewer is clearly discussing a Boot 2.5 codebase. Add the version and you have removed most of the ambiguity.

The transition answer for Boot 2.7

Spring Boot 2.7 introduced @AutoConfiguration and META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports, while retaining the spring.factories path for compatibility. It is the transition release, so both mechanisms can appear in real projects.

This answer shows that you know why old projects and new projects may look different without treating either one as broken.

The current answer for Boot 3.x and 4.1

@SpringBootApplication enables auto-configuration through @EnableAutoConfiguration. AutoConfigurationImportSelector finds candidates from AutoConfiguration.imports, applies exclusions and ordering, and evaluates conditions such as @ConditionalOnClass, @ConditionalOnMissingBean, and @ConditionalOnProperty. The matching configuration classes contribute beans to the application context. Boot 3 and Boot 4 use this dedicated imports file for custom auto-configuration.

That answer has the entry point, the process, the conditions, and the version difference. It is short enough to say out loud and specific enough to survive a follow-up question.

If the interviewer does not name a version, start with the version-neutral mechanism and then add the file boundary. For example: “Spring Boot uses @EnableAutoConfiguration to find candidate configurations, filters them with conditions, and registers the beans that match. In older 2.x projects those candidates are commonly listed in spring.factories; from 2.7 onward the dedicated AutoConfiguration.imports file is the path used by current Boot releases.”

That order matters. Starting with the filename makes the answer sound like a memorized implementation detail. Starting with the pipeline shows that you understand what the framework is trying to do. The version note then proves that your knowledge is not frozen at the first tutorial you read.

Common wrong answers, fixed

“Spring Boot 3 deleted spring.factories.”

Not quite. It stopped using the EnableAutoConfiguration key in that file for auto-configuration registration. Other Spring factories keys can still be relevant.

“Spring Boot scans every configuration class in the dependencies.”

That is too broad. It discovers candidates through the supported auto-configuration mechanism, then filters them using exclusions, ordering, and conditions. It does not simply component-scan every dependency.

“Auto-configuration always wins over my bean.”

The design usually aims for the opposite. Conditions such as @ConditionalOnMissingBean let the application’s own bean take precedence, so the default configuration backs off.

“Spring Boot 4 has a completely new auto-configuration system.”

The platform changed, but the answer to this particular question did not need a new discovery file. Boot 4.1 continues the @AutoConfiguration plus AutoConfiguration.imports model.

“I can answer without naming a version.”

Sometimes. It is still a missed opportunity. Saying “In Boot 2.x…” or “For Boot 3 and later…” takes one breath and tells the interviewer you have worked with the code rather than memorized a sentence from an old tutorial.

What to memorize before the interview

Keep this small map in your notes:

@SpringBootApplication
  → @EnableAutoConfiguration
  → AutoConfigurationImportSelector
  → candidates
  → exclusions and ordering
  → @Conditional checks
  → beans in the application context

And keep the version boundary next to it:

Before 2.7: spring.factories
2.7:        new imports file + old compatibility path
3.x:        AutoConfiguration.imports
4.1:        AutoConfiguration.imports

The answer is not “Spring Boot reads a file.” The answer is “Spring Boot finds candidates, checks whether they belong, and backs off when the application has already made the choice.” The file name matters because it proves you know the version. The conditions matter because they prove you understand the mechanism.

For the interview itself, Cowinx is a macOS AI interview copilot that can help you keep track of the conversation and recover when you get stuck. If you are comparing products, see Cowinx vs Final Round AI and other interview tools.