Zum Hauptinhalt springen

Mock Full 04 — Spring Professional (60 Fragen)

Prüfungsstil: Spring Professional Develop (2V0-72.22) — vollständiger 60-Fragen-Mock aus gemischten Themen.

Zeitlimit: ca. 130 Minuten (etwa 2 Minuten pro Frage).

Anleitung:

  1. Wähle pro Frage eine Option und nutze dann Antwort prüfen, um Erklärung und Punktestand zu sehen.
  2. Mit Zurück und Weiter durch das Set navigieren; deine Auswahl kannst du ändern, bis du prüfst.
  3. Bei jedem Fehler die Erklärung lesen und einen Merksatz notieren, bevor du weitermachst.

Themenverteilung:

  • F1–10: Spring Core & DI
  • F11–18: Konfiguration, Profile & Scopes
  • F19–28: Spring Boot, Auto-Configuration & Actuator
  • F29–36: Spring MVC, REST & Validierung
  • F37–44: Datenzugriff, JPA & Transaktionen
  • F45–50: Spring Security
  • F51–56: Testing
  • F57–60: AOP, Events, Async & Observability

Frage 1​

Ein Payment-Service hat zwei NotificationSender-Implementierungen auf dem Classpath: EmailNotificationSender und SmsNotificationSender. Beide sind mit @Component annotiert.

BillingService muss explizit EmailNotificationSender injizieren. Welcher Ansatz löst die Mehrdeutigkeit auf Spring-idiomatische Weise?


@Service
public class BillingService {
    // nur EmailNotificationSender injizieren
}
  • A) EmailNotificationSender mit @Primary annotieren und SmsNotificationSender vom Classpath entfernen
  • B) @Qualifier("emailNotificationSender") am Injection Point oder Feldparameter verwenden
  • C) BillingService umbenennen, damit Component Scanning den Konflikt überspringt
  • D) Beide Sender als statische Felder innerhalb BillingService deklarieren
Antwort & Erklärung

Richtige Antwort: B

Wenn mehrere Beans denselben Typ implementieren, wirft Spring NoUniqueBeanDefinitionException, außer du disambiguierst. @Qualifier matcht einen spezifischen Bean per Name oder custom Qualifier-Value. @Primary ist eine Alternative, ändert aber den Default für alle Injection Points — breiter als nötig, wenn nur ein Consumer eine spezifische Implementierung braucht.

Warum die anderen Optionen falsch sind:

  • A) @Primary funktioniert global, ist aber heavy-handed, wenn nur ein Injection Point einen spezifischen Bean braucht.
  • C) Klassenumbenennung hat keinen Effekt auf Bean-Type-Matching oder Ambiguity Resolution.
  • D) Statische Felder umgehen den IoC-Container und brechen Dependency Injection komplett.

Merksatz: „Mehrere Beans desselben Typs → mit @Qualifier oder @Primary disambiguieren."

Weiterlernen: Buchkapitel

Frage 2​

Ein Security-Review markiert Feld-Injection in einem neuen AccountService, weil erforderliche Collaborators ohne Compile-Time-Erkennung fehlen können.

Welchen Injection-Stil empfiehlt Spring für obligatorische, unveränderliche Abhängigkeiten?


@Service
public class AccountService {
    private final AuditPort auditPort;
    // bevorzugtes Wiring hier
}
  • A) Setter-Injection mit @Autowired(required = false)
  • B) Feld-Injection mit @Resource
  • C) Lookup-Method-Injection für jede Abhängigkeit
  • D) Konstruktor-Injection mit finalen Feldern
Antwort & Erklärung

Richtige Antwort: D

Konstruktor-Injection macht Abhängigkeiten explizit, unterstützt Unveränderlichkeit via final fields und erlaubt Frameworks, fehlende required Collaborators bei Konstruktion zu erkennen. Seit Spring 4.3 braucht ein einzelner Konstruktor nicht einmal @Autowired. Feld-Injection versteckt Abhängigkeiten und erschwert Unit-Tests.

Warum die anderen Optionen falsch sind:

  • A) Optionale Setter-Injection ist für nicht-obligatorische Collaborators, nicht required immutable ones.
  • B) Feld-Injection ist discouraged, weil Abhängigkeiten in der Konstruktorsignatur nicht sichtbar sind.
  • C) Lookup Methods lösen Scoped-Proxy- oder Prototype-in-Singleton-Fälle, nicht gewöhnliches obligatorisches Wiring.

Merksatz: „Obligatorische Abhängigkeiten → Konstruktor-Injection mit finalen Feldern."

Weiterlernen: Buchkapitel

Frage 3​

Zwei CacheManager-Beans existieren: redisCacheManager und caffeineCacheManager. Ein einzelnes @Autowired CacheManager-Feld in ReportFacade soll standardmäßig redisCacheManager nutzen, ohne Call Sites zu ändern. Was ist die beste Deklaration?

  • A) redisCacheManager mit @Primary markieren
  • B) @Lazy auf dem ReportFacade-Feld hinzufügen
  • C) @Scope("prototype") auf redisCacheManager
  • D) ReportFacade mit @DependsOn("redisCacheManager") annotieren
Antwort & Erklärung

Richtige Antwort: A

@Primary markiert einen Bean als bevorzugten Kandidaten bei Autowiring nur per Type. Consumer, die caffeineCacheManager brauchen, können den Default mit @Qualifier überschreiben. @DependsOn steuert Startup-Reihenfolge, nicht Auswahl unter type-kompatiblen Beans.

Warum die anderen Optionen falsch sind:

  • B) @Lazy verzögert Erstellung, wählt aber nicht unter mehreren CacheManager-Beans.
  • C) Prototype-Scope ändert Instanz-Kardinalität, nicht Autowire-Präferenz.
  • D) @DependsOn sichert Erstellungsreihenfolge; es löst Type-Ambiguity nicht.

Merksatz: „@Primary = Default-Bean, wenn mehrere Kandidaten denselben Typ teilen."

Weiterlernen: Buchkapitel

Frage 4​

Eine Library stellt eine FactoryBean bereit, die verschlüsselte PropertySource-Objekte baut. Entwickler fragen sich, ob getBean("securePropertySource") die FactoryBean selbst oder das Produkt zurückgibt.

Was liefert context.getBean("securePropertySource"), wenn SecurePropertySourceFactory FactoryBean<PropertySource<?>> implementiert?


public class SecurePropertySourceFactory implements FactoryBean<PropertySource<?>> {
    @Override
    public PropertySource<?> getObject() { return new EncryptedPropertySource(); }
    @Override
    public Class<?> getObjectType() { return PropertySource.class; }
}
  • A) Immer die FactoryBean-Instanz selbst
  • B) Eine neue FactoryBean bei jedem getBean-Aufruf unabhängig vom Scope
  • C) Das von getObject() produzierte Objekt, nämlich die PropertySource
  • D) Nichts, außer der Bean-Name ist mit & prefixiert
Antwort & Erklärung

Richtige Antwort: C

Für eine FactoryBean-Registrierung exposed der Container normalerweise das Produkt von getObject() als Bean. Mit & prefixierten Namen holst du die FactoryBean selbst. Diese Unterscheidung ist wichtig beim Diagnostizieren, welcher Typ tatsächlich im Context registriert ist.

Warum die anderen Optionen falsch sind:

  • A) Die FactoryBean-Instanz wird nur mit &name-Syntax geholt, nicht mit plain bean name.
  • B) FactoryBean-Produkte folgen dem deklarierten Bean-Scope; getBean erzeugt nicht immer neue FactoryBean-Instanzen.
  • D) Plain getBean(name) liefert das Produkt; &name liefert die FactoryBean.

Merksatz: „FactoryBean: plain name → Produkt; &name → Factory selbst."

Weiterlernen: Buchkapitel

Frage 5​

Ein Bean braucht die maximale Thread-Pool-Größe aus der Konfiguration. Die Property ist app.pool.max-size=16. Welcher @Value-Ausdruck liest sie korrekt?


@Service
public class WorkerPoolConfigurer {
    // korrekte Injection wählen
}
  • A) @Value("app.pool.max-size")
  • B) @Value("${app.pool.max-size}")
  • C) @Value("#{app.pool.max-size}")
  • D) @Value("$app.pool.max-size")
Antwort & Erklärung

Richtige Antwort: B

Property-Placeholders nutzen die ${property.key}-Syntax, damit Springs PropertySourcesPlaceholderConfigurer externe Konfiguration auflöst. Plain Strings ohne Placeholder-Braces werden literal injiziert. SpEL nutzt eine andere Hash-Brace-Form und ist nicht die Standard-Placeholder-Syntax für Environment-Keys.

Warum die anderen Optionen falsch sind:

  • A) Ohne ${} wird der literal Text „app.pool.max-size" injiziert, nicht der konfigurierte Wert.
  • C) SpEL könnte Properties via @environment lesen, aber #{app.pool.max-size} ist nicht die Placeholder-Form für Keys mit Bindestrichen.
  • D) $ ohne Braces ist keine gültige Spring-Property-Placeholder-Syntax.

Merksatz: „Externe Properties in @Value nutzen ${property.key}-Syntax."

Weiterlernen: Buchkapitel

Frage 6​

OrderService und InventoryService sind Singletons. OrderServices Konstruktor braucht InventoryService, und InventoryServices Konstruktor braucht OrderService.

Was passiert während ApplicationContext-Refresh?

  • A) Spring erzeugt zuerst leichte Proxies und ersetzt sie dann durch echte Instanzen
  • B) Ein Bean wird automatisch @Lazy markiert, um den Zyklus zu brechen
  • C) Spring injiziert null in einen Konstruktor und behebt es später mit Settern
  • D) Context-Refresh schlägt fehl, weil Konstruktor-Injection die Circular Dependency nicht auflösen kann
Antwort & Erklärung

