How Spring Boot Auto-Configuration Works (2026 Exam Guide)

Auto-configuration is the feature that makes Spring Boot opinionated. Instead of forcing you to wire every bean manually, Spring Boot inspects your classpath, existing beans, and properties — then configures sensible defaults automatically. If you're still clarifying how Boot relates to the core framework, start with Spring vs Spring Boot.

This is the core of the "convention over configuration" philosophy and one of the highest-weighted topics on the 2V0-72.22 exam — the Spring Boot section of the exam carries about 28% of all questions. It is also one of the most common interview questions: see our full set of Spring Boot interview questions.

The Entry Point: @SpringBootApplication

Every Spring Boot application starts with @SpringBootApplication, which is a composed annotation combining three things:

@SpringBootConfiguration   // = @Configuration
@EnableAutoConfiguration   // triggers auto-config
@ComponentScan             // scans the current package and sub-packages
public class MyApp {
    public static void main(String[] args) {
        SpringApplication.run(MyApp.class, args);
    }
}

The key annotation is @EnableAutoConfiguration — without it, no auto-configuration takes place.

How @EnableAutoConfiguration Works

What does @EnableAutoConfiguration do? It tells Spring Boot to scan the classpath for auto-configuration classes and apply the ones whose @Conditional checks pass. At startup it loads the list of candidate classes (from spring.factories in Boot 2.x, or AutoConfiguration.imports in Boot 3), then registers each one as a @Configuration only if its conditions match your classpath, beans, and properties. It is included automatically inside @SpringBootApplication, so you rarely declare it directly.

Here is how that process works step by step:

Step 1 — spring.factories (Spring Boot 2.x — exam version)

The 2V0-72.22 exam is based on Spring Boot 2.x, which uses a file at:

META-INF/spring.factories

Inside each starter JAR, this file lists auto-configuration classes under the EnableAutoConfiguration key:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
  org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration,\
  org.springframework.boot.autoconfigure.data.jpa.JpaRepositoriesAutoConfiguration,\
  org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

At startup, SpringFactoriesLoader reads all spring.factories files from the classpath, collects every listed class, and registers them as auto-configuration candidates.

Step 2 — Filtering with @Conditional

The candidates are not applied blindly. Each auto-configuration class uses @Conditional annotations to decide whether to activate (see next section).

Step 3 — Registration as @Configuration

Each candidate that survives its conditions is treated as a regular @Configuration class, so its @Bean methods run and contribute beans to the context — after your own configuration, never before it.

spring.factories vs AutoConfiguration.imports (Boot 2.7 → 3.0)

The mechanism that lists auto-configuration candidates changed between Spring Boot versions. This is a common source of confusion when you move a project from Boot 2.x to Boot 3, and exact, versioned questions about it show up in search.

In Spring Boot 2.6 and earlier, candidates live in META-INF/spring.factories under the EnableAutoConfiguration key:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
  com.example.MyServiceAutoConfiguration

Spring Boot 2.7 introduced a dedicated file and a new annotation, while keeping the old spring.factories entry working for backward compatibility:

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

// Boot 2.7+: @AutoConfiguration replaces @Configuration on auto-config classes.
// It implies @Configuration(proxyBeanMethods = false) and carries ordering hints.
@AutoConfiguration
@ConditionalOnClass(MyService.class)
public class MyServiceAutoConfiguration { ... }

Each line of AutoConfiguration.imports is a single fully-qualified class name — no trailing backslashes, no key. It is more explicit and faster to parse than spring.factories.

In Spring Boot 3.0, the EnableAutoConfiguration key in spring.factories was removed entirely. From Boot 3 onward, the AutoConfiguration.imports file is the only supported way to register auto-configuration candidates.

Exam tip: The 2V0-72.22 exam targets Spring Boot 2.x, so the exam-relevant answer is META-INF/spring.factories. Know AutoConfiguration.imports for real Boot 3 projects, but pick spring.factories on the exam.

