Fifth attempt — 70%, and a very useful failure

There is no rollback attribute — it's rollbackFor and friends

The rollback family is exactly four names — rollbackFor (classes), rollbackForClassName (strings), noRollbackFor, noRollbackForClassName. The full attribute list is worth knowing cold, because "which of these is not an attribute" is a stock question:

The default rule that everything hangs off: unchecked exceptions (RuntimeException, Error) roll back; checked exceptions do not — you must name them in rollbackFor. And remember from review #2 that @Transactional doesn't support SpEL, so these are all fixed types.

Isolation, not atomicity

Pin the four to a one-word trigger each:

Isolation is also the only one you configure in Spring — @Transactional(isolation = Isolation.REPEATABLE_READ). Know the level/anomaly grid:

EmbeddedDatabaseBuilder — it creates the database; the others just connect

new EmbeddedDatabaseBuilder().setType(H2).addScript("classpath:schema.sql") .addScript("classpath:test-data.sql").build() launches an in-process H2/HSQLDB/Derby and runs your scripts — ephemeral, isolated, reset by dropping the bean. That's what makes it the dev/test answer.

Boot ties in automatically: with no configured DataSource and H2/HSQLDB/Derby on the classpath it auto-creates an embedded DB, seeded via spring.sql.init.schema-locations/data-locations. Production is still HikariCP.

WHERE conditions, a result limit, and ordering — never vendor SQL

At startup, PartTree parses the method name into subject + predicate and compiles it to a JPA CriteriaQuery. Derivable from the name:

Not derivable: anything vendor-specific — PL/SQL, T-SQL, native functions. Spring Data is database-agnostic; for vendor SQL you need @Query(nativeQuery = true). And as review #4 noted, a bad property name throws PropertyReferenceException at startup.

That's a join point

Learn the five terms as a sentence: an aspect uses a pointcut to select join points, where it applies advice; the wiring-up is weaving.

Key contrast the exam repeats: Spring AOP supports only method-execution join points, while AspectJ also supports field access, constructor execution and more.

Runtime proxies only — no compile-time weaving, and the annotations come from AspectJ

The three true statements were: AOP handles cross-cutting concerns; Spring AOP cannot proxy final methods; and JDK dynamic proxies are the default when the bean implements an interface. The fifth option was also false in a subtle way worth knowing: the @Aspect/@Before/@Around annotations are AspectJ's (org.aspectj.lang.annotation) — Spring borrows the annotation style and the pointcut parser, but the runtime is pure proxy-based Spring AOP with no AspectJ compiler or weaver involved.

The proxy limits are a family: final methods/classes can't be overridden, private methods aren't advised, and self-invocation bypasses the proxy entirely (the classic reason an internal call to a @Transactional method does nothing).

proceed() may be called any number of times — including zero

The two true statements: an @Around advice's first parameter must be ProceedingJoinPoint (it's the only advice type that gets one), and @AfterThrowing(throwing = "ex") narrows matching to methods that throw that exception type — declaring SQLException means the advice only fires for SQLException. The other distractor, @AfterFinally, doesn't exist — the "always runs" advice is @After (review #3).

What @Around gives you, from review #3's table: it's the only advice that can (a) call proceed() zero times and skip the method entirely, (b) call it many times to implement retry, (c) change the arguments via proceed(Object[] args), and (d) alter or swallow the return value / exception. Its return type should be Object and it should declare throws Throwable.

Matches any method annotated with @CustomTransaction

Learn the four annotation-matching designators by where the annotation sits — this distinction is the whole question:

Two gotchas: the annotation must be @Retention(RUNTIME) or it's invisible and the pointcut never matches; and with JDK proxies the interface method's annotations are checked, while CGLIB checks the target class's — so an annotation declared only on the interface may not match under CGLIB. (Also worth knowing, from the non-annotation family: execution(), within(), this(), target(), args(), bean().)

Choose the scope that fits the bean — no blanket rule

Every other option was an absolute — "all beans", "always", "avoid using scopes other than singleton". As review #3 noted, absolutes are where the wrong answer hides. On any "which practice is recommended" question, the balanced, it-depends option is nearly always correct.

The scope table, and when each fits: singleton (default, one per context) for stateless services and repositories · prototype for stateful, non-shared objects · request / session / application / websocket for web-scoped state — and remember from review #2 that only singleton and prototype work outside a web context.

New instance per request — but injected into a singleton, it's created once, eagerly

Four facts, and the exam tests the counter-intuitive middle two:

The practical consequence (and a favourite follow-up): injecting a prototype into a singleton with plain @Autowired gives you one instance for the singleton's whole life, defeating the point. For a genuinely fresh instance per call use ObjectProvider<T>.getObject(), @Lookup, or a scoped proxy.

"Global" means application-wide, not "web endpoints" — it enables method-level security

@EnableGlobalMethodSecurity turns on the annotations you put on individual methods, and each flag enables a different family:

@Configuration
@EnableGlobalMethodSecurity(
    prePostEnabled = true,   // @PreAuthorize / @PostAuthorize   (SpEL — review #4)
    securedEnabled = true,   // @Secured("ROLE_ADMIN")
    jsr250Enabled  = true)   // @RolesAllowed  (JSR-250)
public class SecurityConfig { }

Two separations to hold: URL security = HttpSecurity / SecurityFilterChain with request matchers; method security = this annotation + @PreAuthorize and friends. And in Spring Security 6+ the annotation is renamed @EnableMethodSecurity (with prePostEnabled on by default) — the exam's Boot 2.5 era still uses @EnableGlobalMethodSecurity.

permitAll() opens a path — it does not switch security off

The two true statements were: authentication data can come from many backends (database, LDAP, in-memory, custom — review #3's UserDetailsService fact) and access control can be configured at the method level. The three false ones are each worth recognising: permitAll() only whitelists a matcher (the request still passes through the filter chain, still gets a SecurityContext); Spring Security is not an implementation of the Java EE Security specification; and no JAAS policy file is required (JAAS integration exists but is optional and rare).

If you genuinely want a path to skip the chain, that's web.ignoring() / WebSecurityCustomizer — a different mechanism from permitAll(), and worth knowing precisely because the exam contrasts them.

The exclude attribute of @ImportAutoConfiguration (or a slice's excludeAutoConfiguration)

There are three separate exclusion mechanisms, and the exam tests that you know test slices use their own:

@WebMvcTest(controllers = OrderController.class,
            excludeAutoConfiguration = SecurityAutoConfiguration.class)
class OrderControllerTests { … }

The pitfalls are exam-shaped: slices are meta-annotated with @ImportAutoConfiguration, so exclusions on your application class have no effect on a slice, and spring.autoconfigure.exclude doesn't apply to slices either. There is no @DisableAutoConfiguration, and dropping a Maven dependency is a side-effect, not a mechanism.