Richtige Antwort: D

Konstruktor-Injection-Zyklen sind nicht befriedigbar, weil keiner der Beans vollständig konstruiert werden kann, bevor der andere fertig ist. Spring kann manche Feld-/Setter-Zyklen mit Early References auflösen, aber gegenseitige Konstruktorabhängigkeiten verursachen BeanCurrentlyInCreationException beim Startup.

Warum die anderen Optionen falsch sind:

  • A) Proxy-basiertes Cycle Breaking gilt für manche Setter/Feld-Fälle, nicht für gegenseitige Konstruktorabhängigkeiten.
  • B) Spring wählt nicht still eine Seite als @Lazy, außer du deklarierst @Lazy explizit.
  • C) Konstruktor-Injection fällt nicht auf null-Collaborators für required dependencies zurück.

Merksatz: „Konstruktor-Zyklen scheitern beim Startup; brechen mit @Lazy oder Redesign."

Weiterlernen: Buchkapitel

Frage 7​

Ein CLI-Utility bootstrapped einen standalone AnnotationConfigApplicationContext und muss nach Refresh programmatisch einen Bean holen. Welcher Aufruf ist korrekt?


AnnotationConfigApplicationContext ctx =
    new AnnotationConfigApplicationContext(AppConfig.class);
// ExportJob-Bean benötigt
  • A) ctx.getBean(ExportJob.class)
  • B) ExportJob.createFromSpring()
  • C) ctx.findComponent(ExportJob.class)
  • D) new ExportJob(ctx)
Antwort & Erklärung

Richtige Antwort: A

ApplicationContext.getBean(Class) ist das Standard-Programmatic-Lookup, sobald der Container refreshed ist. Spring-verwaltete Objekte sollten nicht mit new konstruiert werden, wenn du Container-verwaltete Instanzen mit injizierten Collaborators brauchst.

Warum die anderen Optionen falsch sind:

  • B) Spring generiert keine createFromSpring-Factory-Methoden auf User-Klassen.
  • C) findComponent ist nicht Teil der ApplicationContext-API.
  • D) Manuelle Konstruktion umgeht Dependency Injection und Lifecycle Management.

Merksatz: „Programmatisches Lookup nach Refresh: context.getBean(Type.class)."

Weiterlernen: Buchkapitel

Frage 8​

CatalogService hängt von einem langsamen RemotePricingClient ab. Das Team will, dass CatalogService schnell startet und Pricing-Client-Erstellung bis zur ersten Nutzung aufschiebt.

Welche Deklaration erreicht lazy Initialization der Abhängigkeit?


@Service
public class CatalogService {
    private final PricingClient pricingClient;
}
  • A) CatalogService mit @Scope("prototype") annotieren
  • B) RemotePricingClient nur mit @Repository markieren
  • C) Den PricingClient-Injection-Point oder Bean mit @Lazy annotieren
  • D) @Component von RemotePricingClient entfernen
Antwort & Erklärung

Richtige Antwort: C

@Lazy auf einer Abhängigkeit oder Bean-Definition sagt Spring, einen Proxy zu injizieren und den Target-Bean erst bei erstem Zugriff zu erzeugen. Das reduziert Startup-Kosten für teure Collaborators, ohne den Bean aus dem Container zu entfernen.

Warum die anderen Optionen falsch sind:

  • A) Prototype-Scope auf CatalogService ändert seine eigene Kardinalität, nicht Dependency-Laziness.
  • B) Stereotype-Wahl impliziert keine lazy Initialization.
  • D) Stereotype entfernen verhindert Wiring komplett statt Erstellung aufzuschieben.

Merksatz: „@Lazy schiebt Bean-Erstellung bis zum ersten Zugriff über einen Proxy auf."

Weiterlernen: Buchkapitel

Frage 9​

Eine Klasse com.example.billing.InvoiceExporter ist mit @Component und ohne expliziten Bean-Namen annotiert. Wie lautet der Default-Bean-Name?

  • A) com.example.billing.InvoiceExporter
  • B) invoiceExporter
  • C) InvoiceExporter
  • D) billingInvoiceExporter
Antwort & Erklärung

Richtige Antwort: B

Für annotierte Klassen ist der Default-Bean-Name der dekapitalisierte einfache Klassenname, außer ein expliziter value ist in @Component("name") angegeben. Vollqualifizierte Klassennamen werden nicht als Default-Bean-Namen genutzt.

Warum die anderen Optionen falsch sind:

  • A) Vollqualifizierte Namen sind nicht der Default für Stereotype-annotierte Klassen.
  • C) Das erste Zeichen wird per JavaBeans-Konvention lowercased — invoiceExporter.
  • D) Package-Segmente werden nicht dem Default-Bean-Namen vorangestellt.

Merksatz: „Default-@Component-Name = dekapitalisierter einfacher Klassenname."

Weiterlernen: Buchkapitel

Frage 10​

ShipmentTracker hängt vom TrackingPort-Interface ab. Genau eine Implementierung, FedExTrackingAdapter, ist im Context registriert.

Was passiert, wenn ShipmentTracker @Autowired TrackingPort trackingPort deklariert?


@Component
public class FedExTrackingAdapter implements TrackingPort { }

@Service
public class ShipmentTracker {
    @Autowired
    private TrackingPort trackingPort;
}
  • A) Injection schlägt fehl, weil Interfaces nicht autowired werden können
  • B) Spring verlangt @Qualifier, wann immer der Feldtyp ein Interface ist
  • C) Ein JDK-Proxy wird immer statt der konkreten Klasse erzeugt
  • D) FedExTrackingAdapter wird injiziert, weil er der einzige passende Bean ist
Antwort & Erklärung

Richtige Antwort: D

Autowired per Type gelingt, wenn genau ein Bean den deklarierten Dependency-Typ matcht. Interfaces sind First-Class-Injection-Targets. Ambiguity erscheint nur bei mehreren Implementierungen ohne @Primary oder @Qualifier.

Warum die anderen Optionen falsch sind:

  • A) Interface-typed Injection ist Standard-Spring-Praxis.
  • B) @Qualifier ist nur erforderlich, wenn mehrere Kandidaten existieren.
  • C) Spring injiziert den konkreten managed Bean, außer explizites Proxying ist aus anderen Gründen konfiguriert.

Merksatz: „Einzelner passender Bean → Autowire per Type funktioniert, auch für Interfaces."

Weiterlernen: Buchkapitel

Frage 11​

Zwei @Bean-Methoden in derselben @Configuration-Klasse rufen sich gegenseitig auf. Warum sollte die Klasse als CGLIB-enhanced Configuration Proxy verarbeitet werden?


@Configuration
public class PricingConfig {
    @Bean
    public DiscountPolicy discountPolicy() {
        return new DiscountPolicy(baseRate());
    }
    @Bean
    public RateTable baseRate() {
        return new RateTable();
    }
}
  • A) Um @Profile-Evaluation nur zur Laufzeit zu erlauben
  • B) Damit @Bean-Methoden private sein können
  • C) Damit Inter-Bean-Methodenaufrufe über den Container laufen und Singletons zurückgeben
  • D) Um Component Scanning für das Configuration-Package zu deaktivieren
Antwort & Erklärung

Richtige Antwort: C

Vollständige @Configuration-Klassen sind proxied, sodass @Bean-Methodenaufrufe über den Container laufen statt plain Java-Calls. Ohne dieses Enhancement würde baseRate() direkt aus discountPolicy() eine neue RateTable erzeugen statt den Singleton-Bean wiederzuverwenden.

Warum die anderen Optionen falsch sind:

  • A) Profile-Processing ist unrelated zu CGLIB-Enhancement von @Configuration.
  • B) @Bean-Methoden sollten public sein; Proxying existiert nicht, um private Factory-Methoden zu unterstützen.
  • D) Configuration-Proxying schaltet Component Scanning nicht ab.

Merksatz: „@Configuration-Proxy stellt sicher, dass @Bean-Methodenaufrufe Container-verwaltete Beans wiederverwenden."

Weiterlernen: Buchkapitel

Frage 12​

Ein Team pflegt separate DataSource-Beans für Produktion und lokale Entwicklung.

Welcher Ansatz aktiviert nur den embedded H2-DataSource-Bean bei lokalen Runs?


@Bean
public DataSource dataSource() { /* cloud */ }

@Bean
public DataSource dataSource() { /* h2 */ }
  • A) Die H2-@Bean-Methode mit @Profile("local") annotieren und mit spring.profiles.active=local starten
  • B) Beide Beans in derselben @Configuration ohne Profile platzieren und auf @Primary vertrauen
  • C) @Scope("prototype") auf dem H2-Bean
  • D) Die Main-Application-Klasse mit @ComponentScan(basePackageClasses = DataSource.class) annotieren
Antwort & Erklärung

Richtige Antwort: A

@Profile registriert Bean-Definitionen bedingt basierend auf aktiven Profilen. @Profile("local") kombiniert mit spring.profiles.active=local stellt sicher, dass nur die beabsichtigte DataSource-Konfiguration für diese Environment am Context teilnimmt.

Warum die anderen Optionen falsch sind:

  • B) Zwei @Bean-Methoden mit gleichem Methodennamen in einer Klasse ist ungültiges Java und fehlt Environment-Switching.
  • C) Prototype-Scope versteckt Beans nicht per Environment.
  • D) Component-Scan-Narrowing liefert keine environment-spezifische Bean-Registrierung.

Merksatz: „Environment-spezifische Beans → @Profile plus active profile property."

Weiterlernen: Buchkapitel

Frage 13​

In einer Spring-MVC-Web-Anwendung soll ein DashboardFilter-Bean einmal pro HTTP-Request erstellt werden. Welcher Scope ist passend?


@Component
@Scope("???")
public class DashboardFilter { }
  • A) singleton
  • B) request
  • C) prototype
  • D) application
