Spring Boot Features & Dependency Management practice questions

Worked examples for Spring Boot Features & Dependency Management

1. Question 1

   What does using spring-boot-starter-parent as your Maven parent give you?

   1. A. The application's business logic

      The starter parent is a build configuration parent; it supplies no application code or business logic.

   2. B. Only the version of spring-core and nothing else

      It manages far more than a single library — a whole curated set of compatible dependency versions, not just spring-core.

   3. C. Nothing beyond what a normal POM provides

      It adds real value over a bare POM through curated version and plugin management plus build defaults.

   4. D. Curated dependency management, plugin management, and sensible build defaults (Java version, UTF-8, resource filtering)Correct answer

      The starter parent supplies dependencyManagement for compatible versions, pluginManagement (e.g. the Boot plugin), and defaults such as the Java version, UTF-8 encoding, and resource filtering.

   Explanation

   Inheriting the starter parent hands a project a curated dependency-management section for mutually compatible versions, preconfigured plugin management, and opinionated build defaults. It is purely build configuration, so it never contributes application code and does far more than pin one library or a bare parent POM.

2. Question 2

   Spring Boot groups its starters into categories such as application, production, and technical. Which starter is the 'production' starter that adds production-ready features like monitoring, metrics, and management endpoints?

   1. A. spring-boot-starter-web

      spring-boot-starter-web is an application starter that brings in Spring MVC and an embedded container; it is not the production-ready features starter.

   2. B. spring-boot-starter-validation

      spring-boot-starter-validation is an application starter that pulls in a Bean Validation implementation; it provides no monitoring or management endpoints.

   3. C. spring-boot-starter-actuatorCorrect answer

      Correct: spring-boot-starter-actuator is Boot's production starter, adding production-ready features such as health, metrics, and management endpoints.

   4. D. spring-boot-starter-data-jpa

      spring-boot-starter-data-jpa is an application starter for persistence with Spring Data JPA and Hibernate, not a production-monitoring starter.

   Explanation

   Spring Boot's starter catalog is organized into application starters (web, data-jpa, validation, and so on), the single production starter spring-boot-starter-actuator for production-ready monitoring and management features, and technical starters that swap defaults such as the container or logging. The web, validation, and data-jpa starters are all application starters, so the actuator starter is the production one.

3. Question 3

   When you run a Spring Boot web application via SpringApplication.run(...), what happens with regard to the servlet container?

   1. A. The container starts only if the class is annotated @EnableEmbeddedTomcat

      Wrong: no special annotation such as @EnableEmbeddedTomcat is needed (nor does one exist as a requirement) — the embedded container starts automatically for a web application.

   2. B. An embedded servlet container (e.g. Tomcat) starts automatically; no deployment to an external server is requiredCorrect answer

      Correct: for a Spring Boot web app, running the main method starts the embedded servlet container and binds the port, enabling self-contained executable jars, per the Spring Boot 2.5 reference on Embedded Web Servers.

   3. C. Nothing starts until you also instantiate and call a ServletWebServerFactory yourself

      Wrong: you do not manually instantiate or invoke a ServletWebServerFactory — Boot's auto-configuration wires and starts the container for you.

   4. D. It produces a WAR that you must deploy to an external Tomcat to run

      Wrong: external WAR deployment is an available option, not the default — the default is a self-contained executable jar with an embedded container.

   Explanation

   A Spring Boot web application embeds its servlet container, so invoking the main method starts the container and binds the port automatically, producing a self-contained executable jar with no external server required. This behavior is provided by auto-configuration, needing no special enabling annotation and no manual web-server-factory wiring; deploying a WAR to an external server remains an alternative rather than the default.

4. Question 4

   When Spring Boot startup fails for a well-known reason (e.g. the configured port is already in use), what does it print?

   1. A. A FailureAnalyzer report with a clear Description and Action to takeCorrect answer

      Boot's FailureAnalyzers translate common startup failures into a readable report with a Description of the problem and a suggested Action (e.g. for a port already in use).

   2. B. A success message and continues running

      The startup has genuinely failed, so it is not reported as a success and the application does not continue running.

   3. C. Nothing — the process exits silently

      The process does not exit silently; Boot deliberately prints a diagnostic report for well-known failures.

   4. D. Only a raw stack trace with no guidance

      For recognized failures Boot goes beyond a bare stack trace, adding an explanation and remediation guidance.

   Explanation

   For well-known startup failures, Spring Boot's FailureAnalyzers intercept the error and emit a human-readable report that states what went wrong and what action to take. Rather than exiting silently, masking the failure as success, or dumping only a raw stack trace, this gives the developer actionable diagnostics.

