Boot Properties & Auto-Configuration practice questions

Worked examples for Boot Properties & Auto-Configuration

1. Question 1

   A vendor called Acme wants to publish a reusable Spring Boot integration for its messaging client so that adding one dependency gives applications working defaults that still back off when the application declares its own beans. The team is deciding how to structure and name the artifacts they publish to Maven Central. Which statement correctly describes the roles of an `autoconfigure` module and a `starter` module, and the naming rule for a third-party starter?

   1. A. The starter module must contain the auto-configuration classes and the auto-configuration candidates file, while the `autoconfigure` module exists only to declare the optional third-party dependencies those classes are conditional on.

      Inverts the roles of the two modules. The auto-configuration classes, their conditions, and the candidates file belong in the `autoconfigure` module; the starter is the dependency-aggregating artifact, not the code-bearing one.

   2. B. The `autoconfigure` module holds the auto-configuration classes, their conditions, and the auto-configuration candidates file; the starter is essentially an empty artifact that depends on the `autoconfigure` module plus the libraries needed to make the feature useful. A third-party starter should be named `acme-spring-boot-starter`, because the `spring-boot-starter-` prefix is reserved for official Spring Boot starters — and the two concerns may be combined into a single module if the team does not need to separate them.Correct answer

      Correct on all three points, per the 'Creating Your Own Starter' guidance: the `autoconfigure` module carries the conditional configuration code, the starter carries only dependencies so that one coordinate pulls in a working setup, third-party starters use the `<name>-spring-boot-starter` pattern because the reversed prefix is reserved for the Spring Boot team, and the split is a convention that may be collapsed into one module.

   3. C. The artifact must be named `spring-boot-starter-acme`, because `@EnableAutoConfiguration` discovers auto-configurations by scanning the classpath for jars whose names begin with `spring-boot-starter-`.

      Names the misconception that auto-configuration discovery is driven by artifact naming. Discovery is driven entirely by the auto-configuration candidates file inside the jar; furthermore the `spring-boot-starter-` prefix is reserved for starters maintained by the Spring Boot team, so a third party must not use it.

   4. D. Publishing two modules is mandatory: an auto-configuration cannot back off correctly with `@ConditionalOnMissingBean` unless the conditional code and the dependency declarations are packaged in separate artifacts.

      Names the misconception that the two-module split is a functional requirement of the condition mechanism. Bean conditions are evaluated at runtime against the classpath and bean registry and are indifferent to module layout; the reference documentation explicitly allows combining the two concerns into a single module when separation is not needed.

   Explanation

   A starter is a dependency descriptor: it contains essentially no code and simply pulls in the auto-configuration module together with whatever libraries the technology needs, so an application gets a working, opinionated setup from a single coordinate. The auto-configuration module is where the conditional configuration lives — the auto-configuration classes, their `@ConditionalOn...` annotations, and the file that lists them as candidates. Naming follows `<name>-spring-boot-starter` for third parties because the reversed `spring-boot-starter-<name>` prefix is reserved for starters maintained by the Spring Boot team, and the two modules may be merged into one when the separation of concerns is not needed. Explanations that swap the two modules' contents, that tie discovery or back-off behaviour to artifact naming or module layout, all misplace mechanisms that are actually governed by the candidates file and by runtime condition evaluation.

