Eleventh attempt — Spring MVC hit 100%, and Spring Core is now the whole problem

@Before and @AfterReturning — @Aspect and @Component mark the class

Both class-level annotations are needed together, and that's a stock exam point: @Aspect alone does nothing, because Spring only weaves aspects that are beans. You need @Component (or a @Bean method) as well.

And the version fact that pairs with it: all these annotations come from AspectJ (org.aspectj.lang.annotation), not from Spring. Spring interprets them with its own proxy runtime — which is exactly what Q19 below is about.

It starts and commits a transaction around every matched call

Read the advice body and the answer is written there:

@Around("execution(* com.example.service.*.*(..))")
public Object manageTransaction(ProceedingJoinPoint jp) throws Throwable {
    System.out.println("Transaction started.");     // ← before
    Object result = jp.proceed();                    // ← the real method
    System.out.println("Transaction committed.");    // ← after
    return result;
}

The general principle the distractors miss: AOP is a mechanism for inserting code, not a source of behaviour. It cannot batch, synchronise or make anything idempotent unless you write that code in the advice. If an option claims AOP does something "automatically", ask where that code would live.

And the connection worth making: this is a simplified version of what Spring's own @Transactional does. TransactionInterceptor is an @Around-style MethodInterceptor that begins a transaction, calls proceed(), and then commits or rolls back. Understanding this one aspect explains @Transactional's proxy limitations too.

One flaw in the code worth spotting: there is no try/catch, so if the method throws, "Transaction committed" never prints and nothing rolls back. A real @Around transaction aspect needs a catch.

Annotations and XML and programmatically — and it supports full arithmetic

And the operators, since the other distractor claimed maths was missing: arithmetic + - * / % · relational == != < > <= >= · logical and or not (or && || !) · ternary ?: · Elvis ?: · safe navigation ?. · type reference T() · projection ![] · selection ?[].

Literals are supported too: strings 'hello', numbers, true, false, null. That was the second correct option.

A static @Bean method in a @Configuration class

The problem is a chicken-and-egg ordering conflict. A BeanPostProcessor must exist before other beans are created, because it processes them. But a non-static @Bean method requires its enclosing @Configuration class to be instantiated first — and that class is itself a bean that wants post-processing.

@Configuration
public class InfrastructureConfig {

    @Bean
    public static LoggingBeanPostProcessor loggingBPP() {   // ← static
        return new LoggingBeanPostProcessor();
    }
}

static breaks the cycle — Spring can invoke a static method without instantiating the class, so the BPP is available very early. Declare it non-statically and Spring logs:

BeanPostProcessor [X] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)

The same rule applies to BeanFactoryPostProcessors — which is why PropertySourcesPlaceholderConfigurer and CustomScopeConfigurer are conventionally declared static too. Anything that processes other beans should be a static @Bean method.

One consequence to remember: static @Bean methods are not CGLIB-intercepted, so calling one from another method creates a new instance rather than returning the singleton. Use static only for post-processors, never for ordinary beans other beans depend on.

static methods · constants · nested types · default methods

Why default was added is the Spring-relevant part: it lets an interface gain new methods without breaking every existing implementation. The JDK used it to add Collection.stream() and Comparator.reversed() — and Spring used the same trick in 5.0, making both BeanPostProcessor methods default so implementations only override the one they care about. That connects directly to Q30 above.

Two rules worth having: a default method cannot redeclare an Object method (equals, hashCode, toString) — compile error; and static interface methods are not inherited — you must qualify them with the interface name.

It puts a Mockito mock into the ApplicationContext — @Mock does not

The practical difference: @Mock gives you an object you must wire in by hand — fine for a plain unit test. @MockBean registers a bean definition, so the controller Spring instantiates receives the mock. That's what makes it usable inside @WebMvcTest.

The performance pitfall worth knowing: each distinct combination of @MockBean types produces a different context cache key, so a new ApplicationContext is built. Scattering many different mock combinations across test classes destroys context caching and slows the suite badly.

Version note: in Spring Framework 6.2 / Boot 3.4 this moved to @MockitoBean in spring-test, with @MockBean deprecated. Your exam targets Boot 2.5, where @MockBean is correct.

@SpringBootTest(webEnvironment = RANDOM_PORT) — or server.port=0

Two genuinely equivalent routes, and both were correct:

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class MyIT {
    @LocalServerPort int port;
    @Autowired TestRestTemplate restTemplate;
}

# or — src/test/resources/application.properties
server.port=0        # 0 means "any free port" at the servlet-container level

server.port=0 is the underlying mechanism, and that's why the two are equivalent: RANDOM_PORT sets exactly that property for you. Port 0 is a long-standing TCP convention meaning "let the OS pick a free one".

And the default that made the first option wrong: @SpringBootTest defaults to MOCK — a mock servlet environment with no server and no port, which is why TestRestTemplate isn't auto-configured there. That fact has now appeared on three of your papers.

Starter versions come from the Boot BOM — you never declare them

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'   // ← no version
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

The io.spring.dependency-management plugin (Gradle) or the spring-boot-starter-parent POM (Maven) imports Boot's BOM, which pins a compatible version for every managed dependency. That version curation is the main thing a starter buys you — not just the grouping.

The other correct-rejection here: starter-data-jpa does not add an in-memory database — you add H2 or Postgres yourself. Same principle as "Boot ships no vendor JDBC drivers" from attempt #8.

Public methods only · default propagation REQUIRED

Why interface annotations vanish under CGLIB: a CGLIB proxy is a subclass of your class. Java does not inherit annotations from an interface onto an implementing class, and certainly not onto a generated subclass — so Spring's attribute source never sees the interface-level @Transactional. A JDK dynamic proxy implements the interface, so the annotation is visible.

Spring Boot defaults to CGLIB (proxyTargetClass=true), which is why the Spring reference documentation says: annotate concrete classes, not interfaces. This is also the safer habit generally — it removes the proxy type from the equation entirely.

The two correct options are worth over-learning, since they're the stock @Transactional facts: public methods only (non-public is silently ignored — no error), and default propagation REQUIRED, default isolation DEFAULT, rollback on unchecked exceptions only.

Both roll back — independence governs rollback, not exception flow

Trace it precisely, because this is the subtlest transaction question you've had:

The one-line version: REQUIRES_NEW isolates the transactions, not the exceptions. Independence means TX-B's rollback doesn't drag TX-A down by itself — but nothing stops the exception travelling up the call stack in the ordinary Java way, and Spring rolls back on unchecked exceptions by default.

@Transactional
public void mainOperation() {
    try {
        subService.subOperation();        // TX-B rolls back
    } catch (Exception e) {
        log.warn("sub failed, continuing", e);   // ← now TX-A really does survive
    }
}

That try/catch is the difference between the option you picked and the correct one. It's also the real-world pattern: REQUIRES_NEW plus a catch is how you write an audit record that persists even when the main work fails.

Five of six — LDAP is a directory protocol, not a mechanism

The distinction the question is built on is genuinely useful:

The two layers combine: a Form login collects a username and password, and an LdapAuthenticationProvider verifies them against an LDAP directory. Same request, two different concerns.

This connects to a fact you already have from attempt #9: the question "where can Spring Security store user details?" has the answer JDBC, LDAP, in-memory — and LDAP is on that list precisely because it's a store, not a mechanism. The same word is the right answer to one question and the wrong answer to the other. Read which layer the stem is asking about.