Ninth attempt — 73%, your best score yet, and two marks from the pass

Build/SCM information and arbitrary app information — it is enabled by default, just not exposed

Three ways to put data into info, all worth recognising:

@Component
public class CustomInfo implements InfoContributor {
    @Override public void contribute(Info.Builder builder) {
        builder.withDetail("region", "eu-west-2");
    }
}

The option that looks true and isn't: "it is not enabled by default". info is enabled — every endpoint except shutdown is. What changed in Boot 2.5 is that info stopped being exposed over HTTP by default; in Boot 2.0 both health and info were. Since 2.5, only health is. Enablement ≠ exposure, and this question exists solely to test that you don't conflate them.

Security isn't specific to info either — it applies to every endpoint and is configured with Spring Security, not by the endpoint itself.

It lists every logger with its level, and levels can be changed over HTTP or JMX

loggers is the endpoint that makes Actuator genuinely operational rather than informational — it is read and write:

# read every logger and its level
GET  /actuator/loggers

# read one
GET  /actuator/loggers/com.example

# change one at runtime — no restart
POST /actuator/loggers/com.example
Content-Type: application/json
{"configuredLevel": "DEBUG"}

Two details that get asked. Posting {"configuredLevel": null} resets the logger to inherit from its parent — it does not restore the startup level. And the exposure rule from the table above applies here: loggers is enabled, visible over JMX by default, but needs management.endpoints.web.exposure.include=loggers before HTTP will serve it.

All four were correct

Review #7 covered the file's location (META-INF/spring.factories); this question tests its range. It is a general extension registry, not an auto-configuration-only file:

Why it's a file rather than beans: every one of those runs before the ApplicationContext exists, so there is no container to look them up in. SpringFactoriesLoader reads the file from every JAR on the classpath and merges the entries.

The version fact from review #7 still applies: Boot 2.7 moved auto-configuration registration only to META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports; every other key stayed in spring.factories.

False — every attribute takes a fixed constant, enum or class literal

Look at the attribute list and it's obvious there's nowhere for an expression to go:

The comparison the exam actually wants — which annotations do take SpEL:

There is a rough logic to it: annotations that make a per-invocation decision take SpEL (which user? which cache key? is this expression true right now?). @Transactional's attributes are resolved once when the proxy is built, so there's nothing to evaluate per call.

Build a PreparedStatement from the Connection you're handed — SQL and parameters

The clinic covered the three reading callbacks; this is the writing one. Ordered by when they fire:

Why you'd ever need it — the canonical case is capturing a generated key, which the simple update(sql, args…) form can't do:

KeyHolder keys = new GeneratedKeyHolder();
jdbc.update(con -> {
    PreparedStatement ps = con.prepareStatement(
            "insert into employees(name, dept) values(?, ?)",
            Statement.RETURN_GENERATED_KEYS);      // ← needs the Connection in hand
    ps.setString(1, emp.name());
    ps.setString(2, emp.dept());
    return ps;
}, keys);
long id = keys.getKey().longValue();

Two rules shared with every JdbcTemplate callback: do not execute it yourself (duplicate rows on INSERT), and do not close the statement or connection — JdbcTemplate owns the lifecycle.

Named parameters — readability. Nothing more exotic than that.

Why "prevents SQL injection" is wrong. Both templates use PreparedStatement underneath, so bound parameters are safe in both — the protection comes from prepared statements, not from named parameters. And neither protects you if you concatenate user input into the SQL string:

// unsafe in BOTH templates
String sql = "SELECT * FROM users WHERE name = '" + userInput + "'";

// safe in BOTH — the value is bound, not interpolated
jdbc.query("SELECT * FROM users WHERE name = ?", mapper, userInput);
named.query("SELECT * FROM users WHERE name = :name", Map.of("name", userInput), mapper);

So the difference between the two templates is readability and maintainability only:

It wraps a JdbcTemplate (reachable via getJdbcOperations()) and translates :name into positional ? before executing — so it is strictly a convenience layer, which is exactly why "required for executing SQL" and "handles all SQL including DDL" are both wrong.

@Controller + @ResponseBody

The source is two lines long:

@Target(ElementType.TYPE)
@Controller          // ← makes it a Spring MVC controller bean
@ResponseBody        // ← makes every method write to the response body
public @interface RestController { … }

The consequence is the fork you've now met several times:

The practical rule: if a controller must return views from some methods and JSON from others, use @Controller and put @ResponseBody on the individual JSON methods. @RestController is all-or-nothing for the class.

And note @RequestMapping is not part of it — you still declare mappings yourself. That was the fourth distractor.

Three separate fixes: @Primary, @Qualifier("cat") on the field, or rename the field

Two IAnimal beans exist, so injection by type is ambiguous. Spring's resolution order, in full:

@Component class Person {
    @Autowired private IAnimal cat;     // bean name "cat" → resolved by step 5
}

Why the wrong option is wrong: @Qualifier("animal") on Dog or Cat names a bean called animal, and no such bean exists — the two beans are named dog and cat (the class name, decapitalised). Note also that @Qualifier is placed at the injection point here, not on the candidate class.

Step 5 is why a constructor parameter called myService quietly picks up the bean named myService — behaviour that looks like magic until you know the fallback exists.

Called once · @PreDestroy runs before destroy() · never for prototypes

The callback order, both directions. Annotation first, then interface, then the XML/@Bean attribute:

Why prototypes get no @PreDestroy: the container creates a prototype, injects it, hands it over and forgets it — it keeps no reference, so it has nothing to call back on. The caller owns the cleanup. Singletons are held for the context's lifetime, so their destruction callbacks fire on close.

Worth pairing with the constraints from review #8: void return, no parameters, not static, any visibility. Between the two questions you now have the whole contract.