Thirteenth attempt — two hours spent, second-worst score, and the answer isn't knowledge

Three strategies, three different moments — and only one touches bytecode at load

The one sentence that answers both questions: a proxy wraps the object; weaving changes the class. A wrapper can only see calls that arrive from outside, so this.inner() never reaches it. Woven bytecode is the object, so there is nothing to bypass.

Q60's exact wording matters. "Code is modified" — JDK and CGLIB proxies never modify your code; they generate a separate class that delegates to it. Your original .class file is byte-for-byte untouched. That option is disqualified by the verb in the stem.

LTW needs -javaagent:spring-instrument.jar plus @EnableLoadTimeWeaving; for transactions specifically, @EnableTransactionManagement(mode = AdviceMode.ASPECTJ) plus the spring-aspects dependency.

Two of the four are CGLIB-only — and the stem says both

This question is answerable purely from how each proxy is built, without memorising a list. JDK proxies implement an interface. CGLIB proxies extend the class. Every limitation follows:

Why final is CGLIB-only: CGLIB works by subclassing and overriding. Java forbids overriding a final method and forbids extending a final class, so CGLIB is blocked. A JDK proxy never subclasses anything — it implements the interface — so final on the target class is irrelevant to it.

Why private is both: a private method is not visible to an interface or to a subclass. Neither strategy can see it. Spring AOP advises public method execution join points only.

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

ProceedingJoinPoint.proceed() is an ordinary method call. Calling it twice runs the target twice — that is exactly how retry advice is written. Calling it zero times means the target never runs, which is how caching and short-circuit authorisation advice work.

@Around("execution(* com.app..*(..))")
public Object retry(ProceedingJoinPoint pjp) throws Throwable {
    for (int i = 0; i < 3; i++) {
        try { return pjp.proceed(); }        // called up to THREE times
        catch (TransientException e) { /* retry */ }
    }
    throw new IllegalStateException("gave up");
}

The other three options, ruled individually:

Spot the shape: the false option contains the absolute "must ... only", and the other contains an invented name. Both are recognisable without knowing AOP. Absolutes and invented names are your two most reliable eliminators — they have accounted for a miss on every paper in this series.

The same topic, missed in both directions on one paper

Three components, and the stem decides how many are on offer:

Why Q17 says "two" and Q58 has "three". Q17's option list did not offer the manager bean, so only components 1 and 3 were available. Q58's did. The count in the stem is a fact about the option list, not about Spring. Rule each option on its own merits and both questions answer themselves — you never need to make the number come out.

The distractor you took on Q17: "write a Spring AOP advice to implement transactional behaviour." Spring's transaction support is built on AOP — that is why it feels right — but @EnableTransactionManagement registers TransactionInterceptor for you. The word that disqualifies the option is "write". Likewise, you never implement TransactionInterceptor yourself.

Under Spring Boot: TransactionAutoConfiguration supplies component 1, and the JDBC/JPA starters auto-configure component 2. You still write @Transactional yourself — Boot cannot guess which methods should be transactional.

public — and "Any visibility level" is the absolute that gives it away

Use the contradiction. When an option list contains a specific answer and an "any / all / none" catch-all, they cannot both be true. Ticking both guarantees a zero. Pick one.

The dangerous part, which the exam likes: Spring gives you no warning. @Transactional on a non-public method compiles, starts and runs — with no transaction at all. Same silent failure mode as self-invocation, and for the same reason.

The escape hatch is the same one as Q13: switch to AspectJ weaving (@EnableTransactionManagement(mode = AdviceMode.ASPECTJ)), which can advise non-public methods because there is no proxy — the target class itself is woven. Two conditions apply, and both are worth knowing precisely:

So annotating the non-public method directly is the only way to demarcate it — a class-level @Transactional will not reach it even under AspectJ. The mechanism is one constructor argument: AnnotationTransactionAspect builds its attribute source with new AnnotationTransactionAttributeSource(false) — publicMethodsOnly = false — where proxy mode uses the no-arg constructor and gets true.

And the mode attribute alone does nothing. AdviceMode.ASPECTJ needs spring-aspects on the classpath plus real weaving — the LTW agent (-javaagent:spring-instrument.jar) or compile-time weaving with ajc. Set the mode without weaving and no aspect is applied at all: you silently lose transactions everywhere, not just on the private method.

Version note for your exam. This site targets Spring 5.3, where proxy mode is public-only — so this question's answer is public. As of Spring 6.0, protected and package-visible methods are advised by class-based (CGLIB) proxies by default; interface-based proxies still require public. private is never advised by any proxy, in any version.

