You scored 40 / 60 = 67% — +1 mark on attempt #1. Pass is 76% (46/60), so you're now just +6 questions away. Read each fix, then drill the quiz at the end of every section (options reshuffle on each load).
<exclusion> removes that artifact from the classpath — with no substituteExcluding spring-web from a dependency completely removes it from the classpath. Maven does
not log-and-continue, does not auto-replace it, and does not pin a version. If the library
actually needs it at runtime you get ClassNotFoundException / NoClassDefFoundError. Only that one
transitive dep is removed (not all Spring deps). You can optionally add your own version back explicitly.
mvn dependency:tree to check what breaks.True best practices: use @ComponentScan to cut boilerplate on large projects; define beans
explicitly for control (ordering, init, third-party classes); combine both; and avoid scanning
when several beans share a type/name (prevents NoUniqueBeanDefinitionException). The wrong option was "rely
exclusively on @ComponentScan" — that surrenders control over tricky beans.
ClassPathXml…, FileSystemXml…, AnnotationConfig…The three real non-web implementations are ClassPathXmlApplicationContext (XML on classpath),
FileSystemXmlApplicationContext (XML on filesystem) and AnnotationConfigApplicationContext (@Configuration
classes — the modern default). XmlWebApplicationContext is web-only (needs a servlet container).
FileSystemTxtApplicationContext is a made-up distractor.
#{...} is a SpEL expression; ${...} is a property placeholder#{...} = SpEL: reference beans #{@myBean.value}, call statics via
#{T(java.lang.Math).random()}, read system props #{systemProperties['user.name']}, do arithmetic
#{2*100}. ${...} = property placeholder resolved from the Environment/properties files.
A bare # with @ references a Spring bean. Key gotcha: a @Value("#{...random...}")
is evaluated ONCE at bean creation — the field keeps that value forever. For a fresh value per call, compute it in the
method body.
@Lazy or @DependsOn — NOT @Order@DependsOn("other") forces another bean to be created first; @Lazy defers a bean until first use.
@Order is the trap — it only ranks beans within a collection (lists of filters, event listeners), it does
not affect container instantiation order. @Import pulls in config classes but doesn't order bean creation.
singleton and prototype work in non-web appssingleton (default, one per container) and prototype (new instance every request) work in
any context. request, session, application, websocket need a web-aware
context — using them standalone throws IllegalStateException at runtime.
@Transactional OR programmatically on a TransactionDefinitionTwo valid ways: declaratively via @Transactional(propagation = Propagation.REQUIRES_NEW), or programmatically
via def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW) / a TransactionTemplate.
There is no global property (spring.propagation.mode), no env var, and no PropagationMode bean —
all distractors. Remember the defaults: REQUIRED (join or start); REQUIRES_NEW (suspend outer, start
independent); NESTED (savepoint); MANDATORY (must already have one).
@EnableTransactionManagement + a PlatformTransactionManager bean + @TransactionalTransaction management is not on by default in plain Spring. You need all three:
(1) @EnableTransactionManagement on a @Configuration class (registers the AOP interceptor);
(2) a PlatformTransactionManager bean (e.g. DataSourceTransactionManager, JpaTransactionManager);
(3) @Transactional on the methods/classes. Spring Boot auto-supplies (1) and (2) — but you still write (3).
Local transactions span a single resource (one database) and are managed by that resource — no JTA / external coordinator. Contrast with global (distributed) transactions across multiple resources, which need JTA. "Scoped / Confined / Internal Transactions" are all made-up terms.
RuntimeException and Error roll back — checked exceptions do NOTSpring's default: rollback on unchecked exceptions (RuntimeException + subclasses) and
Error. Checked exceptions (IOException, SQLException) do not
roll back by default. Override with @Transactional(rollbackFor = IOException.class) (or noRollbackFor).
Spring's transaction abstraction integrates with Hibernate, JPA, JTA (distributed) and plain JDBC
(via DataSourceTransactionManager). JDO is no longer supported — the org.springframework.orm.jdo
package (incl. JdoTransactionManager) was removed in Spring Framework 5.0.
DataSource by declaring your own @BeanDefine a @Bean of type DataSource in a @Configuration class. Because
DataSourceAutoConfiguration is guarded by @ConditionalOnMissingBean, Spring Boot's default
backs off and uses yours. You don't edit pom.xml or "disable" anything.
DataSource ← DataSourceAutoConfiguration; JdbcTemplate ← JdbcTemplateAutoConfigurationThese beans come from auto-configuration classes shipped in spring-boot-autoconfigure — the developer writes
nothing. DataSourceAutoConfiguration picks the pool (HikariCP by default), gated by @ConditionalOnClass +
@ConditionalOnMissingBean. JdbcTemplateAutoConfiguration adds JdbcTemplate /
NamedParameterJdbcTemplate, gated by @ConditionalOnSingleCandidate(DataSource.class) — so
two DataSource beans without @Primary silently disables your JdbcTemplate. Registered via
spring.factories (≤2.6) or AutoConfiguration.imports (2.7+).
@WebMvcTest loads the web tier only — no @Component, no @ConfigurationPropertiesLoaded: @Controller/@RestController, @ControllerAdvice,
@JsonComponent, filters, converters — plus auto-configured MockMvc. NOT loaded: plain
@Component, @Service, @Repository, and @ConfigurationProperties beans. Supply the missing
collaborators with @MockBean (or @EnableConfigurationProperties for the properties bean).
@WebMvcTest tests all / one / a subset of controllers — never plain componentsValid uses: @WebMvcTest (all discovered controllers), @WebMvcTest(MyController.class)
(one controller in isolation), @WebMvcTest({A.class, B.class}) (a subset). It is a web slice, so it
can never test a plain @Component in isolation — use a unit test or @SpringBootTest for that.
@DataJpaTest methods are transactional and roll back by defaultYes — every @DataJpaTest method runs in a transaction that is rolled back at the end, keeping the DB
clean between tests. It also configures only JPA components (entities, repositories, TestEntityManager) and uses an
in-memory H2 DB by default. To keep changes, add @Rollback(false) or @Commit.
@TestPropertySource@TestPropertySource(locations = "classpath:test.properties") is the test-specific, highest-priority way to
supply properties in a test. @PropertySource is for regular @Configuration (not test-specific). Also useful:
src/test/resources/application.properties overrides main props, and @ActiveProfiles("test") loads
application-test.properties.
shutdown is enabled, but only health/info are exposed over HTTPTwo separate concerns. Enablement: all endpoints are enabled by default except shutdown.
HTTP exposure: only health (and historically info) are exposed over the web by default — the
/actuator discovery page lists what's exposed. To reach /beans, /env, /metrics etc. over
HTTP you must add them to management.endpoints.web.exposure.include. So /beans being "not
provided out of the box" is about exposure, not enablement.
spring.factories candidates + @Conditional annotationsThe two correct facts: auto-config classes are listed in META-INF/spring.factories (Boot ≤2.6) /
AutoConfiguration.imports (Boot 2.7+) and processed at startup; and they use @Conditional annotations
(@ConditionalOnClass, @ConditionalOnBean, @ConditionalOnMissingBean) to decide when to apply.
Also true: auto-config runs after user beans (so your beans win), and it can trigger on a bean being present OR
missing — not one or the other.