How do you disable Auto Configuration?

Hook: Interviewers love this one because a single exclusion can save startup time—or cause a missing-bean crash if you remove the wrong auto-config.

Question: How do you disable Auto Configuration?

Answer: In Spring Boot, you usually disable specific auto-configurations, not all of them. The common ways are `@SpringBootApplication(exclude = ...)`, `@EnableAutoConfiguration(exclude = ...)`, or the `spring.autoconfigure.exclude` property with fully qualified class names. If you truly want no auto-configuration at all, you use plain `@Configuration` and `@ComponentScan` instead of Boot’s auto-config annotations.

Interview-Ready Answer: I disable auto-configuration by excluding the auto-config classes I do not want. I can do that directly on `@SpringBootApplication`, on `@EnableAutoConfiguration`, or externally with `spring.autoconfigure.exclude` in properties or the environment. If I want to turn off auto-configuration completely, I do not use `@EnableAutoConfiguration` at all and fall back to plain Spring configuration. The important detail is that Spring Boot filters those classes before it imports them, so the unwanted beans are never created.

What you are actually disabling

Spring Boot auto-configuration is the part that adds sensible default beans based on the classpath and existing beans. It is not the same as component scanning. When you disable one auto-config class, Boot simply stops offering that default setup; your own `@Bean` methods and scanned components still work.

How it works under the hood

1. `@SpringBootApplication` includes `@EnableAutoConfiguration`, which triggers `AutoConfigurationImportSelector`.
2. Boot loads the candidate auto-config classes from `META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports` in Spring Boot 3, or from `spring.factories` in Spring Boot 2.
3. It collects exclusions from three places: the annotation attribute, the `spring.autoconfigure.exclude` property, and any programmatic exclusions passed to the application.
4. Boot filters out the excluded class names before registration.
5. The remaining auto-configurations are then conditionally applied with rules such as `@ConditionalOnClass` and `@ConditionalOnMissingBean`.
6. If you excluded the class that would have created a bean, any other bean that depends on that bean may fail at startup with `NoSuchBeanDefinitionException` or a missing configuration error.

Ways to disable it

When to use it

Use exclusion when Boot guessed wrong: for example, JDBC starter on the classpath but no database, a scheduler you do not want, or security defaults that conflict with a custom setup. Do not use it just to make startup quieter; if a bean is there for a good reason, replacing it with your own bean is often cleaner than removing Boot’s default.

Performance and version notes

The filter step is basically linear in the number of candidate auto-configurations, so think O(n) where n is usually a few dozen to a couple hundred classes depending on starters. The real savings come from skipping the beans themselves: avoiding database connection setup, ORM initialization, schema checks, or embedded server wiring can save hundreds of milliseconds and sometimes seconds. In Spring Boot 3, discovery moved to the `AutoConfiguration.imports` file; the exclusion API stayed the same, so the interview answer is stable across versions.

Important edge cases

Excluding an auto-config class does not stop your own manual `@Bean` methods from running. Also, excluding by class name only works if the string is exact; a typo silently leaves the unwanted auto-config in place. Finally, remember that some auto-configurations depend on others, so removing one may cause a downstream auto-config to back off or fail because a required bean is gone.

Real-world story: A checkout service in an e-commerce system added `spring-boot-starter-jdbc` only because a shared library pulled it in. On the next deploy, Boot tried to auto-configure a datasource, but the service had no `spring.datasource.url`, so startup failed with `Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource could be configured`. Users saw 503s because the pod never became ready. The fix was either to remove the unwanted starter or exclude `DataSourceAutoConfiguration` until the service actually needed a database. The lesson: a single auto-configured bean can decide whether your app starts or stalls at the door.

Follow-up & Tricky Questions:

• How is `exclude` different from `excludeName`? `exclude` uses real class references, so it is safer and gives compile-time checking. `excludeName` uses strings, which is useful when the class is optional or you do not want a hard dependency.
• Can I disable auto-configuration from `application.properties` only? Yes, with `spring.autoconfigure.exclude`. That is handy when you want the same artifact to behave differently in dev, test, and production without code changes.
• What happens if another auto-config needs the one I excluded? It usually backs off or the app fails during startup because a required bean is missing. This is why exclusions should be narrow and intentional.
• How do I see which auto-configurations were applied? Run with `--debug` to get the condition evaluation report, or use the Actuator `conditions` endpoint. That shows why a configuration matched or backed off.
• Does excluding auto-configuration stop my own `@Bean` methods? No. Exclusion only prevents Boot from creating its default beans; your manual beans and scanned components still load.
• Is there a single switch to turn off all auto-configuration? Not as a normal Boot toggle. If you want zero auto-configuration, do not use `@EnableAutoConfiguration` or `@SpringBootApplication`; use plain Spring configuration instead.
• If I exclude `DataSourceAutoConfiguration`, does Boot still scan repositories? Repository scanning can still happen, but anything that needs a datasource may fail or stay inactive. The exclusion removes the default datasource setup, not your package scanning rules.
• Is a typo in `spring.autoconfigure.exclude` obvious? Often no. Because it is string-based, a wrong fully qualified class name can be easy to miss and the auto-config will still load.

Common Mistakes:

• Excluding the starter instead of the auto-config class: fix by targeting the actual `...AutoConfiguration` class, not the dependency name.
• Trying to use one magic switch for everything: fix by excluding only the classes you do not want, or removing auto-config annotations entirely if you want none.
• Forgetting to replace a removed bean: fix by defining your own `@Bean` when some downstream code still needs that type.
• Using `excludeName` when you do not need it: fix by preferring class-based `exclude` for compile-time safety.

Memory Hook: Think of Spring Boot as a buffet: exclusions put a small ‘do not serve’ sign on one dish, while removing `@EnableAutoConfiguration` closes the whole kitchen.

Cheat Sheet:

• `@SpringBootApplication(exclude = ...)` is the quickest code-based option.
• `spring.autoconfigure.exclude` is best for externalized, environment-specific control.
• `excludeName` is useful when the class may not be on the compile classpath.
• To disable all auto-config, do not use `@EnableAutoConfiguration`.
• Exclusion happens before beans are imported, so missing dependencies can surface at startup.
• Boot 3 uses `AutoConfiguration.imports`; the exclusion idea is the same as in Boot 2.

Practice Tasks:

• Start a Boot app, exclude `TaskExecutionAutoConfiguration`, and confirm that `applicationTaskExecutor` disappears.
• Add `spring-boot-starter-jdbc`, then exclude `DataSourceAutoConfiguration` and observe how startup changes.
• Run the app with `--debug` and read the condition report to see why an auto-config matched or backed off.