Interview Prep Zoneby CuriouserLabs

Question 4 of 5 · senior level

Auto-configuration is doing something you don't want. Walk me through your escalation ladder to take control.

🎤 Say this first

Escalate gently: (1) properties — most behavior has a knob (spring.datasource.hikari.*, server.*); (2) define your own bean — auto-config backs off via @ConditionalOnMissingBean; (3) customizer/BeanPostProcessor hooks many auto-configs expose (WebServerFactoryCustomizer, RestClientCustomizer) to tweak rather than replace; (4) exclude the auto-configuration class entirely; (5) nuclear: your own @AutoConfiguration earlier in the order or a BFPP editing definitions. Diagnose first with the condition evaluation report so you're overriding the right thing.

The full picture

  1. Property: check configprops/actuator + reference docs before writing code — 'there's a property for that' is true shockingly often.
  2. Own bean: e.g., define ObjectMapper and Boot's Jackson config steps aside — but prefer Jackson2ObjectMapperBuilderCustomizer (next rung) to keep Boot's sensible defaults and change only what you need.
  3. Customizers: the intended extension seam — additive, composable, upgrade-friendly.
  4. Exclude: exclude = SecurityAutoConfiguration.class (or spring.autoconfigure.exclude) when replacing a subsystem wholesale.
  5. Verify: re-run with --debug — confirm the condition report now shows the auto-config unmatched for the reason you intended (your bean present), not accidentally (missing class).

🔄 Likely follow-up questions

  • How do you find which auto-configuration created a given bean? (conditions report, actuator beans)
  • When is a BeanPostProcessor the right override tool vs a customizer?
  • What ordering guarantees exist between your @Configuration and auto-configs?