2. Question 2

   A library's auto-configuration class declares a `@Bean` method whose **declared return type is the concrete class `RedisCacheManager`**, annotated with a bare `@ConditionalOnMissingBean` (no attributes). An application that uses the library defines its own bean in a `@Configuration` class: a `CaffeineCacheManager`, which is a different implementation of the `CacheManager` interface. The application then fails to start with an ambiguity error when a component injects a `CacheManager`. What is the correct explanation and fix?

   1. A. Bean conditions match on bean *name* by default, so the two definitions only clash because both methods are named `cacheManager`; renaming the library's `@Bean` method resolves the ambiguity.

      Confuses type-based matching with name-based matching. `@ConditionalOnMissingBean` matches by type (optionally narrowed by `name`, `annotation`, or `ignoredType` attributes); renaming the method would leave two distinct `CacheManager` beans in the context and the by-type injection ambiguity unchanged.

   2. B. The condition inspects the runtime object each candidate bean would produce, so it should already have detected the `CaffeineCacheManager` as a `CacheManager` and backed off; the failure indicates the application's `@Configuration` class was not component-scanned.

      Assumes runtime-type introspection. Conditions are evaluated against bean *definitions* and declared metadata before beans are instantiated — the container must not eagerly create beans to answer a condition — so the runtime implementation type of a not-yet-created bean is not what the condition sees.

   3. C. Because auto-configuration is always processed after user-declared beans, any user bean present in the context suppresses every conditional bean in the auto-configuration class regardless of type; the failure means the library class was imported too early and needs `@AutoConfigureAfter`.

      Overreads the 'auto-configuration applies last' rule as a blanket, type-independent suppression. Late ordering is what makes back-off *possible*, but each condition still evaluates its own target type; ordering annotations change evaluation sequence, not the type a bean condition looks for.

   4. D. With no attributes, the condition's target type defaults to the method's **declared return type**, so it searches only for an existing `RedisCacheManager`; the application's `CaffeineCacheManager` does not satisfy it and both beans are registered. The auto-configuration should state the target explicitly, e.g. `@ConditionalOnMissingBean(CacheManager.class)`.Correct answer

      This is the documented behaviour of bean conditions: when placed on a `@Bean` method, the target type defaults to the method's return type, which is why a concrete return type must be paired with an explicit target type (as Spring Boot's own `DataSource` auto-configuration does) for the bean to back off against any user-supplied implementation (Spring Boot reference, Bean Conditions).

   Explanation

   When a bean condition such as `@ConditionalOnMissingBean` is placed on a `@Bean` method without attributes, the type it searches for defaults to that method's declared return type. Declaring a concrete implementation as the return type therefore narrows the search to that exact type, so a user-supplied bean of a sibling implementation is invisible to the condition and both definitions survive — the fix is to name the interface as the condition's target type (or declare the interface as the return type). Bean conditions are type-based rather than name-based, so renaming the method changes nothing; they are evaluated against bean definitions before instantiation, so no runtime type of an uncreated bean is available to them; and the fact that auto-configuration is evaluated after user configuration only makes back-off possible — it never suppresses conditional beans irrespective of the type each condition actually looks for.

3. Question 3

   An auto-configuration declares a bean with `@ConditionalOnMissingBean(SomeService.class)`, where `SomeService` is an interface. In the application, a developer declares a `@Bean` method whose declared return type is `SpecialService`, a concrete class implementing `SomeService`, and gives the bean a name unrelated to the auto-configured one. Assuming no other beans of that type exist, what happens to the auto-configured bean?

   1. A. It is still registered, because the condition matches only a bean whose declared type is exactly `SomeService`.

      Misconception that bean-type conditions require an exact type match. Type matching is assignability-based, so any bean assignable to the specified type — including subtypes and implementations — satisfies it.

   2. B. It is still registered, because the developer's bean has a different bean name than the auto-configured bean.

      Confuses the type-based form with the name-based one. `@ConditionalOnMissingBean` matches on name only when its `name` attribute is used; with a type argument the bean name is irrelevant.

   3. C. It is not registered — the auto-configuration backs off, because the developer's bean is assignable to `SomeService`.Correct answer

      Bean conditions resolve candidates by assignable type against the bean factory, so a `SpecialService` bean counts as a `SomeService` and the condition finds a matching bean, suppressing the auto-configured definition.

   4. D. It is still registered, and the application must annotate its own bean with `@Primary` for the condition to detect it.

      Misconception that `@Primary` participates in condition evaluation. `@Primary` only breaks ties when multiple candidates are injected; the condition simply asks whether any bean of the type exists.

   Explanation

   The type-based form of `@ConditionalOnMissingBean` asks the bean factory whether any bean assignable to the given type is already known, using the same assignability rules as type-based lookup — so a bean whose declared type is a concrete implementation satisfies a condition expressed on the interface. Because the condition is satisfied, the auto-configured definition is never registered and the application's implementation stands alone. Requiring an exact declared type misreads assignability; expecting bean names to matter confuses this with the `name` attribute variant of the annotation; and `@Primary` plays no part in condition evaluation, since it only disambiguates among multiple injection candidates.