Antwort & Erklärung

Richtige Antwort: B

Request-Scope erzeugt eine Bean-Instanz pro HTTP-Request in einem Web-aware ApplicationContext. Singleton würde State über User teilen, Prototype eine neue Instanz bei jeder Injection-Point-Resolution, nicht pro Request-Grenze.

Warum die anderen Optionen falsch sind:

  • A) Singleton teilt eine Instanz für die gesamte Anwendungslebensdauer.
  • C) Prototype erzeugt eine neue Instanz pro getBean oder Injection-Resolution, nicht aligned zum HTTP-Request-Lifecycle.
  • D) „application" ist der ServletContext-Scope-Name in Spring-Web-Contexts, nicht per-Request-Isolation.

Merksatz: „State pro HTTP-Request → request scope in einem Web-Context."

Weiterlernen: Buchkapitel

Frage 14​

application.yml enthält verschachtelte Mail-Einstellungen, aber MailSettings-Felder bleiben zur Laufzeit null.

Welches Annotation-Paar bindet Prefix app.mail an eine type-safe Configuration-Properties-Klasse?


app:
  mail:
    host: smtp.example.com
    port: 587
  • A) Nur @Value auf jedem Feld
  • B) @Entity und @Table
  • C) @RequestMapping auf der Properties-Klasse
  • D) @ConfigurationProperties(prefix = "app.mail") mit @EnableConfigurationProperties oder @Component
Antwort & Erklärung

Richtige Antwort: D

@ConfigurationProperties bindet hierarchische externe Konfiguration an ein POJO mit dem deklarierten Prefix. Die Klasse muss via @EnableConfigurationProperties, @ConfigurationPropertiesScan oder als @Component registriert sein. @Value handhabt einzelne Keys, aber nicht so sauber hierarchisches strukturiertes Binding.

Warum die anderen Optionen falsch sind:

  • A) Wiederholtes @Value funktioniert für einzelne Keys, ist aber nicht das gefragte type-safe hierarchische Binding-Muster.
  • B) JPA-Entity-Annotationen mappen auf DB-Tabellen, nicht Konfigurations-Properties.
  • C) Web-Mapping-Annotationen binden keine Environment-Konfiguration an Felder.

Merksatz: „Strukturierte Config → @ConfigurationProperties(prefix = "app.mail")."

Weiterlernen: Buchkapitel

Frage 15​

Eine Property existiert sowohl in application.properties als auch als Command-Line-Argument --app.feature.enabled=true. Welcher Wert gewinnt mit default Spring Boot Property Precedence?

  • A) Der Command-Line-Argument-Wert
  • B) Der application.properties-Wert
  • C) Der erste Wert, der beim Classpath-Scanning entdeckt wird
  • D) Keiner; Startup schlägt bei doppelten Keys fehl
Antwort & Erklärung

Richtige Antwort: A

Spring Boot ordnet Property Sources so, dass Command-Line-Argumente application.properties und application.yml Defaults überschreiben. Das erlaubt Runtime-Overrides ohne Artefakt-Rebuild.

Warum die anderen Optionen falsch sind:

  • B) Dateien im JAR haben niedrigere Precedence als Command-Line-Argumente.
  • C) Precedence ist durch Spring-Boot-Regeln definiert, nicht durch erste Discovery-Reihenfolge.
  • D) Doppelte Keys werden per Precedence aufgelöst statt Startup-Fehler.

Merksatz: „Command-Line-Args schlagen application.properties in Boot-Precedence."

Weiterlernen: Buchkapitel

Frage 16​

Ein custom Metrics-Exporter soll nur registriert werden, wenn management.metrics.export.enabled=true.

Welche Boot-Condition drückt diese Anforderung auf einer @Configuration-Klasse aus?

  • A) @ConditionalOnMissingBean(MeterRegistry.class)
  • B) Nur @Profile("metrics")
  • C) @ConditionalOnProperty(name = "management.metrics.export.enabled", havingValue = "true")
  • D) @Lazy auf der Configuration-Klasse
Antwort & Erklärung

Richtige Antwort: C

@ConditionalOnProperty bindet Bean-Registrierung an Präsenz und Wert einer Konfigurations-Property. Es ist der idiomatische Boot-Mechanismus für Feature-Toggles in Auto-Configuration-Style-Modulen.

Warum die anderen Optionen falsch sind:

  • A) Missing-Bean-Conditions gaten auf Bean-Präsenz, nicht Property-Werte.
  • B) Profile können Environments trennen, testen aber nicht direkt einen beliebigen Property-Wert.
  • D) @Lazy betrifft Initialisierungszeitpunkt, nicht bedingte Registrierung basierend auf Properties.

Merksatz: „Property-gated Beans → @ConditionalOnProperty mit name und havingValue."

Weiterlernen: Buchkapitel

Frage 17​

Ein Singleton ReportBuilder injiziert einen Prototype TemplateEngine. Wie viele TemplateEngine-Instanzen existieren über drei Aufrufe von reportBuilder.build() in derselben Anwendung?


@Component
@Scope("prototype")
class TemplateEngine { }

@Service
class ReportBuilder {
    @Autowired TemplateEngine engine;
    void build() { engine.render(); }
}
  • A) Eine geteilte TemplateEngine für die gesamte Anwendung
  • B) Eine TemplateEngine pro build()-Aufruf
  • C) Null; Prototype-Beans können nicht in Singletons injiziert werden
  • D) Drei Singleton-TemplateEngine-Beans in einem Pool gespeichert
Antwort & Erklärung

Richtige Antwort: B

Prototype in einen Singleton zu injizieren speichert eine Prototype-Instanz im Singleton für dessen Lebensdauer. Für einen neuen Prototype pro Operation: ObjectProvider<TemplateEngine>, @Lookup oder Scope Proxies, die für per-use Resolution designed sind.

Warum die anderen Optionen falsch sind:

  • A) Die injizierte Prototype-Instanz ist zum Singleton-Erstellungszeitpunkt fixiert, außer du nutzt Provider oder Lookup Method.
  • C) Injection ist erlaubt; die Nuance ist Instanz-Kardinalität, nicht Verbot.
  • D) Prototype-Scope erzeugt keinen managed Pool von drei Instanzen automatisch.

Merksatz: „Prototype in Singleton = ein geteilter Prototype, außer du nutzt ObjectProvider."

Weiterlernen: Buchkapitel

Frage 18​

Ein Bean nutzt @PostConstruct zum Öffnen eines Sockets und @PreDestroy zum Schließen.

Wann läuft die @PreDestroy-Methode?

  • A) Sofort nach Rückkehr des Konstruktors
  • B) Vor jeder @PostConstruct-Methode in derselben JVM
  • C) Nur wenn der Bean prototype-scoped ist
  • D) Wenn der ApplicationContext herunterfährt oder der Bean aus dem Container entfernt wird
Antwort & Erklärung

Richtige Antwort: D

@PreDestroy-Methoden nehmen an der Bean-Destruction-Phase teil, wenn der Container schließt oder der scoped Bean endet. Sie sind der symmetrische Cleanup-Hook zu @PostConstruct-Initialisierung für managed Resources.

Warum die anderen Optionen falsch sind:

  • A) Post-Construct-Initialisierung läuft nach Konstruktion; Pre-Destroy läuft beim Shutdown.
  • B) PreDestroy wird nicht vor Initialisierungs-Hooks aufgerufen.
  • C) Singleton und andere Scopes erhalten auch Destruction-Callbacks bei Context-Close.

Merksatz: „@PreDestroy läuft bei Context-Shutdown oder scoped Bean Disposal."

Weiterlernen: Buchkapitel

Frage 19​

Welche Aussage über @SpringBootApplication ist korrekt?


@SpringBootApplication
public class InventoryApplication {
    public static void main(String[] args) {
        SpringApplication.run(InventoryApplication.class, args);
    }
}
  • A) @SpringBootApplication kombiniert @Configuration, @EnableAutoConfiguration und @ComponentScan
  • B) @SpringBootApplication deaktiviert Auto-Configuration standardmäßig
  • C) @SpringBootApplication ist auf jedem @RestController erforderlich
  • D) @SpringBootApplication ersetzt application.properties
Antwort & Erklärung

Richtige Antwort: A

@SpringBootApplication ist eine composed Annotation, die Java Configuration, Auto-Configuration und Component Scanning ab ihrem Package nach unten aktiviert. Es ist der konventionelle Entry-Point-Marker für Boot-Apps.

Warum die anderen Optionen falsch sind:

  • B) Es aktiviert Auto-Configuration via @EnableAutoConfiguration, deaktiviert sie nicht.
  • C) Controller werden wegen Component Scanning entdeckt, nicht weil @SpringBootApplication auf jedem Controller steht.
  • D) Externe Konfiguration bleibt extern; die Annotation bettet keine Property-Dateien ein.

Merksatz: „@SpringBootApplication = @Configuration + @EnableAutoConfiguration + @ComponentScan."

Weiterlernen: Buchkapitel

Frage 20​

Ein Team baut ein CLI-Batch-Modul mit spring-boot-starter, muss aber DataSourceAutoConfiguration verhindern, weil keine Datenbank genutzt wird.

Wie kann die Anwendung diese Auto-Configuration ausschließen und andere Boot-Defaults behalten?


@SpringBootApplication
public class BatchApplication { }
  • A) spring-boot-autoconfigure.jar vom Classpath löschen
  • B) @EnableAutoConfiguration von jeder Configuration-Klasse manuell entfernen
  • C) @SpringBootApplication(exclude = DataSourceAutoConfiguration.class) nutzen
  • D) spring.autoconfigure.exclude=false in Properties setzen
Antwort & Erklärung

Richtige Antwort: C

Spring Boot unterstützt Ausschluss spezifischer Auto-Configuration-Klassen via exclude-Attribut auf @SpringBootApplication oder @EnableAutoConfiguration, oder über spring.autoconfigure.exclude. Das entfernt nur gezielte Auto-Config, behält den Rest.

