Seventh attempt — 70%, +7 marks in one day, four short of a pass

Transactions, Security, Tracing — File and Network I/O are domain work

The test is one question: would this code look the same in a completely unrelated module? If yes, it's cross-cutting. If it exists because of what this particular class is for, it's domain.

The trap in both wrong options is the same move: naming the subject of a cross-cutting concern rather than the concern. And note the related distinction the exam sometimes tests — shared code is not automatically a cross-cutting concern. A utility method called from everywhere is just code reuse; it becomes cross-cutting only when it must be applied around many unrelated methods.

META-INF/spring.factories — at the root of META-INF, no sub-folder

SpringFactoriesLoader scans every JAR on the classpath for exactly META-INF/spring.factories and merges what it finds. Keys are interface names, values are comma-separated implementation names:

# META-INF/spring.factories
org.springframework.context.ApplicationListener=\
com.example.MyListener,\
com.example.OtherListener

The version fact worth knowing: Boot 2.7 deprecated registering auto-configurations under the EnableAutoConfiguration key, moving them to META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (one class per line) alongside the @AutoConfiguration annotation; Boot 3 removed the legacy key entirely. All the other keys still live in spring.factories. The whole mechanism runs before the ApplicationContext exists, which is why it's a file and not a bean.

banner.txt in src/main/resources, or implement Banner

Exactly two supported routes, plus the properties that control them:

SpringApplication app = new SpringApplication(MyApp.class);
app.setBanner((environment, sourceClass, out) -> out.println("=== My Application ==="));
app.run(args);

banner.txt supports placeholders — ${spring-boot.version}, ${application.version}, ${application.title} (the last two come from MANIFEST.MF, so they're empty when you run from an IDE) — and ANSI colour codes such as ${AnsiColor.BRIGHT_YELLOW}. There is no spring.banner.text property: you can point at a file, but you can't inline the content.

YAML, properties, environment variables — not XML

The sources, and the order in which later ones win — the precedence list is itself a stock question:

Two details that get tested. Relaxed binding is what makes environment variables work: SPRING_DATASOURCE_URL, spring.datasource.url and spring.datasource.URL all bind to the same property, because Boot normalises case, hyphens and underscores. And @Value vs @ConfigurationProperties: the first pulls one value, the second binds a whole prefix to a typed object and supports validation and relaxed binding properly.

It registers the class as a bean — the extra attribute is just metadata

Spring resolves annotations transitively, so anything meta-annotated with @Component — directly or through @Service/@Repository/@Controller — is picked up by component scanning:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Service                                  // ← this is what makes it a bean
public @interface SpecialService {
    String description() default "Special service layer";
}

@SpecialService(description = "Handles special business logic")
public class SpecialOrderService { }      // registered, singleton, name "specialOrderService"

Two mechanics behind it: @Retention(RUNTIME) is mandatory (Spring reads annotations reflectively at runtime), and this is the same technique Spring itself uses — @RestController is just @Controller + @ResponseBody, @SpringBootApplication is three annotations. You can also use @AliasFor to expose an attribute of the meta-annotation, e.g. letting your annotation set the bean name.

No — since Spring 4.3 a class with a single constructor is autowired without it

The rule and its boundary:

@Controller
public class MyController {
    private final MyService myService;

    public MyController(MyService myService) {   // only constructor → @Autowired implied
        this.myService = myService;
    }
}

The other correct option is worth learning as its own fact — how Spring breaks a tie when several beans match a type: @Qualifier narrows the candidates, then @Primary wins among what remains, then @Priority, and finally Spring matches the injection-point name (the field or constructor-parameter name) against the bean names. Only if none of that resolves it do you get NoUniqueBeanDefinitionException. That last fallback is why a parameter called myService quietly matches a bean named myService.

T(), projection ![], selection ?[], method calls — the arrow function was JavaScript

The SpEL operators worth recognising on sight:

The distinction most often tested: #{…} is SpEL, evaluated by SpelExpressionParser; ${…} is a property placeholder, resolved by PropertySourcesPlaceholderConfigurer. They look alike, are processed by different machinery, and @Value("#{T(java.lang.Math).PI}") vs @Value("${server.port}") is the classic pairing. Remember ! = map, ? = filter — the projection/selection pair is the one people mix up.

TransactionTemplate

Spring gives you two transaction styles, and the exam wants you to name the class for each:

txTemplate.execute(status -> {
    accountDao.debit(from, amount);
    accountDao.credit(to, amount);
    if (somethingIsOff) status.setRollbackOnly();   // conditional rollback
    return null;
});

Keep the type names straight, because they are exactly what gets swapped in distractors: TransactionManager is the empty marker interface; PlatformTransactionManager is the real synchronous one (its implementations are DataSourceTransactionManager, JpaTransactionManager, JtaTransactionManager); ReactiveTransactionManager is the reactive sibling. TransactionTemplate is built on a PlatformTransactionManager and follows the same template-callback pattern as JdbcTemplate. Use TransactionCallbackWithoutResult when there's nothing to return.

HikariCP, DBCP2 BasicDataSource, C3P0 ComboPooledDataSource

Split the implementations into pools and non-pools, because that's the only distinction the question ever draws:

Boot's auto-configuration picks the first pool it finds on the classpath, in this order: HikariCP → Tomcat JDBC → Commons DBCP2 → Oracle UCP. Override with spring.datasource.type. The reason it matters — and the reason the "not a pool" options are traps — is that DriverManagerDataSource pays a full JDBC handshake per request and SingleConnectionDataSource serialises every thread onto one connection.

Class level applies to every method — moving it to one method is not equivalent

What Spring's test support actually does with @Transactional:

The rollback default is the fact to hold on to — it exists so tests don't leak state into one another, and it's why @DataJpaTest is transactional by default too. Two consequences worth knowing: a rolled-back test never exercises the real commit, so constraint violations that only surface at flush time can hide (use @Commit or an explicit flush()); and code that starts its own thread — or runs with REQUIRES_NEW — is outside the test transaction and will not be rolled back.

Pass an HttpEntity holding HttpHeaders

Per request you wrap headers in an HttpEntity and use exchange(); globally you add an interceptor:

HttpHeaders headers = new HttpHeaders();
headers.setBearerAuth(token);
headers.setContentType(MediaType.APPLICATION_JSON);

HttpEntity<Void> entity = new HttpEntity<>(headers);
ResponseEntity<User> res = restTemplate.exchange(
        "/users/{id}", HttpMethod.GET, entity, User.class, 1);

The distractor worth pinning down: @RequestHeader is server-side — it reads an incoming header in a controller method. Client-side sending and server-side reading are opposite directions, and the exam pairs them deliberately. Note also that HttpEntity is the request-side type; ResponseEntity extends it and adds the status code.