4. Question 4

   During a code review, a developer defends placing `@ConditionalOnMissingBean` on a `@Bean` method inside an ordinary application `@Configuration` class, arguing that it will make the bean back off whenever any other class in the application already declares a bean of that type. Which statement best explains why the Spring Boot reference documentation states that bean conditions such as `@ConditionalOnBean` and `@ConditionalOnMissingBean` are intended only for auto-configuration classes?

   1. A. Bean conditions are evaluated as bean definitions are registered, so they can only see definitions processed up to that point; auto-configuration is guaranteed to be evaluated after user-defined beans, while an ordinary `@Configuration` class yields order-dependent, unreliable results.Correct answer

      This is the documented rationale: auto-configuration is always applied last, after user beans have been registered, so bean conditions there see a settled picture. On user configuration the outcome depends on parsing order, so the guidance restricts these conditions to auto-configuration.

   2. B. Bean conditions are evaluated only after the application context has been fully refreshed and every bean definition is known, so their placement on a user `@Configuration` class is harmless and always accurate.

      Confuses condition evaluation with post-refresh runtime inspection. Conditions are evaluated while configuration classes are parsed and bean definitions are registered, not against a completed context, which is precisely what makes them order-sensitive.

   3. C. `@ConditionalOnMissingBean` can only inspect `@Bean` methods declared within the same `@Configuration` class, so it is unable to detect a bean of the same type contributed by any other class.

      Misconception that the condition's visibility is class-local. It inspects the shared bean factory's registered definitions, not just the enclosing class — the real limitation is *when* it looks, not *where*.

   4. D. Bean conditions are rejected outside classes registered as auto-configuration, and the context fails to start with a configuration error if one is found on a regular `@Configuration` class.

      Treats documented guidance as an enforced constraint. Nothing validates the placement or fails startup; the annotation is simply evaluated at an unpredictable point, which is a silent correctness hazard rather than an error.

   Explanation

   Bean conditions are resolved during configuration-class parsing, at the moment each bean definition would be registered, so they can only observe what has already been processed. Auto-configuration is deliberately applied after all user-defined beans are registered, which makes those conditions dependable there; on ordinary application configuration the same condition sees whatever happened to be parsed first, producing order-dependent behaviour. That is why the guidance is about reliability rather than a class-local scope limitation, an enforced restriction that fails startup, or an evaluation that happens once the context is fully refreshed.

5. Question 5

   To support both Spring Boot 2.6 and 2.7, a library lists the SAME auto-configuration class in both META-INF/spring.factories (under the EnableAutoConfiguration key) and the new META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports file. On Spring Boot 2.7, what is the result?

   1. A. Boot 2.7 ignores spring.factories completely, so if the imports file has a typo the auto-configuration silently disappears with no fallback.

      Boot 2.7 still honors the spring.factories entry for backward compatibility, so it is not ignored; it acts as a fallback path rather than being dropped.

   2. B. The class is registered twice and its beans are contributed twice, failing on a duplicate bean definition unless overriding is enabled.

      Classes listed in both files are de-duplicated, so the auto-configuration and its beans are registered only once.

   3. C. Boot 2.7 rejects the ambiguous registration with an IllegalStateException at startup.

      Listing a class in both files is an explicitly supported dual-compatibility pattern; it does not throw — the duplicate is simply de-duplicated.

   4. D. Boot 2.7 still honors the spring.factories entry for backward compatibility and de-duplicates classes listed in both files, so the auto-configuration is applied exactly once.Correct answer

      The spring.factories key remains honored (deprecated) in 2.7, and entries appearing in both files are de-duplicated, letting a single library support 2.6 and 2.7 with the class applied once.

   Explanation

   Boot 2.7 keeps honoring the deprecated spring.factories EnableAutoConfiguration key for backward compatibility, and it de-duplicates any class that appears in both spring.factories and the new AutoConfiguration.imports file. That means the auto-configuration is applied exactly once, which is precisely how a library targets both 2.6 and 2.7. It is neither ignored, nor double-registered, nor a startup error.