Warum die anderen Optionen falsch sind:

  • A) Autoconfigure-Modul entfernen deaktiviert alle Auto-Configuration, nicht chirurgischen Ausschluss.
  • B) @SpringBootApplication trägt bereits @EnableAutoConfiguration; manuelles Entfernen kämpft gegen das Boot-Modell.
  • D) spring.autoconfigure.exclude erwartet Klassennamen zum Ausschließen, nicht den literal false-Wert.

Merksatz: „Eine Auto-Config ausschließen → @SpringBootApplication(exclude = X.class)."

Weiterlernen: Buchkapitel

Frage 21​

Mit spring-boot-starter-actuator auf dem Classpath und ohne custom Security, die Endpoints blockiert — welche URL exposed typischerweise den Default-Health-Endpoint in Spring Boot 3?

  • A) /status
  • B) /actuator/health
  • C) /health/check
  • D) /management/health
Antwort & Erklärung

Richtige Antwort: B

Actuator-Web-Endpoints werden standardmäßig unter dem /actuator-Base-Path exposed, mit /actuator/health als Standard-Health-Endpoint. Zusätzliche Endpoints brauchen explizite Exposure-Konfiguration in modernen Boot-Defaults.

Warum die anderen Optionen falsch sind:

  • A) /status ist nicht der Default-Actuator-Health-Pfad.
  • C) /health/check ist nicht der konventionelle Boot-3-Actuator-Endpoint.
  • D) /management/health ist nicht der Default, außer der Base-Path ist customisiert.

Merksatz: „Default-Actuator-Health-URL → /actuator/health."

Weiterlernen: Buchkapitel

Frage 22​

Ein Starter soll Auto-Configuration nur konfigurieren, wenn Jackson ObjectMapper auf dem Classpath ist.

Welche Condition soll die Auto-Configuration-Klasse schützen?

  • A) @ConditionalOnWebApplication
  • B) @ConditionalOnMissingClass("com.fasterxml.jackson.databind.ObjectMapper")
  • C) @ConditionalOnExpression("true")
  • D) @ConditionalOnClass(name = "com.fasterxml.jackson.databind.ObjectMapper")
Antwort & Erklärung

Richtige Antwort: D

@ConditionalOnClass prüft Präsenz spezifizierter Klassen auf dem Classpath — so vermeiden Boot-Starter Jackson-bezogene Beans, wenn Jackson fehlt. Missing-Class-Conditions invertieren diese Logik.

Warum die anderen Optionen falsch sind:

  • A) Web-Application-Checks testen nicht Jackson-Präsenz.
  • B) OnMissingClass registriert Beans, wenn die Klasse fehlt — Gegenteil der Anforderung.
  • C) Ein literal true expression ignoriert Classpath-Anforderungen komplett.

Merksatz: „Classpath vorhanden → @ConditionalOnClass; fehlend → @ConditionalOnMissingClass."

Weiterlernen: Buchkapitel

Frage 23​

Ein Entwickler fügt spring-boot-devtools zu einem Web-Projekt hinzu. Was ist typisches Local-Development-Verhalten?

  • A) Automatischer Restart der Anwendung bei Classpath-Dateiänderungen
  • B) Deaktivierung aller Auto-Configuration zur Laufzeit
  • C) Obligatorisches HTTPS auf Port 443
  • D) Produktionsreifes JVM-Performance-Tuning
Antwort & Erklärung

Richtige Antwort: A

DevTools bietet Development-Time-Enhancements wie automatischen Restart bei Classpath-Änderungen und LiveReload-Support. Es ist nicht für Produktions-Classpath gedacht und sollte in Build-Tools als optional markiert sein.

Warum die anderen Optionen falsch sind:

  • B) DevTools deaktiviert Auto-Configuration nicht global.
  • C) DevTools erzwingt kein HTTPS.
  • D) DevTools optimiert Developer-Feedback-Loops, nicht Produktions-JVM-Tuning.

Merksatz: „DevTools = schnellerer lokaler Restart bei Classpath-Änderungen."

Weiterlernen: Buchkapitel

Frage 24​

Beim Startup muss ein Service persistierte Migrations-Flags lesen und danach ausführen, wenn der Context bereit ist.

Welches Callback-Interface läuft, nachdem der ApplicationContext vollständig gestartet ist, und erhält Zugriff auf rohe String-Command-Line-Argumente?

  • A) BeanPostProcessor
  • B) InitializingBean
  • C) CommandLineRunner
  • D) Nur ServletContextListener
Antwort & Erklärung

Richtige Antwort: C

CommandLineRunner-Beans führen nach Application-Startup mit Zugriff auf die main-Method-args als String-Array aus. ApplicationRunner ist ähnlich, nutzt aber ApplicationArguments. Beide sind üblich für Startup-Tasks in Boot-Apps.

Warum die anderen Optionen falsch sind:

  • A) BeanPostProcessor hookt Bean-Initialisierung, nicht Post-Startup-Application-Logik.
  • B) InitializingBean läuft während individueller Bean-Setup, nicht nach vollständig bereitem Context.
  • D) ServletContextListener ist ein Servlet-API-Hook, nicht die Boot-native Startup-Runner-Abstraktion.

Merksatz: „Post-Startup-Tasks mit main args → CommandLineRunner."

Weiterlernen: Buchkapitel

Frage 25​

Nur die health- und info-Actuator-Endpoints sollen in Produktion über HTTP exposed werden. Welche Property-Konfiguration erreicht das?

  • A) management.endpoints.enabled=*
  • B) management.endpoints.web.exposure.include=health,info
  • C) server.actuator.expose=all
  • D) spring.mvc.actuator.paths=health,info
Antwort & Erklärung

Richtige Antwort: B

management.endpoints.web.exposure.include listet, welche Actuator-Endpoints auf dem Web-Port publiziert werden. Moderne Boot-Defaults sind konservativ; Teams müssen explizit jeden Endpoint beyond der limited defaults einschließen, den sie brauchen.

Warum die anderen Optionen falsch sind:

  • A) enabled=* exposed nicht selektiv Web-Endpoints und ist overly broad.
  • C) server.actuator.expose ist keine Standard-Boot-Property.
  • D) spring.mvc.actuator.paths ist nicht der dokumentierte Exposure-Mechanismus.

Merksatz: „Ausgewählte Actuator-Web-Endpoints mit management.endpoints.web.exposure.include exposen."

Weiterlernen: Buchkapitel

Frage 26​

Operations will custom Health-Details für ein Downstream-Payment-Gateway ohne eine volle Actuator-Endpoint-Klasse von Grund auf.

Welcher Extension Point trägt ein verschachteltes Detail-Objekt zur gesamten /actuator/health-Antwort bei?

  • A) HttpMessageConverter
  • B) BeanFactoryPostProcessor
  • C) FilterRegistrationBean
  • D) HealthIndicator- oder ReactiveHealthIndicator-Implementierung
Antwort & Erklärung

Richtige Antwort: D

Spring Boot Actuator aggregiert HealthIndicator-Beans in den composite Health-Endpoint. Custom Indicators melden UP, DOWN oder andere Status mit optionalen Details — der unterstützte Weg, Dependency-Health beyond Defaults zu exposen.

Warum die anderen Optionen falsch sind:

  • A) HttpMessageConverter serialisiert HTTP-Bodies; es definiert keine Health-Status-Contributors.
  • B) BeanFactoryPostProcessor modifiziert Bean-Definitionen beim Startup, nicht Runtime-Health-Reporting.
  • C) FilterRegistrationBean registriert Servlet-Filter, nicht Actuator-Health-Contributors.

Merksatz: „Custom Actuator-Health-Sections → HealthIndicator implementieren."

Weiterlernen: Buchkapitel

Frage 27​

Ein Produktionsvorfall erfordert DEBUG-Logging nur für org.springframework.web. Was ist der Boot-Property-Key?

  • A) logging.level.org.springframework.web=DEBUG
  • B) logger.org.springframework.web=DEBUG
  • C) debug.spring.web=true
  • D) spring.logging.org.springframework.web.level=DEBUG
Antwort & Erklärung

Richtige Antwort: A

Spring Boot mappt logging.level.<logger-name> auf das zugrundeliegende Logging-System. Das ist der unterstützte Weg, Package-Level-Verbosity ohne Code-Änderung zu tunen.

Warum die anderen Optionen falsch sind:

  • B) logger.* ist nicht der Boot-Standard-Property-Namespace.
  • C) debug.spring.web zielt nicht auf eine spezifische Logger-Hierarchie.
  • D) spring.logging.*.level ist nicht das konventionelle Boot-Logging-Property-Format.

Merksatz: „Package-Log-Level → logging.level.<package>=DEBUG."

Weiterlernen: Buchkapitel

Frage 28​

Die Startup-Zeit eines großen Monolithen wird von eager Singleton-Erstellung für selten genutzte Module dominiert.

Welches Boot-2.2+-Feature erstellt non-lazy-init-Beans erst bei erster Anwendung?

  • A) spring.main.web-application-type=none
  • B) spring.jpa.open-in-view=false
  • C) spring.main.lazy-initialization=true
  • D) management.endpoint.shutdown.enabled=true
Antwort & Erklärung

Richtige Antwort: C

spring.main.lazy-initialization=true sagt dem Container, Singleton-Beans lazy zu erstellen, außer @Lazy(false) markiert oder sonst eager. Das kann Startup verkürzen auf Kosten von Erstellung bei erster Nutzung und verzögerten Fehlern.

Warum die anderen Optionen falsch sind:

  • A) Web-Application-Type ändert Servlet-Stack-Präsenz, nicht globale Bean-Laziness.
  • B) Open-in-view passt JPA-Session-Verhalten in Web-Requests an, nicht Bean-Initialisierungs-Policy.
  • D) Shutdown-Endpoint ermöglicht graceful Shutdown-Exposure, nicht lazy Bean Creation.

