Fourth attempt — 72%. Three questions from a pass.

Two ways: SpelParserConfiguration, or the spring.expression.compiler.mode system property

SpEL normally interprets the expression AST on every evaluation. The compiler turns a hot expression into real bytecode. You switch it on either programmatically — new SpelParserConfiguration(SpelCompilerMode.MIXED, classLoader) passed to a SpelExpressionParser — or JVM-wide with -Dspring.expression.compiler.mode=IMMEDIATE|MIXED|OFF, which sets the default used for framework expressions (@Value, @Cacheable …). SpEL is a runtime parser, so there is no build plugin and no JMX surface — both were invented distractors.

The three modes: OFF (default — always interpret) · IMMEDIATE (compile on first evaluation; if the runtime types later differ it fails fast and you must handle it) · MIXED (interpret first, compile in the background after N successful runs, and silently fall back to interpreting on a type mismatch). The two configuration routes are independent — your own parser instance always wins for that parser.

No assignment, no custom resolvers, no conversion service, no selection/projection

Learn it as two short lists. Not compilable: assignment (name = 'John') · expressions using custom PropertyAccessor/MethodResolver (runtime dispatch can't be compiled) · anything relying on the ConversionService for coercion · collection selection .?[…] and projection .![…]. Compilable (the two you must not tick): ordinary operators (+ - * / == < >) and constructor calls (new com.example.Foo()).

All four were correct — @Controller, @RestController, @Repository, @Service

Every stereotype is meta-annotated with @Component, which is exactly why component scanning finds them:

Three true behaviours — and the difference between method-level and parameter-level optionality

Spring resolves all parameters of an @Autowired method against the BeanFactory. What happens when one can't be resolved depends on where you declare the optionality:

The exam loves that middle-versus-bottom distinction: method level = skip the call, parameter level = call it with a hole in it. (Constructors differ — use Optional<T> parameters for optional constructor dependencies.)

It aliases annotation attributes — nothing to do with beans

@AliasFor (in org.springframework.core.annotation) makes two attributes of an annotation interchangeable — set either one and both carry the same value; setting both to different values is an error. It's how @RequestMapping's value/path, and @SpringBootTest/@WebMvcTest's value/controllers, work.

public @interface MyAnnotation {
    @AliasFor("location") String value()    default "";
    @AliasFor("value")    String location() default "";
}

Bean aliases are a different feature entirely: XML <alias name="a" alias="b"/>, or extra names in @Bean(name = {"primary", "alias"}).

No. Its attributes take fixed types only

@Transactional's attributes — propagation, isolation, timeout, readOnly, rollbackFor, transactionManager — accept enums, ints, booleans and classes. None of them is SpEL-evaluated. Learn the annotations by which side of that line they sit on:

void, String, ModelAndView — HttpServletRequest is a parameter, never a return type

Valid returns: void (you wrote the response yourself, or 204 No Content with @ResponseBody) · String (a view name — or the literal body under @ResponseBody) · ModelAndView (view + model together) · a domain object / collection (serialised by an HttpMessageConverter) · ResponseEntity<T> (body + status + headers — the production choice) · also Callable, DeferredResult, Model, View, HttpEntity. Not valid: HttpServletRequest / HttpServletResponse — those are injected into parameters.

Add @AutoConfigureMockMvc — @SpringBootTest alone does not give you MockMvc

@SpringBootTest loads the full context but registers no MockMvc bean. @AutoConfigureMockMvc triggers MockMvcAutoConfiguration, which wires one from the WebApplicationContext — filters, security, error handling and message converters included. (There is no MockMvc.setUp() or MockMvc.create(); the manual route is MockMvcBuilders.webAppContextSetup(wac).build().)

Two exam-worthy details: @AutoConfigureMockMvc(addFilters = false) strips the filter chain (handy to bypass Spring Security), and mixing RANDOM_PORT with MockMvc is contradictory — MockMvc never touches the embedded server. For WebFlux it's @AutoConfigureWebTestClient, since MockMvc is servlet-only.

Integration and slice testing are supported; contexts come from @SpringBootTest or @SpringJUnitConfig

Know which module owns which annotation — that's the whole question:

The other two distractors: Mockito is the default mocking framework (EasyMock needs a manual dependency — not "out of the box"), and spies are fully supported via @SpyBean. Also remember @SpringJUnitConfig = @ExtendWith(SpringExtension.class) + @ContextConfiguration, the plain-Spring way to build a test context.

@LocalManagementPort — or @Value("${local.management.port}")

By default Actuator shares the app's port; set management.server.port=8081 to split them. Then:

@LocalManagementPort lives in org.springframework.boot.actuate.autoconfigure.web.server. This matters most in tests using webEnvironment = RANDOM_PORT, where both ports are assigned dynamically. @ActuatorPort and a bare @LocalPort are invented.

Subject + By + property expressions joined with And/Or

Spring Data parses the method name as subject (find, read, get, query, count, exists, delete, remove) + By + predicate. Both parts are mandatory:

Keywords worth recognising: GreaterThan/LessThan, Between, Like/Containing/StartingWith, In, IsNull, Not, IgnoreCase, OrderBy…Asc/Desc, Top/First. Property names must match entity fields — findByLastNameFirstName is parsed as one property lastNameFirstName and, when it doesn't exist, fails at startup, not at call time.