6. Question 6

   A team is onboarding a legacy Spring application onto Spring Boot. The application has a dozen `@Configuration` classes, none of which is annotated with `@SpringBootApplication`, and the team is unsure how auto-configuration becomes active and how far it reaches. Which statement correctly describes the role of `@EnableAutoConfiguration` in a Spring Boot application?

   1. A. Auto-configuration is active by default for any application with Spring Boot on the classpath; `@EnableAutoConfiguration` only increases the verbosity of the auto-configuration report at startup.

      Assumes auto-configuration is implicit. The documentation is explicit that it is an opt-in feature; report verbosity is controlled separately by enabling debug logging, not by this annotation.

   2. B. Auto-configuration is opt-in: exactly one `@Configuration` class should carry `@EnableAutoConfiguration` (or `@SpringBootApplication`, which includes it), after which Boot attempts to configure beans by inspecting the jars on the classpath and the beans the application has already defined.Correct answer

      This matches the documented contract — you opt in by adding one of the two annotations to a single `@Configuration` class, and auto-configuration then guesses and configures beans from classpath contents while deferring to beans you define yourself.

   3. C. `@EnableAutoConfiguration` also performs classpath scanning for `@Component`-annotated classes, so declaring `@ComponentScan` alongside it is redundant.

      Conflates auto-configuration with component scanning. They are distinct concerns — `@SpringBootApplication` is a convenience annotation that combines `@EnableAutoConfiguration`, `@ComponentScan`, and `@Configuration`, which would be pointless if one implied the other.

   4. D. `@EnableAutoConfiguration` should be repeated on every `@Configuration` class so that each one can consume auto-configured beans; classes lacking the annotation are excluded from auto-configured infrastructure.

      Misconception that the annotation scopes auto-configuration per configuration class. Auto-configuration contributes beans to the single shared application context available to all configuration classes, and the guidance is to add the annotation to only one class.

   Explanation

   Auto-configuration must be opted into by adding `@EnableAutoConfiguration` — or `@SpringBootApplication`, which bundles it together with `@Configuration` and `@ComponentScan` — to a single configuration class; the documentation advises adding only one such annotation, typically on the primary configuration class. Once enabled, Boot infers what to configure from the jars present on the classpath and from beans the application has already declared, contributing them to the one shared context rather than to individual classes. So it is neither implicitly active, nor a substitute for component scanning, nor something to repeat on every configuration class.

7. Question 7

   A team wants a single `application.yml` to hold both the shared defaults and the `prod`-specific overrides, instead of maintaining a separate `application-prod.yml`. Which Spring Boot externalized-configuration feature supports this, and how is the profile-specific section marked?

   1. A. Enclose the overrides in a `profiles: prod:` nested block anywhere in the YAML tree; Boot activates any subtree whose parent key is `profiles`

      Invents an arbitrary nested-key convention. Profile activation is a document-level concern declared via spring.config.activate.on-profile, not an ordinary nested key that can appear anywhere.

   2. B. Split the file into multiple documents separated by `---`, and mark the profile-specific document with `spring.config.activate.on-profile: prod`Correct answer

      Multi-document files are the documented mechanism: YAML documents are separated by --- and a document is conditionally activated by spring.config.activate.on-profile.

   3. C. Prefix each overriding key with the profile name, for example `prod.server.port`, so Boot strips the prefix when that profile is active

      Confuses profile activation with key prefixing. Boot does not strip a profile prefix from property keys; such a key would simply be a distinct property named prod.server.port.

   4. D. Set `spring.profiles.active: prod` inside the same document as the overrides, which both activates the profile and scopes the surrounding keys to it

      Conflates activating a profile with conditionally activating a document, and spring.profiles.active is not permitted in a profile-conditional document; it never scopes neighbouring keys to a profile.

   Explanation

   Spring Boot supports multi-document configuration files: a YAML file can be split into several documents with `---` (properties files use `#---`), and any document can be made conditional with `spring.config.activate.on-profile`, which is the supported way to keep shared defaults and profile-specific overrides in one file. Profile scoping therefore operates at document granularity, not via an arbitrary nested key, a profile-name prefix on individual keys, or `spring.profiles.active`, which activates a profile rather than gating the surrounding configuration.

8. Question 8

   How does Spring Boot decide which auto-configuration classes to apply?

   1. A. Candidate auto-configurations are registered (via spring.factories / AutoConfiguration imports) and each is applied conditionally based on @Conditional checks — classpath contents, existing beans, set propertiesCorrect answer

      @EnableAutoConfiguration loads a curated list of candidate configurations, and each guards itself with conditions such as @ConditionalOnClass, @ConditionalOnMissingBean, and @ConditionalOnProperty, so only the relevant ones activate.

   2. B. You must list each auto-configuration you want in application.properties

      Auto-configuration requires no manual listing; the candidate list is registered by starters and Boot itself, not enumerated by the user in application.properties.

   3. C. It unconditionally applies every auto-configuration that ships with Boot

      Application is not unconditional — each candidate is gated by @Conditional checks and backs off when its conditions are not met.

   4. D. It scans the whole classpath and instantiates every class it finds

      It is not a blanket classpath instantiation; only registered candidate configurations are considered, and each activates only if its conditions pass.

   Explanation

   Spring Boot registers a curated set of candidate auto-configuration classes and then applies each one conditionally, guarding it with checks such as @ConditionalOnClass, @ConditionalOnMissingBean, and @ConditionalOnProperty. Only configurations whose conditions are satisfied by the classpath, existing beans, and set properties actually activate — it is neither an unconditional sweep nor a manual opt-in list.