Merksatz: „Globale lazy Singletons → spring.main.lazy-initialization=true."

Weiterlernen: Buchkapitel

Frage 29​

Eine Klasse soll JSON direkt aus Methodenergebnissen zurückgeben ohne View Resolution. Welches Stereotype ist passend?


@???
public class ProductApi {
    @GetMapping("/products/{id}")
    public ProductDto one(@PathVariable Long id) { }
}
  • A) Nur @Controller
  • B) @RestController
  • C) @Repository
  • D) @Configuration
Antwort & Erklärung

Richtige Antwort: B

@RestController kombiniert @Controller und @ResponseBody und signalisiert, dass Handler-Methoden direkt in den HTTP-Response-Body über Message Converter schreiben statt View-Namen aufzulösen.

Warum die anderen Optionen falsch sind:

  • A) Plain @Controller-Methoden geben typischerweise View-Namen zurück, außer jede Methode fügt @ResponseBody hinzu.
  • C) @Repository ist ein Persistence-Stereotype, kein MVC-Web-Stereotype.
  • D) @Configuration definiert Beans; es mappt keine HTTP-Requests.

Merksatz: „@RestController = @Controller + @ResponseBody für direkte HTTP-Bodies."

Weiterlernen: Buchkapitel

Frage 30​

Ein GET-Endpoint muss /orders/42 lesen, wobei 42 die Order-ID ist.

Welches Mapping bindet die Path-Variable korrekt?


@GetMapping("/orders/{id}")
public OrderDto get(@??? Long id) { }
  • A) @RequestParam("id")
  • B) @RequestHeader("id")
  • C) @CookieValue("id")
  • D) @PathVariable("id")
Antwort & Erklärung

Richtige Antwort: D

@PathVariable extrahiert URI-Template-Variablen aus dem Pfad. @RequestParam liest Query-Parameter, nicht Path-Segmente. Die Namen müssen mit der {id}-Template-Variable übereinstimmen.

Warum die anderen Optionen falsch sind:

  • A) @RequestParam bindet Query-String-Parameter wie ?id=42, nicht /orders/42 Path-Segmente.
  • B) @RequestHeader liest HTTP-Header, nicht URI-Templates.
  • C) @CookieValue liest Cookies, nicht Path-Variablen.

Merksatz: „URI-Template {id} → @PathVariable("id")."

Weiterlernen: Buchkapitel

Frage 31​

Ein POST /customers-Endpoint soll einen JSON-Request-Body validieren, bevor Business-Logik läuft. Was muss der Controller-Parameter enthalten?


@PostMapping("/customers")
public ResponseEntity<Void> create(@??? CustomerRequest request)
  • A) @Valid @RequestBody CustomerRequest request
  • B) @RequestParam CustomerRequest request
  • C) @ResponseBody CustomerRequest request
  • D) @PathVariable CustomerRequest request
Antwort & Erklärung

Richtige Antwort: A

@RequestBody mappt den JSON-Payload auf das Objekt, und @Valid triggert Bean Validation auf den Constraints des Objekts. Ohne @Valid werden Constraint-Annotationen auf CustomerRequest bei MVC-Validierung ignoriert.

Warum die anderen Optionen falsch sind:

  • B) @RequestParam bindet Form- oder Query-Parameter, nicht einen JSON-Request-Body.
  • C) @ResponseBody serialisiert Rückgabewerte; es validiert keine eingehenden Payloads.
  • D) @PathVariable bindet URI-Segmente, nicht Request-Bodies.

Merksatz: „JSON-Body validieren → @Valid @RequestBody auf dem Parameter."

Weiterlernen: Buchkapitel

Frage 32​

Eine Controller-Methode soll 201 Created mit Location-Header und Response-Body zurückgeben.

Welcher Return-Type drückt Status und Header idiomatisch aus?

  • A) void mit response.sendRedirect
  • B) String view name
  • C) ResponseEntity<CustomerDto>
  • D) HttpServletRequest
Antwort & Erklärung

Richtige Antwort: C

ResponseEntity trägt Status Code, Header und Body in einem Typ. Es ist der Standard-Weg, REST-Responses beyond einfacher @ResponseStatus-Annotationen fein abzustimmen.

Warum die anderen Optionen falsch sind:

  • A) sendRedirect ist servlet-zentriert und nicht der idiomatische Spring-MVC-REST-Ansatz.
  • B) View-Namen nehmen an View Resolution teil, nicht präziser REST-Status/Header-Kontrolle.
  • D) HttpServletRequest repräsentiert den eingehenden Request, nicht die ausgehende Response-Payload.

Merksatz: „Custom Status, Header und Body → ResponseEntity<T>."

Weiterlernen: Buchkapitel

Frage 33​

Mehrere Controller werfen InvalidOrderException. Eine Klasse soll diese Exception auf HTTP 400 mit Problem-Body mappen. Wo soll der Handler leben?

  • A) In jedem Controller dupliziert als private Methoden
  • B) Eine @ControllerAdvice-Klasse mit @ExceptionHandler-Methoden
  • C) Nur im DispatcherServlet-Quellcode
  • D) In application.properties als Error-Code-Mapping
Antwort & Erklärung

Richtige Antwort: B

@ControllerAdvice kombiniert mit @ExceptionHandler zentralisiert Exception-to-Response-Übersetzung über Controller. Das vermeidet duplizierte Error-Handling-Logik und hält Controller auf Happy-Path fokussiert.

Warum die anderen Optionen falsch sind:

  • A) Duplikation verletzt DRY und ist schwerer konsistent zu pflegen.
  • C) DispatcherServlet ist Framework-Infrastruktur, nicht Application-Exception-Policy.
  • D) Properties-Dateien können keine Java-Exception-Handler-Methoden deklarieren.

Merksatz: „Globales MVC-Exception-Mapping → @ControllerAdvice + @ExceptionHandler."

Weiterlernen: Buchkapitel

Frage 34​

Ein Client sendet Content-Type: application/xml, der Endpoint unterstützt aber nur JSON.

Welche Annotation auf der Handler-Methode beschränkt Input auf JSON?

  • A) produces = "application/json"
  • B) headers = "Accept: text/plain"
  • C) method = RequestMethod.PATCH only
  • D) consumes = MediaType.APPLICATION_JSON_VALUE
Antwort & Erklärung

Richtige Antwort: D

consumes schränkt Matching auf Requests mit kompatiblen Content-Type-Werten ein. produces filtert Response-Content-Negotiation basierend auf Accept. XML-Input an einen JSON-only Consumer sollte 415 Unsupported Media Type ergeben.

Warum die anderen Optionen falsch sind:

  • A) produces regiert Response-Content-Type, nicht akzeptierte Request-Bodies.
  • B) Accept-Header-Constraints nutzen produces oder explizite Header-Conditions, nicht diesen mismatched plain-text-Wert.
  • C) HTTP-Method-Restriction adressiert keinen Media-Type-Mismatch.

Merksatz: „Request Content-Type-Matching → consumes auf @RequestMapping/@PostMapping."

Weiterlernen: Buchkapitel

Frage 35​

Spring MVC konvertiert einen JSON-Request-Body in ein Java-Objekt, bevor eine @RestController-Methode läuft. Welche Komponente führt diese Konvertierung aus?

  • A) Ein HttpMessageConverter wie MappingJackson2HttpMessageConverter
  • B) Der ViewResolver
  • C) BeanFactoryPostProcessor
  • D) TransactionInterceptor
Antwort & Erklärung

Richtige Antwort: A

HttpMessageConverter-Implementierungen lesen und schreiben HTTP-Bodies. Jackson-basierte Converter mappen JSON auf Objekte für @RequestBody und Objekte auf JSON für @ResponseBody-Methoden.

Warum die anderen Optionen falsch sind:

  • B) ViewResolver löst View-Namen zu Templates auf, nicht JSON-Request-Bodies.
  • C) BeanFactoryPostProcessor modifiziert Bean-Definitionen beim Context-Startup, unrelated zu HTTP-Konvertierung.
  • D) TransactionInterceptor verwaltet transaktionale Proxies, nicht Message Conversion.

Merksatz: „@RequestBody JSON ↔ Java via HttpMessageConverter-Implementierungen."

Weiterlernen: Buchkapitel

Frage 36​

Ein Client postet JSON an einen Endpoint mit consumes = "application/json", aber der Request hat keinen Content-Type-Header.

Was ist das wahrscheinlichste HTTP-Ergebnis?

  • A) 200 OK mit leerem Body
  • B) 302 Found Redirect
  • C) 415 Unsupported Media Type oder 400er Content-Negotiation-Failure
  • D) 500 Internal Server Error nur durch NPE in Jackson
Antwort & Erklärung

Richtige Antwort: C

Wenn ein Handler consumes deklariert, matcht Spring Content-Type sorgfältig. Fehlende oder inkompatible Media Types verhindern Handler-Selection oder Body-Konvertierung — typischerweise 415 Unsupported Media Type oder ein anderer 4xx bezogen auf Content Negotiation.

Warum die anderen Optionen falsch sind:

  • A) Erfolgreiches 200 ist unwahrscheinlich, wenn der deklarierte Consumer-Media-Type nicht erfüllt ist.
  • B) Redirects sind unrelated zu Content-Type-Negotiation für REST-POST-Bodies.
  • D) Während tiefer Fehler auftreten können, lehnt das Framework den Request meist früher mit Client-Error ab.

Merksatz: „Falscher oder fehlender Content-Type vs. consumes → 415-artiger Client-Error."

Weiterlernen: Buchkapitel

Frage 37​

Eine @Transactional-Service-Methode fängt eine RuntimeException, loggt sie und wirft nicht erneut. Was passiert mit der Transaction by default?


