Twelfth attempt — MVC held 100%, and four questions you've now missed more than once

POST {"configuredLevel": null} to /actuator/loggers/{name}

Every logger has two levels, and that's the whole question:

Sending null clears the override, so the logger falls back to inheritance. Posting "INFO" instead would set a new override that happens to be INFO — not the same thing, since the original might have been WARN inherited from a parent.

@ConditionalOnProperty — and @ConditionalOnExpression also works

Read the suffix and it answers itself: OnProperty → a property, OnBean → a bean, OnClass → a class, OnResource → a resource. The naming is completely literal.

Useful detail: @ConditionalOnProperty has a matchIfMissing attribute — true means "apply when the property is absent", which is how Boot writes opt-out defaults.

Curated, version-aligned dependencies plus auto-configuration — not smaller jars or faster startup

A starter is a convenience for the developer, not the runtime. If an option claims a starter improves a runtime characteristic — size, speed, memory — it's wrong. The benefit is entirely at build and configuration time.

Micrometer — the vendor-neutral metrics facade

Micrometer is "SLF4J for metrics" — one API, many backends. Add a registry dependency and it wires itself up:

A CompositeMeterRegistry fans every meter out to all registered backends, so one Counter can reach several systems at once. The integration is dependency-driven — you add a jar, not code.

Don't confuse the two Actuator concerns: HealthIndicator feeds /actuator/health (is the app alive?); Micrometer feeds metrics backends (how is it behaving?). The third distractor tried to swap them.

Simpler codebase · independent deployment · fine-grained scaling — not simplicity of the system

The phrase "simple distributed system" is nearly a contradiction, and that's the tell. Distribution is the cost you accept in exchange for the three benefits — no architecture question will ever list it as an advantage.

Three of four true — it does not match other classes in the package

Read execution(* com.example.service.UserService.saveUser(..)) segment by segment:

Two dots mean two different things, which is the thing to hold: (..) in the parameter position = any arguments; .. in the package position = this package and below.

InitializingBean.afterPropertiesSet() and DisposableBean.destroy()

Three routes, and they run in that order — annotation, then interface, then attribute — on both sides of the lifecycle. That ordering has appeared on several of your papers.

The names are worth reading literally: afterPropertiesSet says when it runs — after dependency injection completes. @PostConstruct says the same thing in a different vocabulary. Same moment, two mechanisms, two different names — and neither borrows the other's. There is no init() in InitializingBean either.

Prefer the annotations: the interfaces couple your domain classes to Spring, which is exactly what "non-invasive" is meant to avoid.

Five true — the false one claims high coupling is good

The five genuine advantages, and one is Spring-specific:

The proxy point is the exam-relevant one. With an interface Spring can use a JDK dynamic proxy; with no interface it must use CGLIB, which can't proxy final classes or methods. Note that Spring Boot still defaults to CGLIB (proxyTargetClass=true) — having an interface makes JDK proxying possible, not automatic.

And the pitfall that follows: under a JDK proxy, injecting the concrete class fails with BeanNotOfRequiredTypeException — the proxy implements the interface but is not an instance of your class. Inject the interface.

REQUIRED — and you ticked four other options

Take the stem's two clauses and eliminate:

SUPPORTS is the near-miss, and the trap is the word "supports" in the stem. SUPPORTS joins an existing transaction but runs without one when none exists — it never creates. The second clause is what separates them.

The seven levels, in the two columns that answer every propagation question:

Four true: readOnly, rollbackFor, noRollbackFor, timeout

Where the two fake ideas actually live, which makes them easier to reject: exit codes are ExitCodeGenerator (a Boot concern); post-commit/post-rollback hooks are TransactionSynchronization, registered through TransactionSynchronizationManager. Both are real capabilities — just not attributes of this annotation.

And there is no retry attribute either — that's @Retryable from Spring Retry.

Embedded DB · scans repositories · transactional — it does not load @Service or @Controller

Two defaults it applies, both of which appear as their own questions: an embedded in-memory database replaces your configured one (disable with @AutoConfigureTestDatabase(replace = Replace.NONE)), and each test runs in a transaction that is rolled back afterwards.

The mirror of @WebMvcTest from yesterday's paper: each slice loads exactly one layer and mocks or omits the rest. If a slice question offers "it also loads services", that's the wrong answer by definition.