5. Question 5

   After upgrading to Spring Boot 2.6, a controller mapping that placed a `**` wildcard in the middle of its path pattern stops matching, and a Spring Security rule written as mvcMatchers("hello") no longer applies. What Boot 2.6 change explains both symptoms, and how can the old behavior be restored?

   1. A. AntPathMatcher became the new default matching strategy in 2.6, and its stricter rules reject a mid-pattern ** — revert by setting spring.mvc.pathmatch.matching-strategy=path-pattern-parser.

      This reverses the two strategies: AntPathMatcher was the previous default, not the new one, and path-pattern-parser is the new default rather than the value that reverts.

   2. B. Spring Security 5.7 removed mvcMatchers in favor of requestMatchers, which is why the security rule no longer applies; the controller change is unrelated.

      mvcMatchers was not removed in 5.7, and this ignores the shared root cause: both symptoms stem from the MVC path-matching strategy change, not a security API removal.

   3. C. The default of spring.mvc.pathmatch.matching-strategy changed to path-pattern-parser, whose PathPatternParser allows ** only at the end of a pattern and requires the leading slash (so mvcMatchers("/hello")); set the property to ant-path-matcher to revert.Correct answer

      Boot 2.6 made PathPatternParser the default path-matching strategy; it permits `**` only as a trailing element and needs the leading slash in matcher patterns, and setting the strategy back to ant-path-matcher restores the previous behavior.

   4. D. There is no default matching strategy in 2.6, so both problems arise because spring.mvc.pathmatch.matching-strategy must now be set explicitly to path-pattern-parser.

      PathPatternParser is the default in 2.6; nothing must be set explicitly to obtain it. The property only needs setting if you want to revert to the older matcher.

   Explanation

   Boot 2.6 switched the default value of spring.mvc.pathmatch.matching-strategy to path-pattern-parser, so PathPatternParser replaced AntPathMatcher. PathPatternParser is stricter: a `**` wildcard is valid only at the end of a pattern, and Security matcher patterns need a leading slash, so mvcMatchers("hello") must become mvcMatchers("/hello"). Reverting is done by setting the strategy to ant-path-matcher, not by naming a nonexistent default or blaming a Security API removal.

6. Question 6

   An application that started cleanly on Spring Boot 2.5 fails to start after an upgrade to 2.7, throwing BeanCurrentlyInCreationException because a service and a repository each field-inject the other, forming a cycle. Which statement correctly explains the failure and the recommended response?

   1. A. Spring never permitted circular references; the upgrade merely exposed a latent compilation error that was always present in the code.

      The cycle compiled and ran fine before — Boot silently resolved circular references at startup on the older baseline, so this is not a compile error that was always present.

   2. B. As of Boot 2.6, spring.main.allow-circular-references defaults to false, so a cycle now fails startup; setting it to true restores the old behavior, but the recommended fix is to break the cycle (for example with constructor injection, @Lazy, or an event publisher).Correct answer

      Boot 2.6 flipped the default of spring.main.allow-circular-references to false, turning a previously tolerated cycle into a startup failure; the flag can restore the old tolerance, but the documented advice is to redesign away the cycle.

   3. C. Setting spring.main.allow-circular-references=false will restore the behavior the application had on Boot 2.5.

      This inverts the change: false is precisely the new 2.6+ default that causes the failure, so setting it to false changes nothing — restoring the old behavior requires setting it to true.

   4. D. The only supported fix is to annotate both beans with @Lazy, because the allow-circular-references property was removed in 2.6.

      The property still exists and can re-enable cycles; @Lazy is just one of several ways to break the cycle, not the sole supported remedy.

   Explanation

   Spring Boot 2.6 changed the default of spring.main.allow-circular-references from true to false, so a circular bean reference that was silently resolved on 2.5 now fails startup with BeanCurrentlyInCreationException. You can set the property to true (or call setAllowCircularReferences(true)) to restore the old tolerance, but the intended fix is to eliminate the cycle. The property was not removed, and setting it to false is the new default that causes the failure rather than a cure.

7. Question 7

   How does a Spring Boot executable ('fat') jar run its nested dependency jars?

   1. A. It always unpacks every dependency to a temp directory first

      The launcher reads nested jars in place and does not require unpacking every dependency to a temp directory.

   2. B. Through JNI native calls

      JNI is unrelated to how Boot loads nested jars; the mechanism is a pure-Java launcher and classloader.

   3. C. Via Boot's launcher and a special classloader that reads nested jars under BOOT-INF/lib without unpacking themCorrect answer

      Boot's executable jar uses a custom launcher (e.g. JarLauncher) and a nested-jar classloader that loads jars stored under BOOT-INF/lib directly, keeping the single jar self-contained.

   4. D. It cannot; dependencies must be installed on the OS classpath separately

      The fat jar is self-contained, so no separate OS-level installation of dependencies is required.

   Explanation

   A Boot executable jar embeds its dependencies under BOOT-INF/lib and boots through a custom launcher paired with a classloader that reads those nested jars in place. That design keeps the artifact fully self-contained, needing neither prior unpacking to disk, native JNI bridging, nor externally installed dependencies.

8. Question 8

   When you build on spring-boot-starter-parent (or import the Spring Boot BOM), where do dependency versions come from?

   1. A. Versions are resolved and downloaded at application runtime

      Wrong: dependency resolution happens at build time via Maven, not at application runtime — the versions are fixed when the artifact is assembled.

   2. B. Each starter pins only its own version and does not align transitive dependencies

      Wrong: the whole point of the parent/BOM is coordinated alignment of transitive dependencies, not per-starter pinning in isolation.

   3. C. You must specify an explicit <version> for every dependency you declare

      Wrong: explicit versions are optional overrides for managed dependencies — you normally omit them and let the curated set supply the version.

   4. D. Spring Boot's dependency management curates compatible versions, so you normally omit <version> for managed dependenciesCorrect answer

      Correct: the parent/BOM supplies a tested, mutually compatible set of versions via Maven dependency management, letting you declare managed dependencies without a version, per the Spring Boot 2.5 reference on Dependency Management.

   Explanation

   The Spring Boot parent POM or imported BOM provides a curated, tested set of mutually compatible versions through Maven's dependency management, so managed dependencies can be declared without a version element. This resolution is a build-time concern and its purpose is coordinated alignment across transitive dependencies, with explicit versions serving only as optional overrides.