@Transactional
public void placeOrder() {
    try {
        orderRepository.save(order);
        throw new IllegalStateException("inventory hold failed");
    } catch (RuntimeException ex) {
        log.warn("failure", ex);
    }
}
  • A) Die Transaction committed immer, weil die Exception gefangen wurde
  • B) Die Transaction wird rollback-only markiert, wenn die RuntimeException geworfen wird, auch wenn innerhalb der Methode gefangen
  • C) Rollback tritt nur bei checked exceptions auf
  • D) Transactions werden in catch-Blöcken automatisch suspendiert
Antwort & Erklärung

Richtige Antwort: B

Springs Transaction-Interceptor markiert die Transaction rollback-only, wenn eine rollback-triggering Exception die transaktionale Grenze kreuzt. RuntimeException innerhalb der Methode zu fangen macht rollback marking für Default-Rollback-Regeln nicht rückgängig.

Warum die anderen Optionen falsch sind:

  • A) Fangen ohne Rollback-Konfiguration garantiert kein Commit; Default-Runtime-Exceptions rollen trotzdem zurück.
  • C) Checked Exceptions rollen by default nicht zurück, außer konfiguriert.
  • D) Catch-Blöcke suspendieren Transactions nicht automatisch.

Merksatz: „Gefangen oder nicht — Default-@Transactional rollt bei RuntimeException trotzdem zurück."

Weiterlernen: Buchkapitel

Frage 38​

Ein read-heavy Report-Service lädt große Result Sets, die auf DTOs gemappt und nie modifiziert werden.

Welches @Transactional-Attribut kann die Interaktion mit dem Persistence Provider optimieren?

  • A) propagation = REQUIRES_NEW für jede Query
  • B) rollbackFor = Exception.class auf allen Reports
  • C) timeout = -1 only
  • D) readOnly = true
Antwort & Erklärung

Richtige Antwort: D

readOnly = true signalisiert, dass keine State-Änderungen passieren — Optimierungen wie Flush-Vermeidung und bei manchen Providern read-only JDBC-Connections. Es passt zu query-only transaktionalen Grenzen.

Warum die anderen Optionen falsch sind:

  • A) REQUIRES_NEW erzeugt unabhängige Transactions pro Call, keine Read-Optimierung.
  • B) rollbackFor erweitert Rollback-Verhalten, optimiert aber keinen read-only Zugriff.
  • C) Timeout-Einstellungen markieren die Transaction nicht als read-only.

Merksatz: „Nur Query-Transactional-Arbeit → readOnly = true."

Weiterlernen: Buchkapitel

Frage 39​

Eine Repository-Methode führt ein Bulk-UPDATE-JPQL-Statement aus. Welche Annotationen sind für korrektes Spring-Data-JPA-Verhalten erforderlich?


@Modifying
@Query("update Inventory i set i.qty = i.qty - 1 where i.sku = ?1")
int decrement(String sku);
  • A) @Modifying plus @Transactional auf Service- oder Repository-Layer
  • B) Nur @Cacheable
  • C) @Entity auf dem Repository-Interface
  • D) @OneToMany auf der Methode
Antwort & Erklärung

Richtige Antwort: A

Custom modifying queries müssen mit @Modifying annotiert sein und innerhalb einer Transaction laufen, damit Persistence Context und DB konsistent bleiben. Spring Data erwartet typischerweise @Transactional für Write-Operations an der Service-Grenze.

Warum die anderen Optionen falsch sind:

  • B) @Cacheable steuert Caching, nicht DML-Ausführungssemantik.
  • C) Repository-Interfaces sind keine JPA-Entities.
  • D) Relationship-Mapping-Annotationen gelten nicht für Repository-Query-Methoden.

Merksatz: „Bulk-JPQL-Updates → @Modifying und umgebende Transaction."

Weiterlernen: Buchkapitel

Frage 40​

Ein Batch-Job lädt Tausende Entities, modifiziert wenige Felder pro Zeile und leidet unter Memory-Wachstum.

Welche EntityManager-Operationen helfen, Persistence-Context-Wachstum während der Schleife zu begrenzen?

  • A) merge() vor jedem Read
  • B) detach() auf dem Transaction Manager
  • C) flush() periodisch und clear(), um managed Entities zu detachen
  • D) Nur getReference() ohne flush
Antwort & Erklärung

Richtige Antwort: C

Lange Schleifen akkumulieren managed Entities im Persistence Context. Periodisches flush() schreibt pending Changes, clear() detacht managed Instanzen, damit Memory nicht unbounded wächst.

Warum die anderen Optionen falsch sind:

  • A) Blind merge bei jedem Read erhöht managed-Entity-Count statt ihn zu kontrollieren.
  • B) detach() gehört zu EntityManager auf Entities; Transaction Manager ist nicht der Persistence Context.
  • D) getReference() vermeidet sofortiges Laden, löst aber Context-Wachstum für geladene Entities nicht von selbst.

Merksatz: „Große Batch-Schleifen → periodisches flush() und clear() auf EntityManager."

Weiterlernen: Buchkapitel

Frage 41​

Was ist der Default-Fetch-Type für eine @OneToMany-Assoziation in JPA?

  • A) EAGER
  • B) LAZY
  • C) IMMEDIATE
  • D) Nur SUBSELECT
Antwort & Erklärung

Richtige Antwort: B

JPA defaulted @OneToMany und @ManyToMany Collections auf LAZY Fetching. @ManyToOne und @OneToOne defaulten auf EAGER — eine häufige Prüfungsfalle bei N+1 oder unerwarteten Joins.

Warum die anderen Optionen falsch sind:

  • A) EAGER ist der Default für single-valued @ManyToOne, nicht Collections.
  • C) IMMEDIATE ist kein Standard-JPA-Fetch-Type-Name.
  • D) SUBSELECT ist ein optionaler Fetch-Mode, nicht der Default-Fetch-Type.

Merksatz: „Collections default LAZY; Many-to-One default EAGER."

Weiterlernen: Buchkapitel

Frage 42​

Service A ohne Transaction ruft Service B mit @Transactional(propagation = REQUIRED) auf.

Welches Transaction-Verhalten tritt auf, wenn Bs Methode läuft?

  • A) B läuft immer ohne Transaction
  • B) B erzeugt eine brandneue Transaction, die committed, bevor A weitermacht
  • C) B joined As existierende Transaction nur, wenn A auch transactional ist
  • D) B startet eine neue transaktionale Grenze, weil REQUIRED eine erzeugt, wenn keine existiert
Antwort & Erklärung

Richtige Antwort: D

REQUIRED nimmt an der aktuellen Transaction teil, wenn vorhanden; sonst erzeugt es eine neue. Weil A non-transactional ist, beginnt und committed B seine eigene Transaction für die Dauer des proxied Calls.

Warum die anderen Optionen falsch sind:

  • A) REQUIRED läuft nicht non-transactional, wenn keine existierende Transaction da ist; es erzeugt eine.
  • B) Die Transaction dauert für Bs Methodenausführung, ist aber nicht unabhängig von den hier beschriebenen REQUIRED-Regel-Semantiken.
  • C) A hat keine Transaction zum Joinen, also kann B As Transaction nicht joinen.

Merksatz: „REQUIRED = existierender Tx joinen oder neuen erzeugen, wenn abwesend."

Weiterlernen: Buchkapitel

Frage 43​

Eine Entity enthält @Version private Long version. Zwei Transactions updaten dieselbe Zeile concurrent. Was sollte der Verlierer erwarten?


@Entity
class Product {
    @Version
    private Long version;
}
  • A) OptimisticLockException oder ähnlicher Optimistic-Locking-Failure
  • B) Automatischer Retry durch Spring Data ohne Fehler
  • C) Stilles Überschreiben nur der Version-Spalte
  • D) Sofortiger DB-Deadlock bei jedem Update
Antwort & Erklärung

Richtige Antwort: A

@Version aktiviert Optimistic Locking. Das UPDATE enthält die Version-Prädikat; wenn null Rows matchen, weil eine andere Transaction die Version inkrementiert hat, wirft der Persistence Provider OptimisticLockException.

Warum die anderen Optionen falsch sind:

  • B) Spring Data retried concurrent optimistic failures nicht still standardmäßig.
  • C) Die verlierende Transaction schlägt fehl statt managed State still zu überschreiben.
  • D) Optimistic Locking vermeidet lang gehaltene pessimistic Locks; Deadlock ist nicht garantiertes Ergebnis.

Merksatz: „@Version-Mismatch → OptimisticLockException bei konfliktierendem Update."

Weiterlernen: Buchkapitel

Frage 44​

Eine neue Customer-Entity mit null id wird an customerRepository.save(customer) übergeben.

Was macht save() für eine neue Entity in typischer Spring-Data-JPA-Nutzung?

  • A) Führt immer nur ein UPDATE-Statement aus
  • B) Wirft IllegalArgumentException, weil id null ist
  • C) Nutzt persist-Semantik zum INSERT und Zuweisung der generierten id
  • D) Detacht die Entity ohne DB-Interaktion
Antwort & Erklärung

Richtige Antwort: C

Spring Data JPA save() delegiert an EntityManager persist oder merge basierend auf Entity-State. Eine neue Entity mit null id wird persisted, was INSERT und Population generierter Identifier verursacht.

Warum die anderen Optionen falsch sind:

  • A) UPDATE tritt für existierende detached oder managed Entities mit Identifiern auf, nicht brand-new null-id Entities.
  • B) Null id ist erwartet für neue Entities und triggert nicht von selbst IllegalArgumentException.
  • D) save() interagiert mit dem Persistence Context; es detacht nicht nur.

Merksatz: „save() auf neuer null-id Entity → persist und INSERT."

Weiterlernen: Buchkapitel

Frage 45​

