Eighteenth attempt — two marks short, and the reason is one section

Three questions, no false tick, three marks — and the pass

On these three you ticked nothing that was wrong. You simply stopped before taking every true option. Q16 had three true clients and you took two. Q30 had two true statements. Q39 had three true scopes. Those three marks are the difference between 44 and 47.

It is the fourth paper in a row with this shape — #16 had three, #17 had two (Q2 was five of five), this one has three. The pattern is always the same: you are right about what you tick, and you tick too few.

The routine, unchanged from #17 because it is still the right one: go down the options and write T or F beside each one on its own, ignoring how many you have marked. Then tick every T. You had 55 spare minutes on this paper; there is no excuse on time.

"Which statement is incorrect" — you picked a correct one

Q41 asked which statement about @RequestMapping is incorrect. You ticked "@RequestMapping can be configured to map exclusively to a specific HTTP method" — which is perfectly true (method = RequestMethod.GET). The false statement was "maps only to GET by default".

The mechanical fix: when the stem contains not, incorrect, false or except, mark each option T or F first without looking at the question, then pick the odd one out. Do not try to hold the inversion in your head while reading. The explanations for this question type are themselves confusing — the practice engine prints "Incorrect. This statement is correct" — which is exactly why you sort the options before applying the polarity.

containsBean(String) — by name, and there is no hasBean

Why getBean(...) != null is wrong and not merely ugly: getBean never returns null. If the bean is missing it throws NoSuchBeanDefinitionException, so the comparison is dead code that can only blow up.

In real code you would rarely call any of these. Prefer @Autowired(required = false), ObjectProvider<T>, Optional<T> injection, or @ConditionalOnMissingBean. containsBean is framework-level API.

within() takes a type pattern and nothing else. Only execution() has a throws slot.

execution( [modifiers] ret-type [declaring-type.]name(params) [throws ExPattern] )
//            public     void    com.acme.App.  get*()      throws IOException

within( TypePattern )        // that's the whole grammar
within(com.acme..*)                                  // ✅
within(com.acme..* throws NullPointerException)       // ❌ parse error
execution(* com.acme..*(..) throws NullPointerException)  // ✅ the legal way

Also worth knowing what Spring AOP does not support, since it is a cheap question: call, get, set, initialization, staticinitialization, preinitialization, handler, advice­execution, withincode, cflow, cflowbelow, if. Using one of those throws IllegalArgumentException at startup. Spring AOP is method execution only.

Lite mode is real: @Configuration is recommended, not required

The other three options, each a fact worth holding:

• Closing. new AnnotationConfigApplicationContext(...) registers no shutdown hook. Without close(), registerShutdownHook() or try-with-resources (ConfigurableApplicationContext extends Closeable), no @PreDestroy ever runs. Contrast SpringApplication.run(...), which does register one by default — that asymmetry is the exam's favourite version of this question.
• getBean by type returns the singleton, the same instance each call, unless the bean is prototype-scoped.
• Two candidates of the same type → NoUniqueBeanDefinitionException (a subclass of NoSuchBeanDefinitionException). Fix with @Primary, @Qualifier, or getBean("name", MyService.class).

All three: MockMvc, WebTestClient, TestRestTemplate

@SpringBootTest(webEnvironment = RANDOM_PORT)
@AutoConfigureWebTestClient
class UserApiIT {
    @Autowired WebTestClient web;      // non-blocking, real port
    @Autowired TestRestTemplate rest;  // blocking, real port, never throws on 4xx/5xx

    @Test void getUser() {
        web.get().uri("/users/1").exchange().expectStatus().isOk();
        rest.getForEntity("/users/1", User.class);   // relative URL — the port is filled in
    }
}

Two properties of TestRestTemplate the exam likes: it is fault-tolerant — it never throws on a 4xx/5xx, it returns the status in the ResponseEntity, which is the opposite of RestTemplate — and it does not follow redirects by default. It is also not registered at all under the default webEnvironment = MOCK, because there is no port to talk to.

And MockMvc's limit: no real container, so anything outside Spring's own filter chain — a servlet container valve, a listener, real HTTP parsing — is never exercised. That is the trade you make for the speed.

No. @Target({TYPE, FIELD}) — class level or field, never a parameter.

@SpringBootTest
class OrderServiceTest {

    @MockBean OrderRepository repo;   // ✅ field — replaces the bean in the context
    @Autowired OrderService service;

    @Test void cancels(@MockBean Clock clock) { }   // ❌ does not compile
    @Test void cancels(@Mock Clock clock) { }       // ✅ with @ExtendWith(MockitoExtension.class)
}

Two more things about @MockBean worth a mark: it is @Repeatable, so the class-level form can be stacked; and it resets the mock after every test method (MockReset.AFTER). Because it changes the bean definitions, each distinct set of @MockBeans produces a separate cached context — which is the usual reason a test suite suddenly starts several contexts.

Currency footnote: from Boot 3.4, @MockBean is deprecated in favour of @MockitoBean. The exam is on Boot 2.5, so @MockBean is the answer.

http://localhost:8080/actuator

Enabled versus exposed is the distinction most Actuator questions turn on. Nearly every endpoint is enabled by default (so its bean exists and JMX can see it) while only health is exposed over HTTP. "I added the starter and /actuator/metrics 404s" is not a bug — it is exposure.include.

findByAddressZipCode(…) or findByAddress_ZipCode(…)

How Spring Data resolves …ByAddressZipCode: it first tries the whole thing as one property (addressZipCode); failing that it splits at camel-case boundaries from the right — addressZip.code, then address.zipCode — until a path resolves. An underscore pins the boundary yourself and skips the guessing.

public interface PersonRepository extends JpaRepository<Person, Long> {
    List<Person> findByAddressZipCode(ZipCode zip);    // camel-case traversal
    List<Person> findByAddress_ZipCode(ZipCode zip);   // explicit boundary
}

Why With could never work — and the adjacent fact worth a mark: everything between the subject keyword (find, read, get, query, stream, count, exists, delete) and By is free text and ignored — so findWithZipCodeByAddress(…) is legal and means the same as findByAddress(…). But after By, every word must be a property name or a recognised keyword. With is neither, so findByAddressWithZipCode looks for a property called addressWithZipCode, doesn't find it, and the application fails at startup — not at query time.

The exception to "ignored": Distinct, First and Top are read in that gap — findDistinctTop3ByAddressZipCode(…).