Fourteenth attempt — you fixed both behaviours I asked for, and both worked

Read the number → rule each option → count before submitting

The asymmetry worth internalising: on a single-answer question, a second tick can only ever destroy a mark. It cannot rescue one. If you are torn between two options, ticking both scores 0; committing to either scores 0 or 1. Guessing beats hedging every single time.

On an open multi-select, the redundancy tell: when several options restate the same idea from different angles, they are usually all true — that is how this bank writes "everything is correct" questions. Q19, Q31 and Q35 on this paper were all of that shape.

Twice per bean — and the second hook is where AOP proxies are created

Why "only once" is not a near-miss but a serious error: the second hook, postProcessAfterInitialization, is where Spring wraps your bean in an AOP proxy (AbstractAutoProxyCreator). Drop that hook and @Transactional, @Async, @Cacheable and every custom aspect stop existing. It is the most consequential callback in the container.

The full order for a single bean — worth knowing as a sequence, because the exam asks it from several angles:

Two facts that answer the distractors: instantiation and DI have already happened before any BPP runs — so "before any bean is created" is wrong. And destruction is not part of this interface: that is DestructionAwareBeanPostProcessor, a sub-interface — so "three times" is wrong. The base interface has exactly two methods.

A neat consequence: @PostConstruct at step 5 is itself implemented by a BeanPostProcessor (CommonAnnotationBeanPostProcessor). The mechanism runs the annotation.

application — not singleton, and the difference is real

Where they actually diverge. A singleton is one per ApplicationContext. An application-scoped bean is one per ServletContext. In an app with a root context plus one or more DispatcherServlet child contexts, each context gets its own singleton, but they all share one application-scoped bean — it is stored as a ServletContext attribute, and is reachable via servletContext.getAttribute() from outside Spring entirely.

The exam tell: the words ServletContext and web-aware in the stem. Neither can apply to singleton, which works in any context type. When a stem names a servlet concept, a non-web scope cannot be the answer.

StandardEnvironment has exactly two property sources — everything servlet is absent

The question is a two-class comparison, and once you see that, every option sorts itself:

Profiles are the easy one to under-think: they are not a property source at all — they are part of the Environment interface, so they are available in every context type, web or not.

One relaxed-binding trap worth carrying: SystemEnvironmentPropertySource matches case-insensitively and ignores separators, so MY_VAR, my.var and my-var all resolve to the OS variable MY_VAR.

It aliases annotation attributes — nothing to do with beans

@AliasFor declares that two attributes of the same annotation are the same attribute under two names. Set either and both read back identically; set both to different values and Spring throws.

public @interface MyAnnotation {
    @AliasFor("location") String value()    default "";
    @AliasFor("value")    String location() default "";
}
// @MyAnnotation("/tmp") and @MyAnnotation(location = "/tmp") are identical

Where you have already used it without noticing: it is why @RequestMapping("/x") means path = "/x", why @SpringBootTest(classes = …) works, and why composed annotations can rename an attribute of the annotation they meta-annotate.

Bean aliasing, for contrast — the feature the distractor borrows its words from: @Bean(name = {"primary", "alias1"}), or <alias name="a" alias="b"/> in XML. Different mechanism, different layer. The stem said annotation attributes.

The false option contradicts itself — DI decouples behavior from construction

Read the option's own reasoning. It claims an advantage of DI on the grounds that DI couples behavior with construction — but coupling is exactly what DI removes. The option argues against itself. And its conclusion is backwards too: because the wiring happens in the container rather than at the call site, DI generally makes code harder to trace, not easier. That is one of DI's genuine costs.

A reusable filter for "advantages of X" questions: an option that states a real property of X and then calls it an advantage is often the trap — and an option whose stated mechanism contradicts X's definition is always false. Two of the three false options here are simply DI's definition inverted.

standaloneSetup takes an instance, not a Class

Why it must be an instance. Standalone mode has no Spring context — that is its entire point. With no container there is nothing to instantiate a Class or inject its dependencies, so you construct the controller and hand over the finished object, wiring any collaborators yourself (usually with plain Mockito mocks).

