Sixth attempt — 58%, and it is not a knowledge problem

Yes — JMX exposes everything by default; HTTP exposes almost nothing

Two transports, two independent inclusion lists. This is the table that answers Q21, Q34 and Q49 all at once:

Enabled and exposed are different switches. shutdown is the only endpoint disabled by default, so even include=* won't publish it until you set management.endpoint.shutdown.enabled=true. And exposing health is not the same as showing its detail — management.endpoint.health.show-details defaults to never.

Version note for the exam: this is Boot 2.x behaviour, which is what 2V0-72.22 tests. In Boot 3.x, JMX is off unless spring.jmx.enabled=true.

windows-version does not exist — everything else on that list is real

Know the roster well enough to spot a fake. The ones that turn up in questions:

loggers is the one worth remembering for a second reason: it's read and write — POST /actuator/loggers/com.example with {"configuredLevel":"DEBUG"} changes a log level at runtime with no restart. That ties straight into Q11 and Q13 below.

management.endpoints.web.base-path — a property, never code and never the build file

Everything about where Actuator lives is a property:

management.endpoints.web.base-path=/admin
management.endpoints.web.path-mapping.health=status
# → GET /admin/status

There is no ActuatorController class. When an option names a class you have never seen in the docs, that is eliminator (a) from the protocol.

HTTP and JMX — the same two transports as Q21

Actuator has exactly two exposure technologies, and every Actuator property path names one of them: management.endpoints.web.* or management.endpoints.jmx.*. If a property or an option mentions any other transport, it is invented. TCP/IP is the layer HTTP runs on, not something Actuator speaks.

tag=KEY:VALUE — equals separates the parameter, colon separates the pair

It is an ordinary query parameter whose value is a colon-joined pair, and you repeat it to AND several filters together:

GET /actuator/metrics/http.server.requests?tag=uri:/api/users&tag=status:200

Two related facts that show up alongside it: GET /actuator/metrics lists the available metric names, and GET /actuator/metrics/{name} without tags lists that metric's available tag keys and values — which is how you discover what you can filter on.

JSR-250 annotations — and both XML tags enable them

Two separate facts, and the question tested both:

All of them are processed by CommonAnnotationBeanPostProcessor, and both XML tags register it: <context:annotation-config/> turns on annotation processing, and <context:component-scan/> includes everything annotation-config does plus scanning. That "includes" relationship is why both options were correct — and it's a stock exam fact.

In Java config and Boot they're on automatically. One version trap: JSR-250 left the JDK in Java 11, so on Java 11+ outside Boot you need jakarta.annotation-api on the classpath.

public, protected, package-private — never private

The whole rule is just Java's overriding rules, because CGLIB proxying is subclassing: if a subclass could override it, CGLIB can intercept it.

Three consequences the exam likes: final methods fail silently — no error at startup, the advice simply never runs; self-invocation bypasses the proxy at every visibility level, because this.method() never goes through the proxy reference; and CGLIB needs an accessible no-arg constructor on the target class in Spring 6 / Boot 3.

Pair this with the choice rule: Spring picks a JDK dynamic proxy when the target implements an interface, CGLIB otherwise — unless you force it with proxyTargetClass=true, which Boot does by default (spring.aop.proxy-target-class=true).

All four of them — you answered "None of the above"

JoinPoint is available as an optional first parameter to every advice type. The only special case is @Around, which needs the subinterface:

@Before("execution(* com.app.service.*.*(..))")
public void log(JoinPoint jp) {
    log.info("{} args={}", jp.getSignature().getName(), jp.getArgs());
}

@Around("execution(* com.app.service.*.*(..))")
public Object time(ProceedingJoinPoint pjp) throws Throwable {
    return pjp.proceed();          // may be called 0, 1 or many times
}

The two rules that get tested: JoinPoint must be first if declared at all — binding parameters from returning/throwing come after it; and ProceedingJoinPoint extends JoinPoint, so @Around gets getArgs()/getSignature()/getTarget() too, plus proceed().

@SpringBootTest alone, on the class — no @ExtendWith, no @RunWith

Two independent things were being tested at once, and both distractor axes have to fail:

@SpringBootTest                 // Boot 2.1+ on JUnit 5 — this is the whole thing
class UserServiceIT {
    @Autowired UserService service;
    @Test void loads() { assertNotNull(service); }
}

"Silently ignored" is the exam's favourite consequence: a JUnit 5 class carrying @RunWith looks like it runs, but Spring never bootstraps, so every @Autowired field is null. Note the mirror fact from earlier in this conversation — in plain Spring (no Boot), @ContextConfiguration does still need @ExtendWith(SpringExtension.class), or use @SpringJUnitConfig which bundles both.

Database (JDBC), LDAP, and in-memory/properties — JAAS is authentication, not storage

Everything hangs off one interface with one method — UserDetailsService.loadUserByUsername(String) — and the exam tests which implementations ship in the box:

@Bean
UserDetailsService users() {
    return new InMemoryUserDetailsManager(
        User.withUsername("admin").password("{noop}secret").roles("ADMIN").build());
}

Two facts that ride along: UserDetailsManager extends UserDetailsService with create/update/delete, and the {noop} prefix is DelegatingPasswordEncoder's id — real deployments use {bcrypt}.

Subject + By + property expressions joined with And/Or

The parse is mechanical, and every part is mandatory:

Subjects: find, read, get, query, search, stream, count, exists, delete, remove. Keywords: Is/Equals, Not, LessThan/GreaterThan, Between, Like/StartingWith/EndingWith/Containing, In, IsNull, True/False, IgnoreCase, OrderBy…Asc/Desc, Top/First.

And the consequence that makes it examinable: property names must match entity fields, so findByLastNameFirstName is parsed as one property lastNameFirstName and, when it doesn't exist, fails at application startup — not at call time.

Four of the five options were true — you took fewer

Everything about this exception, in the shape questions ask it:

The hierarchy is the reason it's useful: EmptyResultDataAccessException → IncorrectResultSizeDataAccessException → DataAccessException → RuntimeException. Because it's a distinct subclass you can catch "no rows" precisely, without swallowing connection failures or constraint violations — which is exactly what option 1 said. All of Spring's data access exceptions are unchecked, and the same hierarchy covers JDBC, JPA and Hibernate, so you can swap the technology without changing catch blocks.

JdbcTemplate has no named parameters — that's NamedParameterJdbcTemplate

Read the snippet's two halves against each other: the SQL uses :name, the parameters arrive as a Map — and JdbcTemplate understands neither.

// wrong — JdbcTemplate cannot parse :name
jdbcTemplate.update("INSERT INTO users(name) VALUES (:name)", params);

// right
namedParameterJdbcTemplate.update("INSERT INTO users(name) VALUES (:name)",
        new MapSqlParameterSource("name", name));

NamedParameterJdbcTemplate wraps a JdbcTemplate internally (getJdbcOperations() reaches it) and translates named placeholders to positional ones before execution. Boot auto-configures both when a DataSource exists. The other useful SqlParameterSource is BeanPropertySqlParameterSource, which binds :name straight from a POJO's getName().