Eighth attempt — 70% again, but two sections are now perfect

void, String, ModelAndView — HttpServletRequest is a parameter

Spring injects the servlet objects into your method so you can read from them; returning one would tell the framework nothing about what to render:

@GetMapping("/hello")
public String hello(HttpServletRequest request) {   // ← injected as a PARAMETER
    log.info(request.getRemoteAddr());
    return "helloView";                             // ← returned: a view NAME
}

The parameter side of the contract is worth knowing in its own right, because it's the mirror question: Spring can inject HttpServletRequest, HttpServletResponse, HttpSession, Model, Locale, Principal, and anything annotated @RequestParam/@PathVariable/@RequestBody/@RequestHeader.

It produces the response and extends HttpServlet — it does not resolve views itself

The DispatcherServlet is the front controller: it receives every request and coordinates the components that do the actual work. Knowing who does what is the whole question:

And the registration fact, which was the fourth option: @EnableWebMvc does not register a DispatcherServlet. It only switches on the MVC infrastructure beans (HandlerMapping, HandlerAdapter, ViewResolver). The servlet itself is registered by Spring Boot's auto-configuration (mapped to /), or by hand in web.xml / a WebApplicationInitializer in a non-Boot app.

An absolute path to the view — a logical name and void are both fine

The distinction is between a logical name and a physical path:

That third row is the key insight, and it's why the question is fair: if you genuinely need to name a physical path, you wrap it in a View object, because View return values bypass resolution. A bare String is always treated as a logical name to be resolved — which is exactly what makes an absolute path break.

Note the pattern across all three MVC questions: two of them hinged on a word — "cannot" here, and "return type" versus "parameter" in Q3. At 29 seconds per question, those are the words that get skipped.

Turns on auto-configuration, and lives inside @SpringBootApplication — that's all

Three annotations, three jobs, and the exam tests that you don't blur them:

On the other distractor: an auto-configuration class is annotated @Configuration (or @AutoConfiguration in Boot 2.7+) and is registered in META-INF/spring.factories — or, from Boot 2.7, META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. It never carries @EnableAutoConfiguration itself; that annotation goes on your application, to say "go and find them".

The ordering hint is silently ignored and the configuration loads normally

The clue is in the attribute: name = "com.example.PreviousConfig" is a String, not a class literal. Spring uses the string form precisely so that the class need not be present — referencing it as PreviousConfig.class would require it on the classpath to even compile.

Why the design is like that: auto-configurations are contributed by JARs that may or may not be present. An ordering hint that exploded whenever an optional starter was absent would make every optional dependency mandatory. Ordering is a preference; the real gating is done by @ConditionalOnClass, @ConditionalOnMissingBean and friends.

Five of the six were true — Boot ships no proprietary database drivers

What the starter does give you — and note that the answer to "how does Boot help" is almost always "all of the above":

This is the same bean list as the Data Management clinic's manual-JPA question, seen from the other side: there, you wired those four beans by hand; here, Boot does it. Knowing both directions is what the exam is actually testing.

One behaviour worth carrying: Boot backs off, it does not merge. Declare your own DataSource bean and DataSourceAutoConfiguration steps aside entirely — the same @ConditionalOnMissingBean mechanism as the SecurityFilterChain case from review #7.

It must be registered with the BeanFactory before any bean can use it

@Scope("customScope") is only a lookup by name. If nothing has registered that name, you get IllegalStateException: No Scope registered for scope name 'customScope' when the bean is first created. Two steps are required:

// 1. implement the Scope interface
public class TenantScope implements Scope {
    public Object get(String name, ObjectFactory<?> factory) { … }
    public Object remove(String name) { … }
    // …
}

// 2. register it — declaratively
@Bean
public static CustomScopeConfigurer scopes() {          // note: static
    CustomScopeConfigurer c = new CustomScopeConfigurer();
    c.addScope("tenant", new TenantScope());
    return c;
}

// 3. now this works
@Bean @Scope("tenant")
public TenantContext tenantContext() { return new TenantContext(); }

The static on that @Bean method matters: CustomScopeConfigurer is a BeanFactoryPostProcessor, so it must be instantiated before the enclosing @Configuration class is fully processed. Same reason PropertySourcesPlaceholderConfigurer is declared static.

Compile as soon as possible; on failure throw to the caller — no fallback

By default SpEL interprets expressions by walking the AST. The compiler generates real bytecode, which is much faster for repeated evaluation. Three modes decide when — and what happens when compilation isn't possible:

Read the two clauses separately. "After some number of runs" ⇒ MIXED. "As soon as possible" ⇒ IMMEDIATE. Then check the error half: MIXED is the forgiving one, IMMEDIATE is the strict one. The names carry both meanings — immediate compilation, immediate failure.

SpelParserConfiguration config = new SpelParserConfiguration(
        SpelCompilerMode.IMMEDIATE, getClass().getClassLoader());
ExpressionParser parser = new SpelExpressionParser(config);

Not every expression is compilable — null-safe navigation, some projections and certain casts aren't. That's the whole reason the two modes differ: MIXED degrades quietly, IMMEDIATE tells you. Compilation only pays off for high-frequency evaluation (Spring Integration, Spring Batch); for a one-off @Value at startup the bytecode generation costs more than it saves.

It builds queries dynamically at runtime by composing predicates

Specification<T> wraps the standard JPA Criteria API in something composable. Your repository extends JpaSpecificationExecutor<T> to gain findAll(Specification<T>):

public interface Specification<T> {
    Predicate toPredicate(Root<T> root, CriteriaQuery<?> query, CriteriaBuilder cb);
}

Specification<User> spec = Specification.where(hasLastName("Smith"))
                                        .and(isActive());
List<User> users = userRepo.findAll(spec);          // query assembled at runtime

Why "dynamic" is the point: derived query methods and @Query are both fixed at compile time — one query per method. A search screen with eight optional filters would need 256 methods. Specifications let you build the WHERE clause from whichever filters the user actually supplied.

On the two distractors: it's part of Spring Data JPA, so it works in any Spring application with or without Boot; and it uses standard JPA Criteria, so any JPA-compliant provider works — Hibernate, EclipseLink, OpenJPA. The pattern to notice is that both wrong options invented a dependency. Also note pagination and sorting are not its job — that's Pageable and Sort, which you pass alongside a specification.

True — it's the default implementation behind every repository proxy

What happens when you declare an empty interface:

So save(), findById(), deleteAll() are literally SimpleJpaRepository's methods. That's what connects three separate exam facts: no @Repository is needed (the proxy is registered for you); every call is already transactional (the base class is @Transactional(readOnly = true) with write methods overriding); and repositoryBaseClass exists so you can swap this class for your own.