Custom Auto-Configuration (spring.factories / AutoConfiguration.imports)
Fast recall
Quick revision
Core answer
@ConditionalOn* guards, implement your @Bean methods, then register the class in `META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports` (Spring Boot 2.7+) so Spring Boot discovers it at startup. Use the two-module starter pattern — an autoconfigure module containing the @AutoConfiguration class plus a thin starter POM that aggregates dependencies. Always annotate @Bean methods with @ConditionalOnMissingBean so consumers can override defaults. Test with ApplicationContextRunner for fast assertions on bean presence and override behavior.Whether the candidate understands the registration mechanism and knows how to write safe conditions so the auto-configuration backs off correctly
Forgetting to add the registration file (the `@AutoConfiguration` class is never discovered), or using `@Configuration` instead of `@AutoConfiguration` which bypasses ordering guarantees
Describe the full starter module layout (autoconfigure JAR + starter POM), explain how `@AutoConfigureAfter`/`@AutoConfigureBefore` work, and show how `spring-boot-configuration-processor` generates IDE metadata from `@ConfigurationProperties`
Interview-ready guide
Interview answer
Writing a custom auto-configuration is how you package reusable Spring Boot behavior into a library that others use by simply adding the dependency — no manual bean registration required.
The registration file
- Spring Boot 2.7+: create
META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.importslisting the fully-qualified class name of your@AutoConfigurationclass - Without this file, Spring Boot never discovers your class — the most common mistake when writing the first custom auto-configuration
Starter module layout
my-feature-autoconfigureJAR: contains the@AutoConfigurationclass with@Conditionallogic and bean definitionsmy-feature-spring-boot-starterPOM: depends onautoconfigure+ the feature library; users add only the starter dependency and get everything
The override contract
- Every auto-configured bean must have
@ConditionalOnMissingBean— if the user defines their own bean of that type, yours is skipped - Use
@AutoConfiguration(after = DataSourceAutoConfiguration.class)when your beans depend on aDataSourcebeing available
Testing
ApplicationContextRunneris the standard testing tool — creates a minimal context, applies your auto-configuration, and lets you assert which beans registered- Three tests every auto-config needs: defaults, user override, negative case (
FilteredClassLoader) - No need to start the full application; tests run in milliseconds
IDE metadata
- Add
spring-boot-configuration-processorasoptional - Generates
spring-configuration-metadata.jsonso consumer IDEs auto-completemyprefix.*properties
In an interview, the strong answer is: two modules, `@AutoConfiguration` + `@ConditionalOnClass` + `@ConditionalOnMissingBean`, registration file, three tests including the negative case, and the configuration processor for IDE support.
Custom Auto-Configuration (spring.factories / AutoConfiguration.imports)
Direct Answer
Create an @AutoConfiguration class with @ConditionalOn* guards, implement your @Bean methods, then register the class in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (Spring Boot 2.7+) so Spring Boot discovers it at startup. Use the two-module starter pattern — an autoconfigure module containing the @AutoConfiguration class plus a thin starter POM that aggregates dependencies. Always annotate @Bean methods with @ConditionalOnMissingBean so consumers can override defaults. Test with ApplicationContextRunner for fast assertions on bean presence and override behavior.
Common Mistakes & Pitfalls
Forgetting to add the registration file (the @AutoConfiguration class is never discovered), or using @Configuration instead of @AutoConfiguration which bypasses ordering guarantees
Check your understanding
Answer these without looking back at the article.
- What is the difference between a Spring Boot starter and the autoconfigure module?
- How do you test that your auto-configuration backs off correctly when the user defines their own bean?
- How do `@AutoConfigureAfter` and `@AutoConfigureBefore` prevent ordering problems between auto-configurations?
- Why is `@AutoConfiguration` preferred over `@Configuration` for custom auto-configurations?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.