PersonService service = Mockito.mock(PersonService.class);
mockMvc = MockMvcBuilders
        .standaloneSetup(new PersonController(service))   // an INSTANCE you built
        .build();

And new MockMvc() is never right: MockMvc has no public constructor. It only ever comes from a MockMvcBuilders builder or from @AutoConfigureMockMvc.

The trade-off worth knowing: standalone mode skips @ControllerAdvice, filters, and converters unless you register them on the builder (.setControllerAdvice(...), .addFilters(...)). That speed comes at the cost of fidelity.

Four of six were true — and the key fact is that rollback is already the default

The one fact the question is built on: a @Transactional test method is rolled back automatically. @Rollback is @Rollback(true), which is already the default — so writing it changes nothing. It is redundant, not wrong.

Working through the four true statements, since each is a separate idea:

The false pair, for completeness: testRollback does not need @Transactional — it only reads committed state. And dropping @Transactional is not how you commit; that is @Rollback(false).

A real caveat the question glosses over: this test pair depends on execution order, which JUnit 5 does not guarantee. In practice use @TestMethodOrder(MethodOrderer.OrderAnnotation.class), or have each test set up its own state.

An in-memory database is not automatic — it needs JPA on the classpath

Boot auto-configuration is conditional, never unconditional. An embedded database appears only when both a data starter (spring-boot-starter-data-jpa or -jdbc) and an embedded driver (H2, HSQLDB, Derby) are on the classpath. A pure Spring MVC app with neither gets no DataSource at all.

The three embedded containers, and how you choose: Tomcat (default), Jetty, Undertow — always by dependency, never by a property. Exclude spring-boot-starter-tomcat and add the one you want. To run with no web server at all: spring.main.web-application-type=none.

Three families of return type — and JSONObject is not one of them

The layer test. JdbcTemplate speaks JDBC: it reads a ResultSet of columns and rows. JSON is a serialization concern that lives at the web layer (Jackson), not the data layer. JSONObject is not even a JDK type — it comes from an external JSON library. If an option names a format from another layer, it is wrong.

List<Order> orders = jdbcTemplate.query("SELECT * FROM orders",
        (rs, rowNum) -> new Order(rs.getLong("id"), rs.getString("status")));

RowMapper vs ResultSetExtractor, which the exam pairs with this: RowMapper is called once per row and returns one object; ResultSetExtractor is called once for the whole ResultSet and returns one object — use it when rows must be aggregated, as with a join producing one parent and many children.

Four of five true — the code shown is broken, and saying so is one of the true options

The trick in the stem: the snippet looks like it sends the Bearer token, but it does not. getForEntity(url, String.class, requestEntity) compiles because the third parameter is a varargs of URI template variables — so the HttpEntity is silently used as a URI variable and the Authorization header is never sent.

HttpHeaders headers = new HttpHeaders();
headers.set("Authorization", "Bearer " + token);

ResponseEntity<String> response = restTemplate.exchange(
        url, HttpMethod.GET, new HttpEntity<Void>(headers), String.class);

The four true statements, each a separate fact: HttpEntity wraps headers and an optional body; HttpHeaders is how you set Authorization; the Bearer format in the snippet is correct; and exchange is what you must use for a GET with custom headers. Only "getForEntity accepts an HttpEntity" is false.

Worth noting the "correct but useless" pattern: the token is formatted correctly — that option is true — even though the request never carries it. Rule each statement against what it actually claims, not against whether the code works. That habit is what turns a 4-of-5 into a mark.

# is a method parameter · @ is a bean — and the paper tested both today

Two questions on this paper turn on the same two symbols. Q49 asked what # means in plain SpEL; this asks what it means inside a security expression. Learn the pair once:

Why @username fails: it asks Spring for a bean named username. There is no such bean, so the expression throws at evaluation time — a runtime failure, not a compile error. And @PreAuthorize("'ADMIN'") fails for a different reason: it is a string literal, and the expression must evaluate to a boolean.

The practical gotcha with #param: parameter names are erased at compile time unless you build with -parameters. Without it, annotate the parameter: canEdit(@P("username") String username).