In Spring Security 6 mit Servlet-basierter Spring-Boot-App — welcher Bean definiert die HTTP-Security-Filter-Chain?


@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    public ??? securityFilterChain(HttpSecurity http) throws Exception { }
}
  • A) Nur FilterRegistrationBean ohne SecurityFilterChain
  • B) Eine @Bean-Methode, die SecurityFilterChain zurückgibt
  • C) HttpSecurity als Singleton ohne Chain zu bauen
  • D) Ausschließlich WebMvcConfigurer-Adapter
Antwort & Erklärung

Richtige Antwort: B

Modernes Spring Security konfiguriert die Servlet-Filter-Chain durch Exposing eines SecurityFilterChain-Beans, meist aus einem HttpSecurity-Builder in einer @Configuration-Klasse. Das ersetzt den älteren WebSecurityConfigurerAdapter-Stil.

Warum die anderen Optionen falsch sind:

  • A) FilterRegistrationBean kann Filter registrieren, ersetzt aber nicht SecurityFilterChain-basierte Security-Konfiguration.
  • C) HttpSecurity ist ein Builder; du musst build() aufrufen, um den SecurityFilterChain-Bean zu produzieren.
  • D) WebMvcConfigurer customisiert MVC, nicht Security-Filter-Chain-Ordering und Authorization-Regeln.

Merksatz: „Servlet-Security in Boot 3 → @Bean SecurityFilterChain aus HttpSecurity."

Weiterlernen: Buchkapitel

Frage 46​

User-Passwörter müssen gehasht in der DB gespeichert und beim Login verifiziert werden.

Welcher PasswordEncoder ist die empfohlene Default-Wahl in Spring Security?

  • A) NoOpPasswordEncoder für Lesbarkeit
  • B) PlaintextPasswordEncoder
  • C) Md5PasswordEncoder
  • D) BCryptPasswordEncoder
Antwort & Erklärung

Richtige Antwort: D

BCryptPasswordEncoder ist der empfohlene adaptive Hashing-Encoder für sichere Passwort-Speicherung. Legacy-Plaintext- oder schwache Hash-Encoder existieren für Migration, dürfen aber nicht für neue Systeme genutzt werden.

Warum die anderen Optionen falsch sind:

  • A) NoOpPasswordEncoder speichert Passwörter im Klartext und ist unsicher.
  • B) Plaintext-Speicherung ist für Produktions-Authentifizierung nicht akzeptabel.
  • C) MD5 ist für Passwort-Hashing in modernen Threat Models ungeeignet.

Merksatz: „Passwörter mit BCryptPasswordEncoder speichern, nicht Plaintext oder MD5."

Weiterlernen: Buchkapitel

Frage 47​

Method Security soll deleteOrder nur erlauben, wenn der Caller ROLE_ADMIN hat. Welche Annotation drückt das auf der Service-Methode aus?


@Service
public class OrderAdminService {
    public void deleteOrder(Long id) { }
}
  • A) @PreAuthorize("hasRole('ADMIN')")
  • B) @PermitAll
  • C) @RolesAllowed nur von Servlet API auf Controllern
  • D) @Transactional(readOnly = true)
Antwort & Erklärung

Richtige Antwort: A

@PreAuthorize mit hasRole prüft Authorities bei Methodeninvocation, wenn Method Security via @EnableMethodSecurity aktiviert ist. hasRole prefixiert ROLE_ automatisch für Rollennamen.

Warum die anderen Optionen falsch sind:

  • B) @PermitAll erlaubt uneingeschränkten Zugriff — Gegenteil der Anforderung.
  • C) @RolesAllowed kann in manchen Setups funktionieren, aber die Spring-native expression-basierte Wahl hier ist @PreAuthorize auf der Service-Methode.
  • D) Transaction readOnly regiert Persistence-Verhalten, nicht Autorisierung.

Merksatz: „Method-Level-Rollen → @PreAuthorize("hasRole('ADMIN')")."

Weiterlernen: Buchkapitel

Frage 48​

Eine stateless REST-API nutzt JWT-Bearer-Tokens und hat keinen Browser-Form-Login.

Was ist eine übliche CSRF-Konfiguration für diese API?

  • A) CSRF aktiviert lassen und Synchronizer-Token auf jedem GET verlangen
  • B) Nur Session-Erstellung deaktivieren, aber CSRF-Token-Repository für POST obligatorisch
  • C) CSRF-Schutz deaktivieren, weil Browser keine Cookie-basierte Session-Auth submitten
  • D) formLogin und logout parallel mit JWT aktivieren
Antwort & Erklärung

Richtige Antwort: C

CSRF schützt Cookie-basierte Session-Authentifizierung in Browsern. Stateless JWT-APIs ohne browser-automatische Credential-Submission deaktivieren CSRF häufig, während geschützte Endpoints trotzdem Authentifizierung erzwingen.

Warum die anderen Optionen falsch sind:

  • A) GET-Requests sollten keine CSRF-Tokens tragen; CSRF für Token-APIs ist meist unnötiger Overhead.
  • B) CSRF-Token-Repositories zielen auf Session-Cookie-Form-Posts, nicht Bearer-Token-Clients.
  • D) formLogin ist ein session-orientiertes Muster und kollidiert mit purem stateless JWT-Design.

Merksatz: „Stateless JWT-APIs deaktivieren CSRF oft; Cookie-Sessions brauchen CSRF."

Weiterlernen: Buchkapitel

Frage 49​

In HttpSecurity authorizeHttpRequests-Konfiguration — was bewirkt requestMatchers("/public/**").permitAll()?

  • A) Verlangt ROLE_ADMIN für diese Pfade
  • B) Erlaubt unauthentifizierten Zugriff auf gematchte Pfade
  • C) Deaktiviert die gesamte Security-Filter-Chain
  • D) Verschlüsselt Responses für diese Pfade
Antwort & Erklärung

Richtige Antwort: B

permitAll gewährt Zugriff ohne Authentifizierung für gematchte Requests. Andere Matcher können trotzdem Authentifizierung verlangen, und die Filter-Chain läuft weiter.

Warum die anderen Optionen falsch sind:

  • A) permitAll ist das Gegenteil von admin-only Authorization.
  • C) Security-Filter laufen weiter; nur Authorization-Anforderungen werden für diese Pfade gelockert.
  • D) Authorization-Regeln führen keine Response-Verschlüsselung aus.

Merksatz: „permitAll = ohne Authentifizierung zugänglich für gematchte URLs."

Weiterlernen: Buchkapitel

Frage 50​

Beim Login muss Spring Security User-Details und Granted Authorities aus einer Datenbank laden.

Welchen Extension Point solltest du implementieren?

  • A) HttpMessageConverter
  • B) BeanPostProcessor
  • C) FilterChainProxy direkt in Controllern
  • D) UserDetailsService
Antwort & Erklärung

Richtige Antwort: D

UserDetailsService lädt user-spezifische Daten während Authentifizierung. DaoAuthenticationProvider kombiniert präsentierte Credentials mit UserDetails und PasswordEncoder für Authentifizierungserfolg.

Warum die anderen Optionen falsch sind:

  • A) HttpMessageConverter handhabt HTTP-Bodies, nicht Security-Principal-Loading.
  • B) BeanPostProcessor customisiert Bean-Initialisierung, nicht Authentication-Data-Retrieval.
  • C) Controller sollten FilterChainProxy nicht implementieren; Security bleibt in der Filter-Chain-Konfiguration.

Merksatz: „User für Authentifizierung laden → UserDetailsService implementieren."

Weiterlernen: Buchkapitel

Frage 51​

Du willst einen @RestController isoliert mit MockMvc testen, ohne den vollen Application Context zu laden. Welcher Test-Slice ist passend?

  • A) @WebMvcTest(controllers = InvoiceController.class)
  • B) @SpringBootTest mit RANDOM_PORT
  • C) @DataJpaTest
  • D) Nur @SpringBootConfiguration
Antwort & Erklärung

Richtige Antwort: A

@WebMvcTest auto-konfiguriert Spring-MVC-Infrastruktur und MockMvc und limitiert Component Scanning auf Web-Layer-Beans relevant für die spezifizierten Controller. Service- und Repository-Beans werden nicht geladen, außer via @Import oder @MockBean bereitgestellt.

Warum die anderen Optionen falsch sind:

  • B) Volle Boot-Tests starten den gesamten Context und embedded Server, nicht Controller-Isolation.
  • C) @DataJpaTest zielt auf Persistence-Komponenten, nicht MVC-Controller.
  • D) @SpringBootConfiguration allein liefert nicht den MVC-Test-Slice oder MockMvc-Setup.

Merksatz: „Nur-Controller-MockMvc-Tests → @WebMvcTest mit gezielten Controllern."

Weiterlernen: Buchkapitel

Frage 52​

@WebMvcTest lädt InvoiceController, aber InvoiceController hängt von InvoiceService ab, der simuliert werden muss.

Welche Annotation fügt einen Mockito-Mock von InvoiceService in den gesliced Test Context ein?

  • A) @Mock auf einem Feld ohne Spring-Integration
  • B) @Autowired auf manuell new-ed Service
  • C) @MockBean InvoiceService invoiceService;
  • D) @SpyBean nur auf dem Controller
Antwort & Erklärung

Richtige Antwort: C

@MockBean sagt Spring Boot Test Support, einen Mockito-Mock als Bean in den Application Context zu legen — essentiell in Slice-Tests, wo der echte Collaborator nicht im Classpath-Scan ist.

Warum die anderen Optionen falsch sind:

  • A) Plain @Mock erzeugt ein Mockito-Objekt, das nicht im Spring-Test-Context für Injection in den Controller registriert ist.
  • B) Manuelle Konstruktion umgeht Slice-Context-Wiring.
  • D) @SpyBean wrappt einen echten Bean; der Service-Bean fehlt im Slice und sollte gemockt, nicht gespied werden.