A missing bean throws — Spring never hands you a null

Spring's container is fail-fast by design. Returning null would push the failure to a later NullPointerException far from the cause. Every lookup failure has its own exception:

The three overloads, and which one the snippet used:

Object    b = context.getBean("myService");                 // by NAME  → needs a cast
MyService s = context.getBean("myService", MyService.class); // by NAME + type → type-safe
MyService s = context.getBean(MyService.class);              // by TYPE  → throws if ambiguous

The snippet uses form 1, so "the bean is retrieved by type" is false — the string "myService" is a name. And getBean() is overloaded to return a specific type, which makes that option true.

Reflection is used for all three injection styles, not just fields

Think about what the container has to do. It holds a Class object and must produce an instance. There is no compiled call site anywhere — Constructor.newInstance(), Method.invoke() and Field.set() are all reflection. Field injection is not special; it just additionally needs ReflectionUtils.makeAccessible() to bypass private.

The @Autowired / @Inject pair is worth pinning down because two of the four options turn on it. @Autowired is Spring, in org.springframework.beans.factory.annotation, and has a required attribute. @Inject is the JSR-330 standard, in javax.inject, and has no attributes at all — which is precisely why it cannot express required = false.

Three of four are true — @Value does more than you gave it credit for

@Value resolves two syntaxes, and the difference is the most testable fact about it:

Where it can be placed: fields, setter parameters, constructor parameters and @Bean method parameters — that last one is the "method arguments" option you left untaken. And #{${app.map}} — a placeholder nested inside a SpEL expression — injects a Map, which is the "inject into Maps" option.

@Bean
DataSource ds(@Value("${db.url}") String url) { ... }   // method ARGUMENT — true

@Value("#{${app.map}}")   Map<String,String> config;      // into a MAP — true
@Value("${app.servers}")  List<String> servers;           // comma-separated → List

The single false option — validation — is a layer error. Injection puts a value in; validation checks a value that is already there. Constraints come from Bean Validation (@NotNull, @Size, @Min) plus @Validated. Ask "does this option describe a different Spring feature?" — that is the shape of most false options in this bank.

All four were true — the "everything is true" question, again

All four statements describe the same single design decision — annotation-based controllers are plain objects — from four angles:

"All options correct" is a documented, recurring pattern in this bank — the MVC round 3 page already counted seven of them, and this paper adds two more on its own (Q29 and Q54). You have now lost more marks to this one question shape than to any single Spring topic.

The counting instinct is what fails here. "Four ticks feels like too many" is not evidence. When every option restates one idea from a different angle — as all four do here — that redundancy is the signal that they are all true, not a reason to choose between them.

All four again — Errors, Model, ServletRequest, ServletResponse

The supported-argument list is long, and the exam draws from it repeatedly. Worth holding whole:

The one positional rule the exam tests: Errors/BindingResult must be declared immediately after the validated @ModelAttribute or @RequestBody argument. Put anything between them and Spring cannot associate the two — you get a BindException (a 400) instead of your error-handling branch.

@PostMapping("/users")
String create(@Valid @ModelAttribute UserForm form,
              Errors errors,          // MUST be immediately after the validated arg
              Model model,
              HttpServletRequest req) { ... }

@MockBean replaces the bean in the context — that is its entire purpose

Rule that option against the code in the stem. The test stubs when(orderService.getOrderById(1L)).thenReturn("Mock Order Details") and then asserts the response body is "Mock Order Details". If the real bean were used, the assertion could not pass — the option contradicts the snippet it is asked about.

The performance fact the exam also asks: a @MockBean changes the context definition, so it produces a new, separately cached application context. Scatter different @MockBean combinations across many test classes and you rebuild the context repeatedly — the usual cause of a slow Boot test suite.

And @MockBean works on any Spring-managed bean — services, repositories, components, even controllers. The option restricting it to services was correctly rejected.

Boot configures a DataSource — it does not declare an OracleDataSource

The distinction is configured vs declared as a type. Boot's DataSourceAutoConfiguration picks the connection-pool implementation from the classpath — HikariDataSource by default in Boot 2.x, then Tomcat JDBC, then Commons DBCP2. Your driver-class-name tells that pool which JDBC driver to load; it does not change the bean's type.

The Jetty option is worth naming too, because it is the same shape as Q35's NGINX option: switching containers is a dependency change, not a property. You exclude spring-boot-starter-tomcat and add spring-boot-starter-jetty. No line of YAML can change the embedded server.