You scored 39 / 60 = 65%. Pass is 76% — that's just +7 questions. Every miss below is a precise fact you can memorise. Read the fix, then drill the quiz at the end of each section (options reshuffle every load).
DataSource is NOT a Spring interfacejavax.sql.DataSource is a standard Java / Jakarta EE interface (part of the JDBC API).
It is implemented by driver vendors and connection pools (HikariCP, DBCP2, Oracle UCP). Spring only
auto-configures and uses it. It is for relational databases only — NoSQL stores have their own
factories (MongoClient, RedisConnectionFactory).
DataAccessExceptionDataAccessException is the root, and it is an unchecked (runtime) exception — you never have to
declare or catch it. Spring wraps vendor SQLExceptions into this consistent hierarchy so your code is
independent of JDBC / JPA / Hibernate. SpringDataException and SpringDataAccessException are made-up distractors.
Common subclasses: DataIntegrityViolationException, DuplicateKeyException, EmptyResultDataAccessException.
Model-View-Controller is a software design pattern that separates concerns. Spring MVC is the framework that implements the pattern. True benefits: one controller can serve multiple view types (Thymeleaf, JSON, PDF) → reuse; it gives a standard, team-friendly structure. The trap option was "MVC is a framework".
DispatcherServlet delegates to Controllers, never straight to ViewsIt's the Front Controller — the single entry point. Flow:
Request → DispatcherServlet → HandlerMapping → HandlerAdapter → Controller → ViewResolver → View.render().
So it uses ViewResolvers to resolve view names, but it delegates the request to a Controller,
not directly to a View. In modern apps it needs no web.xml (Java config via
AbstractAnnotationConfigDispatcherServletInitializer, or Boot auto-config).
spring-boot-starter-test excludes nothing on this list — it includes themJUnit 5, Spring Test and Mockito are all included (transitively), so the answer was
"None of the mentioned". The starter bundles: JUnit 5 (Jupiter), Mockito, Spring Test, AssertJ,
Hamcrest, JSONassert, JsonPath, XMLUnit. The one thing dropped since Boot 2.4 is the JUnit 4 Vintage engine
(junit-vintage-engine) — add it explicitly if you still run JUnit 4 tests. Note: Hibernate is not in the test
starter (that's the JPA starter).
@MockBean puts a mock into the ApplicationContext@MockBean (Spring Boot Test) adds a Mockito mock to the context, replacing any existing bean of that
type. Plain @Mock / @InjectMocks are pure Mockito — they never touch the Spring context.
@Inject (JSR-330) just injects existing beans. Sibling: @SpyBean wraps a real bean.
RANDOM_PORT/DEFINED_PORT auto-configure a TestRestTemplateWith a real embedded server running, Spring Boot gives you a TestRestTemplate to make HTTP calls.
MockMvc is only for the default MOCK environment (no real server). On a reactive stack it's
WebTestClient.
@LocalServerPort (or @Value("${local.server.port}"))@LocalServerPort is just a meta-annotation for @Value("${local.server.port}") — both work.
Spring Boot records the chosen port under the local.server.port property at startup. @Autowired injects
beans, not a scalar; @ConfigurationProperties binds a group of properties, not one value. Only works when a
server actually starts (RANDOM_PORT / DEFINED_PORT); under MOCK it injects 0.
info endpoint = arbitrary, non-sensitive app metadata/actuator/info exposes custom, read-only descriptive data built from InfoContributor beans:
build info, git commit, and anything under the info.* namespace. It is not for system/CPU metrics
(that's /metrics), container/hypervisor info, or database info. Since Boot 2.6 the env contributor is off by
default — enable with management.info.env.enabled=true. Never put secrets here (unauthenticated by default).
@ConditionalOnProperty OR @ConditionalOnExpressionBoth work. @ConditionalOnProperty(name="enable.x", havingValue="true") is the direct way;
@ConditionalOnExpression("${enable.x:false}") uses SpEL for more flexible logic. Distractors:
@ConditionalOnResource (a file on the classpath), @ConditionalOnBean (a bean exists).
OUT_OF_SERVICEThe default SimpleStatusAggregator severity order is
DOWN > OUT_OF_SERVICE > UP > UNKNOWN. The aggregate is the most severe status any indicator reports.
A single OUT_OF_SERVICE outranks any number of UPs. (DOWN only appears if some indicator is DOWN.)
DOWN and OUT_OF_SERVICE map to HTTP 503The default SimpleHttpCodeStatusMapper has only two explicit entries: DOWN → 503 and
OUT_OF_SERVICE → 503. Everything else (UP, UNKNOWN, any custom status) falls back to 200.
503 (Service Unavailable) lets a load balancer drain traffic.
Highest → lowest precedence:
1) profile-specific OUTSIDE jar (./config/application-prod.yml) →
2) application OUTSIDE jar (./config/application.yml) →
3) profile-specific INSIDE jar → 4) application INSIDE jar.
Two rules: outside > inside, and within a location profile-specific > plain.
shutdown is DISABLED by default; enabling it does not auto-expose over HTTPFor safety, shutdown is off by default. Enable it with
management.endpoint.shutdown.enabled=true — that makes it available (over JMX), but to reach it over HTTP
you must also add management.endpoints.web.exposure.include=shutdown. It's a normal @Endpoint, so it
can be exposed over both HTTP and JMX — it just isn't automatically.
Not a "failed" section, but you dropped six Core facts. These are easy, high-frequency marks.
BeanFactoryPostProcessor edits bean definitions before beans are createdBeanFactoryPostProcessor operates on the configuration metadata (BeanDefinitions) before instantiation —
change property values, scopes, add/remove definitions. BeanPostProcessor runs after instantiation, on bean
instances (proxies, AOP). PropertyPlaceholderConfigurer is a specialised BFPP; BeanPreProcessor is fake.
Order: BFPP → BPP → init → ready.
@Bean = setter injection (no @Autowired needed)When a @Bean method does svc.setUserRepository(userRepository()), that's setter injection
performed explicitly in config — the bean is built with a no-arg constructor and the dependency set afterwards.
@Autowired is not required (you wired it yourself), and method order doesn't matter.
Setter injection works for mandatory and optional deps (though constructor injection is recommended for mandatory ones).
SpEL works in XML, annotations, @Value, Spring Security rules, and programmatically — not only inside
annotations. It supports literals ('hi', 123, true, null) and arithmetic (+ - * / %), relational
(==, !=, <, >) and logical (&&, ||, !) operators. Syntax: #{...} for expressions, ${...} for
property placeholders.
prototype is NOT web-only; request/session/application areOnly singleton and prototype work in any ApplicationContext. The web-only scopes are
request, session, application, websocket. Trap: the question asked which scope is not web-only → prototype.
Note: prototype beans get no @PreDestroy callback (the container stops tracking them after creation).
On context.refresh() Spring pre-instantiates all non-lazy singletons (running constructors, DI,
@PostConstruct). This catches wiring errors at startup. @Lazy (or
spring.main.lazy-initialization=true) is opt-in to defer that. Prototype beans are never eager.
@ComponentScan("com.example.app")Best practice is a narrow, specific package as a String literal. Broad scans like "com" or
{"org","com"} are slow and risk picking up junk. Un-quoted {com.example.app} is a syntax error.
In Boot, put @SpringBootApplication in the root package so default scanning covers just your code.
@PreAuthorize works at BOTH class and method levelThe false option claimed @PreAuthorize is class-only — wrong, it works at both. True facts:
@EnableGlobalMethodSecurity turns on annotation-based method security (Spring Security 6+ uses
@EnableMethodSecurity); @Secured restricts by role (no SpEL);
@PreAuthorize/@PostAuthorize use SpEL. And hiding URLs in the view isn't enough —
secure the methods too.
@WebMvcTest + @MockBean?
Just ask. Say "quiz me on the 21" for a rapid-fire mixed round.