The @Conditional System

Auto-configuration classes use @Conditional annotations to decide whether their beans should be created:

Example: DataSourceAutoConfiguration

@Configuration
@ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class })
@ConditionalOnMissingBean(type = "io.r2dbc.spi.ConnectionFactory")
@EnableConfigurationProperties(DataSourceProperties.class)
public class DataSourceAutoConfiguration {
    // Creates DataSource bean only if:
    // 1. DataSource class is on classpath (e.g., H2, PostgreSQL driver)
    // 2. No R2DBC connection factory exists
}

If you add spring-boot-starter-data-jpa to your project, it pulls in spring-boot-starter-jdbc, which brings EmbeddedDatabaseType.class (from spring-jdbc) onto the classpath. Combined with DataSource.class (always available from java.sql), both conditions pass → Spring Boot auto-configures a DataSource for you.

@ConditionalOnClass and @ConditionalOnMissingBean in Depth

These two conditions do most of the work in real auto-configuration, so the exam tests them closely.

@ConditionalOnClass — checks the classpath without loading the class

@ConditionalOnClass activates a configuration only when a given type is present on the classpath. The subtle part: Spring evaluates it by reading bytecode with ASM, so it checks for the class by name without actually loading it. That is why an auto-configuration class can safely reference a type that might be absent at runtime — if the class is missing, the condition simply fails and the configuration backs off instead of throwing NoClassDefFoundError.

@AutoConfiguration
@ConditionalOnClass(name = "org.springframework.aop.framework.ProxyFactory")
public class AspectSupportAutoConfiguration {
    // Only contributes when Spring AOP is on the classpath.
    // See how AOP proxies are applied in our
    // Spring AOP & pointcut guide.
}

For the same reason, Spring Boot can auto-configure features like Spring AOP proxying the moment the relevant starter appears on the classpath — and quietly skip them when it does not.

@ConditionalOnMissingBean — enables your overrides and is order-sensitive

@ConditionalOnMissingBean activates only when a bean of the given type is not already defined. Because user @Configuration is always processed before auto-configuration, your bean wins and the auto-configured one backs off (covered in the next section).

The trap: @ConditionalOnBean and @ConditionalOnMissingBean are order-sensitive. They only see beans that were registered before the condition is evaluated, so they rely on auto-configuration ordering (@AutoConfigureAfter / @AutoConfigureBefore). Using them to react to another auto-configuration's beans only works if your class is ordered to run after it.

Exam tip: @ConditionalOnClass is classpath-based and evaluated without loading the class; @ConditionalOnMissingBean is bean-based and order-sensitive. Mixing these two ideas up is a classic exam trap.

Override Auto-configuration with Your Own Beans

The most important @Conditional for developers is @ConditionalOnMissingBean. This means:

"Apply this auto-configuration ONLY if the user hasn't already defined their own bean."

This is how you override defaults:

@Configuration
public class MyDataSourceConfig {
 
    @Bean
    public DataSource dataSource() {
        // Your custom DataSource — Spring Boot's auto-config backs off
        HikariDataSource ds = new HikariDataSource();
        ds.setJdbcUrl("jdbc:postgresql://localhost/mydb");
        return ds;
    }
}

Because @ConditionalOnMissingBean(DataSource.class) detects your bean, the auto-configured DataSource is skipped entirely. Your beans always take priority over auto-configured ones.

Excluding Auto-configuration

Sometimes you want to disable a specific auto-configuration class entirely:

@SpringBootApplication(exclude = {
    DataSourceAutoConfiguration.class,
    SecurityAutoConfiguration.class
})
public class MyApp { ... }

Or via application.properties:

spring.autoconfigure.exclude=\
  org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

Exam tip: Both approaches are valid. The exclude attribute works when you have the class on the classpath. For classes not on the classpath, use excludeName (String-based) instead.

Auto-configuration Order

Auto-configuration classes can declare ordering relative to each other:

@Configuration
@AutoConfigureAfter(DataSourceAutoConfiguration.class)
public class JpaRepositoriesAutoConfiguration { ... }

• @AutoConfigureAfter — run this after the specified class
• @AutoConfigureBefore — run this before the specified class
• @AutoConfigureOrder — numeric ordering (lower values = earlier)

Note: These annotations only affect ordering among auto-configuration classes. They do not affect the order of user-defined @Configuration classes. User configurations are always processed before auto-configurations.

Debugging Auto-configuration

When you need to understand why a specific bean was or wasn't auto-configured, Spring Boot provides a Conditions Evaluation Report.

Enable it by adding to application.properties:

debug=true

Or by passing the --debug flag at startup:

java -jar myapp.jar --debug

The report prints to the console at startup and shows:

• Positive matches — auto-configs that were applied (and which conditions passed)
• Negative matches — auto-configs that were skipped (and which condition failed)
• Unconditional classes — always applied

You can also access this information at runtime via the Actuator /conditions endpoint (if spring-boot-starter-actuator is on the classpath):

GET /actuator/conditions

Writing Your Own Auto-configuration

You can create custom auto-configuration for your own libraries:

@Configuration
@ConditionalOnClass(MyService.class)
@ConditionalOnMissingBean(MyService.class)
public class MyServiceAutoConfiguration {
 
    @Bean
    public MyService myService() {
        return new MyService();
    }
}

Register it in META-INF/spring.factories:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
  com.example.MyServiceAutoConfiguration

The key principle: always use @ConditionalOnMissingBean so users can override your defaults by defining their own bean.

Exam Quick Reference

Frequently Asked Questions

What is Spring Boot auto-configuration?

Auto-configuration is Spring Boot's mechanism for automatically creating and configuring beans based on your classpath, existing beans, and properties. It uses @Conditional annotations to make smart decisions — for example, if you have a PostgreSQL driver on the classpath, Spring Boot auto-configures a DataSource for you. It is triggered by @EnableAutoConfiguration, which is included in @SpringBootApplication.

What does @EnableAutoConfiguration do?

@EnableAutoConfiguration triggers Spring Boot's auto-configuration: it loads the list of candidate auto-configuration classes from the classpath (spring.factories in Boot 2.x, AutoConfiguration.imports in Boot 3) and applies each one whose @Conditional checks pass. The result is that beans like a DataSource, WebMvc setup, or Jackson ObjectMapper are configured automatically based on what is on your classpath. It is bundled inside @SpringBootApplication, so you almost never add it by hand.

How do I override an auto-configured bean?

Define your own @Bean of the same type. Most auto-configuration classes use @ConditionalOnMissingBean, which means they only create a bean if you haven't already defined one. Your custom bean takes priority automatically — no additional configuration needed.

What is the difference between spring.factories and AutoConfiguration.imports?

spring.factories (Spring Boot 2.x) is a multi-purpose file that lists auto-configuration classes under the EnableAutoConfiguration key. AutoConfiguration.imports (Spring Boot 3.x) is a dedicated file where each line is a single auto-configuration class name. Both serve the same purpose — registering auto-configuration candidates — but the newer format is simpler and faster. The 2V0-72.22 exam covers Spring Boot 2.x, so spring.factories is the exam-relevant format.

How do I find out which auto-configurations are active?

Set debug=true in application.properties or run with --debug. This prints a Conditions Evaluation Report at startup showing all positive matches (applied), negative matches (skipped with reasons), and unconditional classes. At runtime, the /actuator/conditions endpoint provides the same information as JSON.

→ Test your knowledge with practice questions — includes auto-configuration questions with detailed explanations

→ Spring Bean Scopes explained — understand how auto-configured beans are scoped

→ Spring Boot Actuator guide — the /conditions endpoint and other monitoring features

→ Get Full Access — 970+ Questions — full practice exam bank with detailed explanations