Merksatz: „Fehlender Collaborator in Slice-Tests → @MockBean im Test-Context."

Weiterlernen: Buchkapitel

Frage 53​

Ein Integrationstest muss die volle Spring-Boot-Anwendung auf einem zufälligen freien Port starten, um RestClient gegen echte Servlet-Listener zu testen. Welche Konfiguration gilt?

  • A) @WebMvcTest
  • B) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
  • C) @JsonTest
  • D) Nur @ExtendWith(MockitoExtension.class)
Antwort & Erklärung

Richtige Antwort: B

@SpringBootTest mit RANDOM_PORT startet den kompletten Application Context und bindet den Webserver an einen zufälligen Port — echte End-to-End-HTTP-Integrationstests.

Warum die anderen Optionen falsch sind:

  • A) @WebMvcTest startet keinen echten Listening-Port für die volle Anwendung.
  • C) @JsonTest sliced nur JSON-Mapping-Support.
  • D) MockitoExtension liefert Unit-Test-Mocks ohne Spring-Context oder HTTP-Port-Binding.

Merksatz: „Volle App auf Random Port → @SpringBootTest(RANDOM_PORT)."

Weiterlernen: Buchkapitel

Frage 54​

Ein Entwickler will JPA-Repositories gegen eine In-Memory-DB testen, ohne Controller oder Security zu laden.

Welche Annotation passt am besten?

  • A) @WebMvcTest
  • B) @SpringBootTest
  • C) @MockMvcTest
  • D) @DataJpaTest
Antwort & Erklärung

Richtige Antwort: D

@DataJpaTest limitiert den Context auf JPA-bezogene Beans und Repositories, nutzt standardmäßig embedded DB und schließt die meiste Web- und Security-Auto-Configuration aus, außer explizit importiert.

Warum die anderen Optionen falsch sind:

  • A) @WebMvcTest zielt auf Controller, nicht Repositories.
  • B) @SpringBootTest lädt die gesamte Anwendung — schwerer als nötig für Repository-Tests.
  • C) @MockMvcTest ist keine Standard-Spring-Boot-Test-Slice-Annotation.

Merksatz: „Repository-fokussierte JPA-Tests → @DataJpaTest-Slice."

Weiterlernen: Buchkapitel

Frage 55​

Ein @SpringBootTest braucht einen extra @Bean, der in der Produktions-Konfiguration fehlt. Wo sollten Test-only-Beans deklariert werden?

  • A) @TestConfiguration-Klasse, vom Test importiert oder entdeckt
  • B) Direkt in der Produktions-@SpringBootApplication-Klasse
  • C) Nur in der static main-Methode
  • D) In application.properties als Key-Value-Paare
Antwort & Erklärung

Richtige Antwort: A

@TestConfiguration liefert supplementale Beans für Tests, ohne Produktions-Konfiguration zu verschmutzen. Es kann innere static Klassen oder separate Typen sein, die von der Test-Klasse referenziert werden.

Warum die anderen Optionen falsch sind:

  • B) Produktions-Application-Sources sollten keine Test-only-Beans tragen.
  • C) main ist unrelated zu Spring-Test-Bean-Registrierung.
  • D) Properties können keine beliebigen @Bean-Factory-Methoden deklarieren.

Merksatz: „Test-only-Beans → @TestConfiguration, Produktions-Config sauber halten."

Weiterlernen: Buchkapitel

Frage 56​

Ein plain Unit-Test ohne Spring Context muss Mocks in OrderService injizieren.

Welche Mockito-Annotation erzeugt den Service und injiziert @Mock-Collaborators?

  • A) @MockBean auf OrderService
  • B) Nur @Captor
  • C) @InjectMocks OrderService orderService;
  • D) @SpringBootTest
Antwort & Erklärung

Richtige Antwort: C

@InjectMocks konstruiert die Klasse unter Test und injiziert Mockito-Mocks und Spies in Felder oder Konstruktor. @MockBean ist für Spring-Tests, nicht plain Mockito Unit-Tests.

Warum die anderen Optionen falsch sind:

  • A) @MockBean braucht einen Spring-Test-Context.
  • B) @Captor erfasst Argument-Werte für Verification; es erzeugt nicht das System under Test.
  • D) @SpringBootTest bootet den Context — unnötig für isolierten Mockito Unit-Test.

Merksatz: „Reines Mockito-Wiring → @InjectMocks plus @Mock-Felder."

Weiterlernen: Buchkapitel

Frage 57​

AuditService ist für @Transactional proxied, aber interne Methodenaufrufe überspringen Advice.

Warum startet this.save(record) aus this.archive(record) keine neue Transaction?


@Service
public class AuditService {
    @Transactional
    public void archive(Record record) {
        this.save(record);
    }
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void save(Record record) { }
}
  • A) Weil @Transactional nur auf privaten Methoden funktioniert
  • B) Weil Self-Invocation den Spring-Proxy umgeht und das Target-Objekt direkt aufruft
  • C) Weil REQUIRES_NEW innerhalb derselben Klasse ungültig ist
  • D) Weil archive() nicht public ist
Antwort & Erklärung

Richtige Antwort: B

Spring-AOP-Proxies fangen externe Aufrufe über die Proxy-Referenz ab. this.save() ist ein interner Aufruf auf dem raw Target, sodass Transaction Advice auf save() nie angewendet wird. An anderen Bean delegieren oder AopContext.currentProxy() bewusst nutzen, falls nötig.

Warum die anderen Optionen falsch sind:

  • A) @Transactional auf public Methoden wird unterstützt; Privacy ist hier nicht das Problem.
  • C) REQUIRES_NEW ist gültig; das Problem ist Proxy-Bypass via Self-Invocation.
  • D) archive()-Sichtbarkeit ist in Ordnung; Self-Invocation würde scheitern, auch wenn beide Methoden public wären.

Merksatz: „this.method() innerhalb eines Beans umgeht den Proxy — kein Advice angewendet."

Weiterlernen: Buchkapitel

Frage 58​

Eine Service-Methode soll asynchron auf einem Task Executor laufen, nachdem @EnableAsync vorhanden ist. Welche Annotation markiert die Methode?


@Service
public class EmailDispatchService {
    @???
    public void sendReceipt(String orderId) { }
}
  • A) @Scheduled
  • B) @EventListener
  • C) @Cacheable
  • D) @Async
Antwort & Erklärung

Richtige Antwort: D

@Async routet Methodenausführung über einen TaskExecutor, wenn @EnableAsync konfiguriert ist. Der Caller erhält sofort Future oder void, während die Arbeit auf einem anderen Thread weiterläuft.

Warum die anderen Optionen falsch sind:

  • A) @Scheduled läuft Tasks auf einem Timer, nicht ad-hoc async Invocation von Callern.
  • B) @EventListener reagiert auf Application Events; es ist nicht der allgemeine Async-Methoden-Marker.
  • C) @Cacheable fängt Methodenaufrufe für Cache-Speicherung ab, nicht asynchrone Ausführung.

Merksatz: „Asynchrone Methodenausführung → @Async mit @EnableAsync aktiviert."

Weiterlernen: Buchkapitel

Frage 59​

OrderPlacedEvent wird mit applicationContext.publishEvent(orderPlacedEvent) publiziert. Kein @Async auf Listenern.

Wie werden @EventListener-Methoden standardmäßig im selben Thread aufgerufen?

  • A) Synchron im Caller-Thread, bevor publishEvent zurückkehrt
  • B) Immer auf einem neuen Daemon-Thread
  • C) Nur nach JVM-Shutdown
  • D) Nur wenn @TransactionalEventListener(AFTER_COMMIT) vorhanden ist
Antwort & Erklärung

Richtige Antwort: A

Default-@EventListener-Invocation ist synchron im Publishing-Thread, außer der Listener ist async gemacht. Transactional Event Listeners fügen Phasen-Kontrolle relativ zum Transaction-Commit hinzu, sind aber ein separater Mechanismus.

Warum die anderen Optionen falsch sind:

  • B) Async-Verhalten braucht explizite @Async-Konfiguration auf Listenern oder Executor-Setup.
  • C) Events werden während normaler Application-Ausführung geliefert, nicht ausschließlich beim Shutdown.
  • D) AFTER_COMMIT ist optional für transactional listeners, nicht Default für jedes Event.

Merksatz: „Default-@EventListener läuft synchron im Publisher-Thread."

Weiterlernen: Buchkapitel

Frage 60​

@Scheduled(fixedRate = 5000) ist auf einer cleanup()-Methode platziert. Was bedeutet fixedRate?


@Component
public class TempFileCleaner {
    @Scheduled(fixedRate = 5000)
    public void cleanup() { }
}
  • A) 5000 ms nach Ende des vorherigen Runs warten, bevor erneut gestartet wird
  • B) Nur einmal 5000 ms nach Startup laufen
  • C) Alle 5000 ms ab Start jeder scheduled Execution starten
  • D) Nur ausführen, wenn ein Cron-Ausdruck matcht
Antwort & Erklärung

Richtige Antwort: C

fixedRate plant die nächste Execution basierend auf Startzeit der Invocations — alle 5000 ms in diesem Beispiel. fixedDelay misst ab Completion des vorherigen Runs — eine andere Scheduling-Semantik-Falle.

Warum die anderen Optionen falsch sind:

  • A) Warten nach Completion beschreibt fixedDelay, nicht fixedRate.
  • B) fixedRate wiederholt im Intervall; es ist kein einzelner delayed One-Shot, außer anders konfiguriert.
  • D) Cron-Scheduling nutzt Cron-Ausdrücke, nicht fixedRate-Millisekunden.

Merksatz: „fixedRate = Intervall ab Start; fixedDelay = Pause nach vorherigem Ende."

Weiterlernen: Buchkapitel

Ende von Mock Full 04 — Spring Professional (60 Fragen)