Spring Boot Auto-configuration Explained: How @EnableAutoConfiguration Works

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.

This is the core of the "convention over configuration" philosophy and one of the highest-weighted topics on the 2V0-72.22 exam (Spring Boot = 28% of all 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

@EnableAutoConfiguration tells Spring Boot to load auto-configuration classes from the classpath. Here is how it works:

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).

Spring Boot 3.x — AutoConfiguration.imports

Spring Boot 3.x replaced spring.factories with a dedicated file:

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

Each line is one auto-configuration class name. This is more explicit and faster to process. Note: This format is not covered by the 2V0-72.22 exam, but it is good to know for real-world Spring Boot 3 projects.

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.

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.

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

→ View 970+ Questions on Udemy — full practice exam bank with video explanations