Revision 3 — new questions up from 44% to 62%. Now stop leaving true options out

@MockBean has three true facts. You keep picking one or two

@MockBean as one picture. Every true statement about it comes from this:

@WebMvcTest(OrderController.class)
@MockBean(AuditLog.class)              // ① on the CLASS: a mock goes in the context, no field
class OrderControllerTest {
    @MockBean PaymentClient payments;  // ① on a FIELD: a mock goes in the context AND into this field
}

// ② what happens to the context, for each @MockBean type:
//     a PaymentClient bean already exists → the mock REPLACES it
//     no PaymentClient bean exists        → the mock is ADDED
// ③ the set of mocks is part of the context's cache key:
//     test classes with different @MockBean sets get separate contexts (slower suite)

If you can answer ① where it goes, ② replace and add, and ③ caching, you can't under-select. The only false one is "same as @Mock": @Mock never touches a Spring context.

Why @MockBean can't bring in auto-config: it would register a Mockito mock of the auto-config class. A mock is an empty stand-in, and Spring never reads its @Bean methods, so none of the beans Acme should provide would be created.

The annotations that bring in auto-config. All three have "AutoConfiguration" in the name, or contain an annotation that does:

"Closest to" @ContextConfiguration: both it and @ImportAutoConfiguration take classes, which is why they look alike. Ask what happens to the class you pass. @ContextConfiguration builds the test context from your classes, as plain config, just like new AnnotationConfigApplicationContext(AppConfig.class). In a Boot test it also replaces the usual search for your @SpringBootApplication, which is why it's wrong for adding one extra thing.

"Missing class" is a condition in some questions, not all. And scan filters never work

Look at the two attributes' Java types:

public @interface SpringBootApplication {
    Class<?>[] exclude()   default {};   // exclude = Foo.class        ← needs Foo to compile
    String[]   excludeName() default {};   // excludeName = "com.acme.Foo" ← never needs Foo
}

They have the same effect when Foo is on the classpath. They're not the same when it isn't, because a .class literal is checked by the compiler. So "can it remove an auto-config?" gives exclude a yes, and "the jar is missing" gives it a no. Check which question you're answering.

@ComponentScan(excludeFilters) is wrong every time. This is the third time you've ticked it (exam Q56, revision 1, today). Scanning never finds auto-config classes in the first place. They're imported from a list (spring.factories) by AutoConfigurationImportSelector, so a scan filter has nothing to filter.

server.port: the timeout options made it feel like a timeout question, but the question was "which are real?". server.port is the best-known Boot property there is. Giving each option its own yes or no would have caught it.

Last time a final class was "silent". This time a final method "fails startup"

You got "final class → startup fails" right in both retries, then applied it to the final method as well. There's only one loud case, so learn that one and treat everything else as silent:

The test is "is there a proxy?" If there is one, the app starts, and certain calls just slip past it. Startup only fails when Spring can't build a proxy at all.

You got 4 of 6, up from 0 of 4. The two left are about what web adds

It's Java inheritance. This is a simplified version of the Spring 5 source:

public class StandardServletEnvironment extends StandardEnvironment {   // ← EXTENDS
    protected void customizePropertySources(MutablePropertySources sources) {
        sources.addLast(servletConfigInitParams);
        sources.addLast(servletContextInitParams);
        if (jndiAvailable) sources.addLast(jndiProperties);
        super.customizePropertySources(sources);   // ← then adds systemProperties + systemEnvironment
    }
}

The web class is a subclass, and it calls super, so it keeps everything the non-web one has. "Instead of" would mean losing env vars in a web app, and you already knew env.getProperty("HOME") works there.

<context-param>: the servlet container reads web.xml and exposes the values through the ServletContext. A non-web app has no web.xml and no ServletContext object at all, so there's nowhere for the value to come from. That makes it "servlet" → web only, the same rule you applied correctly to the property-source names.

postProcessBeforeInitialization gets the object, not the definition

Read the method name: Initialization. Only an object gets initialised, through @PostConstruct and init methods. A definition is never initialised. The signature is postProcessBeforeInitialization(Object bean, String beanName). Definitions are the BFPP's job, and it gets the whole factory.